[PATCH] i386: Fix up cond_{and,ior,xor,mul}* [PR104779]

2022-03-05 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs, because the cond_andv* expander
has vector_operand predicates in both of the commutative inputs
and calls gen_andv*_mask which calls ix86_binary_operator_ok
in its condition, but nothing calls ix86_fixup_binary_operands_no_copy
during the expansion, which means cond_* accepts even operands
like 2 MEMs which then can't be matched.

The following patch handles it like most other insns that the other
cond_* patterns use - by having a separate define_expand that calls
ix86_fixup_binary_operands_no_copy and define_ins with
ix86_binary_operator_ok.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Note, the predicates on cond_fma* and other FMA variants look all wrong to
me, usually the fma instructions require nonimmediate_operand operands,
but the cond_* patterns use vector_operand.  Besides what this patch
fixes and the unfixed fma which I don't have spare cycles for right
now I went through all the other cond_* patterns checking for predicate
mismatches or similar missing ix86_fixup_binary_operands* issues and
didn't find other problems.

2022-03-05  Jakub Jelinek  

PR target/104779
* config/i386/sse.md (avx512dq_mul3): New
define_expand pattern.  Rename define_insn to ...
(*avx512dq_mul3): ... this.
(3_mask): New any_logic define_expand pattern.
(3): Rename to ...
(*3): ... this.

* gcc.target/i386/pr104779.c: New test.

--- gcc/config/i386/sse.md.jj   2022-02-24 15:27:14.722743984 +0100
+++ gcc/config/i386/sse.md  2022-03-04 13:56:34.863572916 +0100
@@ -15210,7 +15210,15 @@ (define_expand "cond_mul"
   DONE;
 })
 
-(define_insn "avx512dq_mul3"
+(define_expand "avx512dq_mul3"
+  [(set (match_operand:VI8_AVX512VL 0 "register_operand")
+   (mult:VI8_AVX512VL
+ (match_operand:VI8_AVX512VL 1 "bcst_vector_operand")
+ (match_operand:VI8_AVX512VL 2 "bcst_vector_operand")))]
+  "TARGET_AVX512DQ && "
+  "ix86_fixup_binary_operands_no_copy (MULT, mode, operands);")
+
+(define_insn "*avx512dq_mul3"
   [(set (match_operand:VI8_AVX512VL 0 "register_operand" "=v")
(mult:VI8_AVX512VL
  (match_operand:VI8_AVX512VL 1 "bcst_vector_operand" "%v")
@@ -16824,7 +16832,18 @@ (define_expand "cond_"
   DONE;
 })
 
-(define_insn "3"
+(define_expand "3_mask"
+  [(set (match_operand:VI48_AVX512VL 0 "register_operand")
+   (vec_merge:VI48_AVX512VL
+ (any_logic:VI48_AVX512VL
+   (match_operand:VI48_AVX512VL 1 "bcst_vector_operand")
+   (match_operand:VI48_AVX512VL 2 "bcst_vector_operand"))
+ (match_operand:VI48_AVX512VL 3 "nonimm_or_0_operand")
+ (match_operand: 4 "register_operand")))]
+  "TARGET_AVX512F"
+  "ix86_fixup_binary_operands_no_copy (, mode, operands);")
+
+(define_insn "*3"
   [(set (match_operand:VI48_AVX_AVX512F 0 "register_operand" "=x,x,v")
(any_logic:VI48_AVX_AVX512F
  (match_operand:VI48_AVX_AVX512F 1 "bcst_vector_operand" "%0,x,v")
--- gcc/testsuite/gcc.target/i386/pr104779.c.jj 2022-03-04 14:09:03.278961269 
+0100
+++ gcc/testsuite/gcc.target/i386/pr104779.c2022-03-04 14:08:38.063318794 
+0100
@@ -0,0 +1,27 @@
+/* PR target/104779 */
+/* { dg-do compile } */
+/* { dg-options "-O1 --param sccvn-max-alias-queries-per-access=0" } */
+
+__attribute__ ((simd)) int
+foo (int x, int y, int z)
+{
+  return (x & y) * !!z;
+}
+
+__attribute__ ((simd)) int
+bar (int x, int y, int z)
+{
+  return (x | y) * !!z;
+}
+
+__attribute__ ((simd)) int
+baz (int x, int y, int z)
+{
+  return (x ^ y) * !!z;
+}
+
+__attribute__ ((simd, target ("avx512dq"))) long
+qux (long x, long y, long z)
+{
+  return (x * y) * !!z;
+}

Jakub



[PATCH] waccess: Remove visited bitmap and stop on EDGE_ABNORMAL

2022-03-05 Thread Jakub Jelinek via Gcc-patches
On Fri, Mar 04, 2022 at 02:58:37PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Mar 03, 2022 at 05:08:30PM -0700, Martin Sebor wrote:
> > > 1) shouldn't it give up for EDGE_ABNORMAL too?  I mean, e.g.
> > > following a non-local goto forced edge from a noreturn call
> > > to a non-local label (if there is just one) doesn't seem
> > > right to me
> > 
> > Possibly yes.  I can add it but I don't have a lot of experience with
> > these bits so if you can suggest a test case to exercise this that
> > would be helpful.
> 
> Something like:
> void
> foo (void)
> {
>   __label__ l;
>   __attribute__((noreturn)) void bar (int x) { if (x) goto l; __builtin_trap 
> (); }
>   bar (0);
> l:;
> }
> shows a single EDGE_ABNORMAL from the bar call.
> But it would need tweaking for the ptr use and clobber.
> 
> > > 2) if EDGE_DFS_BACK is computed and 1) is done, is there any
> > > reason why you need 2 levels of protection, i.e. the EDGE_DFS_BACK
> > > check as well as the visited bitmap (and having them use
> > > very different answers, if EDGE_DFS_BACK is seen, the function
> > > will return false, if visited bitmap has a bb, it will return true)?
> > > Can't the visited bitmap go away?
> > 
> > Possibly.  As I said above, I don't have enough experience with these
> > bits to make (and test) the changes quickly, or enough bandwidth to
> > come up to speed on them.  Please feel free to make these improvements.
> 
> I'll change that if it passes testing.

Here is a patch to do both.  I don't think we really need to have a testcase
for the EDGE_ABNORMAL case (Martin, feel free to add it later), abnormal
edges simply aren't normal control flow and what exactly it means varies.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-03-05  Jakub Jelinek  

* gimple-ssa-warn-access.cc (pass_waccess::use_after_inval_p): Remove
visited bitmap and its use.  Also punt on EDGE_ABNORMAL edges.

--- gcc/gimple-ssa-warn-access.cc.jj2022-03-03 22:09:22.073800776 +0100
+++ gcc/gimple-ssa-warn-access.cc   2022-03-04 19:21:18.840416075 +0100
@@ -3812,20 +3812,15 @@ pass_waccess::use_after_inval_p (gimple
   /* Proceed only when looking for uses of dangling pointers.  */
   auto gsi = gsi_for_stmt (use_stmt);
 
-  auto_bitmap visited;
-
   /* A use statement in the last basic block in a function or one that
 falls through to it is after any other prior clobber of the used
 variable unless it's followed by a clobber of the same variable. */
   basic_block bb = use_bb;
   while (bb != inval_bb
 && single_succ_p (bb)
-&& !(single_succ_edge (bb)->flags & (EDGE_EH|EDGE_DFS_BACK)))
+&& !(single_succ_edge (bb)->flags
+ & (EDGE_EH | EDGE_ABNORMAL | EDGE_DFS_BACK)))
{
- if (!bitmap_set_bit (visited, bb->index))
-   /* Avoid cycles. */
-   return true;
-
  for (; !gsi_end_p (gsi); gsi_next_nondebug (&gsi))
{
  gimple *stmt = gsi_stmt (gsi);


Jakub



[PATCH] rs6000: Fix up __SIZEOF_{FLOAT,IBM}128__ defines [PR99708]

2022-03-05 Thread Jakub Jelinek via Gcc-patches
Hi!

As mentioned in the PR, right now on powerpc* __SIZEOF_{FLOAT,IBM}128__
macros are predefined unconditionally, because {ieee,ibm}128_float_type_node
is always non-NULL, doesn't reflect whether __ieee128 or __ibm128 are
actually supported or not.

The following patch:
1) makes those {ieee,ibm}128_float_type_node trees NULL if we don't
   really support them instead of equal to long_double_type_node
2) adjusts the builtins code to use
   ibm128_float_type_node ? ibm128_float_type_node : long_double_type_node
   for the 2 builtins, so that we don't ICE during builtins creation
   if ibm128_float_type_node is NULL (using error_mark_node instead of
   long_double_type_node sounds more risky to me)
3) in rs6000_type_string will not match NULL as __ibm128, and adds
   a __ieee128 case
4) removes the clearly unused ptr_{ieee,ibm}128_float_type_node trees;
   if something needs them in the future, they can be easily added back,
   but wasting GTY just in case...
5) actually syncs __SIZEOF_FLOAT128__ with the __float128 macro being
   defined in addition to __ieee128 being usable

Now, in the PR Segher said he doesn't like 5), but I think it is better
to match the reality and get this PR fixed and if we want to rethink
how __float128 is defined (whether it is a macro, or perhaps another
builtin type like __ieee128 which could be easily done by
   lang_hooks.types.register_builtin_type (ieee128_float_type_node,
  "__ieee128");
   lang_hooks.types.register_builtin_type (ieee128_float_type_node,
  "__float128");
perhaps under some conditions, rethink if the -mfloat128 option exists
and what it does etc., it can be done incrementally and the rs6000-c.cc
hunks in the patch can be easily reverted (appart from the formatting
fix).

Bootstrapped/regtested on powerpc{64le,64}-linux, on powerpc64-linux
with -m32/-m64 testing, ok for trunk?

2022-03-05  Jakub Jelinek  

PR target/99708
* config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Remove
RS6000_BTI_ptr_ieee128_float and RS6000_BTI_ptr_ibm128_float.
(ptr_ieee128_float_type_node, ptr_ibm128_float_type_node): Remove.
* config/rs6000/rs6000-builtin.cc (rs6000_type_string): Return
"unknown" if type_node is NULL first.  Handle ieee128_float_type_node.
(rs6000_init_builtins): Don't initialize ptr_ieee128_float_type_node
and ptr_ibm128_float_type_node.  Set ibm128_float_type_node and
ieee128_float_type_node to NULL rather than long_double_type_node if
they aren't supported.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
__SIZEOF_FLOAT128__ here and only if __float128 macro is defined.
(rs6000_cpu_cpp_builtins): Don't define __SIZEOF_FLOAT128__ here.
Formatting fix.
* config/rs6000/rs6000-gen-builtins.cc (TYPE_MAP_SIZE): Set to
85 instead of 86.
(type_map): For "if" use ibm128_float_type_node only if it is
non-NULL, otherwise fall back to long_double_type_node.  Remove "pif"
entry.

* gcc.dg/pr99708.c: New test.
* gcc.target/powerpc/pr99708-2.c: New test.

--- gcc/config/rs6000/rs6000.h.jj   2022-02-04 14:36:54.546611710 +0100
+++ gcc/config/rs6000/rs6000.h  2022-03-04 16:45:59.962329746 +0100
@@ -2444,8 +2444,6 @@ enum rs6000_builtin_type_index
   RS6000_BTI_ptr_long_double,
   RS6000_BTI_ptr_dfloat64,
   RS6000_BTI_ptr_dfloat128,
-  RS6000_BTI_ptr_ieee128_float,
-  RS6000_BTI_ptr_ibm128_float,
   RS6000_BTI_ptr_vector_pair,
   RS6000_BTI_ptr_vector_quad,
   RS6000_BTI_ptr_long_long,
@@ -2541,8 +2539,6 @@ enum rs6000_builtin_type_index
 #define ptr_long_double_type_node   
(rs6000_builtin_types[RS6000_BTI_ptr_long_double])
 #define ptr_dfloat64_type_node  
(rs6000_builtin_types[RS6000_BTI_ptr_dfloat64])
 #define ptr_dfloat128_type_node 
(rs6000_builtin_types[RS6000_BTI_ptr_dfloat128])
-#define ptr_ieee128_float_type_node 
(rs6000_builtin_types[RS6000_BTI_ptr_ieee128_float])
-#define ptr_ibm128_float_type_node  
(rs6000_builtin_types[RS6000_BTI_ptr_ibm128_float])
 #define ptr_vector_pair_type_node   
(rs6000_builtin_types[RS6000_BTI_ptr_vector_pair])
 #define ptr_vector_quad_type_node   
(rs6000_builtin_types[RS6000_BTI_ptr_vector_quad])
 #define ptr_long_long_integer_type_node 
(rs6000_builtin_types[RS6000_BTI_ptr_long_long])
--- gcc/config/rs6000/rs6000-builtin.cc.jj  2022-02-04 14:36:54.499612366 
+0100
+++ gcc/config/rs6000/rs6000-builtin.cc 2022-03-04 16:46:07.978218984 +0100
@@ -402,7 +402,9 @@ rs6000_vector_type (const char *name, tr
 static
 const char *rs6000_type_string (tree type_node)
 {
-  if (type_node == void_type_node)
+  if (type_node == NULL_TREE)
+return "unknown";
+  else if (type_node == void_type_node)
 return "void";
   else if (type_node == long_integer_type_node)
 return "long";
@@ -432,6 +434,8

[PATCH] s390: Fix up *cmp_and_trap_unsigned_int constraints [PR104775]

2022-03-05 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
insn not being accepted by assembler.
My rough understanding is that in the RSY-b insn format the spot
in other formats used for index registers is used instead for M3 what
kind of comparison it is, so this patch follows what other similar
instructions use for constraint (i.e. one without index register).

Bootstrapped on s390x-linux, regtest there still pending, ok for
trunk if it passes it?

2022-03-05  Jakub Jelinek  

PR target/104775
* config/s390/s390.md (*cmp_and_trap_unsigned_int): Use
S constraint instead of T in the last alternative.

* gcc.target/s390/pr104775.c: New test.

--- gcc/config/s390/s390.md.jj  2022-02-08 20:08:13.873404137 +0100
+++ gcc/config/s390/s390.md 2022-03-04 14:38:23.252988476 +0100
@@ -9578,7 +9578,7 @@ (define_insn "*cmp_and_trap_signed_int"
   [(trap_if (match_operator 0 "s390_unsigned_integer_comparison"
   [(match_operand:GPR 1 "register_operand" "d,d,d")
-   (match_operand:GPR 2 "general_operand"  "d,D,T")])
+   (match_operand:GPR 2 "general_operand"  "d,D,S")])
(const_int 0))]
   "TARGET_Z10"
   "@
--- gcc/testsuite/gcc.target/s390/pr104775.c.jj 2022-03-04 14:49:58.190134898 
+0100
+++ gcc/testsuite/gcc.target/s390/pr104775.c2022-03-04 14:49:42.845352647 
+0100
@@ -0,0 +1,14 @@
+/* PR target/104775 */
+/* { dg-do assemble { target s390_zEC12_hw } } */
+/* { dg-options "-O2 -march=zEC12" } */
+
+long a[64];
+void bar (void);
+
+void
+foo (int x, int y)
+{
+  if (x != a[y])
+bar ();
+  __builtin_trap ();
+}

Jakub



Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-05 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-03-05 at 09:36 +0800, Paul Hua wrote:
> > 
> > And based on the history of RISC-V port
> > (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the
> > process
> > for a new port seems:
> > 
> > 1. Get a permission from the Steering Committee.
> > 2. Add one or two port maintainers into MAINTAINERS file.
> > 3. Now the technical reviewing of the patch series just begin.
> > 
> 
> Hi Ruoyao,
> Thanks for your advice.  But I don't know how to contact the GCC
> Steering Committee.

https://gcc.gnu.org/steering.html

It says the best place to reach the SC members is the list
g...@gcc.gnu.org.

And Joseph is also a SC member.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] waccess: Remove visited bitmap and stop on EDGE_ABNORMAL

2022-03-05 Thread Richard Biener via Gcc-patches



> Am 05.03.2022 um 09:08 schrieb Jakub Jelinek via Gcc-patches 
> :
> 
> On Fri, Mar 04, 2022 at 02:58:37PM +0100, Jakub Jelinek via Gcc-patches 
> wrote:
>> On Thu, Mar 03, 2022 at 05:08:30PM -0700, Martin Sebor wrote:
 1) shouldn't it give up for EDGE_ABNORMAL too?  I mean, e.g.
following a non-local goto forced edge from a noreturn call
to a non-local label (if there is just one) doesn't seem
right to me
>>> 
>>> Possibly yes.  I can add it but I don't have a lot of experience with
>>> these bits so if you can suggest a test case to exercise this that
>>> would be helpful.
>> 
>> Something like:
>> void
>> foo (void)
>> {
>>  __label__ l;
>>  __attribute__((noreturn)) void bar (int x) { if (x) goto l; __builtin_trap 
>> (); }
>>  bar (0);
>> l:;
>> }
>> shows a single EDGE_ABNORMAL from the bar call.
>> But it would need tweaking for the ptr use and clobber.
>> 
 2) if EDGE_DFS_BACK is computed and 1) is done, is there any
reason why you need 2 levels of protection, i.e. the EDGE_DFS_BACK
check as well as the visited bitmap (and having them use
very different answers, if EDGE_DFS_BACK is seen, the function
will return false, if visited bitmap has a bb, it will return true)?
Can't the visited bitmap go away?
>>> 
>>> Possibly.  As I said above, I don't have enough experience with these
>>> bits to make (and test) the changes quickly, or enough bandwidth to
>>> come up to speed on them.  Please feel free to make these improvements.
>> 
>> I'll change that if it passes testing.
> 
> Here is a patch to do both.  I don't think we really need to have a testcase
> for the EDGE_ABNORMAL case (Martin, feel free to add it later), abnormal
> edges simply aren't normal control flow and what exactly it means varies.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard 

> 2022-03-05  Jakub Jelinek  
> 
>* gimple-ssa-warn-access.cc (pass_waccess::use_after_inval_p): Remove
>visited bitmap and its use.  Also punt on EDGE_ABNORMAL edges.
> 
> --- gcc/gimple-ssa-warn-access.cc.jj2022-03-03 22:09:22.073800776 +0100
> +++ gcc/gimple-ssa-warn-access.cc2022-03-04 19:21:18.840416075 +0100
> @@ -3812,20 +3812,15 @@ pass_waccess::use_after_inval_p (gimple
>   /* Proceed only when looking for uses of dangling pointers.  */
>   auto gsi = gsi_for_stmt (use_stmt);
> 
> -  auto_bitmap visited;
> -
>   /* A use statement in the last basic block in a function or one that
> falls through to it is after any other prior clobber of the used
> variable unless it's followed by a clobber of the same variable. */
>   basic_block bb = use_bb;
>   while (bb != inval_bb
> && single_succ_p (bb)
> - && !(single_succ_edge (bb)->flags & (EDGE_EH|EDGE_DFS_BACK)))
> + && !(single_succ_edge (bb)->flags
> +  & (EDGE_EH | EDGE_ABNORMAL | EDGE_DFS_BACK)))
>{
> -  if (!bitmap_set_bit (visited, bb->index))
> -/* Avoid cycles. */
> -return true;
> -
>  for (; !gsi_end_p (gsi); gsi_next_nondebug (&gsi))
>{
>  gimple *stmt = gsi_stmt (gsi);
> 
> 
>Jakub
> 


[PATCH] x86: Disable SSE on unwind-c.c and unwind-dw2.c

2022-03-05 Thread H.J. Lu via Gcc-patches
Since eh_return doesn't work with stack realignment, disable SSE on
unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte
incoming stack to avoid SSE usage which is caused by

commit 609e8c492d62d92465460eae3d43dfc4b2c68288
Author: H.J. Lu 
Date:   Sat Feb 26 14:17:23 2022 -0800

x86: Always return pseudo register in ix86_gen_scratch_sse_rtx

when pseudo vector registers are used to expand memset.

gcc/

PR target/104781
* config/i386/i386.cc (ix86_expand_epilogue): Assert there is
no stack realignment for eh_return.

gcc/testsuite/

* gcc.target/i386/eh_return-1.c: Add -mincoming-stack-boundary=4.
* gcc.target/i386/eh_return-2.c: Likewise.

libgcc/

PR target/104781
* config.host (tmake_file): Add i386/32/t-eh-return-no-sse for
32-bit x86 Cygwin and Solaris.
* config/i386/32/t-eh-return-no-sse: New file.
---
 gcc/config/i386/i386.cc |  5 ++---
 gcc/testsuite/gcc.target/i386/eh_return-1.c |  2 +-
 gcc/testsuite/gcc.target/i386/eh_return-2.c |  2 +-
 libgcc/config.host  | 13 +
 libgcc/config/i386/32/t-eh-return-no-sse|  5 +
 5 files changed, 22 insertions(+), 5 deletions(-)
 create mode 100644 libgcc/config/i386/32/t-eh-return-no-sse

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 95219902694..1c675304e32 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -9444,9 +9444,8 @@ ix86_expand_epilogue (int style)
  rtx sa = EH_RETURN_STACKADJ_RTX;
  rtx_insn *insn;
 
- /* %ecx can't be used for both DRAP register and eh_return.  */
- if (crtl->drap_reg)
-   gcc_assert (REGNO (crtl->drap_reg) != CX_REG);
+ /* Stack realignment doesn't work with eh_return.  */
+ gcc_assert (!crtl->stack_realign_needed);
 
  /* regparm nested functions don't work with eh_return.  */
  gcc_assert (!ix86_static_chain_on_stack);
diff --git a/gcc/testsuite/gcc.target/i386/eh_return-1.c 
b/gcc/testsuite/gcc.target/i386/eh_return-1.c
index b21fd75fc93..43f94f01a97 100644
--- a/gcc/testsuite/gcc.target/i386/eh_return-1.c
+++ b/gcc/testsuite/gcc.target/i386/eh_return-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=haswell -mno-avx512f 
-mtune-ctrl=avx256_move_by_pieces" } */
+/* { dg-options "-O2 -mincoming-stack-boundary=4 -march=haswell -mno-avx512f 
-mtune-ctrl=avx256_move_by_pieces" } */
 
 struct _Unwind_Context
 {
diff --git a/gcc/testsuite/gcc.target/i386/eh_return-2.c 
b/gcc/testsuite/gcc.target/i386/eh_return-2.c
index f23f4492dac..cb762f92cc2 100644
--- a/gcc/testsuite/gcc.target/i386/eh_return-2.c
+++ b/gcc/testsuite/gcc.target/i386/eh_return-2.c
@@ -1,6 +1,6 @@
 /* PR target/101772  */
 /* { dg-do compile } */
-/* { dg-additional-options "-O0 -march=x86-64 -mstackrealign" } */
+/* { dg-additional-options "-O0 -mincoming-stack-boundary=4 -march=x86-64 
-mstackrealign" } */
 
 struct _Unwind_Context _Unwind_Resume_or_Rethrow_this_context;
 
diff --git a/libgcc/config.host b/libgcc/config.host
index 094fd3ad254..7ac379d1fd4 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1583,3 +1583,16 @@ case ${host} in
   tmake_file="$tmake_file t-gthr-noweak"
   ;;
 esac
+
+case ${host} in
+i[34567]86-*-* | x86_64-*-*)
+  if test "${host_address}" = 32; then
+case ${host} in
+*-*-cygwin* | *-*-solaris2*)
+  # Disable SSE on unwind-c.c and unwind-dw2.c to avoid stack
+  # realignment with the 4-byte aligned incoming stack.
+  tmake_file="${tmake_file} i386/${host_address}/t-eh-return-no-sse"
+  ;;
+esac
+  fi
+esac
diff --git a/libgcc/config/i386/32/t-eh-return-no-sse 
b/libgcc/config/i386/32/t-eh-return-no-sse
new file mode 100644
index 000..5a8c3135911
--- /dev/null
+++ b/libgcc/config/i386/32/t-eh-return-no-sse
@@ -0,0 +1,5 @@
+# Since eh_return doesn't work with stack realignment, disable SSE on
+# unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte
+# incoming stack.
+
+unwind-c.o unwind-c_s.o unwind-dw2.o unwind-dw2_s.o : HOST_LIBGCC2_CFLAGS += 
-mno-sse
-- 
2.35.1



[r12-7502 Regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg" on Linux/x86_64

2022-03-05 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

8ea4a34bd0b0a46277b5e077c89cbd86dfb09c48 is the first bad commit
commit 8ea4a34bd0b0a46277b5e077c89cbd86dfb09c48
Author: Roger Sayle 
Date:   Sat Mar 5 08:50:45 2022 +

PR 104732: Simplify/fix DI mode logic expansion/splitting on -m32.

caused

FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-7502/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/lower-subreg-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/lower-subreg-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


[committed] libstdc++: Ensure __glibcxx_assert_fail has default visibility

2022-03-05 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk.

-- >8 --

This ensures there's no linker error if libstdc++ headers are included
following a pragma that sets hidden visibility.

Similarly for std::__terminate, which is always-inline so shouldn't
matter, but it's not wrong to do this anyway.

libstdc++-v3/ChangeLog:

* include/bits/c++config (__glibcxx_assert_fail): Add visibility
attribute.
(__terminate): Likewise.
---
 libstdc++-v3/include/bits/c++config | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index c64b61b3c90..6c134f13509 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -305,6 +305,7 @@ namespace std
   // This allows the library to terminate without including all of 
   // and without making the declaration of std::terminate visible to users.
   extern "C++" __attribute__ ((__noreturn__, __always_inline__))
+  _GLIBCXX_VISIBILITY(default)
   inline void __terminate() _GLIBCXX_USE_NOEXCEPT
   {
 void terminate() _GLIBCXX_USE_NOEXCEPT __attribute__ ((__noreturn__));
@@ -554,7 +555,7 @@ namespace std
 {
   // Avoid the use of assert, because we're trying to keep the 
   // include out of the mix.
-  extern "C++" _GLIBCXX_NORETURN
+  extern "C++" _GLIBCXX_NORETURN _GLIBCXX_VISIBILITY(default)
   void
   __glibcxx_assert_fail(const char* __file, int __line,
const char* __function, const char* __condition)
-- 
2.34.1