Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

[Kees Cook via Gcc-patches]

On Thu, Jul 28, 2022 at 07:26:57AM +, Richard Biener wrote:
> On Tue, 19 Jul 2022, Qing Zhao wrote:
> > [...]
> > +@cindex @code{strict_flex_array} variable attribute
> > +@item strict_flex_array (@var{level})
> > +The @code{strict_flex_array} attribute should be attached to the trailing
> > +array field of a structure.  It specifies the level of strictness of
> > +treating the trailing array field of a structure as a flexible array
> > +member. @var{level} must be an integer betwen 0 to 3.
> > +
> > +@var{level}=0 is the least strict level, all trailing arrays of structures
> > +are treated as flexible array members. @var{level}=3 is the strictest 
> > level,
> > +only when the trailing array is declared as a flexible array member per C99
> > +standard onwards ([]), it is treated as a flexible array member.
> 
> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
> -std=c89?  How for -std=gnu89?

To me, it makes sense that either c99 is required (most sane to me)
or it would disable flexible arrays entirely (seems an unlikely combo to
be useful).

> 
> > +
> > +There are two more levels in between 0 and 3, which are provided to support
> > +older codes that use GCC zero-length array extension ([0]) or one-size 
> > array
> > +as flexible array member ([1]):
> > +When @var{level} is 1, the trailing array is treated as a flexible array 
> > member
> > +when it is declared as either "[]", "[0]", or "[1]";
> > +When @var{level} is 2, the trailing array is treated as a flexible array 
> > member
> > +when it is declared as either "[]", or "[0]".
> 
> Given the above does adding level 2 make sense given that [0] is a GNU
> extension?

Level 1 removes the general "all trailing arrays are flex arrays" logic, but
allows the 2 common "historical" fake flex array styles ("[1]" and "[0]").
Level 2 additionally removes the "[1]" style.
Level 3 additionally removes the "[0]" style.

I don't understand how "[0]" being a GNU extension matters here for
level 2 -- it's dropping "[1]". And for level 3, the point is to defang
the GNU extension of "[0]" to no longer mean "flexible array", and
instead only mean "zero sized member" (as if it were something like
"struct { } no_size;").

Note that for the Linux kernel, we only care about level 3, but could
make do with level 2. We need to purge all the "fake" flexible array usage
so we can start building a sane set of behaviors around array bounds
that are reliably introspectable.


As a related bit of feature creep, it would be great to expose something
like __builtin_has_flex_array_p() so FORTIFY could do a better job
filtering __builtin_object_size() information.

Given:

struct inside {
int foo;
int bar;
unsigned long items[];
};

struct outside {
int a;
int b;
struct inside inner;
};

The follow properties are seen within, for example:

void stuff(struct outside *outer, struct inside *inner)
{
...
}

__builtin_object_size(>inner, 1) == 8
__builtin_object_size(inner, 1) == -1

(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832)

So things like FORTIFY misfire on >inner, as it's _not_ actually
8 bytes -- it has a potential trailing flex array.

If it could be introspected better, FORTIFY could check for the flex
array. For example, instead of using the inconsistent __bos(ptr, 1) for
finding member sizes, it could do something like:

#define __member_size(ptr)  \
(__builtin_has_flex_array_p(ptr) ? -1 : \
 __builtin_object_size(ptr, 1))

-- 
Kees Cook

[PATCH v2] LoongArch: Define the macro ASM_PREFERRED_EH_DATA_FORMAT by checking the assembler's support for eh_frame encoding.

[Lulu Cheng]

The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is as 
follows:

 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
-  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)

Use the following tests to describe the effect of modifying this macro on the 
generated
assembly code：

#include 
#include 

using namespace std;
int main()
{

　　try {
　　throw 1;
　　}
　　catch (int i)
　　{
cout << i << endl;
　　}
}

The main comparisons related to the eh_frame section are as follows：

　　 OLD  
  NEW
.LFB1997 = .  |  .LFB1780 = .   

   
  .cfi_startproc  |  
.cfi_startproc
  .cfi_personality 0x80,DW.ref.__gxx_personality_v0   |  
.cfi_personality 0x9b,DW.ref.__gxx_personality_v0   
  
  .cfi_lsda 0,.LLSDA1997  |  
.cfi_lsda 0x1b,.LLSDA1780

If the assembly file generated by the new gcc is compiled with the binutils of 
version 2.38, the
following error will be reported:
test.s:74: Error: invalid or unsupported encoding in .cfi_personality
test.s:75: Error: invalid or unsupported encoding in .cfi_lsda

So I think I should judge whether binutils supports this encoding when gcc is 
configured, and then choose how to define
macro ASM_PREFERRED_EH_DATA_FORMAT.





.eh_frame DW_EH_PE_pcrel encoding format is not supported by gas <= 2.39.
Check if the assembler support DW_EH_PE_PCREL encoding and define .eh_frame
encoding type.

gcc/ChangeLog:

* config.in: Regenerate.
* config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
Select the value of the macro definition according to whether
HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT is defined.
* configure: Regenerate.
* configure.ac: Reinstate HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT test.
---
 gcc/config.in|  8 +++-
 gcc/config/loongarch/loongarch.h |  5 +
 gcc/configure| 34 
 gcc/configure.ac |  8 
 4 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/gcc/config.in b/gcc/config.in
index 16bb963b45b..413b2bd36cb 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -404,13 +404,19 @@
 #endif
 
 
+/* Define if your assembler supports eh_frame pcrel encoding. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT
+#endif
+
+
 /* Define if your assembler supports the R_PPC64_ENTRY relocation. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_ENTRY_MARKERS
 #endif
 
 
-/* Define if your assembler supports explicit relocations. */
+/* Define if your assembler supports explicit relocation. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_EXPLICIT_RELOCS
 #endif
diff --git a/gcc/config/loongarch/loongarch.h b/gcc/config/loongarch/loongarch.h
index 89a5bd728fe..8b1288961e4 100644
--- a/gcc/config/loongarch/loongarch.h
+++ b/gcc/config/loongarch/loongarch.h
@@ -1127,8 +1127,13 @@ struct GTY (()) machine_function
 };
 #endif
 
+#ifdef HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT
+#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
+#else
 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
   (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+#endif
 
 /* Do emit .note.GNU-stack by default.  */
 #ifndef NEED_INDICATE_EXEC_STACK
diff --git a/gcc/configure b/gcc/configure
index 7eb9479ae8e..05efa5b01ef 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28836,6 +28836,40 @@ if test $gcc_cv_as_loongarch_explicit_relocs = yes; 
then
 
 $as_echo "#define HAVE_AS_EXPLICIT_RELOCS 1" >>confdefs.h
 
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for eh_frame 
pcrel encoding support" >&5
+$as_echo_n "checking assembler for eh_frame pcrel encoding support... " >&6; }
+if ${gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support=no
+  if test x$gcc_cv_as != x; then
+$as_echo '.cfi_startproc
+   .cfi_personality 0x9b,a
+   .cfi_lsda 0x1b,b
+   .cfi_endproc' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; 

Re: [PATCH v1] LoongArch: Define the macro ASM_PREFERRED_EH_DATA_FORMAT by checking the assembler's support for eh_frame encoding.

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-07-29 at 11:51 +0800, Lulu Cheng wrote:
> > > gcc/ChangeLog:
> > > 
> > > * config.in: Regenerate.
> > > * config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
> > > Select the value of the macro definition according to whether
> > > HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT is defined.
> > > * configure: Regenerate.
> > > * configure.ac: Reinstate HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT 
> > > test.

> > To me it looks a little strange to list regenerated config.in &
> > configure before configure.ac.  But maybe I'm wrong here if a
> > lexicographical order is preferred...

> This information is generated by me through the git gcc-commit-mklog command,
> then I didn't move the sequence.

I have no objection then.

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

Re: [PATCH v1] LoongArch: Define the macro ASM_PREFERRED_EH_DATA_FORMAT by checking the assembler's support for eh_frame encoding.

[Lulu Cheng]

在 2022/7/29 上午11:18, Xi Ruoyao 写道:

On Fri, 2022-07-29 at 10:43 +0800, Lulu Cheng wrote:


.eh_frame DW_EH_PE_pcrel encoding format is not supported by gas <= 2.39.
Check if the assembler support DW_EH_PE_PCREL encoding and define .eh_frame
encoding type.

gcc/ChangeLog:

 * config.in: Regenerate.
 * config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
 Select the value of the macro definition according to whether
 HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT is defined.
 * configure: Regenerate.
 * configure.ac: Reinstate HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT test.

To me it looks a little strange to list regenerated config.in &
configure before configure.ac.  But maybe I'm wrong here if a
lexicographical order is preferred...


This information is generated by me through the git gcc-commit-mklog 
command, then I didn't move the sequence.




/* snip */


+    gcc_GAS_CHECK_FEATURE([eh_frame pcrel encoding support],
+  gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support,,
+  [.LFB1780 = .
+   .cfi_startproc
+   .cfi_personality 0x9b,DW.ref.__gxx_personality_v0
+   .cfi_lsda 0x1b,.LLSDA1780
+   .cfi_endproc],,

I think the conftest content can be simplified to:

 .cfi_startproc
 .cfi_personality 0x9b,a
 .cfi_lsda 0x1b,b
 .cfi_endproc


This one looks more concise, I'll change it

Re: [PATCH v1] LoongArch: Define the macro ASM_PREFERRED_EH_DATA_FORMAT by checking the assembler's support for eh_frame encoding.

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-07-29 at 10:43 +0800, Lulu Cheng wrote:

> .eh_frame DW_EH_PE_pcrel encoding format is not supported by gas <= 2.39.
> Check if the assembler support DW_EH_PE_PCREL encoding and define .eh_frame
> encoding type.
> 
> gcc/ChangeLog:
> 
> * config.in: Regenerate.
> * config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
> Select the value of the macro definition according to whether
> HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT is defined.
> * configure: Regenerate.
> * configure.ac: Reinstate HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT 
> test.

To me it looks a little strange to list regenerated config.in &
configure before configure.ac.  But maybe I'm wrong here if a
lexicographical order is preferred...

/* snip */

> +    gcc_GAS_CHECK_FEATURE([eh_frame pcrel encoding support],
> +  gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support,,
> +  [.LFB1780 = .
> +   .cfi_startproc
> +   .cfi_personality 0x9b,DW.ref.__gxx_personality_v0
> +   .cfi_lsda 0x1b,.LLSDA1780
> +   .cfi_endproc],,

I think the conftest content can be simplified to:

.cfi_startproc
.cfi_personality 0x9b,a
.cfi_lsda 0x1b,b
.cfi_endproc


> +  [AC_DEFINE(HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT, 1,
> + [Define if your assembler supports eh_frame pcrel encoding.])])
>  ;;
>  s390*-*-*)
>  gcc_GAS_CHECK_FEATURE([.gnu_attribute support],

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

[PATCH v1] LoongArch: Define the macro ASM_PREFERRED_EH_DATA_FORMAT by checking the assembler's support for eh_frame encoding.

[Lulu Cheng]

The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is as 
follows:

 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
-  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)

Use the following tests to describe the effect of modifying this macro on the 
generated
assembly code：

#include 
#include 

using namespace std;
int main()
{

　　try {
　　throw 1;
　　}
　　catch (int i)
　　{
cout << i << endl;
　　}
}

The main comparisons related to the eh_frame section are as follows：

　　 OLD  
  NEW
.LFB1997 = .  |  .LFB1780 = .   

   
  .cfi_startproc  |  
.cfi_startproc
  .cfi_personality 0x80,DW.ref.__gxx_personality_v0   |  
.cfi_personality 0x9b,DW.ref.__gxx_personality_v0   
  
  .cfi_lsda 0,.LLSDA1997  |  
.cfi_lsda 0x1b,.LLSDA1780

If the assembly file generated by the new gcc is compiled with the binutils of 
version 2.38, the
following error will be reported:
test.s:74: Error: invalid or unsupported encoding in .cfi_personality
test.s:75: Error: invalid or unsupported encoding in .cfi_lsda

So I think I should judge whether binutils supports this encoding when gcc is 
configured, and then choose how to define
macro ASM_PREFERRED_EH_DATA_FORMAT.





.eh_frame DW_EH_PE_pcrel encoding format is not supported by gas <= 2.39.
Check if the assembler support DW_EH_PE_PCREL encoding and define .eh_frame
encoding type.

gcc/ChangeLog:

* config.in: Regenerate.
* config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
Select the value of the macro definition according to whether
HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT is defined.
* configure: Regenerate.
* configure.ac: Reinstate HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT test.
---
 gcc/config.in|  8 +++-
 gcc/config/loongarch/loongarch.h |  5 +
 gcc/configure| 35 
 gcc/configure.ac |  9 
 4 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/gcc/config.in b/gcc/config.in
index 16bb963b45b..413b2bd36cb 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -404,13 +404,19 @@
 #endif
 
 
+/* Define if your assembler supports eh_frame pcrel encoding. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT
+#endif
+
+
 /* Define if your assembler supports the R_PPC64_ENTRY relocation. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_ENTRY_MARKERS
 #endif
 
 
-/* Define if your assembler supports explicit relocations. */
+/* Define if your assembler supports explicit relocation. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_EXPLICIT_RELOCS
 #endif
diff --git a/gcc/config/loongarch/loongarch.h b/gcc/config/loongarch/loongarch.h
index 89a5bd728fe..8b1288961e4 100644
--- a/gcc/config/loongarch/loongarch.h
+++ b/gcc/config/loongarch/loongarch.h
@@ -1127,8 +1127,13 @@ struct GTY (()) machine_function
 };
 #endif
 
+#ifdef HAVE_AS_EH_FRAME_PCREL_ENCODING_SUPPORT
+#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
+#else
 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
   (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+#endif
 
 /* Do emit .note.GNU-stack by default.  */
 #ifndef NEED_INDICATE_EXEC_STACK
diff --git a/gcc/configure b/gcc/configure
index 7eb9479ae8e..1e1a264b92a 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28836,6 +28836,41 @@ if test $gcc_cv_as_loongarch_explicit_relocs = yes; 
then
 
 $as_echo "#define HAVE_AS_EXPLICIT_RELOCS 1" >>confdefs.h
 
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for eh_frame 
pcrel encoding support" >&5
+$as_echo_n "checking assembler for eh_frame pcrel encoding support... " >&6; }
+if ${gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_loongarch_eh_frame_pcrel_encoding_support=no
+  if test x$gcc_cv_as != x; then
+$as_echo '.LFB1780 = .
+   .cfi_startproc
+   .cfi_personality 0x9b,DW.ref.__gxx_personality_v0
+   .cfi_lsda 0x1b,.LLSDA1780
+   .cfi_endproc' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo 

[x86 PATCH] Support logical shifts by (some) integer constants in TImode STV.

[Roger Sayle]

This patch improves TImode STV by adding support for logical shifts by
integer constants that are multiples of 8.  For the test case:

__int128 a, b;
void foo() { a = b << 16; }

on x86_64, gcc -O2 currently generates:

movqb(%rip), %rax
movqb+8(%rip), %rdx
shldq   $16, %rax, %rdx
salq$16, %rax
movq%rax, a(%rip)
movq%rdx, a+8(%rip)
ret

with this patch we now generate:

movdqa  b(%rip), %xmm0
pslldq  $2, %xmm0
movaps  %xmm0, a(%rip)
ret

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check. both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-07-28  Roger Sayle  

gcc/ChangeLog
* config/i386/i386-features.cc (compute_convert_gain): Add gain
for converting suitable TImode shift to a V1TImode shift.
(timode_scalar_chain::convert_insn): Add support for converting
suitable ASHIFT and LSHIFTRT.
(timode_scalar_to_vector_candidate_p): Consider logical shifts
by integer constants that are multiples of 8 to be candidates.

gcc/testsuite/ChangeLog
* gcc.target/i386/sse4_1-stv-7.c: New test case.


Thanks again,
Roger
--

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index aa5de71..e1e0645 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1221,6 +1221,13 @@ timode_scalar_chain::compute_convert_gain ()
igain = COSTS_N_INSNS (1);
  break;
 
+   case ASHIFT:
+   case LSHIFTRT:
+ /* For logical shifts by constant multiples of 8. */
+ igain = optimize_insn_for_size_p () ? COSTS_N_BYTES (4)
+ : COSTS_N_INSNS (1);
+ break;
+
default:
  break;
}
@@ -1462,6 +1469,12 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
   src = convert_compare (XEXP (src, 0), XEXP (src, 1), insn);
   break;
 
+case ASHIFT:
+case LSHIFTRT:
+  convert_op ( (src, 0), insn);
+  PUT_MODE (src, V1TImode);
+  break;
+
 default:
   gcc_unreachable ();
 }
@@ -1796,6 +1809,14 @@ timode_scalar_to_vector_candidate_p (rtx_insn *insn)
 case NOT:
   return REG_P (XEXP (src, 0)) || timode_mem_p (XEXP (src, 0));
 
+case ASHIFT:
+case LSHIFTRT:
+  /* Handle logical shifts by integer constants between 0 and 120
+that are multiples of 8.  */
+  return REG_P (XEXP (src, 0))
+&& CONST_INT_P (XEXP (src, 1))
+&& (INTVAL (XEXP (src, 1)) & ~0x78) == 0;
+
 default:
   return false;
 }
diff --git a/gcc/testsuite/gcc.target/i386/sse4_1-stv-7.c 
b/gcc/testsuite/gcc.target/i386/sse4_1-stv-7.c
new file mode 100644
index 000..b0d5fce
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/sse4_1-stv-7.c
@@ -0,0 +1,18 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2 -msse4.1 -mstv -mno-stackrealign" } */
+
+unsigned __int128 a;
+unsigned __int128 b;
+
+void foo()
+{
+  a = b << 16;
+}
+
+void bar()
+{
+  a = b >> 16;
+}
+
+/* { dg-final { scan-assembler "pslldq" } } */
+/* { dg-final { scan-assembler "psrldq" } } */

[committed] analyzer: expand the comment in region.h

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1879-g9cac6811cf0d6c.

gcc/analyzer/ChangeLog:
* region.h: Add notes to the comment describing the region
class hierarchy.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region.h | 52 ++-
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/gcc/analyzer/region.h b/gcc/analyzer/region.h
index fd0d4a05cc9..70f0f93111d 100644
--- a/gcc/analyzer/region.h
+++ b/gcc/analyzer/region.h
@@ -72,27 +72,37 @@ enum region_kind
 
region
  space_region
-   frame_region (RK_FRAME)
-   globals_region (RK_GLOBALS)
-   code_region (RK_CODE)
-   stack_region (RK_STACK)
-   heap_region (RK_HEAP)
- root_region (RK_ROOT)
- function_region (RK_FUNCTION)
- label_region (RK_LABEL)
- symbolic_region (RK_SYMBOLIC)
- decl_region (RK_DECL),
- field_region (RK_FIELD)
- element_region (RK_ELEMENT)
- offset_region (RK_OFFSET)
- sized_region (RK_SIZED)
- cast_region (RK_CAST)
- heap_allocated_region (RK_HEAP_ALLOCATED)
- alloca_region (RK_ALLOCA)
- string_region (RK_STRING)
- bit_range_region (RK_BIT_RANGE)
- var_arg_region (RK_VAR_ARG)
- unknown_region (RK_UNKNOWN).  */
+   frame_region (RK_FRAME): a function frame on the stack
+   globals_region (RK_GLOBALS): holds globals variables (data and bss)
+   code_region (RK_CODE): represents the code segment, containing functions
+   stack_region (RK_STACK): a stack, containing all stack frames
+   heap_region (RK_HEAP): the heap, containing heap_allocated_regions
+ root_region (RK_ROOT): the top-level region
+ function_region (RK_FUNCTION): the code for a particular function
+ label_region (RK_LABEL): a particular label within a function
+ symbolic_region (RK_SYMBOLIC): dereferencing a symbolic pointer
+ decl_region (RK_DECL): the memory occupied by a particular global, local,
+   or SSA name
+ field_region (RK_FIELD): the memory occupied by a field within a struct
+ or union
+ element_region (RK_ELEMENT): an element within an array
+ offset_region (RK_OFFSET): a byte-offset within another region, for
+   handling pointer arithmetic as a region
+ sized_region (RK_SIZED): a subregion of symbolic size (in bytes)
+ within its parent
+ cast_region (RK_CAST): a region that views another region using a
+   different type
+ heap_allocated_region (RK_HEAP_ALLOCATED): an untyped region dynamically
+   allocated on the heap via
+   "malloc" or similar
+ alloca_region (RK_ALLOCA): an untyped region dynamically allocated on the
+   stack via "alloca"
+ string_region (RK_STRING): a region for a STRING_CST
+ bit_range_region (RK_BIT_RANGE): a region for a specific range of bits
+ within another region
+ var_arg_region (RK_VAR_ARG): a region for the N-th vararg within a
+ frame_region for a variadic call
+ unknown_region (RK_UNKNOWN): for handling unimplemented tree codes.  */
 
 /* Abstract base class for representing ways of accessing chunks of memory.
 
-- 
2.26.3

[committed] analyzer: new warning: -Wanalyzer-putenv-of-auto-var [PR105893]

[David Malcolm via Gcc-patches]

This patch implements a new -fanalyzer warning:
  -Wanalyzer-putenv-of-auto-var
which complains about stack pointers passed to putenv(3) calls, as
per SEI CERT C Coding Standard rule POS34-C ("Do not call putenv() with
a pointer to an automatic variable as the argument").

For example, given:

#include 
#include 

void test_arr (void)
{
  char arr[] = "NAME=VALUE";
  putenv (arr);
}

it emits:

demo.c: In function ‘test_arr’:
demo.c:7:3: warning: ‘putenv’ on a pointer to automatic variable ‘arr’ 
[POS34-C] [-Wanalyzer-putenv-of-auto-var]
7 |   putenv (arr);
  |   ^~~~
  ‘test_arr’: event 1
|
|7 |   putenv (arr);
|  |   ^~~~
|  |   |
|  |   (1) ‘putenv’ on a pointer to automatic variable ‘arr’
|
demo.c:6:8: note: ‘arr’ declared on stack here
6 |   char arr[] = "NAME=VALUE";
  |^~~
demo.c:7:3: note: perhaps use ‘setenv’ rather than ‘putenv’
7 |   putenv (arr);
  |   ^~~~

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1881-g872693eebb6b88.

gcc/analyzer/ChangeLog:
PR analyzer/105893
* analyzer.opt (Wanalyzer-putenv-of-auto-var): New.
* region-model-impl-calls.cc (class putenv_of_auto_var): New.
(region_model::impl_call_putenv): New.
* region-model.cc (region_model::on_call_pre): Handle putenv.
* region-model.h (region_model::impl_call_putenv): New decl.

gcc/ChangeLog:
PR analyzer/105893
* doc/invoke.texi: Add -Wanalyzer-putenv-of-auto-var.

gcc/testsuite/ChangeLog:
PR analyzer/105893
* gcc.dg/analyzer/putenv-1.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/analyzer.opt|   4 +
 gcc/analyzer/region-model-impl-calls.cc  | 117 +++
 gcc/analyzer/region-model.cc |   6 ++
 gcc/analyzer/region-model.h  |   1 +
 gcc/doc/invoke.texi  |  14 +++
 gcc/testsuite/gcc.dg/analyzer/putenv-1.c | 109 +
 6 files changed, 251 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/putenv-1.c

diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index 5021376b6fb..808ff36ac54 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -126,6 +126,10 @@ Wanalyzer-null-dereference
 Common Var(warn_analyzer_null_dereference) Init(1) Warning
 Warn about code paths in which a NULL pointer is dereferenced.
 
+Wanalyzer-putenv-of-auto-var
+Common Var(warn_analyzer_putenv_of_auto_var) Init(1) Warning
+Warn about code paths in which an on-stack buffer is passed to putenv.
+
 Wanalyzer-shift-count-negative
 Common Var(warn_analyzer_shift_count_negative) Init(1) Warning
 Warn about code paths in which a shift with negative count is attempted.
diff --git a/gcc/analyzer/region-model-impl-calls.cc 
b/gcc/analyzer/region-model-impl-calls.cc
index 8c38e9206fa..3f821ff07e1 100644
--- a/gcc/analyzer/region-model-impl-calls.cc
+++ b/gcc/analyzer/region-model-impl-calls.cc
@@ -549,6 +549,123 @@ region_model::impl_call_memset (const call_details )
   fill_region (sized_dest_reg, fill_value_u8);
 }
 
+/* A subclass of pending_diagnostic for complaining about 'putenv'
+   called on an auto var.  */
+
+class putenv_of_auto_var
+: public pending_diagnostic_subclass
+{
+public:
+  putenv_of_auto_var (tree fndecl, const region *reg)
+  : m_fndecl (fndecl), m_reg (reg),
+m_var_decl (reg->get_base_region ()->maybe_get_decl ())
+  {
+  }
+
+  const char *get_kind () const final override
+  {
+return "putenv_of_auto_var";
+  }
+
+  bool operator== (const putenv_of_auto_var ) const
+  {
+return (m_fndecl == other.m_fndecl
+   && m_reg == other.m_reg
+   && same_tree_p (m_var_decl, other.m_var_decl));
+  }
+
+  int get_controlling_option () const final override
+  {
+return OPT_Wanalyzer_putenv_of_auto_var;
+  }
+
+  bool emit (rich_location *rich_loc) final override
+  {
+auto_diagnostic_group d;
+diagnostic_metadata m;
+
+/* SEI CERT C Coding Standard: "POS34-C. Do not call putenv() with a
+   pointer to an automatic variable as the argument".  */
+diagnostic_metadata::precanned_rule
+  rule ("POS34-C", "https://wiki.sei.cmu.edu/confluence/x/6NYxBQ;);
+m.add_rule (rule);
+
+bool warned;
+if (m_var_decl)
+  warned = warning_meta (rich_loc, m, get_controlling_option (),
+"%qE on a pointer to automatic variable %qE",
+m_fndecl, m_var_decl);
+else
+  warned = warning_meta (rich_loc, m, get_controlling_option (),
+"%qE on a pointer to an on-stack buffer",
+m_fndecl);
+if (warned)
+  {
+   if (m_var_decl)
+ inform (DECL_SOURCE_LOCATION (m_var_decl),
+ "%qE declared on stack here", m_var_decl);
+   inform (rich_loc->get_loc (), "perhaps use %qs rather than %qE",
+   

[committed] analyzer: add CWE identifier URLs to docs

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1880-g9c60338061bf36.

gcc/analyzer/ChangeLog:
* sm-malloc.cc (free_of_non_heap::emit): Add comment about CWE.
* sm-taint.cc (tainted_size::emit): Likewise.

gcc/ChangeLog:
* doc/invoke.texi (-fdiagnostics-show-cwe): Use uref rather than
url.
(Static Analyzer Options): Likewise.  Add urefs for all of the
warnings that have associated CWE identifiers.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/sm-malloc.cc |  1 +
 gcc/analyzer/sm-taint.cc  |  1 +
 gcc/doc/invoke.texi   | 50 +++
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/gcc/analyzer/sm-malloc.cc b/gcc/analyzer/sm-malloc.cc
index 608aceb1abe..73c549fa081 100644
--- a/gcc/analyzer/sm-malloc.cc
+++ b/gcc/analyzer/sm-malloc.cc
@@ -1300,6 +1300,7 @@ public:
 
   bool emit (rich_location *rich_loc) final override
   {
+/* "CWE-401: Missing Release of Memory after Effective Lifetime".  */
 diagnostic_metadata m;
 m.add_cwe (401);
 if (m_arg)
diff --git a/gcc/analyzer/sm-taint.cc b/gcc/analyzer/sm-taint.cc
index 51bfe06835d..549373b322d 100644
--- a/gcc/analyzer/sm-taint.cc
+++ b/gcc/analyzer/sm-taint.cc
@@ -435,6 +435,7 @@ public:
 
   bool emit (rich_location *rich_loc) override
   {
+/* "CWE-129: Improper Validation of Array Index".  */
 diagnostic_metadata m;
 m.add_cwe (129);
 if (m_arg)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9a3f2d14c5a..5c6fdef16e3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5045,7 +5045,7 @@ the vertical bars and the ``char *'' and ``long int'' 
text).
 @opindex fno-diagnostics-show-cwe
 @opindex fdiagnostics-show-cwe
 Diagnostic messages can optionally have an associated
-@url{https://cwe.mitre.org/index.html, CWE} identifier.
+@uref{https://cwe.mitre.org/index.html, CWE} identifier.
 GCC itself only provides such metadata for some of the @option{-fanalyzer}
 diagnostics.  GCC plugins may also provide diagnostics with such metadata.
 By default, if this information is present, it will be printed with
@@ -9808,7 +9808,7 @@ This diagnostic warns for paths through the code in which 
a pointer to
 a buffer is assigned to point at a buffer with a size that is not a
 multiple of @code{sizeof (*pointer)}.
 
-See @url{https://cwe.mitre.org/data/definitions/131.html, CWE-131: Incorrect 
Calculation of Buffer Size}.
+See @uref{https://cwe.mitre.org/data/definitions/131.html, CWE-131: Incorrect 
Calculation of Buffer Size}.
 
 @item -Wno-analyzer-double-fclose
 @opindex Wanalyzer-double-fclose
@@ -9819,6 +9819,8 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 This diagnostic warns for paths through the code in which a @code{FILE *}
 can have @code{fclose} called on it more than once.
 
+See @uref{https://cwe.mitre.org/data/definitions/1341.html, CWE-1341: Multiple 
Releases of Same Resource or Handle}.
+
 @item -Wno-analyzer-double-free
 @opindex Wanalyzer-double-free
 @opindex Wno-analyzer-double-free
@@ -9829,6 +9831,8 @@ This diagnostic warns for paths through the code in which 
a pointer
 can have a deallocator called on it more than once, either @code{free},
 or a deallocator referenced by attribute @code{malloc}.
 
+See @uref{https://cwe.mitre.org/data/definitions/415.html, CWE-415: Double 
Free}.
+
 @item -Wno-analyzer-exposure-through-output-file
 @opindex Wanalyzer-exposure-through-output-file
 @opindex Wno-analyzer-exposure-through-output-file
@@ -9840,6 +9844,8 @@ This diagnostic warns for paths through the code in which 
a
 security-sensitive value is written to an output file
 (such as writing a password to a log file).
 
+See @uref{https://cwe.mitre.org/data/definitions/532.html, CWE-532: 
Information Exposure Through Log Files}.
+
 @item -Wno-analyzer-fd-access-mode-mismatch
 @opindex Wanalyzer-fd-access-mode-mismatch
 @opindex Wno-analyzer-fd-access-mode-mismatch
@@ -9866,6 +9872,8 @@ to disable it.
 This diagnostic warns for paths through code in which a
 file descriptor can be closed more than once.
 
+See @uref{https://cwe.mitre.org/data/definitions/1341.html, CWE-1341: Multiple 
Releases of Same Resource or Handle}.
+
 @item -Wno-analyzer-fd-leak
 @opindex Wanalyzer-fd-leak
 @opindex Wno-analyzer-fd-leak
@@ -9876,6 +9884,8 @@ to disable it.
 This diagnostic warns for paths through code in which an
 open file descriptor is leaked.
 
+See @uref{https://cwe.mitre.org/data/definitions/775.html, CWE-775: Missing 
Release of File Descriptor or Handle after Effective Lifetime}.
+
 @item -Wno-analyzer-fd-use-after-close
 @opindex Wanalyzer-fd-use-after-close
 @opindex Wno-analyzer-fd-use-after-close
@@ -9916,6 +9926,8 @@ to disable it.
 This diagnostic warns for paths through the code in which a
 @code{} @code{FILE *} stream object is leaked.
 
+See @uref{https://cwe.mitre.org/data/definitions/775.html, CWE-775: Missing 
Release of File 

[committed] jit: update docs to reflect .c to .cc renaming

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1878-gb8ce0c4361c267.

gcc/jit/ChangeLog:
* docs/internals/index.rst: Remove reference to ".c" extensions
of source files.

Signed-off-by: David Malcolm 
---
 gcc/jit/docs/internals/index.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/jit/docs/internals/index.rst b/gcc/jit/docs/internals/index.rst
index 9200181bba4..092380c8f20 100644
--- a/gcc/jit/docs/internals/index.rst
+++ b/gcc/jit/docs/internals/index.rst
@@ -291,8 +291,7 @@ For example:
 Overview of code structure
 --
 
-The library is implemented in C++.  The source files have the ``.c``
-extension for legacy reasons.
+The library is implemented in C++.
 
 * ``libgccjit.cc`` implements the API entrypoints.  It performs error
   checking, then calls into classes of the gcc::jit::recording namespace
-- 
2.26.3

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Mikael Morin]

Hello,

Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :

ok, I have thought about your comments in the review process,
and played with the Cray compiler.  Attached is a refined version
of the patch that now rejects in addition these cases for which there
are no possible related pointer assignments with bounds remapping:

   ASSOCIATED (scalar, array) ! impossible, cannot remap bounds
   ASSOCIATED (array, scalar) ! a scalar is not simply contiguous

In principle, it could make sense to construct a one-sized array pointer 
(of any rank) pointing to a scalar, but I agree that if we follow the 
rules of the standard to the letter, it should be rejected (and we do 
reject such a pointer assignment).

So, with this case eliminated, this patch looks good to me as is.

Regarding Toon’s suggestion to ask the fortran committee, it sounds 
sensible.  I propose to prepare something tomorrow.

[PATCH] Fortran: detect blanks within literal constants in free-form mode [PR92805]

[Harald Anlauf via Gcc-patches]

Dear all,

in free-form mode, blanks are significant, so they cannot appear
in literal constants, especially not before or after the "_" that
separates the literal and the kind specifier.

The initial patch from Steve addressed numerical literals, which
I completed by adjusting the parsing of string literals.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From f58c00f5792d6ec0037696df733857580a029ba9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 28 Jul 2022 22:07:02 +0200
Subject: [PATCH] Fortran: detect blanks within literal constants in free-form
 mode [PR92805]

gcc/fortran/ChangeLog:

	PR fortran/92805
	* primary.cc (get_kind): Do not skip over blanks in free-form mode.
	(match_string_constant): Likewise.

gcc/testsuite/ChangeLog:

	PR fortran/92805
	* gfortran.dg/literal_constants.f: New test.
	* gfortran.dg/literal_constants.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/primary.cc| 18 --
 gcc/testsuite/gfortran.dg/literal_constants.f | 20 
 .../gfortran.dg/literal_constants.f90 | 24 +++
 3 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/literal_constants.f
 create mode 100644 gcc/testsuite/gfortran.dg/literal_constants.f90

diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 3f01f67cd49..9d200cdf65b 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -92,14 +92,21 @@ get_kind (int *is_iso_c)
 {
   int kind;
   match m;
+  char c;

   *is_iso_c = 0;

+  c = gfc_peek_ascii_char ();
+  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+return -2;
+
   if (gfc_match_char ('_') != MATCH_YES)
 return -2;

-  m = match_kind_param (, is_iso_c);
-  if (m == MATCH_NO)
+  m = MATCH_NO;
+  c = gfc_peek_ascii_char ();
+  if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+  || (m = match_kind_param (, is_iso_c)) == MATCH_NO)
 gfc_error ("Missing kind-parameter at %C");

   return (m == MATCH_YES) ? kind : -1;
@@ -1074,6 +1081,9 @@ match_string_constant (gfc_expr **result)
   c = gfc_next_char ();
 }

+  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+goto no_match;
+
   if (c == ' ')
 {
   gfc_gobble_whitespace ();
@@ -1083,6 +1093,10 @@ match_string_constant (gfc_expr **result)
   if (c != '_')
 goto no_match;

+  c = gfc_peek_ascii_char ();
+  if (gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+goto no_match;
+
   gfc_gobble_whitespace ();

   c = gfc_next_char ();
diff --git a/gcc/testsuite/gfortran.dg/literal_constants.f b/gcc/testsuite/gfortran.dg/literal_constants.f
new file mode 100644
index 000..4d1f1b7eb4c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/literal_constants.f
@@ -0,0 +1,20 @@
+! { dg-do compile }
+! { dg-options "-ffixed-form" }
+! PR fortran/92805 - blanks within literal constants in fixed-form mode
+
+  implicit none
+  integer, parameter :: ck = kind ("a")  ! default character kind
+  integer, parameter :: rk = kind (1.0)  ! default real kind
+  print *, 1_"abc"
+  print *, 1 _"abc"
+  print *, 1_ "abc"
+  print *, ck_"a"
+  print *, ck _"ab"
+  print *, ck_ "ab"
+  print *, 3.1415_4
+  print *, 3.1415 _4
+  print *, 3.1415_ 4
+  print *, 3.1415_rk
+  print *, 3.1415 _rk
+  print *, 3.1415_ rk
+  end
diff --git a/gcc/testsuite/gfortran.dg/literal_constants.f90 b/gcc/testsuite/gfortran.dg/literal_constants.f90
new file mode 100644
index 000..f8908f9ad76
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/literal_constants.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+! { dg-options "-ffree-form" }
+! PR fortran/92805 - blanks within literal constants in free-form mode
+
+  implicit none
+  integer, parameter :: ck = kind ("a")  ! default character kind
+  integer, parameter :: rk = kind (1.0)  ! default real kind
+  print *, 1_"abc"
+  print *, 1 _"abc"   ! { dg-error "Syntax error" }
+  print *, 1_ "abc"   ! { dg-error "Missing kind-parameter" }
+  print *, 1 _ "abc"  ! { dg-error "Syntax error" }
+  print *, ck_"a"
+  print *, ck _"ab"   ! { dg-error "Syntax error" }
+  print *, ck_ "ab"   ! { dg-error "Syntax error" }
+  print *, ck _ "ab"  ! { dg-error "Syntax error" }
+  print *, 3.1415_4
+  print *, 3.1415 _4  ! { dg-error "Syntax error" }
+  print *, 3.1415_ 4  ! { dg-error "Missing kind-parameter" }
+  print *, 3.1415 _ 4 ! { dg-error "Syntax error" }
+  print *, 3.1415_rk
+  print *, 3.1415 _rk ! { dg-error "Syntax error" }
+  print *, 3.1415_ rk ! { dg-error "Missing kind-parameter" }
+  print *, 3.141 _ rk ! { dg-error "Syntax error" }
+  end
--
2.35.3

[PATCH] RISC-V/testsuite: Restrict remaining `fmin'/`fmax' tests to hard float

[Maciej W. Rozycki]

Complement commit 7915f6551343 ("RISC-V/testsuite: constraint some of 
tests to hard_float") and also restrict the remaining `fmin'/`fmax' 
tests to hard-float test configurations.

gcc/testsuite/
* gcc.target/riscv/fmax-snan.c: Add `dg-require-effective-target 
hard_float'.
* gcc.target/riscv/fmaxf-snan.c: Likewise.
* gcc.target/riscv/fmin-snan.c: Likewise.
* gcc.target/riscv/fminf-snan.c: Likewise.
---
 gcc/testsuite/gcc.target/riscv/fmax-snan.c  |1 +
 gcc/testsuite/gcc.target/riscv/fmaxf-snan.c |1 +
 gcc/testsuite/gcc.target/riscv/fmin-snan.c  |1 +
 gcc/testsuite/gcc.target/riscv/fminf-snan.c |1 +
 4 files changed, 4 insertions(+)

gcc-riscv-fmin-fmax-test-hard-float.diff
Index: gcc/gcc/testsuite/gcc.target/riscv/fmax-snan.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/fmax-snan.c
+++ gcc/gcc/testsuite/gcc.target/riscv/fmax-snan.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target hard_float } */
 /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" } 
*/
 
 double
Index: gcc/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
+++ gcc/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target hard_float } */
 /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" } 
*/
 
 float
Index: gcc/gcc/testsuite/gcc.target/riscv/fmin-snan.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/fmin-snan.c
+++ gcc/gcc/testsuite/gcc.target/riscv/fmin-snan.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target hard_float } */
 /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" } 
*/
 
 double
Index: gcc/gcc/testsuite/gcc.target/riscv/fminf-snan.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/fminf-snan.c
+++ gcc/gcc/testsuite/gcc.target/riscv/fminf-snan.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target hard_float } */
 /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" } 
*/
 
 float

[PATCH] libgo: Explicitly define SYS_timer_settime for 32-bit musl targets

[soeren--- via Gcc-patches]

From: Sören Tempel 

On 32-bit systems, musl only defines SYS_timer_settime32 not
SYS_timer_settime. This causes the following compilation error:

os_linux.go:251:30: error: reference to undefined name 
'_SYS_timer_settime'
  251 | return int32(syscall(_SYS_timer_settime, 
uintptr(timerid), uintptr(flags), uintptr(unsafe.Pointer(new)), 
uintptr(unsafe.Pointer(old)), 0, 0))
  |  ^

This commit fixes this error by "aliasing" SYS_timer_settime to
SYS_timer_settime32 if the latter is defined. This is also what
musl does internally [1].

[1]: 
https://git.musl-libc.org/cgit/musl/tree/src/internal/syscall.h?h=v1.2.3#n212
---
 libgo/sysinfo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libgo/sysinfo.c b/libgo/sysinfo.c
index fc021099..6848fba5 100644
--- a/libgo/sysinfo.c
+++ b/libgo/sysinfo.c
@@ -354,6 +354,12 @@ enum {
 };
 #endif
 
+// musl libc does not have SYS_timer_settime on 32-bit platforms
+// but defines SYS_timer_settime32 instead, alias accordingly.
+#ifdef SYS_timer_settime32
+#define SYS_timer_settime SYS_timer_settime32
+#endif
+
 #if defined(HAVE_LOFF_T)
 // loff_t can be defined as a macro; for -fgo-dump-spec make sure we
 // see a typedef.

Re: [x86_64 PATCH] PR target/106450: Tweak timode_remove_non_convertible_regs.

[H.J. Lu via Gcc-patches]

On Thu, Jul 28, 2022 at 9:43 AM Roger Sayle  wrote:
>
>
> This patch resolves PR target/106450, some more fall-out from more
> aggressive TImode scalar-to-vector (STV) optimizations.  I continue
> to be caught out by how far TImode STV has diverged from DImode/SImode
> STV, and therefore requires additional (unexpected) tweaking.  Many
> thanks to H.J. Lu for pointing out timode_remove_non_convertible_regs
> needs to be extended to handle XOR (and other new operations).
>
> Unhelpfully the comment above this function states that it's the TImode
> version of "remove_non_convertible_regs", which doesn't exist anymore,
> so I've resurrected an explanatory comment from the git history.
> By refactoring the checks for hard regs and already "marked" regs
> into timode_check_non_convertible_regs itself, all its callers are
> simplified.  This patch then uses GET_RTX_CLASS to generically handle
> unary and binary operations, calling timode_check_non_convertible_regs
> on each TImode register operand in the single_set's SET_SRC.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?
>
>
> 2022-07-28  Roger Sayle  
>
> gcc/ChangeLog
> PR target/106450
> * config/i386/i386-features.cc (timode_check_non_convertible_regs):
> Do nothing if REGNO is set in the REGS bitmap, or is a hard reg.
> (timode_remove_non_convertible_regs): Update comment.
> Call timode_check_non_convertible_regs on all register operands
> of supported (binary and unary) operations.

Should we use

df_ref ref;
FOR_EACH_INSN_USE (ref, insn)
   if (!DF_REF_REG_MEM_P (ref))
 timode_check_non_convertible_regs (candidates, regs,
  DF_REF_REGNO (ref));

to check each use?

> gcc/testsuite/ChangeLog
> PR target/106450
> * gcc.target/i386/pr106450.c: New test case.
>
>
> Thanks in advance,
> Roger
> --
>


-- 
H.J.

cselib: add function to check if SET is redundant [PR106187]

[Richard Earnshaw via Gcc-patches]

[resend with correct subject line]

A SET operation that writes memory may have the same value as an earlier 
store but if the alias sets of the new and earlier store do not conflict 
then the set is not truly redundant.  This can happen, for example, if 
objects of different types share a stack slot.


To fix this we define a new function in cselib that first checks for 
equality and if that is successful then finds the earlier store in the 
value history and checks the alias sets.


The routine is used in two places elsewhere in the compiler.  Firstly
in cfgcleanup and secondly in postreload.

gcc/ChangeLog:
* cselib.h (cselib_redundant_set_p): Declare.
* cselib.cc: Include alias.h
(cselib_redundant_set_p): New function.
* cfgcleanup.cc: (mark_effect): Use cselib_redundant_set_p instead
of rtx_equal_for_cselib_p.
* postreload.c (reload_cse_simplify): Use cselib_redundant_set_p.
(reload_cse_noop_set_p): Delete.
diff --git a/gcc/cfgcleanup.cc b/gcc/cfgcleanup.cc
index 18047da7b24..a8b0139bb4d 100644
--- a/gcc/cfgcleanup.cc
+++ b/gcc/cfgcleanup.cc
@@ -208,7 +208,7 @@ mark_effect (rtx exp, regset nonequal)
   return false;
 
 case SET:
-  if (rtx_equal_for_cselib_p (SET_DEST (exp), SET_SRC (exp)))
+  if (cselib_redundant_set_p (exp))
 	return false;
   dest = SET_DEST (exp);
   if (dest == pc_rtx)
diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 6769beeeaf8..fcfd8340a4a 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dumpfile.h"
 #include "cselib.h"
 #include "function-abi.h"
+#include "alias.h"
 
 /* A list of cselib_val structures.  */
 struct elt_list
@@ -1157,6 +1158,75 @@ rtx_equal_for_cselib_1 (rtx x, rtx y, machine_mode memmode, int depth)
   return 1;
 }
 
+/* Wrapper for rtx_equal_for_cselib_p to determine whether a SET is
+   truly redundant, taking into account aliasing information.  */
+bool
+cselib_redundant_set_p (rtx set)
+{
+  gcc_assert (GET_CODE (set) == SET);
+  rtx dest = SET_DEST (set);
+  if (cselib_reg_set_mode (dest) != GET_MODE (dest))
+return false;
+
+  if (!rtx_equal_for_cselib_p (dest, SET_SRC (set)))
+return false;
+
+  while (GET_CODE (dest) == SUBREG
+	 || GET_CODE (dest) == ZERO_EXTRACT
+	 || GET_CODE (dest) == STRICT_LOW_PART)
+dest = XEXP (dest, 0);
+
+  if (!flag_strict_aliasing || !MEM_P (dest))
+return true;
+
+  /* For a store we need to check that suppressing it will not change
+ the effective alias set.  */
+  rtx dest_addr = XEXP (dest, 0);
+
+  /* Lookup the equivalents to the dest.  This is more likely to succeed
+ than looking up the equivalents to the source (for example, when the
+ src is some form of constant).  */
+  cselib_val *src_val = cselib_lookup (SET_DEST (set),
+   GET_MODE (SET_DEST (set)),
+   0, VOIDmode);
+
+  if (src_val)
+{
+  /* Walk the list of source equivalents to find the MEM accessing the same
+	 location.  */
+  for (elt_loc_list *l = src_val->locs; l; l = l->next)
+	{
+	  rtx src_equiv = l->loc;
+	  while (GET_CODE (src_equiv) == SUBREG
+		 || GET_CODE (src_equiv) == ZERO_EXTRACT
+		 || GET_CODE (src_equiv) == STRICT_LOW_PART)
+	src_equiv = XEXP (src_equiv, 0);
+
+	  if (MEM_P (src_equiv))
+	{
+	  /* Match the MEMs by comparing the addresses.  */
+	  if (rtx_equal_for_cselib_1 (dest_addr, XEXP (src_equiv, 0),
+	  GET_MODE (dest), 0))
+		return alias_sets_conflict_p (MEM_ALIAS_SET (dest),
+	  MEM_ALIAS_SET (src_equiv));
+	}
+	}
+}
+
+  /* We failed to find a recorded value in the cselib history, so try the
+ source of this set.  */
+  rtx src = SET_SRC (set);
+  while (GET_CODE (src) == SUBREG)
+src = XEXP (src, 0);
+
+  if (MEM_P (src) && rtx_equal_for_cselib_1 (dest_addr, XEXP (src, 0),
+	 GET_MODE (dest), 0))
+return alias_sets_conflict_p (MEM_ALIAS_SET (dest),
+  MEM_ALIAS_SET (src));
+
+  return false;
+}
+
 /* Helper function for cselib_hash_rtx.  Arguments like for cselib_hash_rtx,
except that it hashes (plus:P x c).  */
 
diff --git a/gcc/cselib.h b/gcc/cselib.h
index 9ae65e6459e..b0905053ea5 100644
--- a/gcc/cselib.h
+++ b/gcc/cselib.h
@@ -83,6 +83,7 @@ extern void cselib_process_insn (rtx_insn *);
 extern bool fp_setter_insn (rtx_insn *);
 extern machine_mode cselib_reg_set_mode (const_rtx);
 extern int rtx_equal_for_cselib_1 (rtx, rtx, machine_mode, int);
+extern bool cselib_redundant_set_p (rtx);
 extern int references_value_p (const_rtx, int);
 extern rtx cselib_expand_value_rtx (rtx, bitmap, int);
 typedef rtx (*cselib_expand_callback)(rtx, bitmap, int, void *);
diff --git a/gcc/postreload.cc b/gcc/postreload.cc
index d1c99fe6dc9..41f61d32648 100644
--- a/gcc/postreload.cc
+++ b/gcc/postreload.cc
@@ -43,7 +43,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "function-abi.h"
 #include "rtl-iter.h"
 
-static int reload_cse_noop_set_p 

http://pdtlreviewboard.cambridge.arm.com/r/16099/

[Richard Earnshaw via Gcc-patches]

A SET operation that writes memory may have the same value as an earlier 
store but if the alias sets of the new and earlier store do not conflict 
then the set is not truly redundant.  This can happen, for example, if 
objects of different types share a stack slot.


To fix this we define a new function in cselib that first checks for 
equality and if that is successful then finds the earlier store in the 
value history and checks the alias sets.


The routine is used in two places elsewhere in the compiler.  Firstly
in cfgcleanup and secondly in postreload.

gcc/ChangeLog:
* cselib.h (cselib_redundant_set_p): Declare.
* cselib.cc: Include alias.h
(cselib_redundant_set_p): New function.
* cfgcleanup.cc: (mark_effect): Use cselib_redundant_set_p instead
of rtx_equal_for_cselib_p.
* postreload.c (reload_cse_simplify): Use cselib_redundant_set_p.
(reload_cse_noop_set_p): Delete.
diff --git a/gcc/cfgcleanup.cc b/gcc/cfgcleanup.cc
index 18047da7b24..a8b0139bb4d 100644
--- a/gcc/cfgcleanup.cc
+++ b/gcc/cfgcleanup.cc
@@ -208,7 +208,7 @@ mark_effect (rtx exp, regset nonequal)
   return false;
 
 case SET:
-  if (rtx_equal_for_cselib_p (SET_DEST (exp), SET_SRC (exp)))
+  if (cselib_redundant_set_p (exp))
 	return false;
   dest = SET_DEST (exp);
   if (dest == pc_rtx)
diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 6769beeeaf8..fcfd8340a4a 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dumpfile.h"
 #include "cselib.h"
 #include "function-abi.h"
+#include "alias.h"
 
 /* A list of cselib_val structures.  */
 struct elt_list
@@ -1157,6 +1158,75 @@ rtx_equal_for_cselib_1 (rtx x, rtx y, machine_mode memmode, int depth)
   return 1;
 }
 
+/* Wrapper for rtx_equal_for_cselib_p to determine whether a SET is
+   truly redundant, taking into account aliasing information.  */
+bool
+cselib_redundant_set_p (rtx set)
+{
+  gcc_assert (GET_CODE (set) == SET);
+  rtx dest = SET_DEST (set);
+  if (cselib_reg_set_mode (dest) != GET_MODE (dest))
+return false;
+
+  if (!rtx_equal_for_cselib_p (dest, SET_SRC (set)))
+return false;
+
+  while (GET_CODE (dest) == SUBREG
+	 || GET_CODE (dest) == ZERO_EXTRACT
+	 || GET_CODE (dest) == STRICT_LOW_PART)
+dest = XEXP (dest, 0);
+
+  if (!flag_strict_aliasing || !MEM_P (dest))
+return true;
+
+  /* For a store we need to check that suppressing it will not change
+ the effective alias set.  */
+  rtx dest_addr = XEXP (dest, 0);
+
+  /* Lookup the equivalents to the dest.  This is more likely to succeed
+ than looking up the equivalents to the source (for example, when the
+ src is some form of constant).  */
+  cselib_val *src_val = cselib_lookup (SET_DEST (set),
+   GET_MODE (SET_DEST (set)),
+   0, VOIDmode);
+
+  if (src_val)
+{
+  /* Walk the list of source equivalents to find the MEM accessing the same
+	 location.  */
+  for (elt_loc_list *l = src_val->locs; l; l = l->next)
+	{
+	  rtx src_equiv = l->loc;
+	  while (GET_CODE (src_equiv) == SUBREG
+		 || GET_CODE (src_equiv) == ZERO_EXTRACT
+		 || GET_CODE (src_equiv) == STRICT_LOW_PART)
+	src_equiv = XEXP (src_equiv, 0);
+
+	  if (MEM_P (src_equiv))
+	{
+	  /* Match the MEMs by comparing the addresses.  */
+	  if (rtx_equal_for_cselib_1 (dest_addr, XEXP (src_equiv, 0),
+	  GET_MODE (dest), 0))
+		return alias_sets_conflict_p (MEM_ALIAS_SET (dest),
+	  MEM_ALIAS_SET (src_equiv));
+	}
+	}
+}
+
+  /* We failed to find a recorded value in the cselib history, so try the
+ source of this set.  */
+  rtx src = SET_SRC (set);
+  while (GET_CODE (src) == SUBREG)
+src = XEXP (src, 0);
+
+  if (MEM_P (src) && rtx_equal_for_cselib_1 (dest_addr, XEXP (src, 0),
+	 GET_MODE (dest), 0))
+return alias_sets_conflict_p (MEM_ALIAS_SET (dest),
+  MEM_ALIAS_SET (src));
+
+  return false;
+}
+
 /* Helper function for cselib_hash_rtx.  Arguments like for cselib_hash_rtx,
except that it hashes (plus:P x c).  */
 
diff --git a/gcc/cselib.h b/gcc/cselib.h
index 9ae65e6459e..b0905053ea5 100644
--- a/gcc/cselib.h
+++ b/gcc/cselib.h
@@ -83,6 +83,7 @@ extern void cselib_process_insn (rtx_insn *);
 extern bool fp_setter_insn (rtx_insn *);
 extern machine_mode cselib_reg_set_mode (const_rtx);
 extern int rtx_equal_for_cselib_1 (rtx, rtx, machine_mode, int);
+extern bool cselib_redundant_set_p (rtx);
 extern int references_value_p (const_rtx, int);
 extern rtx cselib_expand_value_rtx (rtx, bitmap, int);
 typedef rtx (*cselib_expand_callback)(rtx, bitmap, int, void *);
diff --git a/gcc/postreload.cc b/gcc/postreload.cc
index d1c99fe6dc9..41f61d32648 100644
--- a/gcc/postreload.cc
+++ b/gcc/postreload.cc
@@ -43,7 +43,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "function-abi.h"
 #include "rtl-iter.h"
 
-static int reload_cse_noop_set_p (rtx);
 static bool 

[x86_64 PATCH] PR target/106450: Tweak timode_remove_non_convertible_regs.

[Roger Sayle]

This patch resolves PR target/106450, some more fall-out from more
aggressive TImode scalar-to-vector (STV) optimizations.  I continue
to be caught out by how far TImode STV has diverged from DImode/SImode
STV, and therefore requires additional (unexpected) tweaking.  Many
thanks to H.J. Lu for pointing out timode_remove_non_convertible_regs
needs to be extended to handle XOR (and other new operations).

Unhelpfully the comment above this function states that it's the TImode
version of "remove_non_convertible_regs", which doesn't exist anymore,
so I've resurrected an explanatory comment from the git history.
By refactoring the checks for hard regs and already "marked" regs
into timode_check_non_convertible_regs itself, all its callers are
simplified.  This patch then uses GET_RTX_CLASS to generically handle
unary and binary operations, calling timode_check_non_convertible_regs
on each TImode register operand in the single_set's SET_SRC.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-07-28  Roger Sayle  

gcc/ChangeLog
PR target/106450
* config/i386/i386-features.cc (timode_check_non_convertible_regs):
Do nothing if REGNO is set in the REGS bitmap, or is a hard reg.
(timode_remove_non_convertible_regs): Update comment.
Call timode_check_non_convertible_regs on all register operands
of supported (binary and unary) operations.

gcc/testsuite/ChangeLog
PR target/106450
* gcc.target/i386/pr106450.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index aa5de71..2a4097c 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1808,6 +1808,11 @@ static void
 timode_check_non_convertible_regs (bitmap candidates, bitmap regs,
   unsigned int regno)
 {
+  /* Do nothing if REGNO is already in REGS or is a hard reg.  */
+  if (bitmap_bit_p (regs, regno)
+  || HARD_REGISTER_NUM_P (regno))
+return;
+
   for (df_ref def = DF_REG_DEF_CHAIN (regno);
def;
def = DF_REF_NEXT_REG (def))
@@ -1843,7 +1848,13 @@ timode_check_non_convertible_regs (bitmap candidates, 
bitmap regs,
 }
 }
 
-/* The TImode version of remove_non_convertible_regs.  */
+/* For a given bitmap of insn UIDs scans all instructions and
+   remove insn from CANDIDATES in case it has both convertible
+   and not convertible definitions.
+
+   All insns in a bitmap are conversion candidates according to
+   scalar_to_vector_candidate_p.  Currently it implies all insns
+   are single_set.  */
 
 static void
 timode_remove_non_convertible_regs (bitmap candidates)
@@ -1861,21 +1872,40 @@ timode_remove_non_convertible_regs (bitmap candidates)
rtx dest = SET_DEST (def_set);
rtx src = SET_SRC (def_set);
 
-   if ((!REG_P (dest)
-|| bitmap_bit_p (regs, REGNO (dest))
-|| HARD_REGISTER_P (dest))
-   && (!REG_P (src)
-   || bitmap_bit_p (regs, REGNO (src))
-   || HARD_REGISTER_P (src)))
- continue;
-
if (REG_P (dest))
  timode_check_non_convertible_regs (candidates, regs,
 REGNO (dest));
 
-   if (REG_P (src))
- timode_check_non_convertible_regs (candidates, regs,
-REGNO (src));
+   switch (GET_RTX_CLASS (GET_CODE (src)))
+ {
+ case RTX_OBJ:
+   if (REG_P (src))
+ timode_check_non_convertible_regs (candidates, regs,
+REGNO (src));
+   break;
+
+ case RTX_UNARY:
+   if (REG_P (XEXP (src, 0))
+   && GET_MODE (XEXP (src, 0)) == TImode)
+ timode_check_non_convertible_regs (candidates, regs,
+REGNO (XEXP (src, 0)));
+   break;
+
+ case RTX_COMM_ARITH:
+ case RTX_BIN_ARITH:
+   if (REG_P (XEXP (src, 0))
+   && GET_MODE (XEXP (src, 0)) == TImode)
+ timode_check_non_convertible_regs (candidates, regs,
+REGNO (XEXP (src, 0)));
+   if (REG_P (XEXP (src, 1))
+   && GET_MODE (XEXP (src, 1)) == TImode)
+ timode_check_non_convertible_regs (candidates, regs,
+REGNO (XEXP (src, 1)));
+   break;
+
+ default:
+   break;
+ }
   }
 
 EXECUTE_IF_SET_IN_BITMAP (regs, 0, id, bi)
diff --git a/gcc/testsuite/gcc.target/i386/pr106450.c 
b/gcc/testsuite/gcc.target/i386/pr106450.c
new file mode 100644
index 000..d16231f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr106450.c
@@ -0,0 +1,14 @@
+/* { dg-do compile { target int128 

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

[H.J. Lu via Gcc-patches]

On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva  wrote:
>
> On Jul 27, 2022, "H.J. Lu"  wrote:
>
> > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva  wrote:
>
> >> The use of @GOTOFF for locally-bound but externally-visible symbols
> >> (e.g. protected visibility) also breaks pointer identity if the
> >> canonical address ends up preempted by a PLT entry.
>
> > Here is a different fix:
>
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html
>
> Oh, thanks, I'd missed that.
>
> It doesn't seem to fix the part of the problem I quoted above, though.
> I think fixing that requires testing the visibility, to make sure the
> symbol's canonical address cannot be preempted, which may occur with
> local binding, if the symbol is protected and referenced in the main
> program, otherwise pointer identity is broken again, admittedly for a
> more obscure case, but pointer identity was the point of the PR.

The protected symbol issue isn't IFUNC specific.   The protected
symbol handling is changed in glibc 2.36 and binutils 2.39.   Only
the address of the protected symbol definition should be used as
its address.

> >> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
> >> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
>
> You may also need to do something like this bit for mvc10.c on ia32 PIE.
> Because the ifunc is called through an alias, AFAICT we don't even
> notice that the call target is (an alias to) an ifunc.  GCC's
> gotoff_operand predicate accepts it, but binutils (the linker, IIRC)
> then rejects that reference, because the named symbol is an alias to an
> ifunc.

Yes, this change is needed.

>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 



-- 
H.J.

[PATCH] c++: Fix location for -Wunused-macros [PR66290]

[Lewis Hyatt via Gcc-patches]

In C++, since all tokens are lexed from libcpp up front, diagnostics generated
by libcpp after lexing has completed do not get a valid location from libcpp
(rather, libcpp thinks they all pertain to the end of the file.) This has long
been addressed using the global variable "done_lexing", which the C++ frontend
sets at the appropriate time; when done_lexing is true, then c_cpp_diagnostic(),
which outputs libcpp's diagnostics, uses input_location instead of the wrong
libcpp location. The C++ frontend arranges that input_location will point to the
token it is currently processing, so this generally works fine. However, there
is one exception currently, which is -Wunused-macros. This gets generated at the
end of processing in cpp_finish (), since we need to wait until then to
determine whether a macro was eventually used or not. But the locations it
passes to c_cpp_diagnostic () were remembered from the original lexing and hence
they should not be overridden with input_location, which is now the one
incorrectly pointing to the end of the file.

Fixed by setting done_lexing=false again just prior to calling cpp_finish (). I
also renamed the variable from done_lexing to "override_libcpp_locations", since
it's now not strictly about lexing anymore.

There is no new testcase with this patch, since we already had an xfailed
testcase which is now fixed.

gcc/c-family/ChangeLog:

PR c++/66290
* c-common.h: Rename global done_lexing to
override_libcpp_locations.
* c-common.cc (c_cpp_diagnostic): Likewise.
* c-opts.cc (c_common_finish): Set override_libcpp_locations
(formerly done_lexing) immediately prior to calling cpp_finish ().

gcc/cp/ChangeLog:

PR c++/66290
* parser.cc (cp_lexer_new_main): Rename global done_lexing to
override_libcpp_locations.

gcc/testsuite/ChangeLog:

PR c++/66290
* c-c++-common/pragma-diag-15.c: Remove xfail for C++.
---

Notes:
Hello-

The attached patch fixes PR66290, which is about C++ diagnostics using
the wrong location for -Wunused-macros. Please let me know if it looks OK?

Bootstrap + regtest all languages on x86-64 linux looks good, no changes 
other
than the un-XFAILed testcases.

Thank you!

-Lewis

 gcc/c-family/c-common.cc| 10 ++
 gcc/c-family/c-common.h |  8 +---
 gcc/c-family/c-opts.cc  |  6 ++
 gcc/cp/parser.cc|  2 +-
 gcc/testsuite/c-c++-common/pragma-diag-15.c |  2 +-
 5 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 655c3aefee6..6e41ceb38e9 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -284,9 +284,11 @@ int c_inhibit_evaluation_warnings;
be generated.  */
 bool in_late_binary_op;
 
-/* Whether lexing has been completed, so subsequent preprocessor
-   errors should use the compiler's input_location.  */
-bool done_lexing = false;
+/* Depending on which phase of processing we are in, we may need
+   to prefer input_location to libcpp's locations.  (Specifically,
+   after the C++ lexer is done lexing tokens, but prior to calling
+   cpp_finish (), we need to do so.  */
+bool override_libcpp_locations;
 
 /* Information about how a function name is generated.  */
 struct fname_var_t
@@ -6681,7 +6683,7 @@ c_cpp_diagnostic (cpp_reader *pfile ATTRIBUTE_UNUSED,
 default:
   gcc_unreachable ();
 }
-  if (done_lexing)
+  if (override_libcpp_locations)
 richloc->set_range (0, input_location, SHOW_RANGE_WITH_CARET);
   diagnostic_set_info_translated (, msg, ap,
   richloc, dlevel);
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f9064393b4e..c06769b6f0b 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -767,10 +767,12 @@ extern int max_tinst_depth;
 
 extern int c_inhibit_evaluation_warnings;
 
-/* Whether lexing has been completed, so subsequent preprocessor
-   errors should use the compiler's input_location.  */
+/* Depending on which phase of processing we are in, we may need
+   to prefer input_location to libcpp's locations.  (Specifically,
+   after the C++ lexer is done lexing tokens, but prior to calling
+   cpp_finish (), we need to do so.  */
 
-extern bool done_lexing;
+extern bool override_libcpp_locations;
 
 /* C types are partitioned into three subsets: object, function, and
incomplete types.  */
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..4e1463689de 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1281,6 +1281,12 @@ c_common_finish (void)
 	}
 }
 
+  /* When we call cpp_finish (), it may generate some diagnostics using
+ locations it remembered from the preprocessing phase, e.g. for
+ -Wunused-macros.  So inform c_cpp_diagnostic () not to override those
+ locations with input_location, which 

Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

[Martin Liška]

On 7/28/22 15:43, Dimitrije Milosevic wrote:
> |Gentle ping, requiring someone to push the change. :)|

Sure, I can do that, but please attach output of (git format-patch) as an 
attachment
to an email. The current email has a weird format I can directly apply with git 
am.

Cheers,
Martin

Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

[Dimitrije Milosevic]

Gentle ping, requiring someone to push the change. :)

From: Dimitrije Milosevic
Sent: Monday, July 25, 2022 8:55 AM
To: gcc-patches@gcc.gnu.org 
Cc: Djordje Todorovic ; xry...@xry111.site 

Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from 
upstream 
 
2bfb0fcb51510f22723c8cdfefe [Sanitizer][MIPS] Fix stat struct size for the O32 
ABI.

Signed-off-by: Dimitrije Milosevic .

---
 .../sanitizer_common/sanitizer_platform_limits_posix.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+    SANITIZER_ANDROID
+    ? FIRST_32_SECOND_64(104, 128)
+    : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1

Re: [PATCH] doc: Clarify FENV_ACCESS pragma semantics WRT `-ftrapping-math'

[Maciej W. Rozycki]

On Wed, 27 Jul 2022, Joseph Myers wrote:

> > gcc/
> > * doc/implement-c.texi (Floating point implementation): Mention
> > `-fno-trapping-math' in the context of FENV_ACCESS pragma.
> > * doc/invoke.texi (Optimize Options): Clarify FENV_ACCESS pragma
> > implication in the descriptions of `-fno-trapping-math' and 
> > `-frounding-math'.
> 
> OK.

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

  Maciej

Re: [PING][PATCH v2] RISC-V: Split unordered FP comparisons into individual RTL insns

[Maciej W. Rozycki]

Hi Kito,

> I am convinced that is OK for now, I agree modeling fflags would be a
> rabbit hole, I tried to build a full GNU toolchain with my quick patch
> and saw many ICE during build libraries, that definitely should be a
> long-term optimization project.
> 
> Although I'm thinking if we should default -fno-trapping-math for
> RISC-V, because RISC-V didn't trap for any floating point operations,
> however I think that would be another topic.

 No need to do anything for RISC-V I believe, as Richard has mentioned 
that's been his plan for GCC 13 compiler-wide; see the discussion here:
 for 
further details.

> so you got my LGTM :)

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

  Maciej

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 2022/7/28 下午6:41, Xi Ruoyao 写道:

On Thu, 2022-07-28 at 10:59 +0800, Lulu Cheng wrote:


The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification
is

as follows:
  #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
  -  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
  +  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel |
DW_EH_PE_sdata4)

The master branch still contains:

#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
   (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)

Did you forgot to commit this change (or lost it during a rebase)?



Oh,sorry I forgot to commit to upstream.

Re: [PATCH V1] HIGH part of symbol ref is invalid for constant pool

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

Thanks a lot for your review!

> Hi!
>
> On Tue, Jul 19, 2022 at 10:30:54PM +0800, Jiufu Guo wrote:
>> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
>> test case was not added.  After more check, a testcase is added for it.
>> 
>> The high part of the symbol address is invalid for the constant pool.
>
> Invalid, how so?  Is there a PR related here?
Thanks, I just opened PR106460 for this issue.
>
> But it is not particularly useful ever, either: we do not know two
> different addresses will have the same HIGH unless we know the exact
> address, and then we don't need HIGH anyway.
>
>>  * config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
>>  Return true for HIGH code rtx.
>
>   * config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem): Return true
>   for HIGH code rtx.
>
> Please don't wrap lines early: changelog lines are 80 positions long,
> including the leading tab (which counts as eight positions).
Thanks for your suggestion!
>
>>  static bool
>>  rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
>>  {
>> -  if (GET_CODE (x) == HIGH
>> -  && GET_CODE (XEXP (x, 0)) == UNSPEC)
>> +  /* High part of a symbol ref/address can not be put into constant pool. 
>> e.g.
>> + (high:DI (symbol_ref:DI ("var")..)) or
>> + (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)
>> + (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx")) (const_int 12.  
>> */
>> +  if (GET_CODE (x) == HIGH)
>>  return true;
>
> I'm not sure the new comment is helpful at all?  Are these examples of
> where the compiler (or assembler perhaps) will choke?
I debugged this function with the source code from GCC bootstrap and
regtest, and then figured out these examples.
In the next version patch, I updated the comments a little, hope that
is more meaningful. :-)
>
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile { target powerpc*-*-* } } */
>
> Everything in gcc.target/powerpc is target powerpc* always.
Thanks! I would remove this line.
>
>> +/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
>> +/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */
>
> Ah, so there is an ICE, I see.  Please open a PR, and mention that in
> the testcase as well as in the commit message and changelog.
Thanks! I should open PR ealry :)
In the updated patch,  a testcase is named as pr106460.c, and memtioned
in commit message and changelog.
>
> I agree with what the patch does, it just needs a little more work :-)
I submitted a new version patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598980.html

Thanks in advance for any comments!

BR,
Jeff(Jiufu)

>
>
> Segher

Re: [PATCH] Add new target hook: simplify_modecc_const.

[Richard Sandiford via Gcc-patches]

Seems this thread has become a bit heated, so I'll try to proceed
with caution :-)

In the below, I'll use "X-mode const_int" to mean "a const_int that
is known from context to represent an X-mode value".  Of course,
the const_int itself always stores VOIDmode.

"Roger Sayle"  writes:
> Hi Segher,
> It's very important to distinguish the invariants that exist for the RTL
> data structures as held in memory (rtx), vs. the use of "enum rtx_code"s,
> "machine_mode"s and operands in the various processing functions
> of the middle-end.

FWIW, I agree this distinction is important, with the proviso (which
I think you were also adding) that the code never loses track of what
mode an rtx operand (stored in a variable) actually has/is being
interpreted to have.

In other words, the reason (zero_extend (const_int N)) is invalid is
not that constant integers can't be extended in principle (of course
they can).  It's invalid because we've lost track of how many bits
that N actually has.  That problem doesn't apply in contexts where
the operation is described using individual variables (rather than
a single rtx) *provided that* one of those variables says what mode
any potential const_ints actually represent.

> Yes, it's very true that RTL integer constants don't specify a mode
> (are VOIDmode), so therefore operations like ZERO_EXTEND or EQ
> don't make sense with all constant operands.  This is (one reason)
> why constant-only operands are disallowed from RTL (data structures),
> and why in APIs that perform/simplify these operations, the original
> operand mode (of the const_int(s)) must be/is always passed as a
> parameter.
>
> Hence, for say simplify_const_binary_operation, op0 and op1 can
> both be const_int, as the mode argument specifies the mode of the
> "code" operation. Likewise, in simplify_relational_operation, both
> op0 and op1 may be CONST_INT as "cmp_mode" explicitly specifies
> the mode that the operation is performed in and "mode" specifies
> the mode of the result.

And the mode argument to simplify_const_relational_operation specifies
the mode of the operands, not the mode of the result.  I.e. it specifies
the modes of op0 and op1 rather than the mode that would be attached to
the code in "(code:mode ...)" if an rtx were created with these parameters.

That confused me when I saw the patch initially.  Elsewhere in the
file "mode" tends to be the mode of the result, in cases where the
mode of the result can be different from the modes of the operands,
so using it for the mode of the operands seems a bit confusing
(not your fault of course).

I still struggle with the idea of having CC-mode const_ints though
(using the meaning of "CC-mode const_ints" above).  I realise
(compare (...) (const_int 0)) has been the norm "for ever", but here
it feels like we're also blessing non-zero CC-mode const_ints.
That raises the question of how many significant bits a CC-mode
const_int actually has.  Currently:

 ...  For historical reasons,
 the size of a CC mode is four units.

But treating CC-mode const_ints as having 32 significant bits is surely
the wrong thing to do.

So if we want to add more interpretation around CC modes, I think we
should first clean up the representation to make the set of valid values
more explicit.  (Preferably without reusing const_int for constant values,
but that's probably a losing battle :-))

Thanks,
Richard

[PATCH] middle-end/106457 - improve array_at_struct_end_p for array objects

[Richard Biener via Gcc-patches]

Array references to array objects are never at struct end.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR middle-end/106457
* tree.cc (array_at_struct_end_p): Handle array objects
specially.
---
 gcc/tree.cc | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/tree.cc b/gcc/tree.cc
index 84000dd8b69..fed1434d141 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12778,6 +12778,10 @@ array_at_struct_end_p (tree ref)
   && DECL_SIZE_UNIT (ref)
   && TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
 {
+  /* If the object itself is the array it is not at struct end.  */
+  if (DECL_P (ref_to_array))
+   return false;
+
   /* Check whether the array domain covers all of the available
  padding.  */
   poly_int64 offset;
-- 
2.35.3

[PATCH V2]HIGH part of symbol ref is invalid for constant pool[PR106460]

[Jiufu Guo via Gcc-patches]

Hi,

As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
to store into constant pool.  But actually, it indicates partial address,
which to be forced to constant memory.

In function rs6000_cannot_force_const_mem, we already return true for
"HIGH with UNSPEC" rtx.  For this function if GET_CODE (X) is HIGH, the "X"
represents the high part of a symbol ref, this function would also return
true.  Below are some examples:
(high:DI (const:DI (plus:DI (symbol_ref:DI ("xx") (const_int 12 [0xc])
(high:DI (symbol_ref:DI ("var_1")..)))

This patch updates rs6000_cannot_force_const_mem to return true for
rtx with HIGH code.

PR target/106460

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem): Return true
for HIGH code rtx.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106460.c: New test.

---
 gcc/config/rs6000/rs6000.cc   |  7 +--
 gcc/testsuite/gcc.target/powerpc/pr106460.c | 11 +++
 2 files changed, 16 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106460.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 0af2085adc0..d56832ebbfc 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9704,8 +9704,11 @@ rs6000_init_stack_protect_guard (void)
 static bool
 rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
-  if (GET_CODE (x) == HIGH
-  && GET_CODE (XEXP (x, 0)) == UNSPEC)
+  /* If GET_CODE (x) is HIGH, the 'X' represets the high part of a symbol_ref.
+ It indicates partial address,  which can not be put into a constant pool.
+ e.g.  (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)
+ (high:DI (symbol_ref:DI ("var")..)).  */
+  if (GET_CODE (x) == HIGH)
 return true;
 
   /* A TLS symbol in the TOC cannot contain a sum.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106460.c 
b/gcc/testsuite/gcc.target/powerpc/pr106460.c
new file mode 100644
index 000..ed7a994827b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106460.c
@@ -0,0 +1,11 @@
+/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
+
+/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */
+extern short var_48;
+void
+foo (double *r)
+{
+  if (var_48)
+*r = 1234.5678;
+}
+
-- 
2.17.1

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Philip Herron]

That would be brilliant if you could do that! I can spend my time
focused on splitting the front-end into patches. In the meantime,
while you work on that, I will use your patch here to disable the
target hook stuff so that the patches are buildable.

--Phil

On Thu, 28 Jul 2022 at 12:09, Thomas Schwinge  wrote:
>
> Hi Phil!
>
> On 2022-07-28T11:51:37+0100, Philip Herron  wrote:
> > I think you are right here. There are parts in
> > libstd/liballoc/libpanic which start to look for what CPU features are
> > available iirc.
>
> Aha, good.  That -- once we get there ;-) -- shall then guide us on the
> target options we implement, in addition to what we find generally
> necessary for a conforming Rust programming language implementation (as
> I'd mentioned).
>
> > libcore [...] just
> > cares about target pointer width and endienness which is more
> > generally available as macros.
>
> Right, and these are already implemented in
> 'gcc/rust/rust-session-manager.cc:Session::init'.  (..., but also should
> get some test cases added; I'll have a look at some point.)
>
> > It seems more clear now that maybe for this v1 set of patches,
> > possibly this stuff doesn't really matter right now until we compile
> > libstd which seems like a much better approach in order to review the
> > front-end code. I think i will apply your patch and revert these
> > changes for now since we have the git history for them we can look at
> > this more closely when we need it.
>
> Unless this issue is time-critical, let me offer that instead of my
> "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'",
> I'll cook up a proper patch, removing the implementations of
> 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the
> general infrastructure in place (if I find that makes sense)?
>
>
> Grüße
>  Thomas
>
>
> > On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge  
> > wrote:
> >>
> >> Hi!
> >>
> >> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
> >>  wrote:
> >> > This patch introduces a new set of interfaces to define the target info 
> >> > as
> >> > expected by the rust front-end. It takes advantage of the information
> >> > within gcc/config/target directories which gets called by the front-end
> >> > to populate rust front-end datastructures by calling into:
> >> > builtin_rust_info. This patch has been isolated to find if we are
> >> > approaching this in an idiomatic way and is compilable without the
> >> > rust-front-end code.
> >>
> >> I suppose the general approach may be fine, as is similarly implemented
> >> by other languages' front ends in GCC.
> >>
> >> > We have received many patches here which gives us the target hook info 
> >> > for
> >> > most platforms
> >>
> >> But this is all so much WIP and full of TODO notes, and has no test cases
> >> at all!, that I still don't really see much value in keeping the current
> >> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
> >> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
> >> that I've attached, we're not seeing any change in 'make check-rust'
> >> results, for example.
> >>
> >> In my opinion, the current implementation should be backed out from the
> >> main development branch (would also reduce pain in merges from GCC
> >> upstream, as mentioned before), and then be developed (quite possibly
> >> based on the current implementation) individually for all GCC
> >> configurations that we'd like to support (with 'sorry' otherwise), in a
> >> coherent way, instead of trying to guess all possible target options as
> >> done by the current implementation.  And, with all relevant test cases
> >> getting added, of course.  That is, at this time, restrict outselves to
> >> GCC configurations that we're actually supporting and testing.
> >>
> >> Have we even figured out which of those target options are actually
> >> mandated for a conforming Rust programming language implementation (that
> >> is, users would potentially rely on these)?
> >>
> >> As far as I can tell, 'rustc' defines target options here:
> >> ,
> >> and you may use 'rustc --print=cfg' to dump for the current
> >> configuration?
> >>
> >> > but getting the normal x86 done correctly will define if
> >> > the other patches are done correctly.
> >>
> >> Yes -- but I'm not sure this is it really, in its current WIPy,
> >> un-tested, un-verified form:
> >>
> >> > gcc/config/ChangeLog:
> >>
> >> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
> >> >   * dragonfly.h: define TARGET_RUST_OS_INFO
> >> >   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
> >> >   * freebsd.h: define guard for TARGET_RUST_OS_INFO
> >> >   * fuchsia.h: define TARGET_RUST_OS_INFO
> >> >   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> >> >   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> >> >   * linux-android.h: 

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Thomas Schwinge]

Hi Phil!

On 2022-07-28T11:51:37+0100, Philip Herron  wrote:
> I think you are right here. There are parts in
> libstd/liballoc/libpanic which start to look for what CPU features are
> available iirc.

Aha, good.  That -- once we get there ;-) -- shall then guide us on the
target options we implement, in addition to what we find generally
necessary for a conforming Rust programming language implementation (as
I'd mentioned).

> libcore [...] just
> cares about target pointer width and endienness which is more
> generally available as macros.

Right, and these are already implemented in
'gcc/rust/rust-session-manager.cc:Session::init'.  (..., but also should
get some test cases added; I'll have a look at some point.)

> It seems more clear now that maybe for this v1 set of patches,
> possibly this stuff doesn't really matter right now until we compile
> libstd which seems like a much better approach in order to review the
> front-end code. I think i will apply your patch and revert these
> changes for now since we have the git history for them we can look at
> this more closely when we need it.

Unless this issue is time-critical, let me offer that instead of my
"[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'",
I'll cook up a proper patch, removing the implementations of
'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the
general infrastructure in place (if I find that makes sense)?


Grüße
 Thomas


> On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge  wrote:
>>
>> Hi!
>>
>> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
>>  wrote:
>> > This patch introduces a new set of interfaces to define the target info as
>> > expected by the rust front-end. It takes advantage of the information
>> > within gcc/config/target directories which gets called by the front-end
>> > to populate rust front-end datastructures by calling into:
>> > builtin_rust_info. This patch has been isolated to find if we are
>> > approaching this in an idiomatic way and is compilable without the
>> > rust-front-end code.
>>
>> I suppose the general approach may be fine, as is similarly implemented
>> by other languages' front ends in GCC.
>>
>> > We have received many patches here which gives us the target hook info for
>> > most platforms
>>
>> But this is all so much WIP and full of TODO notes, and has no test cases
>> at all!, that I still don't really see much value in keeping the current
>> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
>> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
>> that I've attached, we're not seeing any change in 'make check-rust'
>> results, for example.
>>
>> In my opinion, the current implementation should be backed out from the
>> main development branch (would also reduce pain in merges from GCC
>> upstream, as mentioned before), and then be developed (quite possibly
>> based on the current implementation) individually for all GCC
>> configurations that we'd like to support (with 'sorry' otherwise), in a
>> coherent way, instead of trying to guess all possible target options as
>> done by the current implementation.  And, with all relevant test cases
>> getting added, of course.  That is, at this time, restrict outselves to
>> GCC configurations that we're actually supporting and testing.
>>
>> Have we even figured out which of those target options are actually
>> mandated for a conforming Rust programming language implementation (that
>> is, users would potentially rely on these)?
>>
>> As far as I can tell, 'rustc' defines target options here:
>> ,
>> and you may use 'rustc --print=cfg' to dump for the current
>> configuration?
>>
>> > but getting the normal x86 done correctly will define if
>> > the other patches are done correctly.
>>
>> Yes -- but I'm not sure this is it really, in its current WIPy,
>> un-tested, un-verified form:
>>
>> > gcc/config/ChangeLog:
>>
>> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
>> >   * dragonfly.h: define TARGET_RUST_OS_INFO
>> >   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
>> >   * freebsd.h: define guard for TARGET_RUST_OS_INFO
>> >   * fuchsia.h: define TARGET_RUST_OS_INFO
>> >   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>> >   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>> >   * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
>> >   * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
>> >   * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
>> >   * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
>> >   * phoenix.h: define TARGET_RUST_OS_INFO
>> >   * sol2.h: define TARGET_RUST_OS_INFO
>> >   * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
>> >   * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
>> >
>> > gcc/config/i386/ChangeLog:
>> >
>> > * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
>> 

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Philip Herron]

Hi Thomas,

I think you are right here. There are parts in
libstd/liballoc/libpanic which start to look for what CPU features are
available iirc. Maintaining our patches here has been becoming
difficult as of late, especially when it comes to libcore, which just
cares about target pointer width and endienness which is more
generally available as macros.

It seems more clear now that maybe for this v1 set of patches,
possibly this stuff doesn't really matter right now until we compile
libstd which seems like a much better approach in order to review the
front-end code. I think i will apply your patch and revert these
changes for now since we have the git history for them we can look at
this more closely when we need it.

Thanks

--Phil


On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
>  wrote:
> > This patch introduces a new set of interfaces to define the target info as
> > expected by the rust front-end. It takes advantage of the information
> > within gcc/config/target directories which gets called by the front-end
> > to populate rust front-end datastructures by calling into:
> > builtin_rust_info. This patch has been isolated to find if we are
> > approaching this in an idiomatic way and is compilable without the
> > rust-front-end code.
>
> I suppose the general approach may be fine, as is similarly implemented
> by other languages' front ends in GCC.
>
> > We have received many patches here which gives us the target hook info for
> > most platforms
>
> But this is all so much WIP and full of TODO notes, and has no test cases
> at all!, that I still don't really see much value in keeping the current
> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
> that I've attached, we're not seeing any change in 'make check-rust'
> results, for example.
>
> In my opinion, the current implementation should be backed out from the
> main development branch (would also reduce pain in merges from GCC
> upstream, as mentioned before), and then be developed (quite possibly
> based on the current implementation) individually for all GCC
> configurations that we'd like to support (with 'sorry' otherwise), in a
> coherent way, instead of trying to guess all possible target options as
> done by the current implementation.  And, with all relevant test cases
> getting added, of course.  That is, at this time, restrict outselves to
> GCC configurations that we're actually supporting and testing.
>
> Have we even figured out which of those target options are actually
> mandated for a conforming Rust programming language implementation (that
> is, users would potentially rely on these)?
>
> As far as I can tell, 'rustc' defines target options here:
> ,
> and you may use 'rustc --print=cfg' to dump for the current
> configuration?
>
> > but getting the normal x86 done correctly will define if
> > the other patches are done correctly.
>
> Yes -- but I'm not sure this is it really, in its current WIPy,
> un-tested, un-verified form:
>
> > gcc/config/ChangeLog:
>
> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
> >   * dragonfly.h: define TARGET_RUST_OS_INFO
> >   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
> >   * freebsd.h: define guard for TARGET_RUST_OS_INFO
> >   * fuchsia.h: define TARGET_RUST_OS_INFO
> >   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> >   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> >   * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
> >   * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
> >   * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
> >   * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
> >   * phoenix.h: define TARGET_RUST_OS_INFO
> >   * sol2.h: define TARGET_RUST_OS_INFO
> >   * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
> >   * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
> >
> > gcc/config/i386/ChangeLog:
> >
> > * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
> > * cygming.h: define TARGET_RUST_OS_INFO
> > * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
> > * darwin.h: define TARGET_RUST_OS_INFO
> > * djgpp.h: likewise
> > * gnu-user-common.h: define TARGET_RUST_OS_INFO
> > * i386-protos.h: prototype for ix86_rust_target_cpu_info
> > * i386-rust.cc: new file to generate the rust target host info
> > * i386.h: define TARGET_RUST_CPU_INFO hook
> > * linux-common.h: define hooks for target info
> > * lynx.h: likewise
> > * mingw32.h: likewise
> > * netbsd-elf.h: likewise
> > * netbsd64.h: likewise
> > * nto.h: likewise
> > * openbsdelf.h: likewise
> > * rdos.h: likewise
> > * rtemself.h: likewise
> >  

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Xi Ruoyao via Gcc-patches]

On Thu, 2022-07-28 at 10:59 +0800, Lulu Cheng wrote:

> > The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification
> > is
> as follows:
>  #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
>  -  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
>  +  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel |
> DW_EH_PE_sdata4)

The master branch still contains:

#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)

Did you forgot to commit this change (or lost it during a rebase)?


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

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Thomas Schwinge]

Hi!

On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
 wrote:
> This patch introduces a new set of interfaces to define the target info as
> expected by the rust front-end. It takes advantage of the information
> within gcc/config/target directories which gets called by the front-end
> to populate rust front-end datastructures by calling into:
> builtin_rust_info. This patch has been isolated to find if we are
> approaching this in an idiomatic way and is compilable without the
> rust-front-end code.

I suppose the general approach may be fine, as is similarly implemented
by other languages' front ends in GCC.

> We have received many patches here which gives us the target hook info for
> most platforms

But this is all so much WIP and full of TODO notes, and has no test cases
at all!, that I still don't really see much value in keeping the current
implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
that I've attached, we're not seeing any change in 'make check-rust'
results, for example.

In my opinion, the current implementation should be backed out from the
main development branch (would also reduce pain in merges from GCC
upstream, as mentioned before), and then be developed (quite possibly
based on the current implementation) individually for all GCC
configurations that we'd like to support (with 'sorry' otherwise), in a
coherent way, instead of trying to guess all possible target options as
done by the current implementation.  And, with all relevant test cases
getting added, of course.  That is, at this time, restrict outselves to
GCC configurations that we're actually supporting and testing.

Have we even figured out which of those target options are actually
mandated for a conforming Rust programming language implementation (that
is, users would potentially rely on these)?

As far as I can tell, 'rustc' defines target options here:
,
and you may use 'rustc --print=cfg' to dump for the current
configuration?

> but getting the normal x86 done correctly will define if
> the other patches are done correctly.

Yes -- but I'm not sure this is it really, in its current WIPy,
un-tested, un-verified form:

> gcc/config/ChangeLog:

> * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
>   * dragonfly.h: define TARGET_RUST_OS_INFO
>   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
>   * freebsd.h: define guard for TARGET_RUST_OS_INFO
>   * fuchsia.h: define TARGET_RUST_OS_INFO
>   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
>   * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
>   * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
>   * phoenix.h: define TARGET_RUST_OS_INFO
>   * sol2.h: define TARGET_RUST_OS_INFO
>   * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
>   * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
>
> gcc/config/i386/ChangeLog:
>
> * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
> * cygming.h: define TARGET_RUST_OS_INFO
> * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
> * darwin.h: define TARGET_RUST_OS_INFO
> * djgpp.h: likewise
> * gnu-user-common.h: define TARGET_RUST_OS_INFO
> * i386-protos.h: prototype for ix86_rust_target_cpu_info
> * i386-rust.cc: new file to generate the rust target host info
> * i386.h: define TARGET_RUST_CPU_INFO hook
> * linux-common.h: define hooks for target info
> * lynx.h: likewise
> * mingw32.h: likewise
> * netbsd-elf.h: likewise
> * netbsd64.h: likewise
> * nto.h: likewise
> * openbsdelf.h: likewise
> * rdos.h: likewise
> * rtemself.h: likewise
> * t-i386: add makefilke rule for i386-rust.cc
> * vxworks.h: define TARGET_RUST_OS_INFO


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a5688c5da3c9ffda614f4138e55f46b7078b9e3a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 28 Jul 2022 12:04:28 +0200
Subject: [PATCH] [HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'

---
 gcc/rust/rust-lang.cc| 2 ++
 gcc/rust/rust-session-manager.cc | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/gcc/rust/rust-lang.cc b/gcc/rust/rust-lang.cc
index dd8c608789a..40331f6a431 100644
--- a/gcc/rust/rust-lang.cc
+++ b/gcc/rust/rust-lang.cc
@@ -107,6 +107,8 @@ struct GTY (()) language_function
 void
 rust_add_target_info (const char 

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Jakub Jelinek via Gcc-patches]

Note, the ChangeLog entry formatting is wrong and in various places
the code formatting as well.  In gcc/rust/ you can choose different
formatting if there are strong reasons for that, but at least it should be
consistent and ideally documented.

None of the gcc/doc, gcc/config, gcc/config/i386 directories have
ChangeLog files, so all this should go into gcc/ChangeLog
and filenames should be relative to the gcc/ directory, so
doc/tm.texi.in, config/default-rust.cc, config/i386/crtdll.h etc.

After : there should be a capital letter and the description what
changed should end with a dot.
Where possible, before : there should be space ( followed by what
has changed followed by ).
When some file is regenerated, just write Regenerated. or so.
When a new file is added, just write New. or New file.

On Wed, Jul 27, 2022 at 02:40:38PM +0100, herron.philip--- via Gcc-patches 
wrote:
> gcc/doc/ChangeLog:
> 
> * tm.texi.in: specifiy hooks for rust target info
> * tm.texi: commit the generated documentation
> 
> gcc/ChangeLog:
> 
> * Makefile.in: add target to generate rust hooks
> * config.gcc: add rust target interface to be compiled for i386
>   * genhooks.cc: generate rust target hooks
>   * configure: autoconf update
>   * configure.ac: add tm_rust_file_list and tm_rust_include_list
> 
> gcc/config/ChangeLog:
> 
> * default-rust.cc: new target hooks initializer for rust
> * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
>   * dragonfly.h: define TARGET_RUST_OS_INFO
>   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
>   * freebsd.h: define guard for TARGET_RUST_OS_INFO
>   * fuchsia.h: define TARGET_RUST_OS_INFO
>   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
>   * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
>   * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
>   * phoenix.h: define TARGET_RUST_OS_INFO
>   * sol2.h: define TARGET_RUST_OS_INFO
>   * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
>   * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
> 
> gcc/config/i386/ChangeLog:
> 
> * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
> * cygming.h: define TARGET_RUST_OS_INFO
> * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
> * darwin.h: define TARGET_RUST_OS_INFO
> * djgpp.h: likewise
> * gnu-user-common.h: define TARGET_RUST_OS_INFO
> * i386-protos.h: prototype for ix86_rust_target_cpu_info
> * i386-rust.cc: new file to generate the rust target host info
> * i386.h: define TARGET_RUST_CPU_INFO hook
> * linux-common.h: define hooks for target info
> * lynx.h: likewise
> * mingw32.h: likewise
> * netbsd-elf.h: likewise
> * netbsd64.h: likewise
> * nto.h: likewise
> * openbsdelf.h: likewise
> * rdos.h: likewise
> * rtemself.h: likewise
> * t-i386: add makefilke rule for i386-rust.cc
> * vxworks.h: define TARGET_RUST_OS_INFO
> 
> gcc/rust/ChangeLog:
> 
> * rust-target-def.h: define the headers to access the hooks
> * rust-target.def: define the hooks nessecary based on C90
> * rust-target.h: define extern gcc_targetrustm
> +/* Implement TARGET_RUST_CPU_INFO for x86 targets.  */
> +
> +void
> +ix86_rust_target_cpu_info (void)
> +{
> +if (TARGET_64BIT) {
> +rust_add_target_info("target_arch", "x86_64");

The indentation should be just 2 columns rather than 4, and
{ doesn't go at the end of line.  Single statement if/else/etc.
bodies aren't wrapped with {}s.  There is space before (.
So
  if (TARGET_64BIT)
{
  rust_add_target_info ("target_arch", "x86_64");
  ...
}
  else
rust_add_target_info ("target_arch", "x86");

> +  // nopl: hard-coded (as gcc doesn't technically have feature) to return 
> true for cpu arches with it
> +  // maybe refactor into switch if multiple options
> +  bool hasNOPL = ix86_arch == PROCESSOR_PENTIUMPRO || ix86_arch == 
> PROCESSOR_PENTIUM4 
> +|| ix86_arch == PROCESSOR_NOCONA || ix86_arch == PROCESSOR_CORE2 || 
> ix86_arch == PROCESSOR_NEHALEM 

Some lines are too long.

Jakub

Re: Rust frontend patches v1

[Philip Herron]

Thanks, for confirming David. I think it was too big in the end. I was
trying to figure out how to actually split that up but it seems
reasonable that I can split up the front-end patches into patches for
each separate pass in the compiler seems like a reasonable approach
for now.

--Phil

On Wed, 27 Jul 2022 at 17:45, David Malcolm  wrote:
>
> On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
> wrote:
> > This is the initial version 1 patch set for the Rust front-end. There
> > are more changes that need to be extracted out for all the target
> > hooks we have implemented. The goal is to see if we are implementing
> > the target hooks information for x86 and arm. We have more patches
> > for the other targets I can add in here but they all follow the
> > pattern established here.
> >
> > Each patch is buildable on its own and rebased ontop of
> > 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we keep
> > attribution for all the patches we have received in the front-end
> > should we create a CONTRIBUTOR's file inside the front-end folder?
> >
> > Note thanks to Thomas Schwinge and Mark Wielaard, we are keeping a
> > branch up to date with our code on:
> > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
> >  but this is not rebased ontop of gcc head.
> >
> > Let me know if I have sent these patches correctly or not, this is a
> > learning experience with git send-email.
> >
> > [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder
> > [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and
> > [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM
> > [PATCH Rust front-end v1 4/4] Add Rust front-end and associated
>
> FWIW it looks like patch 4 of the kit didn't make it (I didn't get a
> copy and I don't see it in the archives).
>
> Maybe it exceeded a size limit?  If so, maybe try splitting it up into
> more patches.
>
> Dave
>

Re: Re: [PATCH] testsuite: Add extra RISC-V options so that -fprefetch-loop-arrays works

[jiawei]

 -原始邮件-
 发件人: "Richard Biener" 
 发送时间: 2022-07-28 15:45:27 (星期四)
 收件人: jiawei 
 抄送: gcc-patches@gcc.gnu.org, ja...@redhat.com, pal...@rivosinc.com, 
kito.ch...@gmail.com, jim.wilson@gmail.com, wuwei2...@iscas.ac.cn
 主题: Re: [PATCH] testsuite: Add extra RISC-V options so that 
-fprefetch-loop-arrays works
 
 On Thu, 28 Jul 2022, jiawei wrote:
 
  This patch adds the additional options on RISC-V target.
  "-fprefetch-loop-arrays" option needs enable prefetch instruction,
  for RISC-V that contained in "zicbop" extension.
  Use "-march" with "zicbop" will enable this feature.
 
 OK.
 
 Note -fprefetch-loop-arrays is just required to trigger an ICE,
 do you see a diagnostic when prefetching is not supported?  Maybe
 simply adding -w is better then.

Yes, without -march support it report warning info:

cc1: warning: '-fprefetch-loop-arrays' not supported for this target (try 
'-march' switches)

after add -w the warning ignored.

 
  gcc/testsuite/ChangeLog:
  
  * gcc.dg/pr106397.c: New dg-additional-options for RISC-V.
  
  ---
   gcc/testsuite/gcc.dg/pr106397.c | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/gcc/testsuite/gcc.dg/pr106397.c 
b/gcc/testsuite/gcc.dg/pr106397.c
  index 2bc17f8cf80..19274fa8771 100644
  --- a/gcc/testsuite/gcc.dg/pr106397.c
  +++ b/gcc/testsuite/gcc.dg/pr106397.c
  @@ -1,6 +1,8 @@
   /* { dg-do compile } */
   /* { dg-options "-O3 -fprefetch-loop-arrays --param l2-cache-size=0 
--param prefetch-latency=3 -fprefetch-loop-arrays" } */
   /* { dg-additional-options "-march=i686 -msse" { target { { i?86-*-* 
x86_64-*-* }  ia32 } } } */
  +/* { dg-additional-options "-march=rv64gc_zicbop" { target { 
riscv64-*-* } } */
  +/* { dg-additional-options "-march=rv32gc_zicbop" { target { 
riscv32-*-* } } */
   
   int
   bar (void)
  
 
 -- 
 Richard Biener 
 SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
 Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
 HRB 36809 (AG Nuernberg)

PING^1 [PATCH v4] rs6000: Adjust mov optabs for opaque modes [PR103353]

[Kewen.Lin via Gcc-patches]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html

BR,
Kewen

on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote:
> Hi Segher!
> 
> on 2022/6/25 00:49, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:
>>> on 2022/6/24 03:06, Segher Boessenkool wrote:
 On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions.  As shown in
> that PR, without one explicit mov optab on OOmode provided, it would
> call emit_move_insn recursively.

 First off: lxvp is a VSX insn, not an MMA insn.  So please don't call it
 that -- this confusion is what presumably caused the problem here, so it
 would be good to root it out :-)
>>>
>>> I guess the "it" in "don't call it call" is for "MMA built-in function"?
>>> It comes from the current code:
>>
>> Your proposed commit message says "MMA built-in function".  It is not
>> an MMA builtin, or rather, it should not be.
>>
> +  /* Opaque modes are only expected to be available when MMA is 
> supported,

 Why do people expect that?  It is completely wrong.  The name "opaque"
 itself already says this is not just for MMA, but perhaps more
 importantly, it is a basic VSX insn, doesn't touch any MMA resources,
 and is useful in other contexts as well.
>>>
>>> ... The above statements are also based on current code, for now, the
>>> related things like built-in functions, mov optab, hard_regno_ok etc.
>>> for these two modes are guarded by TARGET_MMA.
>>
>> Opaque modes are a generic thing, not an rs6000 thing.  It is important
>> not to conflate completely different things that just happened to
>> coincide some months ago (but not anymore right now even!)
>>
>>> I think I get your points here, you want to separate these opaque
>>> modes from MMA since the underlying lxvp/stxvp are not MMA specific,
>>> so those related things (bifs, mov optabs etc.) are not necessarily
>>> guarded under MMA.
>>
>> Yup.  This can take some time of course, but in the mean time we should
>> stop pretending the status quo is correct.
>>
 So this needs some bigger surgery.
>>>
>>> Yes, Peter may have more comments on this.
>>
>> Yes.  Can you do a patch that just fixes this PR103353, without adding
>> more misleading comments?  :-)
>>
> 
> Many thanks for all the further explanation above!  The attached patch
> updated the misleading comments as you pointed out and suggested, could
> you help to have another look?
> 
> BR,
> Kewen

PING^3 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

[Kewen.Lin via Gcc-patches]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html

BR,
Kewen

>>> Hi,
>>>
>>> As PR104482 shown, it's one regression about the handlings when
>>> the argument number is more than the one of built-in function
>>> prototype.  The new bif support only catches the case that the
>>> argument number is less than the one of function prototype, but
>>> it misses the case that the argument number is more than the one
>>> of function prototype.  Because it uses "n != expected_args",
>>> n is updated in
>>>
>>>for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs;
>>> fnargs = TREE_CHAIN (fnargs), n++)
>>>
>>> , it's restricted to be less than or equal to expected_args with
>>> the guard !VOID_TYPE_P (TREE_VALUE (fnargs)), so it's wrong.
>>>
>>> The fix is to use nargs instead, also move the checking hunk's
>>> location ahead to avoid useless further scanning when the counts
>>> mismatch.
>>>
>>> Bootstrapped and regtested on powerpc64-linux-gnu P8 and
>>> powerpc64le-linux-gnu P9 and P10.
>>>
>>> v3: Update test case with dg-excess-errors.
>>>
>>> v2: Add one test case and refine commit logs.
>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593155.html
>>>
>>> v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html
>>>
>>> Is it ok for trunk?
>>>
>>> BR,
>>> Kewen
>>> -
>>> PR target/104482
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin): Fix
>>> the equality check for argument number, and move this hunk ahead.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/powerpc/pr104482.c: New test.
>>> ---
>>>  gcc/config/rs6000/rs6000-c.cc   | 60 ++---
>>>  gcc/testsuite/gcc.target/powerpc/pr104482.c | 16 ++
>>>  2 files changed, 46 insertions(+), 30 deletions(-)
>>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr104482.c
>>>
>>> diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
>>> index 9c8cbd7a66e..61881f29230 100644
>>> --- a/gcc/config/rs6000/rs6000-c.cc
>>> +++ b/gcc/config/rs6000/rs6000-c.cc
>>> @@ -1756,6 +1756,36 @@ altivec_resolve_overloaded_builtin (location_t loc, 
>>> tree fndecl,
>>>vec *arglist = static_cast *> 
>>> (passed_arglist);
>>>unsigned int nargs = vec_safe_length (arglist);
>>>
>>> +  /* If the number of arguments did not match the prototype, return NULL
>>> + and the generic code will issue the appropriate error message.  Skip
>>> + this test for functions where we don't fully describe all the possible
>>> + overload signatures in rs6000-overload.def (because they aren't 
>>> relevant
>>> + to the expansion here).  If we don't, we get confusing error 
>>> messages.  */
>>> +  /* As an example, for vec_splats we have:
>>> +
>>> +; There are no actual builtins for vec_splats.  There is special handling 
>>> for
>>> +; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the call
>>> +; is replaced by a constructor.  The single overload here causes
>>> +; __builtin_vec_splats to be registered with the front end so that can 
>>> happen.
>>> +[VEC_SPLATS, vec_splats, __builtin_vec_splats]
>>> +  vsi __builtin_vec_splats (vsi);
>>> +ABS_V4SI SPLATS_FAKERY
>>> +
>>> +So even though __builtin_vec_splats accepts all vector types, the
>>> +infrastructure cheats and just records one prototype.  We end up 
>>> getting
>>> +an error message that refers to this specific prototype even when we
>>> +are handling a different argument type.  That is completely confusing
>>> +to the user, so it's best to let these cases be handled individually
>>> +in the resolve_vec_splats, etc., helper functions.  */
>>> +
>>> +  if (expected_args != nargs
>>> +  && !(fcode == RS6000_OVLD_VEC_PROMOTE
>>> +  || fcode == RS6000_OVLD_VEC_SPLATS
>>> +  || fcode == RS6000_OVLD_VEC_EXTRACT
>>> +  || fcode == RS6000_OVLD_VEC_INSERT
>>> +  || fcode == RS6000_OVLD_VEC_STEP))
>>> +return NULL;
>>> +
>>>for (n = 0;
>>> !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs;
>>> fnargs = TREE_CHAIN (fnargs), n++)
>>> @@ -1816,36 +1846,6 @@ altivec_resolve_overloaded_builtin (location_t loc, 
>>> tree fndecl,
>>>types[n] = type;
>>>  }
>>>
>>> -  /* If the number of arguments did not match the prototype, return NULL
>>> - and the generic code will issue the appropriate error message.  Skip
>>> - this test for functions where we don't fully describe all the possible
>>> - overload signatures in rs6000-overload.def (because they aren't 
>>> relevant
>>> - to the expansion here).  If we don't, we get confusing error 
>>> messages.  */
>>> -  /* As an example, for vec_splats we have:
>>> -
>>> -; There are no actual builtins for vec_splats.  There is special handling 
>>> for
>>> -; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the call
>>> -; is replaced by a constructor.  The single overload 

PING^3 [PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

[Kewen.Lin via Gcc-patches]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html

BR,
Kewen

> 
>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR105485 exposes that new builtin function framework doesn't handle
>>> unresolved overloaded builtin function well.  With new builtin
>>> function support, we don't have builtin info for any overloaded
>>> rs6000_gen_builtins enum, since they are expected to be resolved to
>>> one specific instance.  So when function rs6000_gimple_fold_builtin
>>> faces one unresolved overloaded builtin, the access for builtin info
>>> becomes out of bound and gets ICE then.
>>>
>>> We should not try to fold one unresolved overloaded builtin there
>>> and as the previous support we should emit one error message during
>>> expansion phase like "unresolved overload for builtin ...".
>>>
>>> Bootstrapped and regtested on powerpc64-linux-gnu P8 and
>>> powerpc64le-linux-gnu P9 and P10.
>>>
>>> Is it ok for trunk?
>>>
>>> BR,
>>> Kewen
>>> -
>>> PR target/105485
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Add
>>> the handling for unresolved overloaded builtin function.
>>> (rs6000_expand_builtin): Likewise.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * g++.target/powerpc/pr105485.C: New test.
>>>
>>> ---
>>>  gcc/config/rs6000/rs6000-builtin.cc | 13 +
>>>  gcc/testsuite/g++.target/powerpc/pr105485.C |  9 +
>>>  2 files changed, 22 insertions(+)
>>>  create mode 100644 gcc/testsuite/g++.target/powerpc/pr105485.C
>>>
>>> diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
>>> b/gcc/config/rs6000/rs6000-builtin.cc
>>> index e925ba9fad9..e102305c90c 100644
>>> --- a/gcc/config/rs6000/rs6000-builtin.cc
>>> +++ b/gcc/config/rs6000/rs6000-builtin.cc
>>> @@ -1294,6 +1294,11 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator 
>>> *gsi)
>>>enum tree_code bcode;
>>>gimple *g;
>>>
>>> +  /* For an unresolved overloaded builtin, return early here since there
>>> + is no builtin info for it and we are unable to fold it.  */
>>> +  if (fn_code > RS6000_OVLD_NONE)
>>> +return false;
>>> +
>>>size_t uns_fncode = (size_t) fn_code;
>>>enum insn_code icode = rs6000_builtin_info[uns_fncode].icode;
>>>const char *fn_name1 = rs6000_builtin_info[uns_fncode].bifname;
>>> @@ -3295,6 +3300,14 @@ rs6000_expand_builtin (tree exp, rtx target, rtx /* 
>>> subtarget */,
>>>tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
>>>enum rs6000_gen_builtins fcode
>>>  = (enum rs6000_gen_builtins) DECL_MD_FUNCTION_CODE (fndecl);
>>> +
>>> +  /* Emit error message if it's an unresolved overloaded builtin.  */
>>> +  if (fcode > RS6000_OVLD_NONE)
>>> +{
>>> +  error ("unresolved overload for builtin %qF", fndecl);
>>> +  return const0_rtx;
>>> +}
>>> +
>>>size_t uns_fcode = (size_t)fcode;
>>>enum insn_code icode = rs6000_builtin_info[uns_fcode].icode;
>>>
>>> diff --git a/gcc/testsuite/g++.target/powerpc/pr105485.C 
>>> b/gcc/testsuite/g++.target/powerpc/pr105485.C
>>> new file mode 100644
>>> index 000..a3b8290df8c
>>> --- /dev/null
>>> +++ b/gcc/testsuite/g++.target/powerpc/pr105485.C
>>> @@ -0,0 +1,9 @@
>>> +/* It's to verify no ICE here, ignore error/warning messages since
>>> +   they are not test points here.  */
>>> +/* { dg-excess-errors "pr105485" } */
>>> +
>>> +template  void __builtin_vec_vslv();
>>> +typedef  __attribute__((altivec(vector__))) char T;
>>> +T b (T c, T d) {
>>> +return __builtin_vec_vslv(c, d);
>>> +}

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

[Alexandre Oliva via Gcc-patches]

On Jul 27, 2022, "H.J. Lu"  wrote:

> On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva  wrote:

>> The use of @GOTOFF for locally-bound but externally-visible symbols
>> (e.g. protected visibility) also breaks pointer identity if the
>> canonical address ends up preempted by a PLT entry.

> Here is a different fix:

> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html

Oh, thanks, I'd missed that.

It doesn't seem to fix the part of the problem I quoted above, though.
I think fixing that requires testing the visibility, to make sure the
symbol's canonical address cannot be preempted, which may occur with
local binding, if the symbol is protected and referenced in the main
program, otherwise pointer identity is broken again, admittedly for a
more obscure case, but pointer identity was the point of the PR.

>> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
>> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.

You may also need to do something like this bit for mvc10.c on ia32 PIE.
Because the ifunc is called through an alias, AFAICT we don't even
notice that the call target is (an alias to) an ifunc.  GCC's
gotoff_operand predicate accepts it, but binutils (the linker, IIRC)
then rejects that reference, because the named symbol is an alias to an
ifunc.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] testsuite: Add extra RISC-V options so that -fprefetch-loop-arrays works

[Richard Biener via Gcc-patches]

On Thu, 28 Jul 2022, jiawei wrote:

> This patch adds the additional options on RISC-V target.
> "-fprefetch-loop-arrays" option needs enable prefetch instruction,
> for RISC-V that contained in "zicbop" extension.
> Use "-march" with "zicbop" will enable this feature.

OK.

Note -fprefetch-loop-arrays is just required to trigger an ICE,
do you see a diagnostic when prefetching is not supported?  Maybe
simply adding -w is better then.

> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/pr106397.c: New dg-additional-options for RISC-V.
> 
> ---
>  gcc/testsuite/gcc.dg/pr106397.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr106397.c b/gcc/testsuite/gcc.dg/pr106397.c
> index 2bc17f8cf80..19274fa8771 100644
> --- a/gcc/testsuite/gcc.dg/pr106397.c
> +++ b/gcc/testsuite/gcc.dg/pr106397.c
> @@ -1,6 +1,8 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O3 -fprefetch-loop-arrays --param l2-cache-size=0 --param 
> prefetch-latency=3 -fprefetch-loop-arrays" } */
>  /* { dg-additional-options "-march=i686 -msse" { target { { i?86-*-* 
> x86_64-*-* } && ia32 } } } */
> +/* { dg-additional-options "-march=rv64gc_zicbop" { target { riscv64-*-* } } 
> */
> +/* { dg-additional-options "-march=rv32gc_zicbop" { target { riscv32-*-* } } 
> */
>  
>  int
>  bar (void)
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

[Richard Biener via Gcc-patches]

On Tue, 19 Jul 2022, Qing Zhao wrote:

> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
> From: Qing Zhao 
> Date: Mon, 18 Jul 2022 18:12:26 +
> Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in __builtin_object_size
> [PR101836]
> 
> Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
> of a structure is flexible array member in __builtin_object_size.
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/101836
>   * tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
>   and DECL_NOT_FLEXARRAY to determine a flexible array member reference.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/101836
>   * gcc.dg/pr101836.c: New test.
>   * gcc.dg/pr101836_1.c: New test.
>   * gcc.dg/pr101836_2.c: New test.
>   * gcc.dg/pr101836_3.c: New test.
>   * gcc.dg/pr101836_4.c: New test.
>   * gcc.dg/pr101836_5.c: New test.
>   * gcc.dg/strict-flex-array-2.c: New test.
>   * gcc.dg/strict-flex-array-3.c: New test.
> ---
> gcc/testsuite/gcc.dg/pr101836.c| 60 ++
> gcc/testsuite/gcc.dg/pr101836_1.c  | 60 ++
> gcc/testsuite/gcc.dg/pr101836_2.c  | 60 ++
> gcc/testsuite/gcc.dg/pr101836_3.c  | 60 ++
> gcc/testsuite/gcc.dg/pr101836_4.c  | 60 ++
> gcc/testsuite/gcc.dg/pr101836_5.c  | 60 ++
> gcc/testsuite/gcc.dg/strict-flex-array-2.c | 60 ++
> gcc/testsuite/gcc.dg/strict-flex-array-3.c | 60 ++
> gcc/tree-object-size.cc| 18 +++
> 9 files changed, 489 insertions(+), 9 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
> create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
> create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
> create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
> create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
> create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
> create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
> create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c
> 
> diff --git a/gcc/testsuite/gcc.dg/pr101836.c b/gcc/testsuite/gcc.dg/pr101836.c
> new file mode 100644
> index 000..e5b4e5160a4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr101836.c
> @@ -0,0 +1,60 @@
> +/* -fstrict-flex-array is aliased with -ftrict-flex-array=3, which is the
> +   strictest, only [] is treated as flexible array.  */ 
> +/* PR tree-optimization/101836 */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fstrict-flex-array" } */
> +
> +#include 
> +
> +#define expect(p, _v) do { \
> +size_t v = _v; \
> +if (p == v) \
> +printf("ok:  %s == %zd\n", #p, p); \
> +else \
> + {  \
> +  printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
> +   __builtin_abort (); \
> + } \
> +} while (0);
> +
> +struct trailing_array_1 {
> +int a;
> +int b;
> +int c[4];
> +};
> +
> +struct trailing_array_2 {
> +int a;
> +int b;
> +int c[1];
> +};
> +
> +struct trailing_array_3 {
> +int a;
> +int b;
> +int c[0];
> +};
> +struct trailing_array_4 {
> +int a;
> +int b;
> +int c[];
> +};
> +
> +void __attribute__((__noinline__)) stuff(
> +struct trailing_array_1 *normal,
> +struct trailing_array_2 *trailing_1,
> +struct trailing_array_3 *trailing_0,
> +struct trailing_array_4 *trailing_flex)
> +{
> +expect(__builtin_object_size(normal->c, 1), 16);
> +expect(__builtin_object_size(trailing_1->c, 1), 4);
> +expect(__builtin_object_size(trailing_0->c, 1), 0);
> +expect(__builtin_object_size(trailing_flex->c, 1), -1);
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void 
> *)argv[0]);
> +
> +return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/pr101836_1.c 
> b/gcc/testsuite/gcc.dg/pr101836_1.c
> new file mode 100644
> index 000..30ea20427a5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr101836_1.c
> @@ -0,0 +1,60 @@
> +/* -fstrict-flex-array=3 is the strictest, only [] is treated as
> +   flexible array.  */ 
> +/* PR tree-optimization/101836 */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fstrict-flex-array=3" } */
> +
> +#include 
> +
> +#define expect(p, _v) do { \
> +size_t v = _v; \
> +if (p == v) \
> +printf("ok:  %s == %zd\n", #p, p); \
> +else \
> + {  \
> +  printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
> +   __builtin_abort (); \
> + } \
> +} while (0);
> +
> +struct trailing_array_1 {
> +int a;
> +int b;
> +int c[4];
> +};
> +
> +struct trailing_array_2 {
> +int a;
> +int b;
> +int c[1];
> +};
> +
> +struct trailing_array_3 {
> +int a;
> +int b;
> +int c[0];
> +};
> +struct trailing_array_4 {
> +int a;
> +int b;
> +int c[];
> +};
> +
> +void 

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

[Richard Biener via Gcc-patches]

On Tue, 19 Jul 2022, Qing Zhao wrote:

> From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
> From: Qing Zhao 
> Date: Mon, 18 Jul 2022 17:04:12 +
> Subject: [PATCH 1/2] Add a new option -fstrict-flex-array[=n] and new
> attribute strict_flex_array
> 
> Add the following new option -fstrict-flex-array[=n] and a corresponding
> attribute strict_flex_array to GCC:
> 
> '-fstrict-flex-array'
> Treat the trailing array of a structure as a flexible array member
> in a stricter way.  The positive form is equivalent to
> '-fstrict-flex-array=3', which is the strictest.  A trailing array
> is treated as a flexible array member only when it is declared as a
> flexible array member per C99 standard onwards.  The negative form
> is equivalent to '-fstrict-flex-array=0', which is the least
> strict.  All trailing arrays of structures are treated as flexible
> array members.
> 
> '-fstrict-flex-array=LEVEL'
> Treat the trailing array of a structure as a flexible array member
> in a stricter way.  The value of LEVEL controls the level of
> strictness.
> 
> The possible values of LEVEL are the same as for the
> 'strict_flex_array' attribute (*note Variable Attributes::).
> 
> You can control this behavior for a specific trailing array field
> of a structure by using the variable attribute 'strict_flex_array'
> attribute (*note Variable Attributes::).
> 
> 'strict_flex_array (LEVEL)'
> The 'strict_flex_array' attribute should be attached to the
> trailing array field of a structure.  It specifies the level of
> strictness of treating the trailing array field of a structure as a
> flexible array member.  LEVEL must be an integer betwen 0 to 3.
> 
> LEVEL=0 is the least strict level, all trailing arrays of
> structures are treated as flexible array members.  LEVEL=3 is the
> strictest level, only when the trailing array is declared as a
> flexible array member per C99 standard onwards ([]), it is treated
> as a flexible array member.
> 
> There are two more levels in between 0 and 3, which are provided to
> support older codes that use GCC zero-length array extension ([0])
> or one-size array as flexible array member ([1]): When LEVEL is 1,
> the trailing array is treated as a flexible array member when it is
> declared as either [], [0], or [1]; When LEVEL is 2, the trailing
> array is treated as a flexible array member when it is declared as
> either [], or [0].
> 
> This attribute can be used with or without '-fstrict-flex-array'.
> When both the attribute and the option present at the same time,
> the level of the strictness for the specific trailing array field
> is determined by the attribute.
> 
> gcc/c-family/ChangeLog:
> 
>   * c-attribs.cc (handle_strict_flex_array_attribute): New function.
>   (c_common_attribute_table): New item for strict_flex_array.
>   * c.opt (fstrict-flex-array): New option.
>   (fstrict-flex-array=): New option.
> 
> gcc/c/ChangeLog:
> 
>   * c-decl.cc (add_flexible_array_elts_to_size): Call new utility
>   routine flexible_array_member_p.
>   (is_flexible_array_member_p): New function.
>   (finish_struct): Set the new DECL_NOT_FLEXARRAY flag.
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi: Document strict_flex_array attribute.
>   * doc/invoke.texi: Document -fstrict-flex-array[=n] option.
>   * tree-core.h (struct tree_decl_common): New bit field
>   decl_not_flexarray.
>   * tree.cc (component_ref_size): Reorg by using new utility functions.
>   (flexible_array_member_p): New function.
>   (zero_length_array_p): Likewise.
>   (one_element_array_p): Likewise.
>   (flexible_array_type_p): Likewise.
>   * tree.h (DECL_NOT_FLEXARRAY): New flag.
>   (zero_length_array_p): New function prototype.
>   (one_element_array_p): Likewise.
>   (flexible_array_member_p): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/strict-flex-array-1.c: New test.
> ---
> gcc/c-family/c-attribs.cc  |  47 
> gcc/c-family/c.opt |   7 ++
> gcc/c/c-decl.cc|  91 +--
> gcc/doc/extend.texi|  25 
> gcc/doc/invoke.texi|  27 -
> gcc/testsuite/gcc.dg/strict-flex-array-1.c |  31 +
> gcc/tree-core.h|   5 +-
> gcc/tree.cc| 130 ++---
> gcc/tree.h |  16 ++-
> 9 files changed, 322 insertions(+), 57 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-1.c
> 
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index c8d96723f4c..10d16532f0d 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -101,6 +101,8 @@ static tree handle_special_var_sec_attribute (tree 

Re: [PATCH] match.pd: Add new division pattern [PR104992]

[Richard Biener via Gcc-patches]

On Wed, Jul 27, 2022 at 9:57 PM Sam Feifer  wrote:
>
>
>> _Complex int are strange beasts, I'd simply avoid the transform for them.
>>
>
> I added to the match.pd rule to not simplify if the operands are complex. 
> There is now a test case for complex types to make sure they do not simplify. 
> I had to move the "dg-do run" test to g++.dg to accommodate the complex type 
> function that is included (even though there isn't a runtime test for complex 
> types).
>
>> Can you please move the pattern next to the existing div/mod patterns,
>> like after the related
>>
>
> done :)
>
>> /* Simplify (A / B) * B + (A % B) -> A.  */
>> (for div (trunc_div ceil_div floor_div round_div)
>>  mod (trunc_mod ceil_mod floor_mod round_mod)
>>   (simplify
>>(plus:c (mult:c (div @0 @1) @1) (mod @0 @1))
>>@0))
>>
>> pattern?
>>
>> +/* x / y * y == x -> x % y == 0.  */
>> +(simplify
>> +  (eq (mult (trunc_div @0 @1) @1) @0)
>> +  (eq (trunc_mod @0 @1) { build_zero_cst TREE_TYPE(@0); }))
>>
>> there are parens missing around the TREE_TYPE (@0), how did you test
>> the patch?  You probably want :s on the trunc_div and as Andrew said
>> :c on the eq and the mult.
>
>
> I made those changes to the rule. The rule worked without the parentheses, 
> which is probably why I didn't notice they were missing. Attached is an 
> updated patch file.

+/* x / y * y == x -> x % y == 0.  */
+(simplify
+  (eq:c (mult:c (trunc_div:s @0 @1) @1) @0)
+  (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE
+   && TREE_CODE (TREE_TYPE (@1)) != COMPLEX_TYPE)

Testing this only for @0 is enough, we don't allow mixed types for
trunc_div or mult.

+(eq (trunc_mod @0 @1) { build_zero_cst (TREE_TYPE(@0)); })))

space before (@0) in 'TREE_TYPE(@0)'

OK with those changes.

Thanks,
Richard.



> Thanks
> -Sam
>
>>
>> Richard.
>>
>> > Thanks
>> > -Sam
>> >
>> >
>> > > For vector try (which works for both the C and C++ front-end):
>> > > #define vector __attribute__((vector_size(4*sizeof(int)) ))
>> > > vector int f(vector int x, vector int y)
>> > > {
>> > >   return x == x / y * y;
>> > > }
>> > >
>> > > That is for the vector case, == still returns a vector type.
>> > >
>> > > Thanks,
>> > > Andrew Pinski
>> > >
>> > > >
>> > > > Thanks
>> > > > -Sam
>> > > >
>> > > >> Thanks,
>> > > >> Andrew Pinski
>> > > >>
>> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c
>> > > b/gcc/testsuite/gcc.dg/pr104992-1.c
>> > > >> > new file mode 100644
>> > > >> > index 000..a80e5e180ce
>> > > >> > --- /dev/null
>> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
>> > > >> > @@ -0,0 +1,30 @@
>> > > >> > +/* PR tree-optimization/104992 */
>> > > >> > +/* { dg-do run } */
>> > > >> > +/* { dg-options "-O2"} */
>> > > >> > +
>> > > >> > +#include "pr104992.c"
>> > > >> > +
>> > > >> > +int main () {
>> > > >> > +
>> > > >> > +/* Should be true.  */
>> > > >> > +if (!foo(6, 3)
>> > > >> > +|| !bar(12, 2)
>> > > >> > +|| !baz(34, 17)
>> > > >> > +|| !qux(50, 10)
>> > > >> > +|| !fred(16, 8)
>> > > >> > +|| !baz(-9, 3)
>> > > >> > +|| !baz(9, -3)
>> > > >> > +|| !baz(-9, -3)
>> > > >> > +) {
>> > > >> > +__builtin_abort();
>> > > >> > + }
>> > > >> > +
>> > > >> > +/* Should be false.  */
>> > > >> > +if (foo(5, 30)
>> > > >> > +|| bar(72, 27)
>> > > >> > +|| baz(42, 15)) {
>> > > >> > +__builtin_abort();
>> > > >> > +}
>> > > >> > +
>> > > >> > +return 0;
>> > > >> > +}
>> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
>> > > b/gcc/testsuite/gcc.dg/pr104992.c
>> > > >> > new file mode 100644
>> > > >> > index 000..b4b0ca53118
>> > > >> > --- /dev/null
>> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
>> > > >> > @@ -0,0 +1,35 @@
>> > > >> > +/* PR tree-optimization/104992 */
>> > > >> > +/* { dg-do compile } */
>> > > >> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
>> > > >> > +
>> > > >> > +/* Form from PR.  */
>> > > >> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
>> > > >> > +{
>> > > >> > +return x / y * y == x;
>> > > >> > +}
>> > > >> > +
>> > > >> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
>> > > >> > +return x == x / y * y;
>> > > >> > +}
>> > > >> > +
>> > > >> > +/* Signed test case.  */
>> > > >> > +__attribute__((noipa)) unsigned baz (int x, int y) {
>> > > >> > +return x / y * y == x;
>> > > >> > +}
>> > > >> > +
>> > > >> > +/* Changed order.  */
>> > > >> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
>> > > >> > +return y * (x / y) == x;
>> > > >> > +}
>> > > >> > +
>> > > >> > +/* Wrong order.  */
>> > > >> > +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
>> > > >> > +return y * x / y == x;
>> > > >> > +}
>> > > >> > +
>> > > >> > +/* Wrong pattern.  */
>> > > >> > +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y,
>> > > unsigned z) {
>> > > >> > +return x /