Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx601.security-mail.net
X-Postfix-Queue-ID: 81E033ACDEB
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 10:40:49 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
Hi!

The spaceship-synth-neg6.C testcase ICEs because we call cat_tag_for
on the explicit return type, but pointer types don't have
TYPE_LINKAGE_IDENTIFIER.  The patch fixes that.
Or should I be checking for if (!CLASS_TYPE_P (type)) return cc_last;
instead (are class type guaranteed to have TYPE_LINKAGE_IDENTIFIER?)?
I also wonder if after finding a match we shouldn't verify if is
a class type in std namespace (i.e. that
TYPE_NAME (TYPE_MAIN_VARIANT (type)) is a TYPE_DECL and
decl_in_std_namespace_p (TYPE_NAME (TYPE_MAIN_VARIANT (type)))
because it seems nothing prevents it from returning non-cc_last say on
namespace N {
  struct partial_ordering {};
}
etc.

The g++.dg/cpp2a/spaceship-synth11.C testcase is from a PR that has been
fixed with r12-619-gfc178519771db508c03611cff4a1466cf67fce1d (but
not backported to 11).

Bootstrapped/regtested on x86_64-linux and i686-linux.

2021-08-10  Jakub Jelinek  

gcc/cp/
PR c++/94162
* method.c (cat_tag_for): Return cc_last for types with no
linkage identifier.
gcc/testsuite/
PR c++/99429
* g++.dg/cpp2a/spaceship-synth11.C: New test.

PR c++/94162
* g++.dg/cpp2a/spaceship-synth-neg6.C: New test.

--- gcc/cp/method.c.jj  2021-06-25 10:36:22.169019953 +0200
+++ gcc/cp/method.c 2021-08-09 12:26:38.590166006 +0200
@@ -1029,6 +1029,8 @@ is_cat (tree type, comp_cat_tag tag)
 static comp_cat_tag
 cat_tag_for (tree type)
 {
+  if (!TYPE_LINKAGE_IDENTIFIER (type))
+return cc_last;
   for (int i = 0; i < cc_last; ++i)
 {
   comp_cat_tag tag = (comp_cat_tag)i;
--- gcc/testsuite/g++.dg/cpp2a/spaceship-synth11.C.jj   2021-08-09 
12:28:58.748240310 +0200
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-synth11.C  2021-08-09 
12:29:44.023618250 +0200
@@ -0,0 +1,29 @@
+// PR c++/99429
+// { dg-do compile { target c++20 } }
+
+namespace std {
+struct strong_ordering {
+  int _v;
+  constexpr strong_ordering (int v) :_v(v) {}
+  constexpr operator int (void) const { return _v; }
+  static const strong_ordering less;
+  static const strong_ordering equal;
+  static const strong_ordering greater;
+};
+constexpr strong_ordering strong_ordering::less = -1;
+constexpr strong_ordering strong_ordering::equal = 0;
+constexpr strong_ordering strong_ordering::greater = 1;
+}
+
+template 
+struct duration {
+  static constexpr const long period = N;
+  constexpr duration (void) = default;
+  constexpr duration (const duration& d) = default;
+  constexpr bool operator== (const duration& d) const = default;
+  constexpr bool operator<=> (const duration& d) const = default;
+  long _d;
+};
+
+using nanoseconds = duration<1>;
+using microseconds = duration;
--- gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg6.C.jj2021-08-09 
12:31:47.411922957 +0200
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg6.C   2021-08-09 
12:35:26.995906403 +0200
@@ -0,0 +1,11 @@
+// PR c++/94162
+// { dg-do compile { target c++20 } }
+
+#include 
+
+struct S {
+  int a;   // { dg-error "three-way comparison of 'S::a' 
has type 'std::strong_ordering', which does not convert to 'int\\*'" }
+  int *operator<=>(const S&) const = default;
+};
+
+bool b = S{} < S{};// { dg-error "use of deleted function 
'constexpr int\\* S::operator<=>\\\(const S&\\\) const'" }

Jakub



To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=1a4c.61123b70.e4e73.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=%5BPATCH%5D+c%2B%2B%3A+Fix+ICE+on+defaulted+spaceship+with+pointer+return+type+%5BPR94162%5D&verdict=C&c=1a81d13ef5acc37fb1148ec14fcd34221032f1c5--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx308.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx308.security-mail.net
X-Postfix-Queue-ID: 150AB233363
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 10:45:57 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
Hi!

On the following testcase we emit
vmovdqa32   .LC0(%rip), %zmm1
vpermd  %zmm0, %zmm1, %zmm0
and
vmovdqa64   .LC1(%rip), %zmm1
vpermq  %zmm0, %zmm1, %zmm0
instead of
vshufi32x4  $78, %zmm0, %zmm0, %zmm0
and
vshufi64x2  $78, %zmm0, %zmm0, %zmm0
we can emit with the patch.  We have patterns that match two argument
permutations for vshuf[if]*, but for one argument it doesn't trigger.
Either we can add two patterns for that, or we would need to add another
routine to i386-expand.c that would transform under certain condition
these cases to the two argument vshuf*, doing it in sse.md looked simpler.
We don't need this for 32-byte vectors, we already emit single insn
permutation that doesn't need memory op there.

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

2021-08-10  Jakub Jelinek  

PR target/80355
* config/i386/sse.md (*avx512f_shuf_64x2_1_1,
*avx512f_shuf_32x4_1_1): New define_insn
patterns.

* gcc.target/i386/avx512f-pr80355-1.c: New test.

--- gcc/config/i386/sse.md.jj   2021-08-05 10:26:15.592554985 +0200
+++ gcc/config/i386/sse.md  2021-08-09 13:31:49.025479889 +0200
@@ -15320,6 +15320,42 @@ (define_insn "avx512f_shuf_
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
+(define_insn "*avx512f_shuf_64x2_1_1"
+  [(set (match_operand:V8FI 0 "register_operand" "=v")
+   (vec_select:V8FI
+ (match_operand:V8FI 1 "register_operand" "v")
+ (parallel [(match_operand 2 "const_0_to_7_operand")
+(match_operand 3 "const_0_to_7_operand")
+(match_operand 4 "const_0_to_7_operand")
+(match_operand 5 "const_0_to_7_operand")
+(match_operand 6 "const_0_to_7_operand")
+(match_operand 7 "const_0_to_7_operand")
+(match_operand 8 "const_0_to_7_operand")
+(match_operand 9 "const_0_to_7_operand")])))]
+  "TARGET_AVX512F
+   && (INTVAL (operands[2]) & 1) == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
+   && (INTVAL (operands[4]) & 1) == 0
+   && INTVAL (operands[4]) == INTVAL (operands[5]) - 1
+   && (INTVAL (operands[6]) & 1) == 0
+   && INTVAL (operands[6]) == INTVAL (operands[7]) - 1
+   && (INTVAL (operands[8]) & 1) == 0
+   && INTVAL (operands[8]) == INTVAL (operands[9]) - 1"
+{
+  int mask;
+  mask = INTVAL (operands[2]) / 2;
+  mask |= INTVAL (operands[4]) / 2 << 2;
+  mask |= INTVAL (operands[6]) / 2 << 4;
+  mask |= INTVAL (operands[8]) / 2 << 6;
+  operands[2] = GEN_INT (mask);
+
+  return "vshuf64x2\t{%2, %1, %1, 
%0|%0, %1, %1, %2}";
+}
+  [(set_attr "type" "sselog")
+   (set_attr "length_immediate" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
 (define_expand "avx512vl_shuf_32x4_mask"
   [(match_operand:VI4F_256 0 "register_operand")
(match_operand:VI4F_256 1 "register_operand")
@@ -15463,6 +15499,58 @@ (define_insn "avx512f_shuf_
 }
   [(set_attr "type" "sselog")
(set_attr "length_immediate" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "*avx512f_shuf_32x4_1_1"
+  [(set (match_operand:V16FI 0 "register_operand" "=v")
+   (vec_select:V16FI
+ (match_operand:V16FI 1 "register_operand" "v")
+ (parallel [(match_operand 2 "const_0_to_15_operand")
+(match_operand 3 "const_0_to_15_operand")
+(match_operand 4 "const_0_to_15_operand")
+(match_operand 5 "const_0_to_15_operand")
+(match_operand 6 "const_0_to_15_operand")
+(match_operand 7 "const_0_to_15_operand")
+(match_operand 8 "const_0_to_15_operand")
+(match_operand 9 "const_0_to_15_operand")
+(match_operand 10 "const_0_to_15_operand")
+(match_operand 11 "const_0_to_15_operand")
+(

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx308.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx308.security-mail.net
X-Postfix-Queue-ID: 1A1F82385F1
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 11:08:46 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
Hi!

When working on the PR, I've noticed we generate terrible code for
V32HImode or V64QImode permutations for -mavx512f -mno-avx512bw.
Generally we can't do much with such permutations, but since PR68655
we can handle at least some, those expressible using V16SImode or V8DImode
permutations, but that wasn't reachable, because ix86_vectorize_vec_perm_const
didn't even try, it said without TARGET_AVX512BW it can't do anything, and
with it can do everything, no d.testing_p attempts.

This patch makes it try it for TARGET_AVX512F && !TARGET_AVX512BW.

The first hunk is to avoid ICE, expand_vec_perm_even_odd_1 asserts d->vmode
isn't V32HImode because expand_vec_perm_1 for AVX512BW handles already
all permutations, but when we let it through without !TARGET_AVX512BW,
expand_vec_perm_1 doesn't handle it.

If we want, that hunk can be dropped if we implement in
expand_vec_perm_even_odd_1 and its helper the even permutation as
vpmovdw + vpmovdw + vinserti64x4 and odd permutation as
vpsrld $16 + vpsrld $16 + vpmovdw + vpmovdw + vinserti64x4.

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

2021-08-10  Jakub Jelinek  

PR target/80355
* config/i386/i386-expand.c (expand_vec_perm_even_odd): Return false
for V32HImode if !TARGET_AVX512BW.
(ix86_vectorize_vec_perm_const) :
If !TARGET_AVX512BW and TARGET_AVX512F and d.testing_p, don't fail
early, but actually check the permutation.

* gcc.target/i386/avx512f-pr80355-2.c: New test.

--- gcc/config/i386/i386-expand.c.jj2021-08-05 10:26:15.589555028 +0200
+++ gcc/config/i386/i386-expand.c   2021-08-09 14:14:35.466268680 +0200
@@ -20337,6 +20337,11 @@ expand_vec_perm_even_odd (struct expand_
 if (d->perm[i] != 2 * i + odd)
   return false;
 
+  if (d->vmode == E_V32HImode
+  && d->testing_p
+  && !TARGET_AVX512BW)
+return false;
+
   return expand_vec_perm_even_odd_1 (d, odd);
 }
 
@@ -20877,16 +20882,16 @@ ix86_vectorize_vec_perm_const (machine_m
return true;
   break;
 case E_V32HImode:
-  if (!TARGET_AVX512BW)
+  if (!TARGET_AVX512F)
return false;
-  if (d.testing_p)
+  if (d.testing_p && TARGET_AVX512BW)
/* All implementable with a single vperm[it]2 insn.  */
return true;
   break;
 case E_V64QImode:
-  if (!TARGET_AVX512BW)
+  if (!TARGET_AVX512F)
return false;
-  if (d.testing_p)
+  if (d.testing_p && TARGET_AVX512BW)
/* Implementable with 2 vperm[it]2, 2 vpshufb and 1 or insn.  */
return true;
   break;
--- gcc/testsuite/gcc.target/i386/avx512f-pr80355-2.c.jj2021-08-09 
14:24:27.176142589 +0200
+++ gcc/testsuite/gcc.target/i386/avx512f-pr80355-2.c   2021-08-09 
14:29:23.308074276 +0200
@@ -0,0 +1,23 @@
+/* PR target/80355 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx512f -mno-avx512vl -mno-avx512dq -mno-avx512bw" } */
+/* { dg-final { scan-assembler-times "\tvshufi(?:32x4|64x2)\t" 2 } } */
+
+typedef short V __attribute__((vector_size (64)));
+typedef char W __attribute__((vector_size (64)));
+
+W
+f0 (W x)
+{
+  return __builtin_shuffle (x, (W) { 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 
42, 43, 44, 45, 46, 47,
+48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 
58, 59, 60, 61, 62, 63,
+0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 
13, 14, 15, 16,
+17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 
27, 28, 29, 30, 31 });
+}
+
+V
+f1 (V x)
+{
+  return __builtin_shuffle (x, (V) { 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 
26, 27, 28, 29, 30, 31,
+0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 
13, 14, 15 });
+}

Jakub



To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=bf1d.61123f06.99556.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3D

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx306.security-mail.net
X-Postfix-Queue-ID: A4AD8399578
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 11:12:06 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, Aug 10, 2021 at 4:44 PM Jakub Jelinek  wrote:
>
> Hi!
>
> On the following testcase we emit
> vmovdqa32   .LC0(%rip), %zmm1
> vpermd  %zmm0, %zmm1, %zmm0
> and
> vmovdqa64   .LC1(%rip), %zmm1
> vpermq  %zmm0, %zmm1, %zmm0
> instead of
> vshufi32x4  $78, %zmm0, %zmm0, %zmm0
> and
> vshufi64x2  $78, %zmm0, %zmm0, %zmm0
> we can emit with the patch.  We have patterns that match two argument
> permutations for vshuf[if]*, but for one argument it doesn't trigger.
> Either we can add two patterns for that, or we would need to add another
> routine to i386-expand.c that would transform under certain condition
> these cases to the two argument vshuf*, doing it in sse.md looked simpler.
Yes, we already have
avx512dq_shuf_64x2_1 and
avx512f_shuf_32x4_1, it's simpler to add
another 2 patterns with similar logic but selected from only 1 vector
instead of 2 vectors.
Patch LGTM.
> We don't need this for 32-byte vectors, we already emit single insn
> permutation that doesn't need memory op there.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2021-08-10  Jakub Jelinek  
>
> PR target/80355
> * config/i386/sse.md (*avx512f_shuf_64x2_1_1,
> *avx512f_shuf_32x4_1_1): New define_insn
> patterns.
>
> * gcc.target/i386/avx512f-pr80355-1.c: New test.
>
> --- gcc/config/i386/sse.md.jj   2021-08-05 10:26:15.592554985 +0200
> +++ gcc/config/i386/sse.md  2021-08-09 13:31:49.025479889 +0200
> @@ -15320,6 +15320,42 @@ (define_insn "avx512f_shuf_
> (set_attr "prefix" "evex")
> (set_attr "mode" "")])
>
> +(define_insn "*avx512f_shuf_64x2_1_1"
> +  [(set (match_operand:V8FI 0 "register_operand" "=v")
> +   (vec_select:V8FI
> + (match_operand:V8FI 1 "register_operand" "v")
> + (parallel [(match_operand 2 "const_0_to_7_operand")
> +(match_operand 3 "const_0_to_7_operand")
> +(match_operand 4 "const_0_to_7_operand")
> +(match_operand 5 "const_0_to_7_operand")
> +(match_operand 6 "const_0_to_7_operand")
> +(match_operand 7 "const_0_to_7_operand")
> +(match_operand 8 "const_0_to_7_operand")
> +(match_operand 9 "const_0_to_7_operand")])))]
> +  "TARGET_AVX512F
> +   && (INTVAL (operands[2]) & 1) == 0
> +   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
> +   && (INTVAL (operands[4]) & 1) == 0
> +   && INTVAL (operands[4]) == INTVAL (operands[5]) - 1
> +   && (INTVAL (operands[6]) & 1) == 0
> +   && INTVAL (operands[6]) == INTVAL (operands[7]) - 1
> +   && (INTVAL (operands[8]) & 1) == 0
> +   && INTVAL (operands[8]) == INTVAL (operands[9]) - 1"
> +{
> +  int mask;
> +  mask = INTVAL (operands[2]) / 2;
> +  mask |= INTVAL (operands[4]) / 2 << 2;
> +  mask |= INTVAL (operands[6]) / 2 << 4;
> +  mask |= INTVAL (operands[8]) / 2 << 6;
> +  operands[2] = GEN_INT (mask);
> +
> +  return "vshuf64x2\t{%2, %1, %1, 
> %0|%0, %1, %1, %2}";
> +}
> +  [(set_attr "type" "sselog")
> +   (set_attr "length_immediate" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
>  (define_expand "avx512vl_shuf_32x4_mask"
>[(match_operand:VI4F_256 0 "register_operand")
> (match_operand:VI4F_256 1 "register_operand")
> @@ -15463,6 +15499,58 @@ (define_insn "avx512f_shuf_
>  }
>[(set_attr "type" "sselog")
> (set_attr "length_immediate" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
> +(define_insn "*avx512f_shuf_32x4_1_1"
> +  [(set (match_operand:V16FI 0 "register_operand" "=v")
> +   (vec_select:V16FI
> + (match_operand:V16FI 1 "register_operand" "v")
> + (parallel [(match_operand 2 "const_0_to_15_operand")
> +(match_operand 3 "const_0_to_15_operand")
> +(match_operand 4 "const_0_to_15_operand")
> +(match_operand 5 "con

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx409.security-mail.net
X-Postfix-Queue-ID: 1E0B63238E5
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 11:35:17 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
Return-Path: 
Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by
 fx409.security-mail.net (Postfix) with ESMTPS id F3866323659 for
 ; Tue, 10 Aug 2021 11:35:12 +0200 (CEST)
Received: from server2.sourceware.org (localhost [IPv6:::1]) by
 sourceware.org (Postfix) with ESMTP id B6F2B385701D for
 ; Tue, 10 Aug 2021 09:35:11 + (GMT)
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org
 (Postfix) with ESMTP id BE86B385780A for ; Tue, 10
 Aug 2021 09:34:14 + (GMT)
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-267-G_Xo3-M5MmuNjX1L_mR37w-1; Tue, 10 Aug 2021 05:34:13 -0400
Received: from smtp.corp.redhat.com
 (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with
 cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by
 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 30713801AE7 for
 ; Tue, 10 Aug 2021 09:34:12 + (UTC)
Received: from tucnak.zalov.cz (unknown [10.39.193.120]) by
 smtp.corp.redhat.com (Postfix) with ESMTPS id 8696A60854 for
 ; Tue, 10 Aug 2021 09:34:11 + (UTC)
Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz
 (8.16.1/8.16.1) with ESMTPS id 17A9Y4Cp1033420 (version=TLSv1.3
 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for
 ; Tue, 10 Aug 2021 11:34:05 +0200
Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit)
 id 17A9Y3qn1033419 for gcc-patches@gcc.gnu.org; Tue, 10 Aug 2021 11:34:03
 +0200
X-Quarantine-ID: 
X-Virus-Scanned: E-securemail, by Secumail
X-Spam-Status: No, score=0.379 tagged_above=-1000 required=7.5
 tests=[AB_ENVFROM_LONG_40=0.5, AB_LONG_SUBJ_30=0.001,
 DCC_REPUT_00_12=-0.002, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1,
 FSL_HTML_ENT_LOTS_1=0.01, FSL_HTML_ENT_LOTS_2=0.01,
 FSL_HTML_ENT_LOTS_3=0.01, FSL_RCVD_EX_GT_5=1, FSL_RCVD_UT_GT_5=0.01,
 HEAD_NEWS=-0.5, MISSING_MID=0.14, MM_ENVFROM_BOUNCE=1,
 RCVD_IN_DNSWL_MED=-1.3, S_FROM_GREY_MINUS_2=-2, S_KW_BODY_EXPLICIT_=2.5]
 autolearn=disabled
Authentication-Results: fx409.security-mail.net (amavisd-new); dkim=pass
 (1024-bit key) header.d=gcc.gnu.org
Secumail-id: 
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6F2B385701D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1628588111; bh=tzbRKtW8BXS1CQn+wgSaigrquTg45e3ecyRzvcn0FYM=;
 h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
 List-Help:List-Subscribe:From:Reply-To:From;
 b=m1IYcNVEW2hG3e/52ghShfxcz32xe1EBeH51vhGVSmVQj4FFtojpazNk4IUqhRSLD
 nW6UrLkcpZZjrmYPchWodiMWd+lK4HUY9PvNo3BGysN58F34INWcMZ1frxjwZbwLjY
 2dXwkFAgNHQgkbGIA7dEnGyYM+bo5gLajhliRa6A=
X-Original-To: gcc-patches@gcc.gnu.org
Delivered-To: gcc-patches@gcc.gnu.org
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE86B385780A
X-MC-Unique: G_Xo3-M5MmuNjX1L_mR37w-1
Date: Tue, 10 Aug 2021 11:34:03 +0200
To: gcc-patches@gcc.gnu.org
Subject: [committed] openmp: Add support for declare simd and declare
 variant in a attribute syntax
Message-ID: <20210810093403.GK2380545@tucnak>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
From: Jakub Jelinek via Gcc-patches 
Reply-To: Jakub Jelinek 
Errors-To: gcc-patches-bounces+marc.poulhies=kalray...@gcc.gnu.org
Sender: Gcc-patches
 
Content-Type: multipart/alternative; boundary="=_WhqiTbHUGhAxDAymDSJ7Aev"
X-ALTERMIMEV2_in: done

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx302.security-mail.net
X-Postfix-Queue-ID: 7104F3D3B0C8
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 12:09:52 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, Aug 10, 2021 at 4:54 PM Jakub Jelinek  wrote:
>
> Hi!
>
> When working on the PR, I've noticed we generate terrible code for
> V32HImode or V64QImode permutations for -mavx512f -mno-avx512bw.
> Generally we can't do much with such permutations, but since PR68655
> we can handle at least some, those expressible using V16SImode or V8DImode
> permutations, but that wasn't reachable, because ix86_vectorize_vec_perm_const
> didn't even try, it said without TARGET_AVX512BW it can't do anything, and
> with it can do everything, no d.testing_p attempts.
>
> This patch makes it try it for TARGET_AVX512F && !TARGET_AVX512BW.
TARGET_AVX512{F,BW,CD,DQ,VL} will be the baseline for all
AVX512-enabled processors after(including)SKX.
But it's definitely good to have this, patch LGTM.
>
> The first hunk is to avoid ICE, expand_vec_perm_even_odd_1 asserts d->vmode
> isn't V32HImode because expand_vec_perm_1 for AVX512BW handles already
> all permutations, but when we let it through without !TARGET_AVX512BW,
> expand_vec_perm_1 doesn't handle it.
>
> If we want, that hunk can be dropped if we implement in
> expand_vec_perm_even_odd_1 and its helper the even permutation as
> vpmovdw + vpmovdw + vinserti64x4 and odd permutation as
> vpsrld $16 + vpsrld $16 + vpmovdw + vpmovdw + vinserti64x4.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2021-08-10  Jakub Jelinek  
>
> PR target/80355
> * config/i386/i386-expand.c (expand_vec_perm_even_odd): Return false
> for V32HImode if !TARGET_AVX512BW.
> (ix86_vectorize_vec_perm_const) :
> If !TARGET_AVX512BW and TARGET_AVX512F and d.testing_p, don't fail
> early, but actually check the permutation.
>
> * gcc.target/i386/avx512f-pr80355-2.c: New test.
>
> --- gcc/config/i386/i386-expand.c.jj2021-08-05 10:26:15.589555028 +0200
> +++ gcc/config/i386/i386-expand.c   2021-08-09 14:14:35.466268680 +0200
> @@ -20337,6 +20337,11 @@ expand_vec_perm_even_odd (struct expand_
>  if (d->perm[i] != 2 * i + odd)
>return false;
>
> +  if (d->vmode == E_V32HImode
> +  && d->testing_p
> +  && !TARGET_AVX512BW)
> +return false;
> +
>return expand_vec_perm_even_odd_1 (d, odd);
>  }
>
> @@ -20877,16 +20882,16 @@ ix86_vectorize_vec_perm_const (machine_m
> return true;
>break;
>  case E_V32HImode:
> -  if (!TARGET_AVX512BW)
> +  if (!TARGET_AVX512F)
> return false;
> -  if (d.testing_p)
> +  if (d.testing_p && TARGET_AVX512BW)
> /* All implementable with a single vperm[it]2 insn.  */
> return true;
>break;
>  case E_V64QImode:
> -  if (!TARGET_AVX512BW)
> +  if (!TARGET_AVX512F)
> return false;
> -  if (d.testing_p)
> +  if (d.testing_p && TARGET_AVX512BW)
> /* Implementable with 2 vperm[it]2, 2 vpshufb and 1 or insn.  */
> return true;
>break;
> --- gcc/testsuite/gcc.target/i386/avx512f-pr80355-2.c.jj2021-08-09 
> 14:24:27.176142589 +0200
> +++ gcc/testsuite/gcc.target/i386/avx512f-pr80355-2.c   2021-08-09 
> 14:29:23.308074276 +0200
> @@ -0,0 +1,23 @@
> +/* PR target/80355 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mavx512f -mno-avx512vl -mno-avx512dq -mno-avx512bw" } 
> */
> +/* { dg-final { scan-assembler-times "\tvshufi(?:32x4|64x2)\t" 2 } } */
> +
> +typedef short V __attribute__((vector_size (64)));
> +typedef char W __attribute__((vector_size (64)));
> +
> +W
> +f0 (W x)
> +{
> +  return __builtin_shuffle (x, (W) { 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 
> 42, 43, 44, 45, 46, 47,
> +48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 
> 58, 59, 60, 61, 62, 63,
> +0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 
> 12, 13, 14, 15, 16,
> +17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 
> 27, 28, 29, 30, 31 });
> +}
> +
> +V
> +f1 (V x)
> +{
> +  return __buil

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx409.security-mail.net
X-Postfix-Queue-ID: C607A323832
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 12:26:10 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
This adds emulated gather support for index vectors with more
elements than the data vector.  The internal function gather
vectorization code doesn't currently handle this (but the builtin
decl code does).  This allows vectorization of double data gather
with int indexes on 32bit platforms where there isn't an implicit
widening to 64bit present.

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

2021-08-10  Richard Biener  

PR tree-optimization/101809
* tree-vect-stmts.c (get_load_store_type): Allow emulated
gathers with offset vector nunits being a constant multiple
of the data vector nunits.
(vect_get_gather_scatter_ops): Use the appropriate nunits
for the offset vector defs.
(vectorizable_store): Adjust call to
vect_get_gather_scatter_ops.
(vectorizable_load): Likewise.  Handle the case of less
offset vectors than data vectors.
---
 gcc/tree-vect-stmts.c | 47 +++
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 5a5a4dab3f2..ab402b57fb4 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -2377,9 +2377,11 @@ get_load_store_type (vec_info  *vinfo, stmt_vec_info 
stmt_info,
  return false;
}
  else if (!TYPE_VECTOR_SUBPARTS (vectype).is_constant ()
-  || !known_eq (TYPE_VECTOR_SUBPARTS (vectype),
-TYPE_VECTOR_SUBPARTS
-  (gs_info->offset_vectype)))
+  || !TYPE_VECTOR_SUBPARTS
+(gs_info->offset_vectype).is_constant ()
+  || !constant_multiple_p (TYPE_VECTOR_SUBPARTS
+ (gs_info->offset_vectype),
+   TYPE_VECTOR_SUBPARTS (vectype)))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -2928,11 +2930,10 @@ vect_build_gather_load_calls (vec_info *vinfo, 
stmt_vec_info stmt_info,
containing loop.  */
 
 static void
-vect_get_gather_scatter_ops (vec_info *vinfo,
+vect_get_gather_scatter_ops (loop_vec_info loop_vinfo,
 class loop *loop, stmt_vec_info stmt_info,
 gather_scatter_info *gs_info,
-tree *dataref_ptr, vec *vec_offset,
-unsigned ncopies)
+tree *dataref_ptr, vec *vec_offset)
 {
   gimple_seq stmts = NULL;
   *dataref_ptr = force_gimple_operand (gs_info->base, &stmts, true, NULL_TREE);
@@ -2943,8 +2944,10 @@ vect_get_gather_scatter_ops (vec_info *vinfo,
   new_bb = gsi_insert_seq_on_edge_immediate (pe, stmts);
   gcc_assert (!new_bb);
 }
-  vect_get_vec_defs_for_operand (vinfo, stmt_info, ncopies, gs_info->offset,
-vec_offset, gs_info->offset_vectype);
+  unsigned ncopies = vect_get_num_copies (loop_vinfo, gs_info->offset_vectype);
+  vect_get_vec_defs_for_operand (loop_vinfo, stmt_info, ncopies,
+gs_info->offset, vec_offset,
+gs_info->offset_vectype);
 }
 
 /* Prepare to implement a grouped or strided load or store using
@@ -8072,8 +8075,9 @@ vectorizable_store (vec_info *vinfo,
}
  else if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
{
- vect_get_gather_scatter_ops (vinfo, loop, stmt_info, &gs_info,
-  &dataref_ptr, &vec_offsets, ncopies);
+ vect_get_gather_scatter_ops (loop_vinfo, loop, stmt_info,
+  &gs_info, &dataref_ptr,
+  &vec_offsets);
  vec_offset = vec_offsets[0];
}
  else
@@ -9376,9 +9380,9 @@ vectorizable_load (vec

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx409.security-mail.net
X-Postfix-Queue-ID: 4CF1C3237ED
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 13:04:23 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
 wrote:
>
> Some target like RISC-V allow to group vector register as a whole,
> and only operate part of it in fact, but the 'init-regs' pass will add 
> initialization
> for uninitialized registers. Add this hook to reject this action for reducing 
> instruction.

Are these groups "visible"?  That is, are the pseudos multi-reg
pseudos?  I wonder
if there's a more generic way to tame down initregs w/o introducing a new target
hook.

Btw, initregs is a red herring - it ideally should go away.  See PR61810.

So instead of adding to it can you see whether disabling the pass for RISC-V
works w/o fallout (and add a comment to the PR)?  Maybe some more RTL
literate (in particular DF literate) can look at the remaining issue.
Richard, did you
ever have a look into the "issue" that initregs covers up (whatever
that exactly is)?

Thanks,
Richard.

> gcc/
> * init-regs.c (initialize_uninitialized_regs): Call 
> register_reject_init_p.
> * target.def (register_reject_init_p): New hook.
> * doc/tm.texi.in: Add TARGET_REGISTER_REJECT_INIT_P.
> * doc/tm.texi: Regenerated.
> ---
>  gcc/doc/tm.texi| 6 ++
>  gcc/doc/tm.texi.in | 2 ++
>  gcc/init-regs.c| 5 +
>  gcc/target.def | 8 
>  4 files changed, 21 insertions(+)
>
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index a30fdcbbf3d6..83fd5496ca3f 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -12588,3 +12588,9 @@ Return an RTX representing @var{tagged_pointer} with 
> its tag set to zero.
>  Store the result in @var{target} if convenient.
>  The default clears the top byte of the original pointer.
>  @end deftypefn
> +
> +@deftypefn {Target Hook} bool TARGET_REGISTER_REJECT_INIT_P (rtx @var{reg})
> +This target hook should return @code{true} if reject initialization for a 
> uninitialized @var{reg}.
> +
> +The default value of this hook is @code{NULL}.
> +@end deftypefn
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 611fc500ac86..13174ce66d59 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -8180,3 +8180,5 @@ maintainer is familiar with.
>  @hook TARGET_MEMTAG_EXTRACT_TAG
>
>  @hook TARGET_MEMTAG_UNTAGGED_POINTER
> +
> +@hook TARGET_REGISTER_REJECT_INIT_P
> diff --git a/gcc/init-regs.c b/gcc/init-regs.c
> index 72e898f3e334..51c0d669d30b 100644
> --- a/gcc/init-regs.c
> +++ b/gcc/init-regs.c
> @@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> +#include "target.h"
>  #include "rtl.h"
>  #include "tree.h"
>  #include "df.h"
> @@ -101,6 +102,10 @@ initialize_uninitialized_regs (void)
>   rtx_insn *move_insn;
>   rtx reg = DF_REF_REAL_REG (use);
>
> + if (targetm.register_reject_init_p
> + && targetm.register_reject_init_p (reg))
> +   continue;
> +
>   bitmap_set_bit (already_genned, regno);
>
>   start_sequence ();
> diff --git a/gcc/target.def b/gcc/target.def
> index 7676d5e626e3..c2b54421618d 100644
> --- a/gcc/target.def
> +++ b/gcc/target.def
> @@ -4545,6 +4545,14 @@ by a subtarget.",
>   unsigned HOST_WIDE_INT, (void),
>   NULL)
>
> +/* Return true if reject initialization for a uninitialized register.  */
> +DEFHOOK
> +(register_reject_init_p,
> + "This target hook should return @code{true} if reject initialization for a 
> uninitialized @var{reg}.\n\
> +\n\
> +The default value of this hook is @code{NULL}.",
> + bool, (rtx reg), NULL)
> +
>  /* Functions relating to calls - argument passing, returns, etc.  */
>  /* Members of struct call have no special macro prefix.  */
>  HOOK_VECTOR (TARGET_CALLS, calls)
> --
> 2.24.3 (Apple Git-128)
>


To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=1dac.61125d35.60598.0&r=marc.poulhies%4

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx409.security-mail.net
X-Postfix-Queue-ID: BC4F832395A
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 13:41:35 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
The GIMPLE SSA operand scanner handles COMPONENT_REFs that are
not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE
FIELD_DECL as volatile.  That's inconsistent in how TREE_THIS_VOLATILE
testing on GENERIC refs works which requires operand zero of
component references to mirror TREE_THIS_VOLATILE to the ref
so that testing TREE_THIS_VOLATILE on the outermost reference
is enough to determine the volatileness.

The following patch thus removes FIELD_DECL scanning from
the GIMPLE SSA operand scanner, possibly leaving fewer stmts
marked as gimple_has_volatile_ops.

It shows we miss at least one case in the fortran frontend, though
there's a suspicious amount of COMPONENT_REF creation compared
to little setting of TREE_THIS_VOLATILE.  This fixes the FAIL
of gfortran.dg/volatile11.f90 that would otherwise occur.

Visually inspecting fortran/ reveals a bunch of likely to fix
cases but I don't know the constraints of 'volatile' uses in
the fortran language to assess whether some of these are not
necessary.  The cases would be fixed with

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 0d013defdbb..5d708fe90aa 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -6983,9 +6983,10 @@ gfc_get_dataptr_offset (stmtblock_t *block, tree parm, 
tree desc, tree offset,
case REF_COMPONENT:
  field = ref->u.c.component->backend_decl;
  gcc_assert (field && TREE_CODE (field) == FIELD_DECL);
- tmp = fold_build3_loc (input_location, COMPONENT_REF,
-TREE_TYPE (field),
-tmp, field, NULL_TREE);
+ tmp = build3_loc (input_location, COMPONENT_REF,
+   TREE_TYPE (field), tmp, field, NULL_TREE);
+ if (TREE_THIS_VOLATILE (field))
+   TREE_THIS_VOLATILE (tmp) = 1;
  break;

case REF_SUBSTRING:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index c4291cce079..e6dc79f8c1e 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2244,9 +2244,11 @@ gfc_get_tree_for_caf_expr (gfc_expr *expr)

if (POINTER_TYPE_P (TREE_TYPE (caf_decl)))
  caf_decl = build_fold_indirect_ref_loc (input_location, caf_decl);
-   caf_decl = fold_build3_loc (input_location, COMPONENT_REF,
-   TREE_TYPE (comp->backend_decl), caf_decl,
-   comp->backend_decl, NULL_TREE);
+   caf_decl = build3_loc (input_location, COMPONENT_REF,
+  TREE_TYPE (comp->backend_decl), caf_decl,
+  comp->backend_decl, NULL_TREE);
+   if (TREE_THIS_VOLATILE (comp->backend_decl))
+ TREE_THIS_VOLATILE (caf_decl) = 1;
if (comp->ts.type == BT_CLASS)
  {
caf_decl = gfc_class_data_get (caf_decl);
@@ -2755,8 +2757,10 @@ gfc_conv_component_ref (gfc_se * se, gfc_ref * ref)
   else
 se->class_vptr = NULL_TREE;

-  tmp = fold_build3_loc (input_location, COMPONENT_REF, TREE_TYPE (field),
-decl, field, NULL_TREE);
+  tmp =build3_loc (input_location, COMPONENT_REF, TREE_TYPE (field),
+  decl, field, NULL_TREE);
+  if (TREE_THIS_VOLATILE (field))
+TREE_THIS_VOLATILE (tmp) = 1;

   se->expr = tmp;

@@ -8792,8 +8796,10 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, 
bool init, bool coarray)
}
   field = cm->backend_decl;
   gcc_assert(field);
-  tmp = fold_build3_loc (input_location, COMPONENT_REF, TREE_TYPE (field),
-dest, field, NULL_TREE);
+  tmp = build3_loc (input_location, COMPONENT_REF, TREE_TYPE (field),
+   dest, field, NULL_TREE);
+  if (TREE_THIS_VOLATILE (field))
+   TREE_THIS_VOLATILE (tmp) = 1;
   if (!c->expr)
{
  gfc_expr *e = gfc_get_null_expr (NULL);

but I did not

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx302.security-mail.net
X-Postfix-Queue-ID: 39A4C3D3B0AB
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 13:52:45 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Thu, Aug 5, 2021 at 2:54 AM Indu Bhagat via Gcc-patches
 wrote:
>
> -mcore in the BPF backend enables code generation for the CO-RE usecase. LTO 
> is
> disabled for CO-RE compilations.

-mcore reads like "core", why not -mco-re?  Anyway, ...

> gcc/ChangeLog:
>
> * config/bpf/bpf.c (bpf_option_override): For BPF backend, disable LTO
> support when compiling for CO-RE.
> * config/bpf/bpf.opt: Add new command line option -mcore.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/bpf/core-lto-1.c: New test.
> ---
>  gcc/config/bpf/bpf.c  | 15 +++
>  gcc/config/bpf/bpf.opt|  4 
>  gcc/testsuite/gcc.target/bpf/core-lto-1.c |  9 +
>  3 files changed, 28 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c
>
> diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
> index e635f9e..028013e 100644
> --- a/gcc/config/bpf/bpf.c
> +++ b/gcc/config/bpf/bpf.c
> @@ -158,6 +158,21 @@ bpf_option_override (void)
>  {
>/* Set the initializer for the per-function status structure.  */
>init_machine_status = bpf_init_machine_status;
> +
> +  /* To support the portability needs of BPF CO-RE approach, BTF debug
> + information includes the BPF CO-RE relocations.  The information
> + necessary for these relocations is added to the CTF container by the
> + BPF backend.  Enabling LTO poses challenges in the generation of the BPF
> + CO-RE relocations because if LTO is in effect, they need to be
> + generated late in the LTO link phase.  This in turn means the compiler
> + needs to provide means to combine the early and late BTF debug info,
> + similar to DWARF debug info.
> +
> + In any case, in absence of linker support for BTF sections at this time,
> + it is acceptable to simply disallow LTO for BPF CO-RE compilations.  */
> +
> +  if (flag_lto && TARGET_BPF_CORE)
> +error ("BPF CO-RE does not support LTO");

... these "errors" should use sorry ("...") which annotate places where the
compiler has to give up because sth is not implemented.

otherwise this patch needs BPF maintainer review of course.

Richard.

>  }
>
>  #undef TARGET_OPTION_OVERRIDE
> diff --git a/gcc/config/bpf/bpf.opt b/gcc/config/bpf/bpf.opt
> index 916b53c..e8926f5 100644
> --- a/gcc/config/bpf/bpf.opt
> +++ b/gcc/config/bpf/bpf.opt
> @@ -127,3 +127,7 @@ Generate little-endian eBPF.
>  mframe-limit=
>  Target Joined RejectNegative UInteger IntegerRange(0, 32767) 
> Var(bpf_frame_limit) Init(512)
>  Set a hard limit for the size of each stack frame, in bytes.
> +
> +mcore
> +Target Mask(BPF_CORE)
> +Generate all necessary information for BPF Compile Once - Run Everywhere.
> diff --git a/gcc/testsuite/gcc.target/bpf/core-lto-1.c 
> b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
> new file mode 100644
> index 000..a90dc5b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
> @@ -0,0 +1,9 @@
> +/* Test -mcore with -flto.
> +
> +   -mcore is used to generate information for BPF CO-RE usecase. To support
> +   the generataion of the .BTF and .BTF.ext sections in GCC, -flto is 
> disabled
> +   with -mcore.  */
> +
> +/* { dg-do compile } */
> +/* { dg-error "BPF CO-RE does not support LTO" "" { target bpf-*-* } 0 } */
> +/* { dg-options "-gbtf -mcore -flto" } */
> --
> 1.8.3.1
>


To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=fba2.6112688b.8382f.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BPATCH%2CV2+1%2F3%5D+bpf%3A+Add+new+-mcore+option+for+BPF+CO-RE&verdict=C&c=efcea6600b27d77b13aec32ad537dc019d3d10cd--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx601.security-mail.net
X-Postfix-Queue-ID: 22D523ACE06
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 13:55:40 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
 wrote:
>
> This patch adds a new target hook to detect if the CTF container can allow the
> emission of CTF/BTF debug info at DWARF debug info early finish time. Some
> backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
> the CTF/BTF debug info sections around the time when late DWARF debug is
> finalized (dwarf2out_finish).

Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.

Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.

> gcc/ChangeLog:
>
> * config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
> (TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
> * doc/tm.texi: Regenerated.
> * doc/tm.texi.in: Document the new hook.
> * target.def: Add a new hook.
> * targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
> * targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
> ---
>  gcc/config/bpf/bpf.c | 14 ++
>  gcc/doc/tm.texi  |  6 ++
>  gcc/doc/tm.texi.in   |  2 ++
>  gcc/target.def   | 10 ++
>  gcc/targhooks.c  |  6 ++
>  gcc/targhooks.h  |  2 ++
>  6 files changed, 40 insertions(+)
>
> diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
> index 028013e..85f6b76 100644
> --- a/gcc/config/bpf/bpf.c
> +++ b/gcc/config/bpf/bpf.c
> @@ -178,6 +178,20 @@ bpf_option_override (void)
>  #undef TARGET_OPTION_OVERRIDE
>  #define TARGET_OPTION_OVERRIDE bpf_option_override
>
> +/* Return FALSE iff -mcore has been specified.  */
> +
> +static bool
> +ctfc_debuginfo_early_finish_p (void)
> +{
> +  if (TARGET_BPF_CORE)
> +return false;
> +  else
> +return true;
> +}
> +
> +#undef TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
> +#define TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P ctfc_debuginfo_early_finish_p
> +
>  /* Define target-specific CPP macros.  This function in used in the
> definition of TARGET_CPU_CPP_BUILTINS in bpf.h */
>
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index cb01528..2d5ff05 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -10400,6 +10400,12 @@ Define this macro if GCC should produce debugging 
> output in BTF debug
>  format in response to the @option{-gbtf} option.
>  @end defmac
>
> +@deftypefn {Target Hook} bool TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P (void)
> +This target hook returns nonzero if the CTF Container can allow the
> + emission of the CTF/BTF debug info at the DWARF debuginfo early finish
> + time.
> +@end deftypefn
> +
>  @node Floating Point
>  @section Cross Compilation and Floating Point
>  @cindex cross compilation and floating point
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 4a522ae..05b3c2c 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -7020,6 +7020,8 @@ Define this macro if GCC should produce debugging 
> output in BTF debug
>  format in response to the @option{-gbtf} option.
>  @end defmac
>
> +@hook TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
> +
>  @node Floating Point
>  @section Cross Compilation and Floating Point
>  @cindex cross compilation and floating point
> diff --git a/gcc/target.def b/gcc/target.def
> index 68a46aa..44e2251 100644
> --- a/gcc/target.def
> +++ b/gcc/target.def
> @@ -4016,6 +4016,16 @@ clobbered parts of a register altering the frame 
> register size",
>   machine_mode, (int regno),
>   default_dwarf_frame_reg_mode)
>
> +/* Return nonzero if CTF Container can finalize the CTF/BTF emission
> +   at DWARF debuginfo early finish time.  */
> +DEFHOOK
> +(ctfc_debuginfo_early_finish_p,
> + "This target hook returns nonzero if t

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx408.security-mail.net
X-Postfix-Queue-ID: 57DF51B7B40F
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 14:02:24 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Thu, Aug 5, 2021 at 2:53 AM Indu Bhagat via Gcc-patches
 wrote:
>
> DWARF generation is split between early and late phases when LTO is in effect.
> This poses challenges for CTF/BTF generation especially if late debug info
> generation is desirable, as turns out to be the case for BPF CO-RE.
>
> In case of BPF CO-RE, the BPF backend adds information about CO-RE relocations
> to the CTF container. This information is what needs to be emitted as a
> separate .BTF.ext section when -more is in effect. Further, each CO-RE
> relocation record holds an offset to a string specifying the access to the
> structure's field. This means that .BTF string table needs to be modified
> "late" in the compilation process. In other words, this implies that the BTF
> sections cannot be finalized in dwarf2out_early_finish when -mcore for the BPF
> backend is in effect.

OK, it didn't really get any clearer as to why the late annotation
cannot be done
after the early info was output.  Something to do with the BTF string table,
but all structure field names must be already present there so I must be missing
something.

ISTR the CO-RE info is fully contained in a new section .BTF.ext and the
"early" .BTF section is not altered?

> Now, the emission of CTF/BTF debug info cannot be moved unconditionally to
> dwarf2out_finish because dwarf2out_finish is not invoked at all for the LTO
> compile phase for slim LTO objects, thus breaking CTF/BTF generation for other
> targets when used with LTO.
>
> The approach taken here in this patch is that -
>
> 1. LTO is disabled for BPF CO-RE
> The reason to disable LTO for BPF CO-RE is that if LTO is in effect, BPF CO-RE
> relocations need to be generated in the LTO link phase _after_ the 
> optimizations
> are done. This means we need to devise way to combine early and late BTF. At
> this time, in absence of linker support for BTF sections, it makes sense to
> steer clear of LTO for BPF CO-RE and bypass the issue.
>
> 2. Use a target hook to allow BPF backend to cleanly convey the case when late
> finalization of the CTF container is desirable.
>
> So, in other words,
>
> dwarf2out_early_finish
>   - Always emit CTF here.
>   - if (BTF && ctfc_debuginfo_early_finish_p), emit BTF now.
>
> dwarf2out_finish
>   - if (BTF && !ctfc_debuginfo_early_finish_p && !in_lto_p) emit BTF now.
>   - Use of in_lto_p to make sure LTO link phase does not affect BTF sections
> for other targets.
>
> gcc/ChangeLog:
>
> * dwarf2ctf.c (ctf_debug_finalize): Make it static.
> (ctf_debug_early_finish): New definition.
> (ctf_debug_finish): Likewise.
> * dwarf2ctf.h (ctf_debug_finalize): Remove declaration.
> (ctf_debug_early_finish): New declaration.
> (ctf_debug_finish): Likewise.
> * dwarf2out.c (dwarf2out_finish): Invoke ctf_debug_finish.
> (dwarf2out_early_finish): Invoke ctf_debug_early_finish.
> ---
>  gcc/dwarf2ctf.c | 55 +++
>  gcc/dwarf2ctf.h |  4 +++-
>  gcc/dwarf2out.c |  9 +++--
>  3 files changed, 53 insertions(+), 15 deletions(-)
>
> diff --git a/gcc/dwarf2ctf.c b/gcc/dwarf2ctf.c
> index 5e8a725..0fa429c 100644
> --- a/gcc/dwarf2ctf.c
> +++ b/gcc/dwarf2ctf.c
> @@ -917,6 +917,27 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
>return type_id;
>  }
>
> +/* Prepare for output and write out the CTF debug information.  */
> +
> +static void
> +ctf_debug_finalize (const char *filename, bool btf)
> +{
> +  if (btf)
> +{
> +  btf_output (filename);
> +  btf_finalize ();
> +}
> +
> +  else
> +{
> +  /* Emit the collected CTF information.  */
> +  ctf_output (filename);
> +
> +  /* Reset the CTF state.  */
> +  ctf_finalize ();
> +}
> +}
> +
>  bool
>  ctf_do_die (dw_die_ref die)
>  {
> @@ -966,25 +987,35 @@ ctf_debug_init_postprocess (bool btf)
>  btf_init_postprocess ();
>  }
>
> -/* Prepare for output and write out the CTF debug in

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx601.security-mail.net
X-Postfix-Queue-ID: 317453ACD0B
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 14:14:35 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
Hi:
  AVX512F supported vscalefs{s,d} which is the same as ldexp except the second 
operand should be floating point.
  Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.

gcc/ChangeLog:

PR target/98309
* config/i386/i386.md (ldexp3): Extend to vscalefs[sd]
when TARGET_AVX512F and TARGET_SSE_MATH.

gcc/testsuite/ChangeLog:

PR target/98309
* gcc.target/i386/pr98309-1.c: New test.
* gcc.target/i386/pr98309-2.c: New test.
---
 gcc/config/i386/i386.md   | 34 +++-
 gcc/testsuite/gcc.target/i386/pr98309-1.c | 18 +++
 gcc/testsuite/gcc.target/i386/pr98309-2.c | 39 +++
 3 files changed, 83 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98309-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98309-2.c

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bc1c30b77f4..56b09c566ed 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -17914,17 +17914,35 @@ (define_expand "ldexp3"
   [(use (match_operand:MODEF 0 "register_operand"))
(use (match_operand:MODEF 1 "general_operand"))
(use (match_operand:SI 2 "register_operand"))]
-  "TARGET_USE_FANCY_MATH_387
-   && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
-   || TARGET_MIX_SSE_I387)
+  "((TARGET_USE_FANCY_MATH_387
+ && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
+|| TARGET_MIX_SSE_I387))
+|| (TARGET_AVX512F && TARGET_SSE_MATH))
&& flag_unsafe_math_optimizations"
 {
-  rtx op0 = gen_reg_rtx (XFmode);
-  rtx op1 = gen_reg_rtx (XFmode);
+  /* Prefer avx512f version.  */
+  if (TARGET_AVX512F && TARGET_SSE_MATH)
+   {
+ rtx op2 = gen_reg_rtx (mode);
+ emit_insn (gen_floatsi2 (op2, operands[2]));
+ operands[0] = lowpart_subreg (mode, operands[0], mode);
+ if (MEM_P (operands[1]))
+   operands[1] = force_reg (mode, operands[1]);
+ operands[1] = lowpart_subreg (mode, operands[1], mode);
+ op2 = lowpart_subreg (mode, op2, mode);
+ emit_insn (gen_avx512f_vmscalef (operands[0],
+  operands[1],
+  op2));
+   }
+  else
+{
+  rtx op0 = gen_reg_rtx (XFmode);
+  rtx op1 = gen_reg_rtx (XFmode);
 
-  emit_insn (gen_extendxf2 (op1, operands[1]));
-  emit_insn (gen_ldexpxf3 (op0, op1, operands[2]));
-  emit_insn (gen_truncxf2 (operands[0], op0));
+  emit_insn (gen_extendxf2 (op1, operands[1]));
+  emit_insn (gen_ldexpxf3 (op0, op1, operands[2]));
+  emit_insn (gen_truncxf2 (operands[0], op0));
+  }
   DONE;
 })
 
diff --git a/gcc/testsuite/gcc.target/i386/pr98309-1.c 
b/gcc/testsuite/gcc.target/i386/pr98309-1.c
new file mode 100644
index 000..3a7afb58971
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98309-1.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx512f -O2 -mfpmath=sse -ffast-math" } */
+/* { dg-final { scan-assembler-times "vcvtsi2s\[sd\]" "2" } } */
+/* { dg-final { scan-assembler-times "vscalefs\[sd\]" "2" } } */
+
+double
+__attribute__((noipa))
+foo (double a, int b)
+{
+  return __builtin_ldexp (a, b);
+}
+
+float
+__attribute__((noipa))
+foo2 (float a, int b)
+{
+  return __builtin_ldexpf (a, b);
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr98309-2.c 
b/gcc/testsuite/gcc.target/i386/pr98309-2.c
new file mode 100644
index 000..ecfb9168b7d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98309-2.c
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-options "-mavx512f -O2 -mfpmath=sse -ffast-math" } */
+/* { dg-require-effective-target avx512f } */
+
+#define AVX512F
+#ifndef CHECK
+#define CHECK "avx512f-helper.h"
+#endif
+
+#include CHECK
+
+#include "pr98309-1.c"
+
+double
+__attribute__((noipa, target("fpmath=387")))
+foo_i387 (double a, int b)
+{
+  return __builtin_ldexp (a, b);
+}
+
+float
+__attribute__((noipa, target("fpmath=387")))
+foo2_i387 (f

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx304.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx304.security-mail.net
X-Postfix-Queue-ID: 5410D62849
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 14:18:50 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---

On 8/9/21 6:44 PM, Segher Boessenkool wrote:
>
>
> This is not a documented GCC extension either, and it might even
> conflict with the existing void * extension (allowing arithmetic on it,
> by defining sizeof(void)).  In either case it is not currently defined.
>
>
I'm not sure how you get to this, but all we're doing here is standard C.

x.c:

char
foo (const void *x)
{
   const char *y = (const char *) x;
   return *y;
}

y.c:

void
foo (const void *x, char c)
{
   const char *y = (const char *) x;
   *y = c;
}

wschmidt@rain6p1:~/src$ gcc -c x.c
wschmidt@rain6p1:~/src$ gcc -c y.c
y.c: In function 'foo':
y.c:5:6: error: assignment of read-only location '*y'
*y = c;
   ^
wschmidt@rain6p1:~/src$



To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=12e60.61126ea8.8c7d6.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BPATCH+03%2F34%5D+rs6000%3A+Add+the+rest+of+the+%5Baltivec%5D+stanza+to+the+builtins+file&verdict=C&c=5e37a7c97b9bae99e1a38ee5b94ae38ddee5b217--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx405.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx405.security-mail.net
X-Postfix-Queue-ID: 800BE323839
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 14:34:43 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
PR tree-optimization/101809
* gcc.target/i386/pr88531-1a.c: Enable for all targets.
---
 gcc/testsuite/gcc.target/i386/pr88531-1a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr88531-1a.c 
b/gcc/testsuite/gcc.target/i386/pr88531-1a.c
index d1c29b2c990..5e4f28e9b17 100644
--- a/gcc/testsuite/gcc.target/i386/pr88531-1a.c
+++ b/gcc/testsuite/gcc.target/i386/pr88531-1a.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
 /* { dg-options "-O3 -march=x86-64 -mfpmath=sse" } */
 
 #include 
-- 
2.31.1



To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=153a.61127260.35533.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=%5BPATCH%5D+Enable+gcc.target%2Fi386%2Fpr88531-1a.c+for+all+targets&verdict=C&c=cd4808a25716a2952ccf6a20ac79e9d529a95275--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx302.security-mail.net
X-Postfix-Queue-ID: 5BF793D3B166
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 15:04:08 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On 8/10/21 7:48 AM, Segher Boessenkool wrote:
> On Tue, Aug 10, 2021 at 07:17:54AM -0500, Bill Schmidt wrote:
>> On 8/9/21 6:44 PM, Segher Boessenkool wrote:
>>> This is not a documented GCC extension either, and it might even
>>> conflict with the existing void * extension (allowing arithmetic on it,
>>> by defining sizeof(void)).  In either case it is not currently defined.
>>>
>> I'm not sure how you get to this, but all we're doing here is standard C.
> Arithmetic on void* is the GCC extension.  sizeof(void) is 1 as GCC
> extension, instead of being undefined.  Pointer arithmetic is only
> defined for arrays of the type being pointed to, and you cannot have an
> array of void.  You can do this as GCC extension though, it behaves as
> if it was a char* instead.
>
>> x.c:
>>
>> char
>> foo (const void *x)
>> {
>>const char *y = (const char *) x;
>>return *y;
>> }
> And this behaves exactly the same if you do s/const void/void/ .  The
> const qualifier is meaningless on things of type void, since you cannot
> have an lvalue of that type anyway.  And all type qualifiers can be cast
> away (or cast into existence).
>
>> y.c:
>>
>> void
>> foo (const void *x, char c)
>> {
>>const char *y = (const char *) x;
>>*y = c;
>> }
>>
>> wschmidt@rain6p1:~/src$ gcc -c x.c
>> wschmidt@rain6p1:~/src$ gcc -c y.c
>> y.c: In function 'foo':
>> y.c:5:6: error: assignment of read-only location '*y'
>> *y = c;
>>^
> Yes, *y is an lvalue.  *x is not: *x is an error.
>
>
> It *is* allowed to have a "const void", but it means exactly the same as
> just "void" (you cannot assign to either!)  And, they are compatible
> types, too, (they are the *same* type in fact!), so if you ever would
> treat them differently it would be mightily confusing :-)


The whole point is that this data type is only used for interfaces, as 
shown in the example code.  Nobody wants to define const void as 
anything.  The const serves only as a contract that the pointed-to 
object, no matter what it is cast to, will not be modified.

I think you're over-thinking this. :-)

Bill

>
>
> Segher


To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=15eb8.61127946.1743d.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BPATCH+03%2F34%5D+rs6000%3A+Add+the+rest+of+the+%5Baltivec%5D+stanza+to+the+builtins+file&verdict=C&c=cf58a577e641bc42ccd2fb0be89ced1517e6257c--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx302.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx302.security-mail.net
X-Postfix-Queue-ID: C7D3E3D3B0BF
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 15:22:53 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On 8/10/21 3:45 AM, Richard Biener wrote:
> On Mon, Aug 9, 2021 at 10:31 PM Andrew MacLeod via Gcc-patches
>  wrote:
>> The user has overridden the function name "toupper" . Its marked as a
>> builtin function, presumably because it matches the name.  In range
>> folding, we were assuming the LHS and the parameter were compatible
>> types...  but they are not in this case..
>>
>> I don't know if we should be marking such a thing as a builtin function,
>> but regardless.. we shouldn't be trapping.  If the type of the argument
>> is not compatible with  the LHS, then we'll simply assume nothing about
>> the function.
>>
>> Bootstraps with no regression on x86_64-pc-linux-gnu.  pushed.
> I wonder why the gimple_call_combined_fn verification
> using gimple_builtin_call_types_compatible_p isn't enough here?
> Yes, it's matching is a bit lazy, but only with respect to promotion
> of arguments to 'int'.
>
> Richard.
>
I set a breakpoint on the return type field for the builtin... A quick 
check shows the return type of the builtin is being changed to "unsigned 
int" here:

#0  merge_decls (newdecl=0x7fffe9f67100, olddecl=0x7fffe9ed2100, 
newtype=0x7fffe9e3ae70, oldtype=0x7fffe9e3ae70) at 
/gcc/master/gcc/gcc/c/c-decl.c:2598
#1  0x00a0628d in duplicate_decls (newdecl=0x7fffe9f67100, 
olddecl=0x7fffe9ed2100) at /gcc/master/gcc/gcc/c/c-decl.c:2963
#2  0x00a07464 in pushdecl (x=0x7fffe9f67100) at 
/gcc/master/gcc/gcc/c/c-decl.c:3256
#3  0x00a1d113 in start_function (declspecs=0x37728b0, 
declarator=0x3772ae0, attributes=0x0) at /gcc/master/gcc/gcc/c/c-decl.c:9644
#4  0x00a8667c in c_parser_declaration_or_fndef 
(parser=0x77ff7ab0, fndef_ok=true, static_assert_ok=true, 
empty_ok=true, nested=false, start_attr_ok=true, 
objc_foreach_object_declaration=0x0,
     omp_declare_simd_clauses=0x0, have_attrs=false, attrs=0x0, 
oacc_routine_data=0x0, fallthru_attr_p=0x0) at 
/gcc/master/gcc/gcc/c/c-parser.c:2444


It would appear that merge_decls is merging the olddecl (the bultin) 
with newdecl  and results in changing the LHS to unsigned int, so now it 
thinks the builtin matches.   eeeks.

I don't know what the correct thing to do is, but a quick hack to check 
if old_decl is a builtin and return false from duplicate_decl also seems 
to resolve the problem:

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 221a67fe57b..27ab6ac9f1a 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2960,6 +2960,9 @@ duplicate_decls (tree newdecl, tree olddecl)
    return false;
  }

+  if (DECL_BUILT_IN_CLASS (olddecl) != NOT_BUILT_IN)
+    return false;
+
    merge_decls (newdecl, olddecl, newtype, oldtype);

    /* The NEWDECL will no longer be needed.




To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=14e68.61127dac.234a0.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BCOMMITTED%5D+PR+tree-optimization%2F101741+-+Ensure+toupper+and+tolower+follow+the+expected+pattern.&verdict=C&c=3fea457da484485891727e6a67eb7e2bee797a0c--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx601.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx601.security-mail.net
X-Postfix-Queue-ID: 72C9E3ACC5D
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 15:41:09 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---


> On Aug 10, 2021, at 2:36 AM, Richard Biener  wrote:
> 
> On Mon, 9 Aug 2021, Qing Zhao wrote:
> 
>> Hi, Richard,
>> 
>> Thanks a lot for you review.
>> 
>> Although these comments are not made on the latest patch (7th version) :-), 
>> all the comments are valid since the parts you commented
>> are not changed in the 7th version.
>> 
>> 
>>> On Aug 9, 2021, at 9:09 AM, Richard Biener  wrote:
>>> 
>>> On Tue, 27 Jul 2021, Qing Zhao wrote:
>>> 
 Hi,
 
 This is the 6th version of the patch for the new security feature for GCC.
 
 I have tested it with bootstrap on both x86 and aarch64, regression 
 testing on both x86 and aarch64.
 Also compile CPU2017 (running is ongoing), without any issue. (With the 
 fix to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586).
 
 Please take a look and let me know any issue.
>>> 
>>> +/* Handle an "uninitialized" attribute; arguments as in
>>> +   struct attribute_spec.handler.  */
>>> +
>>> +static tree
>>> +handle_uninitialized_attribute (tree *node, tree name, tree ARG_UNUSED 
>>> (args),
>>> +   int ARG_UNUSED (flags), bool 
>>> *no_add_attrs)
>>> +{
>>> +  if (!VAR_P (*node))
>>> +{
>>> +  warning (OPT_Wattributes, "%qE attribute ignored", name);
>>> +  *no_add_attrs = true;
>>> +}
>>> 
>>> you are documenting this attribute for automatic variables but
>>> here you allow placement on globals as well (not sure if at this
>>> point TREE_STATIC / DECL_EXTERNAL are set correctly).
>> 
>> Right, I should warn when the attribute is placed for globals or static 
>> variables. 
>> I will try TREE_STATIC/DECL_EXTERNAL to see whether it’s work or not.
>> 
>>> 
>>> +  /* for languages that do not support BUILT_IN_CLEAR_PADDING, create the
>>> + function node for padding initialization.  */
>>> +  if (!fn)
>>> +{
>>> +  tree ftype = build_function_type_list (void_type_node,
>>> +ptr_type_node,
>>> 
>>> the "appropriate" place to do this would be 
>>> tree.c:build_common_builtin_nodes
>> 
>> Sure, will move the creation of  function node of BUILT_IN_CLEAR_PADDING for 
>> Fortran etc. to tree.c:build_common_builtin_nodes.
>> 
>>> 
>>> You seem to marshall the is_vla argument as for_auto_init when
>>> expanding/folding the builtin and there it's used to suppress
>>> diagnostics (and make covered pieces not initialized?).
>> 
>> Yes, I added an extra argument “for_auto_init” for “BUILT_IN_CLEAR_PADDING”, 
>> this argument is added to suppress errors emitted during folding
>> BUILT_IN_CLEAR_PADDING for flexible array member . Such errors should Not be 
>> emitted when “BUILT_IN_CLEAR_PADDING” is called with compiler automatic 
>> initialization.
>> Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586, comment #6 
>> from Jakub Jelinek.
>> 
>>> I suggest
>>> to re-name is_vla/for_auto_init to something more descriptive.
>> 
>> Okay, I will. 
>>> 
>>> +   gimple_fold_builtin_clear_padding. If FOR_AUTO_INIT,
>>> +   not emit some of the error messages since doing that
>>> +   might confuse the end user.  */
>>> 
>>> doesn't explain to me whether errors still might be raised or
>>> what the actual behavior is.
>> 
>> Okay, will make this more clear in the comments.
>> 
>>> 
>>> +static gimple *
>>> +build_deferred_init (tree decl,
>>> +enum auto_init_type init_type,
>>> +bool is_vla)
>>> +{
>>> +  gcc_assert ((is_vla && TREE_CODE (decl) == WITH_SIZE_EXPR)
>>> + || (!is_vla && TREE_CODE (decl) != WITH_SIZE_EXPR));
>>> 
>>> so the is_vla parameter looks redundant (and the assert dangerous?).
>>> Either the caller knows it deals with a VLA, then that should be
>>> passed through - constant sizes can also later appear during
>>> optimization after all - or is_vla should be determined here
>>> based on whether the size at gimplification time is constant.
>> 
>> The routine “build_defe

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx306.security-mail.net
X-Postfix-Queue-ID: E56823995D5
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 15:51:06 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---

On 8/10/21 8:40 AM, Segher Boessenkool wrote:
> On Tue, Aug 10, 2021 at 08:02:24AM -0500, Bill Schmidt wrote:
>> The whole point is that this data type is only used for interfaces, as
>> shown in the example code.  Nobody wants to define const void as
>> anything.  The const serves only as a contract that the pointed-to
>> object, no matter what it is cast to, will not be modified.
> So it is just documentation, nothing to do with overloading?  Any cast
> (implicit as well!) will give new qualifiers, not just a new type.  So I
> still do not see the point here.
>
> I'll just read it as "void *" :-)


Largely documentational, yes.  The overloads must be defined with "const 
unsigned char *" and so forth.  It would be unexpected to define the 
built-in that this maps to as "void *" rather than "const void *".  
Normally passing a "const unsigned char *" to a function requiring a 
"const void *" can be done implicitly with no cast at all, and so this 
is what people expect to see.  "Under the covers" we can of course cast 
in any way that we see fit, but specifying "const void *" really 
reinforces what people should understand is going on.

If it makes you feel better to read it as "void *", I say go for it. 
:-)  I think most people will be less confused with "const" present in 
the signature in both the built-in definition and the overload 
definition, not just in one of them.

Bill

>
>
> Segher


To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=762e.61128440.f4204.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BPATCH+03%2F34%5D+rs6000%3A+Add+the+rest+of+the+%5Baltivec%5D+stanza+to+the+builtins+file&verdict=C&c=a5b68e50745a40904759329912479562a5ab8c0b--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx409.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx409.security-mail.net
X-Postfix-Queue-ID: D14F23238CD
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 16:15:22 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, Aug 10, 2021 at 3:21 PM Andrew MacLeod  wrote:
>
> On 8/10/21 3:45 AM, Richard Biener wrote:
> > On Mon, Aug 9, 2021 at 10:31 PM Andrew MacLeod via Gcc-patches
> >  wrote:
> >> The user has overridden the function name "toupper" . Its marked as a
> >> builtin function, presumably because it matches the name.  In range
> >> folding, we were assuming the LHS and the parameter were compatible
> >> types...  but they are not in this case..
> >>
> >> I don't know if we should be marking such a thing as a builtin function,
> >> but regardless.. we shouldn't be trapping.  If the type of the argument
> >> is not compatible with  the LHS, then we'll simply assume nothing about
> >> the function.
> >>
> >> Bootstraps with no regression on x86_64-pc-linux-gnu.  pushed.
> > I wonder why the gimple_call_combined_fn verification
> > using gimple_builtin_call_types_compatible_p isn't enough here?
> > Yes, it's matching is a bit lazy, but only with respect to promotion
> > of arguments to 'int'.
> >
> > Richard.
> >
> I set a breakpoint on the return type field for the builtin... A quick
> check shows the return type of the builtin is being changed to "unsigned
> int" here:

OK, so gimple_builtin_call_types_compatible_p only checks that the
call is consistent with the fndecl type - iff the declaration is incompatible
with the declaration as specified by builtins.def then that's of course
not detected by that check (this check is to catch cases where a
formerly indirect call through an incompatible type is now known to
be to a builtin).

IIRC that is a recurring issue and indeed my opinion is that frontends
should not mark function decls as BUILT_IN if the definition/declaration
signature is not compatible.

> #0  merge_decls (newdecl=0x7fffe9f67100, olddecl=0x7fffe9ed2100,
> newtype=0x7fffe9e3ae70, oldtype=0x7fffe9e3ae70) at
> /gcc/master/gcc/gcc/c/c-decl.c:2598
> #1  0x00a0628d in duplicate_decls (newdecl=0x7fffe9f67100,
> olddecl=0x7fffe9ed2100) at /gcc/master/gcc/gcc/c/c-decl.c:2963
> #2  0x00a07464 in pushdecl (x=0x7fffe9f67100) at
> /gcc/master/gcc/gcc/c/c-decl.c:3256
> #3  0x00a1d113 in start_function (declspecs=0x37728b0,
> declarator=0x3772ae0, attributes=0x0) at /gcc/master/gcc/gcc/c/c-decl.c:9644
> #4  0x00a8667c in c_parser_declaration_or_fndef
> (parser=0x77ff7ab0, fndef_ok=true, static_assert_ok=true,
> empty_ok=true, nested=false, start_attr_ok=true,
> objc_foreach_object_declaration=0x0,
>  omp_declare_simd_clauses=0x0, have_attrs=false, attrs=0x0,
> oacc_routine_data=0x0, fallthru_attr_p=0x0) at
> /gcc/master/gcc/gcc/c/c-parser.c:2444
>
>
> It would appear that merge_decls is merging the olddecl (the bultin)
> with newdecl  and results in changing the LHS to unsigned int, so now it
> thinks the builtin matches.   eeeks.
>
> I don't know what the correct thing to do is, but a quick hack to check
> if old_decl is a builtin and return false from duplicate_decl also seems
> to resolve the problem:

Yeah, but that's of course too harsh - we do want correct user declarations of
say 'malloc' to be classified as built-in.

The odd thing is that we merge int foo() and unsigned foo () using
composite_type.  diagnose_mismatched_decls should be made
more strict here although it explicitly mentions

  /* Accept "harmless" mismatches in function types such
 as missing qualifiers or int vs long when they're the same
 size.  However, diagnose return and argument types that are
 incompatible according to language rules.  */

whatever 'language rules' means here.

Anyway, this function is where we should avoid making newdecl built-in
(and we should of course not adjust olddecl either).

Richard.

> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index 221a67fe57b..27ab6ac9f1a 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -2960,6 +2960,9 @@ duplicate_decls (tree newdecl, tree olddecl)
> return false;
>   }
>
>

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx306.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx306.security-mail.net
X-Postfix-Queue-ID: EEBA33994A0
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 16:18:00 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, 10 Aug 2021, Qing Zhao wrote:

> 
> 
> > On Aug 10, 2021, at 2:36 AM, Richard Biener  wrote:
> > 
> > On Mon, 9 Aug 2021, Qing Zhao wrote:
> > 
> >> Hi, Richard,
> >> 
> >> Thanks a lot for you review.
> >> 
> >> Although these comments are not made on the latest patch (7th version) 
> >> :-), all the comments are valid since the parts you commented
> >> are not changed in the 7th version.
> >> 
> >> 
> >>> On Aug 9, 2021, at 9:09 AM, Richard Biener  wrote:
> >>> 
> >>> On Tue, 27 Jul 2021, Qing Zhao wrote:
> >>> 
>  Hi,
>  
>  This is the 6th version of the patch for the new security feature for 
>  GCC.
>  
>  I have tested it with bootstrap on both x86 and aarch64, regression 
>  testing on both x86 and aarch64.
>  Also compile CPU2017 (running is ongoing), without any issue. (With the 
>  fix to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586).
>  
>  Please take a look and let me know any issue.
> >>> 
> >>> +/* Handle an "uninitialized" attribute; arguments as in
> >>> +   struct attribute_spec.handler.  */
> >>> +
> >>> +static tree
> >>> +handle_uninitialized_attribute (tree *node, tree name, tree ARG_UNUSED 
> >>> (args),
> >>> +   int ARG_UNUSED (flags), bool 
> >>> *no_add_attrs)
> >>> +{
> >>> +  if (!VAR_P (*node))
> >>> +{
> >>> +  warning (OPT_Wattributes, "%qE attribute ignored", name);
> >>> +  *no_add_attrs = true;
> >>> +}
> >>> 
> >>> you are documenting this attribute for automatic variables but
> >>> here you allow placement on globals as well (not sure if at this
> >>> point TREE_STATIC / DECL_EXTERNAL are set correctly).
> >> 
> >> Right, I should warn when the attribute is placed for globals or static 
> >> variables. 
> >> I will try TREE_STATIC/DECL_EXTERNAL to see whether it’s work or not.
> >> 
> >>> 
> >>> +  /* for languages that do not support BUILT_IN_CLEAR_PADDING, create the
> >>> + function node for padding initialization.  */
> >>> +  if (!fn)
> >>> +{
> >>> +  tree ftype = build_function_type_list (void_type_node,
> >>> +ptr_type_node,
> >>> 
> >>> the "appropriate" place to do this would be 
> >>> tree.c:build_common_builtin_nodes
> >> 
> >> Sure, will move the creation of  function node of BUILT_IN_CLEAR_PADDING 
> >> for Fortran etc. to tree.c:build_common_builtin_nodes.
> >> 
> >>> 
> >>> You seem to marshall the is_vla argument as for_auto_init when
> >>> expanding/folding the builtin and there it's used to suppress
> >>> diagnostics (and make covered pieces not initialized?).
> >> 
> >> Yes, I added an extra argument “for_auto_init” for 
> >> “BUILT_IN_CLEAR_PADDING”, this argument is added to suppress errors 
> >> emitted during folding
> >> BUILT_IN_CLEAR_PADDING for flexible array member . Such errors should Not 
> >> be emitted when “BUILT_IN_CLEAR_PADDING” is called with compiler automatic 
> >> initialization.
> >> Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586, comment #6 
> >> from Jakub Jelinek.
> >> 
> >>> I suggest
> >>> to re-name is_vla/for_auto_init to something more descriptive.
> >> 
> >> Okay, I will. 
> >>> 
> >>> +   gimple_fold_builtin_clear_padding. If FOR_AUTO_INIT,
> >>> +   not emit some of the error messages since doing that
> >>> +   might confuse the end user.  */
> >>> 
> >>> doesn't explain to me whether errors still might be raised or
> >>> what the actual behavior is.
> >> 
> >> Okay, will make this more clear in the comments.
> >> 
> >>> 
> >>> +static gimple *
> >>> +build_deferred_init (tree decl,
> >>> +enum auto_init_type init_type,
> >>> +bool is_vla)
> >>> +{
> >>> +  gcc_assert ((is_vla && TREE_CODE (decl) == WITH_SIZE_EXPR)
> >>> + || (!is_vla && TREE_CODE (decl) != WITH_SIZE_EXPR));
> >>> 
> >>> so the is_vla parameter looks redundant (and the assert dangerous?).
> >>> Either the caller knows it d

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx408.security-mail.net
X-Postfix-Queue-ID: 1E38E1B7B15F
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 16:26:47 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Tue, Aug 10, 2021 at 04:14:15PM +0200, Richard Biener via Gcc-patches wrote:
> OK, so gimple_builtin_call_types_compatible_p only checks that the
> call is consistent with the fndecl type - iff the declaration is incompatible
> with the declaration as specified by builtins.def then that's of course
> not detected by that check (this check is to catch cases where a
> formerly indirect call through an incompatible type is now known to
> be to a builtin).
> 
> IIRC that is a recurring issue and indeed my opinion is that frontends
> should not mark function decls as BUILT_IN if the definition/declaration
> signature is not compatible.

Different FEs use different strictness for what is or is not compatible.
And we can't be too strict, because e.g. of FILE * arguments where the
FILE type isn't pre-declared for the builtins.
On severe mismatches I think the FEs already don't mark it built in
(say double vs. int etc.), and e.g. const char * vs. char * differences
should be allowed (e.g. consider C++ vs. C strchr).
But perhaps we should consider as incompatible somethng that doesn't
pass useless_type_conversion_p too...

Jakub



To declare a filtering error, please use the following link : 
https://www.security-mail.net/reporter.php?mid=2002.61128ca5.85f80.0&r=marc.poulhies%40kalray.eu&s=gcc-patches-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BCOMMITTED%5D+PR+tree-optimization%2F101741+-+Ensure+toupper+and+tolower+follow+the+expected+pattern.&verdict=C&c=faf1b8beb7208e3d8bcbc95892f060f0216217d6--- End Message ---

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx408.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx408.security-mail.net
X-Postfix-Queue-ID: C6AE21B7B136
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 16:48:43 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
On Mon, 9 Aug 2021, Xionghu Luo wrote:

> Thanks,
> 
> On 2021/8/6 19:46, Richard Biener wrote:
> > On Tue, 3 Aug 2021, Xionghu Luo wrote:
> > 
> >> loop split condition is moved between loop1 and loop2, the split bb's
> >> count and probability should also be duplicated instead of (100% vs INV),
> >> secondly, the original loop1 and loop2 count need be propotional from the
> >> original loop.
> >>
> >>
> >> diff base/loop-cond-split-1.c.151t.lsplit  
> >> patched/loop-cond-split-1.c.151t.lsplit:
> >> ...
> >> int prephitmp_16;
> >> int prephitmp_25;
> >>
> >>  [local count: 118111600]:
> >> if (n_7(D) > 0)
> >>   goto ; [89.00%]
> >> else
> >>   goto ; [11.00%]
> >>
> >>  [local count: 118111600]:
> >> return;
> >>
> >>  [local count: 105119324]:
> >> pretmp_3 = ga;
> >>
> >> -   [local count: 955630225]:
> >> +   [local count: 315357973]:
> >> # i_13 = PHI 
> >> # prephitmp_12 = PHI 
> >> if (prephitmp_12 != 0)
> >>   goto ; [33.00%]
> >> else
> >>   goto ; [67.00%]
> >>
> >> -   [local count: 315357972]:
> >> +   [local count: 104068130]:
> >> _2 = do_something ();
> >> ga = _2;
> >>
> >> -   [local count: 955630225]:
> >> +   [local count: 315357973]:
> >> # prephitmp_5 = PHI 
> >> i_10 = inc (i_13);
> >> if (n_7(D) > i_10)
> >>   goto ; [89.00%]
> >> else
> >>   goto ; [11.00%]
> >>
> >>  [local count: 105119324]:
> >> goto ; [100.00%]
> >>
> >> -   [local count: 850510901]:
> >> +   [local count: 280668596]:
> >> if (prephitmp_12 != 0)
> >> -goto ; [100.00%]
> >> +goto ; [33.00%]
> >> else
> >> -goto ; [INV]
> >> +goto ; [67.00%]
> >>
> >> -   [local count: 850510901]:
> >> +   [local count: 280668596]:
> >> goto ; [100.00%]
> >>
> >> -   [count: 0]:
> >> +   [local count: 70429947]:
> >> # i_23 = PHI 
> >> # prephitmp_25 = PHI 
> >>
> >> -   [local count: 955630225]:
> >> +   [local count: 640272252]:
> >> # i_15 = PHI 
> >> # prephitmp_16 = PHI 
> >> i_22 = inc (i_15);
> >> if (n_7(D) > i_22)
> >>   goto ; [89.00%]
> >> else
> >>   goto ; [11.00%]
> >>
> >> -   [local count: 850510901]:
> >> +   [local count: 569842305]:
> >> goto ; [100.00%]
> >>
> >>   }
> >>
> >> gcc/ChangeLog:
> >>
> >>* tree-ssa-loop-split.c (split_loop): Fix incorrect probability.
> >>(do_split_loop_on_cond): Likewise.
> >> ---
> >>   gcc/tree-ssa-loop-split.c | 16 
> >>   1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
> >> index 3a09bbc39e5..8e5a7ded0f7 100644
> >> --- a/gcc/tree-ssa-loop-split.c
> >> +++ b/gcc/tree-ssa-loop-split.c
> >> @@ -583,10 +583,10 @@ split_loop (class loop *loop1)
> >>basic_block cond_bb;
> 
>   if (!initial_true)
> -   cond = fold_build1 (TRUTH_NOT_EXPR, boolean_type_node, cond); 
> +   cond = fold_build1 (TRUTH_NOT_EXPR, boolean_type_node, cond);
> +
> + edge true_edge = EDGE_SUCC (bbs[i], 0)->flags & EDGE_TRUE_VALUE
> +? EDGE_SUCC (bbs[i], 0)
> +: EDGE_SUCC (bbs[i], 1);
> 
> >>   
> >>class loop *loop2 = loop_version (loop1, cond, &cond_bb,
> >> - profile_probability::always (),
> >> - profile_probability::always (),
> >> - profile_probability::always (),
> >> - profile_probability::always (),
> >> + true_edge->probability,
> >> + true_edge->probability.invert (),
> >> + true_edge->probability,
> >> + true_edge->probability.invert (),
> >>   true);
> > 
> > there is no 'true_edge' variable at this point.
> 
> Sorry, missed the above

Undelivered Mail Returned to Sender

[Mail Delivery System]

This is the mail system at host fx308.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host zimbra2.kalray.eu[195.135.97.26] said: 550
5.1.1 : Recipient address rejected: User unknown
in virtual mailbox table (in reply to RCPT TO command)
Reporting-MTA: dns; fx308.security-mail.net
X-Postfix-Queue-ID: 7BEC4273D21
X-Postfix-Sender: rfc822; gcc-patches@gcc.gnu.org
Arrival-Date: Tue, 10 Aug 2021 17:03:42 +0200 (CEST)

Final-Recipient: rfc822; marc.poulhies@kalray.eu
Original-Recipient: rfc822;marc.poulhies@kalray.eu
Action: failed
Status: 5.1.1
Remote-MTA: dns; zimbra2.kalray.eu
Diagnostic-Code: smtp; 550 5.1.1 : Recipient address
rejected: User unknown in virtual mailbox table
--- Begin Message ---
Hi,

> On Aug 10, 2021, at 9:16 AM, Richard Biener  wrote:
> 
> On Tue, 10 Aug 2021, Qing Zhao wrote:
> 
> 
> +static void
> +expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> +{
> +  tree var = gimple_call_lhs (stmt);
> +  tree size_of_var = gimple_call_arg (stmt, 0);
> +  tree vlaaddr = NULL_TREE;
> +  tree var_type = TREE_TYPE (var);
> +  bool is_vla = (bool) TREE_INT_CST_LOW (gimple_call_arg (stmt, 2));
> +  enum auto_init_type init_type
> += (enum auto_init_type) TREE_INT_CST_LOW (gimple_call_arg (stmt, 1));
> +
> +  gcc_assert (init_type > AUTO_INIT_UNINITIALIZED);
> +
> +  /* if this variable is a VLA, get its SIZE and ADDR first.  */
> +  if (is_vla)
> +{
> +  /* The temporary address variable for this vla should have been
> +created during gimplification phase.  Refer to gimplify_vla_decl
> +for details.  */
> +  tree var_decl = (TREE_CODE (var) == SSA_NAME) ?
> +  SSA_NAME_VAR (var) : var;
> +  gcc_assert (DECL_HAS_VALUE_EXPR_P (var_decl));
> +  gcc_assert (TREE_CODE (DECL_VALUE_EXPR (var_decl)) == 
> INDIRECT_REF);
> +  /* Get the address of this vla variable.  */
> +  vlaaddr = TREE_OPERAND (DECL_VALUE_EXPR (var_decl), 0);
> 
> err - isn't the address of the decl represented by the LHS 
> regardless whether this is a VLA or not?
 
 The LHS of the call to .DEFERRED_INIT is the DECL itself whatever it’s a 
 VLA or not. 
 
 In order to create a memset call, we need the Address of this DECL as the 
 first argument. 
 If the DECL is not a VLA, we just simply apply “build_fold_addr_expr” on 
 this DECL to get its address,
 However, for VLA, during gimplification phase “gimplify_vla_decl”, we have 
 already created a temporary
 address variable for this DECL, and recorded this address variable with 
 “DECL_VALUE_EXPR(DECL), 
 We should use this already created address variable  for VLAs. 
>>> 
>>> So the issue is that the LHS of the .DEFERRED_INIT call is not properly
>>> gimplified.  We should not have such decl there but I see we do not
>>> have IL verification that covers this.
>> 
>> Don’t quite understand here:  do you mean all the LHS of .DEFERRED_INIT call 
>> are not properly gimplified, or
>> Only the LHS of .DEFERRED_INIT call for VLA are not properly gimplified?
> 
> Especially in the VLA case but likely also in general (though unlikely
> since usually the receiver of initializations are simple enough).  I'd
> expect the VLA case end up as
> 
> *ptr_to_decl = .DEFERRED_INIT (...);
> 
> where *ptr_to_decl is the DECL_VALUE_EXPR of the decl.

So, for the following small testing case:


extern void bar (int);

void foo(int n)
{
  int arr[n];
  bar (arr[2]);
  return;
}
=

If I compile it with -ftrivial-auto-var-init=zero -fdump-tree-gimple -S -o 
auto-init-11.s -fdump-rtl-expand, the *.gimple dump is:

=
void foo (int n)
{
  int n.0;
  sizetype D.1950;
  bitsizetype D.1951;
  sizetype D.1952;
  bitsizetype D.1953;
  sizetype D.1954;
  int[0:D.1950] * arr.1;
  void * saved_stack.2;
  int arr[0:D.1950] [value-expr: *arr.1];

  saved_stack.2 = __builtin_stack_save ();
  try
{
  n.0 = n;
  _1 = (long int) n.0;
  _2 = _1 + -1;
  _3 = (sizetype) _2;
  D.1950 = _3;
  _4 = (sizetype) n.0;
  _5 = (bitsizetype) _4;
  _6 = _5 * 32;
  D.1951 = _6;
  _7 = (sizetype) n.0;
  _8 = _7 * 4;
  D.1952 = _8;
  _9 = (sizetype) n.0;
  _10 = (bitsizetype) _9;
  _11 = _10 * 32;
  D.1953 = _11;
  _12 = (sizetype) n.0;
  _13 = _12 * 4;
  D.1954 = _13;
  arr.1 = __builtin_alloca_with_align (D.1954, 32);
  arr = .DEFERRED_INIT (D.1952, 2, 1);
  _14 = (*arr.1)[2];
  bar (_14);
  return;
}
  finally
{
  __builtin_stack_restore (saved_stack.2);
}
}



You th

Mail delivery failed: returning message to sender

[Mail Delivery System via Gcc-patches]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  gcc-patches@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
Reporting-MTA: dns; casnvesweb.ga

Action: failed
Final-Recipient: rfc822;gcc-patches@gcc.gnu.org
Status: 5.0.0
Remote-MTA: dns; gcc.gnu.org
Diagnostic-Code: smtp; 550 5.7.1 Blocked by SpamAssassin