Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Richard Biener via Gcc-patches]

On Mon, 9 Aug 2021, Eric Botcazou wrote:

> > But it is okay that we can set a breakpoint on defs__struct1IP,
> > in the test case of PR 101598.
> > And the debugger shall only show assembler here.
> > Right?
> 
> The defs__struct1IP procedure should be totally transparent for the user, so 
> setting a breakpoint in it is not supposed to come into play.
> 
> > Do you have an example where this location information is used in the
> > compiler itself for debugging?
> 
> That's useful when you compile the code with -gnatD, i.e when you debug the 
> intermediate code generated by the front-end.
> 
> > I assume You would agree that having the location for Test2 is better
> > than no debug info at all?
> 
> But we want no debug info at all for these IP functions.
> 
> > What do you think?
> 
> I guess I still don't understand why DECL_IGNORED_P was changed.

ISTR it was changed because at least with location info generated
by gas there's no way to have "no location" for a portion of code.
Instead the assigned location will be that of the previous .loc
directive which results in random and confusing results for the
pc range of the DECL_INGORED_P function.

I guess we should really revisit the decision to rely on gas
to produce line info.  What's the advantage of doing so (apart
from "nice" annotated assembly)?

Richard.

Re: trunk -D_GLIBCXX_DEBUG #include fails

[Stephan Bergmann via Gcc-patches]

On 09/08/2021 16:42, Jonathan Wakely via Gcc-patches wrote:

This is what I'm testing.


Thanks, that worked fine for my build of LibreOffice.

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Richard Biener via Gcc-patches]

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_deferred_init” is ONLY called during gimplification phase 
> by the routine “gimple_add_init_for_auto_var", at this place,
> Is_vla should be determined by the caller to check the size of the DECL. If 
> it’s a vla, the “maybe_with_size_expr” will be applied for
> DECL to make it to a WITH_SIZE_EXPR.  So, the assertion is purely to make 
> sure this at gimplification phase.
> 
> Yes, the size of the VLA decl might become a constant later due to constant 
> propagation, etc.  but during the gimplification phase, the assertion should 
> be true.
> > 
> > + /* If the user requests to initialize automatic variables, we
> > +should initialize paddings inside the variable. Add a call to
> > +__BUILTIN_CLEAR_PADDING (&object, 0, for_auto_init = true) to
> > +initialize paddings of object always to zero regardless of
> > +INIT_TYPE.  */
> > + if (opt_for_fn (current_function_decl, flag_auto_var_init)
> > +   > AUTO_INIT_UNINITIALIZED
> > + && VAR_P (object)
> > + && !DECL_EXTERNAL (object)
> > + && !TRE

Re: [COMMITTED] PR tree-optimization/101741 - Ensure toupper and tolower follow the expected pattern.

[Richard Biener via Gcc-patches]

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.

> Andrew
>
>
>

[PATCH] i386: Fix typos in amxbf16 runtime test.

[Hongyu Wang via Gcc-patches]

Hi,

This patch fixes some typo in amxbf16-dpbf16ps-2 test.

Tested under sde/spr machine and passed.

OK for master and backport to GCC 11?

gcc/testsuite/ChangeLog:

* gcc.target/i386/amxbf16-dpbf16ps-2.c: Fix typos.
---
 gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c 
b/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
index 349ec58ada2..f7002ca5ea5 100644
--- a/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
+++ b/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
@@ -57,7 +57,7 @@ void calc_matrix_dpbf16ps (__tile *dst, __tile *src1, __tile 
*src2)
  (make_f32(src1_buf[i * 4 * N + 4 * j + t]) *
  make_f32(src2_buf[j * 4 * K + 4 * k + t])) +
  (make_f32(src1_buf[i * 4 * N + 4 * j + t + 1]) *
- make_f32(src1_buf[i * 4 * N + 4 * j + t + 1]));
+ make_f32(src2_buf[j * 4 * K + 4 * k + t + 1]));
  }
 
 }
@@ -72,8 +72,8 @@ void test_amx_bf16_dpbf16ps ()
   
   init_tile_config (&cfg);
   init_tile_reg_and_src_with_buffer (1, dst, tmp_dst_buf);
-  init_tile_reg_and_src_with_buffer (2, dst, tmp_dst_buf);
-  init_tile_reg_and_src_with_buffer (3, dst, tmp_dst_buf);
+  init_tile_reg_and_src_with_buffer (2, src1, tmp_dst_buf);
+  init_tile_reg_and_src_with_buffer (3, src2, tmp_dst_buf);
 
   calc_matrix_dpbf16ps (&dst, &src1, &src2);
   
-- 
2.18.1

Re: [PATCH] i386: Fix typos in amxbf16 runtime test.

[Hongtao Liu via Gcc-patches]

On Tue, Aug 10, 2021 at 4:11 PM Hongyu Wang via Gcc-patches
 wrote:
>
> Hi,
>
> This patch fixes some typo in amxbf16-dpbf16ps-2 test.
>
> Tested under sde/spr machine and passed.
>
> OK for master and backport to GCC 11?
Ok for master, and i don't think the backport is necessary.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/amxbf16-dpbf16ps-2.c: Fix typos.
> ---
>  gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c 
> b/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
> index 349ec58ada2..f7002ca5ea5 100644
> --- a/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
> +++ b/gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
> @@ -57,7 +57,7 @@ void calc_matrix_dpbf16ps (__tile *dst, __tile *src1, 
> __tile *src2)
>   (make_f32(src1_buf[i * 4 * N + 4 * j + t]) *
>   make_f32(src2_buf[j * 4 * K + 4 * k + t])) +
>   (make_f32(src1_buf[i * 4 * N + 4 * j + t + 1]) *
> - make_f32(src1_buf[i * 4 * N + 4 * j + t + 1]));
> + make_f32(src2_buf[j * 4 * K + 4 * k + t + 1]));
>   }
>
>  }
> @@ -72,8 +72,8 @@ void test_amx_bf16_dpbf16ps ()
>
>init_tile_config (&cfg);
>init_tile_reg_and_src_with_buffer (1, dst, tmp_dst_buf);
> -  init_tile_reg_and_src_with_buffer (2, dst, tmp_dst_buf);
> -  init_tile_reg_and_src_with_buffer (3, dst, tmp_dst_buf);
> +  init_tile_reg_and_src_with_buffer (2, src1, tmp_dst_buf);
> +  init_tile_reg_and_src_with_buffer (3, src2, tmp_dst_buf);
>
>calc_matrix_dpbf16ps (&dst, &src1, &src2);
>
> --
> 2.18.1
>


-- 
BR,
Hongtao

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

[Tobias Burnus]

Hi Sandra, hi all,

Let's start reverse – by trying to answer:

On 09.08.21 23:42, Sandra Loosemore wrote:
...

if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
  {
+  /* FIXME: why are we assuming that this type has IEEE
+  representation?  That's implied by associating it with the
+  C type __float128.  */
info->c_float128 = 1;


First, a lot of code implicitly assumes x86(-64) with the i387
80bit long double and __float128 being the true 128bit floating type.

In terms of the code, there are builtins for float, double, and
long double but for kind(16) > long double, no builtin exists but
a library call has to be done. Likewise, there is the assumption
that in this case, the functions end in 'q', i.e. 'sinq' besides
the known sinf, sin, and sinl.

Thus, in terms of the FE, info->c_float128 implies 'q' suffix and
library calls for functions where for other types a built-in exists.

Thus, by itself, it is unrelated to __float128.

However, as libquadmath uses __float128, the C decl dependency
appears, unless some other library provides 'sinq' etc. for the
non-__float128 128bit type.

 * * *

In terms of Fortran, REAL types do not need to follow IEEE
(there are IEEE intrinsic modules to handle IEEE); thus, REAL(16)
does not need to be an IEEE type – albeit most users implicitly
expect it.

Likewise, kind numbers have no meaning, but there is plenty of
code which expects that kind=4 = 32bit and kind=8 = 64bit,
especially when used in older code as '*' (e.g. 'real*8')
but also quite some code using the newer syntax '()' or
'(kind=') (e.g. 'real(8)' or 'real(kind=8)').

For real, kind=10 (i387's 80bit type) is a specialty of gfortran
(most? all?) other compilers do not support it; kind=16 is more widely
supported, albeit some simply map it to 'long double'.

There is no reason why the different PowerPC TF modes couldn't be
mapped to, e.g., the kinds 17, 18, 19, 20 – except that the Fortran FE,
libgfortran current assumes that only 4, 8, 10 and 16 exist and if
10 exists, 16 is the 'q'/libquadmath version. – Additionally, those
17-20 kinds will also confuse users and using '16' has to be mapped
somehow to one of the TF modes in a way that it still works with
interface kind checks and .mod module files and PowerPC's -m flags.

 * * *

Back to:


On 8/5/21 2:09 PM, Michael Meissner wrote:


All PowerPC systems that I'm aware of that use 128-bit floating point
use the
IBM format.  It is anticipated that one or more Linux distributions
in the
future may move to IEEE 128-bit format, but right now, I'm not aware
that any
have moved.


OK.  I now think it's correct that the Fortran front end doesn't
support c_float128 and c_float128_complex on this target, but that the
code that initializes those constants is still buggy. The reason why
it shouldn't support them is that all 3 128-bit floating-point modes
on PowerPC would map onto kind=16,


Side note: in rs6000-modes.h, there is:
  #define FLOAT_PRECISION_IFmode  128
  #define FLOAT_PRECISION_TFmode  127
  #define FLOAT_PRECISION_KFmode  126
with IFmode (IBM 128-bit floating point), TFmode (long double mode), KFmode 
(explicit __float128).

As written above, there is nothing in Fortran (the language) which
prevents those to be mapped to, e.g., kind=14, 15, 16. Thus, I do not
see the conclusion that all of them would be kind=16 – neither from the code
(which filters out all but TFmode for kind=16) nor from the language.
(On the other hand, support for multiple 128bit FP is also not in the FE - nor
the support for real kind != 4,8,10,16.)

Actually, kind=11 (= ia64's long double alias RFmode) is also supported,
but I am not sure it really works as it not well tested; it is accessible
via the REAL_KINDS array, which enables access to all kind numbers or
via selected_real_kinds() or ...



and we can only support one of them unless we make some exception to
the formula for mapping precision -> kind.  And the mode the Fortran
front end already prefers is the one that corresponds to long double
or TFmode.

I concur.

So the reason why the current code is wrong is that
gfc_float128_type_node only gets set if there is a type with 128-bit
precision that is not long double, so c_float128 wouldn't be supported
on a target where __float128 is equivalent to long double.  Moreover,
on targets where it does define gfc_float128_type_node, it's not doing
anything to ensure that it's actually the same IEEE representation as
__float128.  Both problems can be fixed by just using
float128_type_node to get the type corresponding to __float128.  If
that's not a mode the Fortran front end knows about,
get_real_kind_from_node will detect that.

That sounds right.

I suspect there are some similar lurking bugs in other uses of
gfc_float128_type_node in the Fortran front end, but that's out of
scope for my current project focusing on interoperability features.
I'll file an issue about it, though.


Besides the general issue ('q' + libquadmath, ca

[PATCH] Adding target hook allows to reject initialization of register

[Jojo R via Gcc-patches]

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.

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)

[PATCH] c++: Fix ICE on defaulted spaceship with pointer return type [PR94162]

[Jakub Jelinek via Gcc-patches]

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

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 ---

[PATCH] i386: Improve single operand AVX512F permutations [PR80355]

[Jakub Jelinek via Gcc-patches]

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")
+(match_operand 12 "const_0_to_15_operand")
+(match_operand 13 "const_0_to_15_operand")
+(match_operand 14 "const_0_to_15_operand")
+(match_operand 15 "const_0_to_15_operand")
+(match_operand 16 "const_0_to_15_operand")
+(match_operand 17 "const_0_to_15_operand")])))]
+  "TARGET_AVX512F
+   && (INTVAL (operands[2]) & 3) == 0
+   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
+   && INTVAL (operands[2]) == INTVAL (operands[4]) - 2
+   && INTVAL (operands[2]) == INTVAL (operands[5]) - 3
+   && (INTVAL (operands[6]) & 3) == 0
+   && INTVAL (operands[6]) == INTVAL (operands[7]) - 1
+   && INTVAL (operands[6]) == INTVAL (operands[8]) - 2
+   && INTVAL (operands[6]) == INTVAL (operands[9]) - 3
+   && (INTVAL (operands[10]) & 3) == 0
+   && INTVAL (operands[10]) == INTVAL (operands[11]) - 1
+   && INTVAL (operands[10]) == INTVAL (operands[12]) - 2
+   && INTVAL (operands[10]) == INTVAL (operands[13]) - 3
+   && (

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")
+(

[PATCH] i386: Allow some V32HImode and V64QImode permutations even without AVX512BW [PR80355]

[Jakub Jelinek via Gcc-patches]

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

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

Re: [PATCH] i386: Improve single operand AVX512F permutations [PR80355]

[Hongtao Liu via Gcc-patches]

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 "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")
> +(match_operand 12 "const_0_to_15_operand")
> +(match_operand 13 "const_0_to_15_operand")
> +(match_operand 14 "const_0_to_15_operand")
> +(match_operand 15 "const_0_to_15_operand")
> +(match_operand 16 "const_0_to_15_operand")
> +(match_operand 17 "const_0_to_15_operand")])))]
> +  "TARGET_AVX512F
> +   && (INTVAL (operands[2]) & 3) == 0
> +   && INTVAL (operands[2]) == INTVAL (operands[3]) - 1
> +   && INTVAL (operands[2]) == INTVAL (operands[4]) - 2
> +   && INTVAL (operands[2]) 

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

[committed] openmp: Add support for declare simd and declare variant in a attribute syntax

[Jakub Jelinek via Gcc-patches]

Hi!

This patch adds support for declare simd and declare variant in attribute
syntax.  Either in attribute-specifier-seq at the start of declaration, in
that case it has similar restriction to pragma-syntax, that there is a single
function declaration/definition in the declaration, rather than variable
declaration or more than one function declarations or mix of function and
variable declarations.  Or after the declarator id, in that case it applies
just to the single function declaration and the same declaration can have
multiple such attributes.  Or both.

Furthermore, cp_parser_statement has been adjusted so that it doesn't
accept [[omp::directive (parallel)]] etc. before statements that don't
take attributes at all, or where those attributes don't appertain to
the statement but something else (e.g. to label, using directive,
declaration, etc.).

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

2021-08-10  Jakub Jelinek  

gcc/cp/
* parser.h (struct cp_omp_declare_simd_data): Remove
in_omp_attribute_pragma and clauses members, add loc and attribs.
(struct cp_oacc_routine_data): Remove loc member, add clauses
member.
* parser.c (cp_finalize_omp_declare_simd): New function.
(cp_parser_handle_statement_omp_attributes): Mention in
function comment the function is used also for
attribute-declaration.
(cp_parser_handle_directive_omp_attributes): New function.
(cp_parser_statement): Don't call
cp_parser_handle_statement_omp_attributes if statement doesn't
have attribute-specifier-seq at the beginning at all or if
if those attributes don't appertain to the statement.
(cp_parser_simple_declaration): Call
cp_parser_handle_directive_omp_attributes and
cp_finalize_omp_declare_simd.
(cp_parser_explicit_instantiation): Likewise.
(cp_parser_init_declarator): Initialize prefix_attributes
only after parsing declarators.
(cp_parser_direct_declarator): Call
cp_parser_handle_directive_omp_attributes and
cp_finalize_omp_declare_simd.
(cp_parser_member_declaration): Likewise.
(cp_parser_single_declaration): Likewise.
(cp_parser_omp_declare_simd): Don't initialize
data.in_omp_attribute_pragma, instead initialize
data.attribs[0] and data.attribs[1].
(cp_finish_omp_declare_variant): Remove
in_omp_attribute_pragma argument, instead use
parser->lexer->in_omp_attribute_pragma.
(cp_parser_late_parsing_omp_declare_simd): Adjust
cp_finish_omp_declare_variant caller.  Handle attribute-syntax
declare simd/variant.
gcc/testsuite/
* g++.dg/gomp/attrs-1.C (bar): Add missing semicolon after
[[omp::directive (threadprivate (t2))]].  Add tests with
if/while/switch after parallel in attribute syntax.
(corge): Add missing omp:: before directive.
* g++.dg/gomp/attrs-2.C (bar): Add missing semicolon after
[[omp::directive (threadprivate (t2))]].
* g++.dg/gomp/attrs-10.C: New test.
* g++.dg/gomp/attrs-11.C: New test.

--- gcc/cp/parser.h.jj  2021-08-09 11:36:38.449390046 +0200
+++ gcc/cp/parser.h 2021-08-09 15:14:20.375843582 +0200
@@ -216,15 +216,14 @@ struct cp_omp_declare_simd_data {
   bool error_seen; /* Set if error has been reported.  */
   bool fndecl_seen; /* Set if one fn decl/definition has been seen already.  */
   bool variant_p; /* Set for #pragma omp declare variant.  */
-  bool in_omp_attribute_pragma; /* True if declare simd/variant comes from
-  C++11 attribute rather than pragma.  */
+  location_t loc;
   vec tokens;
-  tree clauses;
+  tree *attribs[2];
 };
 
 /* Helper data structure for parsing #pragma acc routine.  */
 struct cp_oacc_routine_data : cp_omp_declare_simd_data {
-  location_t loc;
+  tree clauses;
 };
 
 /* The cp_parser structure represents the C++ parser.  */
--- gcc/cp/parser.c.jj  2021-08-09 11:36:38.412390555 +0200
+++ gcc/cp/parser.c 2021-08-09 20:47:06.620792815 +0200
@@ -1440,6 +1440,24 @@ cp_finalize_omp_declare_simd (cp_parser
 }
 }
 
+/* Similarly, but for use in declaration parsing functions
+   which call cp_parser_handle_directive_omp_attributes.  */
+
+static inline void
+cp_finalize_omp_declare_simd (cp_parser *parser, cp_omp_declare_simd_data 
*data)
+{
+  if (parser->omp_declare_simd != data)
+return;
+
+  if (!parser->omp_declare_simd->error_seen
+  && !parser->omp_declare_simd->fndecl_seen)
+error_at (parser->omp_declare_simd->loc,
+ "% directive not immediately followed by "
+ "function declaration or definition",
+ parser->omp_declare_simd->variant_p ? "variant" : "simd");
+  parser->omp_declare_simd = NULL;
+}
+
 /* Diagnose if #pragma acc routine isn't followed immediately by function
declaration or definition.  */
 
@@ -11661,7 +11679,7 @@ str

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

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Bernd Edlinger]

On 8/9/21 4:37 PM, Eric Botcazou wrote:
>> But it is okay that we can set a breakpoint on defs__struct1IP,
>> in the test case of PR 101598.
>> And the debugger shall only show assembler here.
>> Right?
> 
> The defs__struct1IP procedure should be totally transparent for the user, so 
> setting a breakpoint in it is not supposed to come into play.
> 

The symbol defs__struct1IP is a global symbol, so once a user know its name,
that user can set a breakpoint there, has never been changed, and I don't know
how to avoid that.

>> Do you have an example where this location information is used in the
>> compiler itself for debugging?
> 
> That's useful when you compile the code with -gnatD, i.e when you debug the 
> intermediate code generated by the front-end.
> 

Ah, thanks, I tried it but the defs__struct1IP function has
DECL_IGNORED_P = false when I build it with -gnatD.

So that would not be affected by setting DECL_SOURCE_LOCATION to
UNKNOWN_LOCATION as done in the proposed patch, because that is only
done for functions with DECL_IGNORED_P = true.

>> I assume You would agree that having the location for Test2 is better
>> than no debug info at all?
> 
> But we want no debug info at all for these IP functions.
> 
>> What do you think?
> 
> I guess I still don't understand why DECL_IGNORED_P was changed.
> 

We have several issues here.

First we have DECL_IGNORED_P = true functions, where DECL_SOURCE_LOCATION
is UNKNOWN_LOCATION, but they have *wrong* line numbers, either because a
preceding function's last line number extends to the ignored function, or
because of a bug in the assembler which mostly affects -gdwarf-4 with certain
versions if the binutils toolchain.

Then we have ordinary functions with DECL_IGNORED_P = false,
but they are morphed into a thunk calling a similar looking function
and the thunk has now DECL_IGNORED_P = true, and all debug info
removed, except the DECL_SOURCE_LOCATION.  To make this even worse,
the similar looking function is inlined into the thunk again, and
all debug info is again stripped away.

And when this happens it is desirable to at least see the source line where
the original function was declared.


As an example, please consider this test case:

$ cat test.ads
package test is

   type Func_Ptr is access function (X : Integer) return Integer;

   function Test1 (X : Integer) return Integer;
   function Test2 (X : Integer) return Integer;
   function DoIt (X : Integer; Func : Func_Ptr) return Integer;

end test;
$ cat test.ads
package test is

   type Func_Ptr is access function (X : Integer) return Integer;

   function Test1 (X : Integer) return Integer;
   function Test2 (X : Integer) return Integer;
   function DoIt (X : Integer; Func : Func_Ptr) return Integer;

end test;

$ cat test.adb
package body test is

   function Test1 (X : Integer) return Integer is
   begin
  return X;
   end Test1;

   function Test2 (X : Integer) return Integer is
   begin
  return X;
   end Test2;

   function DoIt (X : Integer; Func : Func_Ptr) return Integer is
   begin
  return Func (X);
   end DoIt;

end test;

$ cat main.adb
with Ada.Text_IO; use Ada.Text_IO;
with test; use test;

procedure Main is

   X : Integer := 7;
   Y : Integer := DoIt (X, Test1'Access);
   Z : Integer := DoIt (X, Test2'Access);

begin
   Put_Line (X'Img & " " & Y'Img & " " & Z'Img);
end Main;

$ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno

Now Test1 and Test2 are ordinary functions, but Test2 ends up as DECL_IGNORED_P 
= true,
that happens between test.adb.052t.local-fnsummary2 and 
test.adb.092t.fixup_cfg3:

in test.adb.052t.local-fnsummary2 we have:

integer test.test1 (integer x)
{
   [local count: 1073741824]:
  [test.adb:5:7] return x_1(D);

}

and

integer test.test2 (integer x)
{
   [local count: 1073741824]:
  [test.adb:10:7] return x_1(D);

}


but in test.adb.092t.fixup_cfg3

we have

integer test.test1 (integer x)
{
   [local count: 1073741824]:
  [test.adb:5:7] return x_1(D);

}

and

integer test.test2 (integer x)
{
  integer D.4674;
  integer retval.5;
  integer _4;

   [local count: 1073741824]:
  # DEBUG x => x_1(D)
  _4 = x_1(D);
  # DEBUG x => NULL
  retval.5_2 = _4;
  return retval.5_2;

}


the line numbers are gone, and the function has DECL_IGNORED_P,
but still a useful DECL_SOURCE_LOCATION, I don't know
where the DECL_SOURCE_LOCATION can be seen in the dump files,
but from debugging this effect, I know that quite well.

This second effect is why as a special case DECL_IGNORED_P functions
with valid looking DECL_SOURCE_LOCATION have now a .loc statement,
because that is less surprising to a user than having no line numbers
at all here.


Thanks
Bernd.

Re: [PATCH] i386: Allow some V32HImode and V64QImode permutations even without AVX512BW [PR80355]

[Hongtao Liu via Gcc-patches]

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 __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
>


-- 
BR,
Hongtao

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

Re: [wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang

[Tobias Burnus]

Hi all,

On 09.08.21 20:53, Gerald Pfeifer wrote:


(Is "CU" a sufficiently established term, or might it make sense
to spell it out?)

I don't know – but we could use "per compute unit (CU)".

On 09.08.21 16:27, Thomas Schwinge wrote:

On 2021-08-09T15:55:07+0200, Tobias Burnus  wrote:

+++ b/htdocs/gcc-12/changes.html
+  When used as OpenACC device: the limitation of 1 worker per gang, 2 gangs
+  per CU has been lifted; now up to 16 workers per gang and 40 gangs per CU
+  are supported. (Except that the hardware limit of 40 workers total may
+  not be exceeded.)

I haven't changed anything related to a "limitation of [...] 2 gangs per
CU has been lifted".  Maybe that has already been done earlier, maybe
that still has to be done?  I don't know -- Julian?


Looking at the current code, it has:
  if (dims[0] == 0) dims[0] = get_cu_count (kernel->agent); /* Gangs.  */

Thus at least when nothing else has been specified, it uses #CUs of gangs,
running on #CUs CUs, i.e. 1 gang per CU.

[OG11 – but not mainline] What's needed is something like:
  dims[0] = get_cu_count (kernel->agent) * (32 / dims[1]);
which I see in OG11 – oddly, I also see there code like:
  def->gdims[0] = get_cu_count (agent); // * (40 / gcn_threads);

In other words:  For gangs > #CUs or >1 gang per CU, the following patch
is needed:
  [OG11] https://gcc.gnu.org/g:4dcd1e1f4e6b451aac44f919b8eb3ac49292b308
  [email] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550102.html
 "not suitable for mainline until the multiple-worker support is merged 
there"

@Andrew + @Julian:  Do you intent to commit it relatively soon?
Regarding the wwwdocs patch, I can hold off until that commit or reword
it to only cover the workers part.

Thanks Thomas & Gerald for the comments!

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

[PATCH] tree-optimization/101809 - support emulated gather for double[int]

[Richard Biener via Gcc-patches]

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_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);
- vec_offset = vec_offsets[0];
+ vect_get_gather_scatter_ops (loop_vinfo, loop, stmt_info,
+  &gs_info, &dataref_ptr,
+  &vec_offsets);
}
  else
dataref_ptr
@@ -9395,9 +9399,7 @@ vectorizable_load (vec_info *vinfo,
  if (dataref_offset)
dataref_offset = int_const_binop (PLUS_EXPR, dataref_offset,
  bump);
- else if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
-   vec_offset = vec_offsets[j];
- else
+ else if (!STMT_VINFO_GATHER_SCATTER_P (stmt_info))
dataref_ptr = bump_vector_ptr (vinfo, dataref_ptr, ptr_incr, gsi,

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

Re: [PATCH] Adding target hook allows to reject initialization of register

[Richard Biener via Gcc-patches]

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)
>

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

[PATCH][v2] Adjust volatile handling of the operand scanner

[Richard Biener via Gcc-patches]

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 include them as they have no effect on the testsuite.

The question is whether we instead want to amend build3 to
set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
it set.  At least for the Fortran FE cases the gimplifier
fails to see some volatile references and thus can generate
wrong code which is a latent issue.

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

OK?

Thanks,
Richard.

2021-08-09  Richard Biener  

gcc/
* tree-ssa-operands.c (operands_scanner::get_expr_operands):
Do not look at COMPONENT_REF FIELD_DECLs TREE_THIS_VOLATILE
to determine has_volatile_ops.

gcc/fortran/
* trans-common.c (create_common): Set TREE_THIS_VOLATILE on the
COMPONENT_REF if the field is volatile.
---
 gcc/fortran/trans-common.c | 9 +
 gcc/tree-ssa-operands.c| 7 +--
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index a11cf4c839e..7bcf18dc475 100644
--- a/gcc/fortran/trans-

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

Re: [PATCH,V2 1/3] bpf: Add new -mcore option for BPF CO-RE

[Richard Biener via Gcc-patches]

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
>

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 ---

Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission

[Richard Biener via Gcc-patches]

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 the CTF Container can allow the\n\
> + emission of the CTF/BTF debug info at the DWARF debuginfo early finish\n\
> + time.",
> + bool, (void),
> + default_ctfc_debuginfo_early_finish_p)
> +
>  /* If expand_builtin_init_dwarf_reg_sizes needs to fill in table
> entries not corresponding directly to registers below
> FIRST_PSEUDO_REGISTER, this hook should generate the necessary
> diff --git a/gcc/targhooks.c b/gcc/targhooks.c
> index eb51909..e38566c 100644
> --- a/gcc/targhooks.c
> +++ b/gcc/targhooks.c
> @@ -2112,6 +2112,12 @@ default_dwarf_frame_reg_mode (int regno)
>return save_mode;
>  }
>
> +bool
> +default_ctfc_debuginfo_early_finish_p (void)
> +{
> +  return true;
> +}
> +
>  /* To be used by targets where reg_raw_mode doesn't return the right
> mode for registers used in apply_builtin_return and apply_builtin_arg.  */
>
> diff --git a/gcc/targhooks.h b/gcc/targhooks.h
> index f92e102..55dc443 100644
> --- a/gcc/targhooks.h
> +++ b/gcc/targhooks.h
> @@ -255,6 +255,8 @@ extern unsigned i

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

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

[Segher Boessenkool]

Hi!

On Tue, Aug 10, 2021 at 10:29:08AM +0200, Tobias Burnus wrote:
> On 09.08.21 23:42, Sandra Loosemore wrote:
> In terms of Fortran, REAL types do not need to follow IEEE
> (there are IEEE intrinsic modules to handle IEEE); thus, REAL(16)
> does not need to be an IEEE type – albeit most users implicitly
> expect it.
>
> Likewise, kind numbers have no meaning, but there is plenty of
> code which expects that kind=4 = 32bit and kind=8 = 64bit,
> especially when used in older code as '*' (e.g. 'real*8')
> but also quite some code using the newer syntax '()' or
> '(kind=') (e.g. 'real(8)' or 'real(kind=8)').
> 
> For real, kind=10 (i387's 80bit type) is a specialty of gfortran
> (most? all?) other compilers do not support it; kind=16 is more widely
> supported, albeit some simply map it to 'long double'.

So, make 16 always mean IEEE QP float for us, and 15 mean double-double?
(Or whatever other number you prefer -- as you explain, 16 should be the
preferred one though, and that is the IEEE float of course).

> There is no reason why the different PowerPC TF modes couldn't be
> mapped to, e.g., the kinds 17, 18, 19, 20 – except that the Fortran FE,
> libgfortran current assumes that only 4, 8, 10 and 16 exist and if
> 10 exists, 16 is the 'q'/libquadmath version. – Additionally, those
> 17-20 kinds will also confuse users and using '16' has to be mapped
> somehow to one of the TF modes in a way that it still works with
> interface kind checks and .mod module files and PowerPC's -m flags.

There are only two 16-byte float modes: IFmode is double-double, and
KFmode is IEEE QP float.  Those modes mean the same thing whatever
options the compiler has, and whatever the default is.  TFmode is
another name for one of those two modes, and that one can vary.

Also, of course, a mode is not a type, and a type is not a mode, they
are different concepts.  IEEE QP float is always available (if enabled)
via __ieee128, and double-double is always available via __ibm128.

> >code that initializes those constants is still buggy. The reason why
> >it shouldn't support them is that all 3 128-bit floating-point modes
> >on PowerPC would map onto kind=16,

So fix that?  16 should be the IEEE kind, and then something else for
the double-double kind?

> Side note: in rs6000-modes.h, there is:
>   #define FLOAT_PRECISION_IFmode  128
>   #define FLOAT_PRECISION_TFmode  127
>   #define FLOAT_PRECISION_KFmode  126
> with IFmode (IBM 128-bit floating point), TFmode (long double mode), KFmode 
> (explicit __float128).

This is a workaround for a fundamental problem in GCC internals, which
requires all floating point modes to be ordered.  This is not true for
QP float and double-double: each of those can represent values the other
can not.

And it is only a workaround, and it will change some day.

> >and we can only support one of them unless we make some exception to
> >the formula for mapping precision -> kind.  And the mode the Fortran
> >front end already prefers is the one that corresponds to long double
> >or TFmode.
> I concur.

A kind number should always map to the same floating point format, it
should not depend on unrelated compiler flags.  It should not matter at
all what "long double" maps to.  Anything else leads to more insanity
than needed.


Segher

Re: [PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase

[Richard Biener via Gcc-patches]

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 information.  */
> +/* Early finish CTF/BTF debug info.  */
>
>  void
> -ctf_debug_finalize (const char *filename, bool btf)
> +ctf_debug_early_finish (const char * filename)
>  {
> -  if (btf)
> +  /* Emit CTF debug info early always.  */
> +  if (ctf_debug_info_level > CTFINFO_LEVEL_NONE
> +  /* Emit BTF debug info early if the target does not require late
> +emission.  */
> +   || (btf_debuginfo_p ()
> +  && targetm.ctfc_debuginfo_early_finish_p ()))
>  {
> -  btf_output (filename);
> -  btf_finalize ();
> +  /* Emit CTF/BTF debug info.  */
> +  ctf_debug_finalize (filename, btf_debuginfo_p ());
>  }
> +}
>
> -  else
> -{
> -  /* Emit the collected CTF information.  */
> -  ctf_output (filename);
> +/* Finish CTF/BTF debug info emission.  */
>
> -  /* Reset the CTF state.  */
> -  ctf_finalize ();
> -}
> +void
> +ctf_debug_finish (const char * filename)
> +{
> +  /* Emit BTF debug info here when the target needs to update the CTF 
> con

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

[PATCH] Extend ldexp{s, d}f3 to vscalefs{s, d} when TARGET_AVX512F and TARGET_SSE_MATH.

[liuhongt via Gcc-patches]

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 (float a, int b)
+{
+  return __builtin_ldexpf (a, b);
+}
+
+static void
+test_512 (void)
+{
+  float fa = 14.5;
+  double da = 44.5;
+  int fb = 12;
+  int db = 8;
+  if (foo_i387 (da, db) != foo (da, db))
+abort ();
+  if (foo2_i387 (fa, fb) != foo2 (fa, fb))
+abort ();
+}
-- 
2.27.0

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

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

[Bill Schmidt via Gcc-patches]

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$

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 ---

[PATCH] Enable gcc.target/i386/pr88531-1a.c for all targets

[H.J. Lu via Gcc-patches]

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

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 ---

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

[Segher Boessenkool]

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 :-)


Segher

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

[Bill Schmidt via Gcc-patches]

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

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 ---

Re: [COMMITTED] PR tree-optimization/101741 - Ensure toupper and tolower follow the expected pattern.

[Andrew MacLeod via Gcc-patches]

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.

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 ---

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

> 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_deferred_init” is ONLY called during gimplification phase 
>> by the routine “gimple_add_init_for_auto_var", at this place,
>> Is_vla should be determined by the caller to check the size of the DECL. If 
>> it’s a vla, the “maybe_with_size_expr” will be applied for
>> DECL to make it to a WITH_SIZE_EXPR.  So, the assertion is purely to make 
>> sure this at gimplification phase.
>> 
>> Yes, the size of the VLA decl might become a constant later due to constant 
>> propagation, etc.  but during the gimplification phase, the assertion should 
>> be true.
>>> 
>>> + /* If the user requests to initialize automatic variables, we
>>> +should initialize paddings inside the variable. Add a call to
>>> +__BUILTIN_CLEAR_PADDING (&object, 0, for_auto_init = true) to
>>> +initialize paddings of object always to zero regardless of
>>> +INIT_TYPE.  */
>>> + if (opt_for_fn (current_function_decl, flag_auto_var_init)
>>> +   > AUTO_INIT_UNINITIALIZED
>

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

[Segher Boessenkool]

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 *" :-)


Segher

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

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

[Bill Schmidt via Gcc-patches]

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

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 ---

Re: [COMMITTED] PR tree-optimization/101741 - Ensure toupper and tolower follow the expected pattern.

[Richard Biener via Gcc-patches]

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;
>   }
>
> +  if (DECL_BUILT_IN_CLASS (olddecl) != NOT_BUILT_IN)
> +return false;
> +
> merge_decls (newdecl, olddecl, newtype, oldtype);
>
> /* The NEWDECL will no longer be needed.
>
>

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;
>   }
>
>

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Richard Biener via Gcc-patches]

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 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_deferred_init” is ONLY called during gimplification 
> >> phase by the routine “gimple_add_init_for_auto_var", at this place,
> >> Is_vla should be determined by the caller to check the size of the DECL. 
> >> If it’s a vla, the “maybe_with_size_expr” will be applied for
> >> DECL to make it to a WITH_SIZE_EXPR.  So, the assertion is purely to make 
> >> sure this at gimplification phase.
> >> 
> >> Yes, the size of the VLA decl might become a constant later due to 
> >> constant propagation, etc.  but during the gimplification phase, the 
> >> assertion should be true.
> >>> 
> >>> + /* If the user requests to initialize automatic variables, we
> >>> +should initialize paddings inside the variable. Add a call to
> >>> +   

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

Re: [COMMITTED] PR tree-optimization/101741 - Ensure toupper and tolower follow the expected pattern.

[Jakub Jelinek via Gcc-patches]

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

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 ---

[Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

[Tobias Burnus]

This is a follow up to 
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576970.html
/https://gcc.gnu.org/r12-2808-g527a1cf32c27a3fbeaf6be7596241570d864cc4c  


It turned out that -I $specpath/libgfortran caused gfortran to regard the 
IEEE_*.mod
files in that directory as non-intrinsic user modules – which prevented all the 
special
handling for the IEEE intrinsic module.

As discussed with Jakub on IRC, the simplest/best solution is to copy the
ISO_Fortran_binding.h file from the libgfortran build directory into a
separate 'include' subdirectory and use that one instead.

Additionally, I removed the -I flag as already the (pre-)existing
-B$specpath/libgfortran/ (with tailing '/'!) causes GCC to search
in include for include files.

Tested on x86-64 by doing in-build-tree testing by running "make check-fortran";
plus by checking one ISO*.f90 testcase with --target_board=unix\{,-m32\} and 
then
copying the command line and running it with 'strace -f', ensuring that the 
correct
ISO_Fortran_binding.h is read for both '' (= -m64) and '-m32'.

I think the patch is obvious – especially as it matches what was discussed in 
IRC,
but I will wait until later today until I commit it to permit for pre-commit 
comments.

Thanks,

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
gfortran: Fix in-build-tree testing [PR101305, PR101660]

ISO_Fortran_binding.h is written in the build dir - hence, a previous commit
added it as include directory for in-build-tree testing.  However,
it turned out that -I$specdir/libgfortran interferes with reading .mod files
as they are then no longer regareded as intrinsic modules.  Solution: Create
an extra include/ directory in the libgfortran build dir and copy
ISO_Fortran_binding.h to that directory.  As -B$specdir/libgfortran already
causes gfortran to read that include subdirectory, the -I flag is no longer
needed.

	PR libfortran/101305
	PR fortran/101660

libgfortran/ChangeLog:

	* Makefile.am (ISO_Fortran_binding.h): Create include/ in the build dir
	and copy the include file to it.
	(clean-local): Add for removing the 'include' directory.
	* Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

	* lib/gfortran.exp (gfortran_init): Remove -I$specpath/libgfortran
	from the string used to set GFORTRAN_UNDER_TEST.

 gcc/testsuite/lib/gfortran.exp | 2 +-
 libgfortran/Makefile.am| 8 
 libgfortran/Makefile.in| 9 -
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/gfortran.exp b/gcc/testsuite/lib/gfortran.exp
index cae6738b4b8..43f4d4eda17 100644
--- a/gcc/testsuite/lib/gfortran.exp
+++ b/gcc/testsuite/lib/gfortran.exp
@@ -184,7 +184,7 @@ proc gfortran_init { args } {
 		set specpath [get_multilibs]
 		}
 		set gfortran_init_set_GFORTRAN_UNDER_TEST 1
-		set GFORTRAN_UNDER_TEST [findfile $base_dir/../../gfortran "$base_dir/../../gfortran -B$base_dir/../../ -B$specpath/libgfortran/ -I$specpath/libgfortran" [findfile $base_dir/gfortran "$base_dir/gfortran -B$base_dir/" [transform gfortran]]]
+		set GFORTRAN_UNDER_TEST [findfile $base_dir/../../gfortran "$base_dir/../../gfortran -B$base_dir/../../ -B$specpath/libgfortran/" [findfile $base_dir/gfortran "$base_dir/gfortran -B$base_dir/" [transform gfortran]]]
 	}
 	}
 }
diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
index 3546a3f3711..47035dd8921 100644
--- a/libgfortran/Makefile.am
+++ b/libgfortran/Makefile.am
@@ -1076,6 +1076,9 @@ fpu-target.inc: fpu-target.h $(srcdir)/libgfortran.h
 	grep '^#define GFC_FPE_' < $(top_srcdir)/../gcc/fortran/libgfortran.h > $@ || true
 	grep '^#define GFC_FPE_' < $(srcdir)/libgfortran.h >> $@ || true
 
+# Place ISO_Fortran_binding.h also under include/ in the build directory such
+# that it can be used for in-built-tree testsuite runs without interference of
+# other files in the build dir - like intrinsic .mod files or other .h files.
 ISO_Fortran_binding.h: $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
 		   $(srcdir)/ISO_Fortran_binding-2-tmpl.h \
 		   $(srcdir)/ISO_Fortran_binding-3-tmpl.h \
@@ -1085,6 +1088,8 @@ ISO_Fortran_binding.h: $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
 	$(COMPILE) -E -dD $(srcdir)/ISO_Fortran_binding-2-tmpl.h \
 	| grep '^#define CFI_type' >> $@
 	cat $(srcdir)/ISO_Fortran_binding-3-tmpl.h >> $@
+	$(MKDIR_P) include
+	cp $@ include/ISO_Fortran_binding.h
 
 ## A 'normal' build shouldn't need to regenerate these
 ## so we only include them in maintainer mode
@@ -1245,6 +1250,9 @@ $(gfor_misc_specifics): m4/misc_specifics.m4 m4/head.m4
 ## end of maintainer mode only rules
 endif
 
+clean-local:
+	-rm -rf include
+
 EXTRA_DIST = $(m4_files)
 
 # target overrides
diff --git a/libgfortran/Makefile.

Re: [PATCH] Fix loop split incorrect count and probability

[Richard Biener via Gcc-patches]

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 hunk when split the patch. 
> 
> > 
> >>gcc_assert (loop2);
> >>   
> >> @@ -1486,10 +1486,10 @@ do_split_loop_on_cond (struct loop *loop1, edge 
> >> invar_branch)
> >> initialize_original_copy_tables ();
> >>   
> >> struct loop *loop2 = loop_version (loop1, boolean_true_node, NULL,
> >> -   profile_probability::always (),
> >> -   profile_probability::never (),
> >> -   profile_probability::always (),
> >> -   profile_probability::always (),
> >> +   invar_branch->probability.invert (),
> >> +   invar_branch->probability,
> >> +   invar_branch->probability.invert (),
> >> +   invar_branch->probability,
> >> true);
> >> if (!loop2)
> >>   {
> > 
> > The patch introduction seems to talk about do_split_loop_on_cond only.
> 
> split_loop

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

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

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 think that the above .DEFEERED_INIT is not correct?
It should be:

*arr.1 = .DEFERRED_INIT (D.1952. 2, 1);

?

> 
>> What do you mean by “such” decl? A decl whole “DECL_VALUE_EXPR(DECL)” is 
>> valid?
> 
> A 'decl' that has a DECL_VALUE_EXPR should not appear in the IL, it should
> always be refered to as its DECL_VALUE_EXPR.

Okay.

Qing
> 
> Richard.
> 
>> Qing
>>> 

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

Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

[Jakub Jelinek via Gcc-patches]

On Tue, Aug 10, 2021 at 04:45:33PM +0200, Tobias Burnus wrote:
> --- a/libgfortran/Makefile.am
> +++ b/libgfortran/Makefile.am
> @@ -1076,6 +1076,9 @@ fpu-target.inc: fpu-target.h $(srcdir)/libgfortran.h
>   grep '^#define GFC_FPE_' < $(top_srcdir)/../gcc/fortran/libgfortran.h > 
> $@ || true
>   grep '^#define GFC_FPE_' < $(srcdir)/libgfortran.h >> $@ || true
>  
> +# Place ISO_Fortran_binding.h also under include/ in the build directory such
> +# that it can be used for in-built-tree testsuite runs without interference 
> of
> +# other files in the build dir - like intrinsic .mod files or other .h files.
>  ISO_Fortran_binding.h: $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
>  $(srcdir)/ISO_Fortran_binding-2-tmpl.h \
>  $(srcdir)/ISO_Fortran_binding-3-tmpl.h \
> @@ -1085,6 +1088,8 @@ ISO_Fortran_binding.h: 
> $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
>   $(COMPILE) -E -dD $(srcdir)/ISO_Fortran_binding-2-tmpl.h \
>   | grep '^#define CFI_type' >> $@
>   cat $(srcdir)/ISO_Fortran_binding-3-tmpl.h >> $@
> + $(MKDIR_P) include
> + cp $@ include/ISO_Fortran_binding.h

I see many Makefile.* in GCC doing rm -f file before cp whatever file,
but don't know if that is just trying to be extra cautious or if it is
needed for portability.  coreutils cp (and what POSIX says) is that
overwriting the destination file should be fine and shouldn't cause
failures, at least when the destination is writable.

Otherwise LGTM.

Jakub

Re: [PATCH 5/7] bpf: BPF CO-RE support

[Jose E. Marchesi via Gcc-patches]

Hi David.
This BPF part is OK.

> This commit introduces support for BPF Compile Once - Run
> Everywhere (CO-RE) in GCC.
>
> gcc/ChangeLog:
>
>   * config/bpf/bpf.c: Adjust includes.
>   (bpf_handle_preserve_access_index_attribute): New function.
>   (bpf_attribute_table): Use it here.
>   (bpf_builtins): Add BPF_BUILTIN_PRESERVE_ACCESS_INDEX.
>   (bpf_option_override): Handle "-mcore" option.
>   (bpf_asm_init_sections): New.
>   (TARGET_ASM_INIT_SECTIONS): Redefine.
>   (bpf_file_end): New.
>   (TARGET_ASM_FILE_END): Redefine.
>   (bpf_init_builtins): Add "__builtin_preserve_access_index".
>   (bpf_core_compute, bpf_core_get_index): New.
>   (is_attr_preserve_access): New.
>   (bpf_expand_builtin): Handle new builtins.
>   (bpf_core_newdecl, bpf_core_is_maybe_aggregate_access): New.
>   (bpf_core_walk): New.
>   (bpf_resolve_overloaded_builtin): New.
>   (TARGET_RESOLVE_OVERLOADED_BUILTIN): Redefine.
>   (handle_attr): New.
>   (pass_bpf_core_attr): New RTL pass.
>   * config/bpf/bpf-passes.def: New file.
>   * config/bpf/bpf-protos.h (make_pass_bpf_core_attr): New.
>   * config/bpf/coreout.c: New file.
>   * config/bpf/coreout.h: Likewise.
>   * config/bpf/t-bpf (TM_H): Add $(srcdir)/config/bpf/coreout.h.
>   (coreout.o): New rule.
>   (PASSES_EXTRA): Add $(srcdir)/config/bpf/bpf-passes.def.
>   * config.gcc (bpf): Add coreout.h to extra_headers.
>   Add coreout.o to extra_objs.
>   Add $(srcdir)/config/bpf/coreout.c to target_gtfiles.
> ---
>  gcc/config.gcc|   3 +
>  gcc/config/bpf/bpf-passes.def |  20 ++
>  gcc/config/bpf/bpf-protos.h   |   2 +
>  gcc/config/bpf/bpf.c  | 579 ++
>  gcc/config/bpf/coreout.c  | 356 +
>  gcc/config/bpf/coreout.h  | 114 +++
>  gcc/config/bpf/t-bpf  |   8 +
>  7 files changed, 1082 insertions(+)
>  create mode 100644 gcc/config/bpf/bpf-passes.def
>  create mode 100644 gcc/config/bpf/coreout.c
>  create mode 100644 gcc/config/bpf/coreout.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 93e2b3219b9..6c790ce1b35 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1515,6 +1515,9 @@ bpf-*-*)
>  use_collect2=no
>  extra_headers="bpf-helpers.h"
>  use_gcc_stdint=provide
> +extra_headers="coreout.h"
> +extra_objs="coreout.o"
> +target_gtfiles="$target_gtfiles \$(srcdir)/config/bpf/coreout.c"
>  ;;
>  cr16-*-elf)
>  tm_file="elfos.h ${tm_file} newlib-stdint.h"
> diff --git a/gcc/config/bpf/bpf-passes.def b/gcc/config/bpf/bpf-passes.def
> new file mode 100644
> index 000..3e961659411
> --- /dev/null
> +++ b/gcc/config/bpf/bpf-passes.def
> @@ -0,0 +1,20 @@
> +/* Declaration of target-specific passes for eBPF.
> +   Copyright (C) 2021 Free Software Foundation, Inc.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3, or (at your option)
> +   any later version.
> +
> +   GCC is distributed in the hope that it will be useful, but
> +   WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   .  */
> +
> +INSERT_PASS_AFTER (pass_df_initialize_opt, 1, pass_bpf_core_attr);
> diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
> index aeb512665ed..7ce3386ffda 100644
> --- a/gcc/config/bpf/bpf-protos.h
> +++ b/gcc/config/bpf/bpf-protos.h
> @@ -30,4 +30,6 @@ extern void bpf_print_operand_address (FILE *, rtx);
>  extern void bpf_expand_prologue (void);
>  extern void bpf_expand_epilogue (void);
>  
> +rtl_opt_pass * make_pass_bpf_core_attr (gcc::context *);
> +
>  #endif /* ! GCC_BPF_PROTOS_H */
> diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
> index 85f6b76a11f..5edc8cc715a 100644
> --- a/gcc/config/bpf/bpf.c
> +++ b/gcc/config/bpf/bpf.c
> @@ -54,6 +54,25 @@ along with GCC; see the file COPYING3.  If not see
>  #include "builtins.h"
>  #include "predict.h"
>  #include "langhooks.h"
> +#include "flags.h"
> +
> +#include "cfg.h" /* needed for struct control_flow_graph used in BB macros */
> +#include "gimple.h"
> +#include "gimple-iterator.h"
> +#include "gimple-walk.h"
> +#include "tree-pass.h"
> +#include "tree-iterator.h"
> +
> +#include "context.h"
> +#include "pass_manager.h"
> +
> +#include "gimplify.h"
> +#include "gimplify-me.h"
> +
> +#include "ctfc.h"
> +#include "btf.h"
> +
> +#include "coreout.h"
>  
>  /* Per-function machine data.  */
>  struct GTY(()) machine_function
> @@ -104,6 +123,27 

Re: [PATCH 6/7] bpf testsuite: Add BPF CO-RE tests

[Jose E. Marchesi via Gcc-patches]

Hi David.
This BPF part is OK.

> This commit adds several tests for the new BPF CO-RE functionality to
> the BPF target testsuite.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/bpf/core-attr-1.c: New test.
>   * gcc.target/bpf/core-attr-2.c: Likewise.
>   * gcc.target/bpf/core-attr-3.c: Likewise.
>   * gcc.target/bpf/core-attr-4.c: Likewise
>   * gcc.target/bpf/core-builtin-1.c: Likewise
>   * gcc.target/bpf/core-builtin-2.c: Likewise.
>   * gcc.target/bpf/core-builtin-3.c: Likewise.
>   * gcc.target/bpf/core-section-1.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/bpf/core-attr-1.c| 23 +++
>  gcc/testsuite/gcc.target/bpf/core-attr-2.c| 21 ++
>  gcc/testsuite/gcc.target/bpf/core-attr-3.c| 41 
>  gcc/testsuite/gcc.target/bpf/core-attr-4.c| 35 ++
>  gcc/testsuite/gcc.target/bpf/core-builtin-1.c | 64 +++
>  gcc/testsuite/gcc.target/bpf/core-builtin-2.c | 26 
>  gcc/testsuite/gcc.target/bpf/core-builtin-3.c | 26 
>  gcc/testsuite/gcc.target/bpf/core-section-1.c | 38 +++
>  8 files changed, 274 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-attr-1.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-attr-2.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-attr-3.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-attr-4.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-1.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-2.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-3.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-section-1.c
>
> diff --git a/gcc/testsuite/gcc.target/bpf/core-attr-1.c 
> b/gcc/testsuite/gcc.target/bpf/core-attr-1.c
> new file mode 100644
> index 000..7f0d0e50dd6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-attr-1.c
> @@ -0,0 +1,23 @@
> +/* Basic test for struct __attribute__((preserve_access_index))
> +   for BPF CO-RE support.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O0 -dA -gbtf -mcore" } */
> +
> +struct S {
> +  int a;
> +  int b;
> +  int c;
> +} __attribute__((preserve_access_index));
> +
> +void
> +func (struct S * s)
> +{
> +  /* 0:2 */
> +  int *x = &(s->c);
> +
> +  *x = 4;
> +}
> +
> +/* { dg-final { scan-assembler-times "ascii \"0:2.0\"\[\t 
> \]+\[^\n\]*btf_aux_string" 1 } } */
> +/* { dg-final { scan-assembler-times "bpfcr_type" 1 } } */
> diff --git a/gcc/testsuite/gcc.target/bpf/core-attr-2.c 
> b/gcc/testsuite/gcc.target/bpf/core-attr-2.c
> new file mode 100644
> index 000..508e1e4c4b1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-attr-2.c
> @@ -0,0 +1,21 @@
> +/* Basic test for union __attribute__((preserve_access_index))
> +   for BPF CO-RE support.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O0 -dA -gbtf -mcore" } */
> +
> +union U {
> +  int a;
> +  char c;
> +} __attribute__((preserve_access_index));
> +
> +void
> +func (union U *u)
> +{
> +  /* 0:1 */
> +  char *c = &(u->c);
> +  *c = 'c';
> +}
> +
> +/* { dg-final { scan-assembler-times "ascii \"0:1.0\"\[\t 
> \]+\[^\n\]*btf_aux_string" 1 } } */
> +/* { dg-final { scan-assembler-times "bpfcr_type" 1 } } */
> diff --git a/gcc/testsuite/gcc.target/bpf/core-attr-3.c 
> b/gcc/testsuite/gcc.target/bpf/core-attr-3.c
> new file mode 100644
> index 000..1813fd07a2f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-attr-3.c
> @@ -0,0 +1,41 @@
> +/* Test for __attribute__((preserve_access_index)) for BPF CO-RE support
> +   for nested structure.
> +
> +   Note that even though struct O lacks the attribute, when accessed as a
> +   member of another attributed type, CO-RE relocations should still be
> +   generated.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O0 -dA -gbtf -mcore" } */
> +
> +struct O {
> +  int e;
> +  int f;
> +};
> +
> +struct S {
> +  int a;
> +  struct {
> +int b;
> +int c;
> +  } inner;
> +  struct O other;
> +} __attribute__((preserve_access_index));
> +
> +void
> +func (struct S *foo)
> +{
> +  /* 0:1:1 */
> +  int *x = &(foo->inner.c);
> +
> +  /* 0:2:0 */
> +  int *y = &(foo->other.e);
> +
> +  *x = 4;
> +  *y = 5;
> +}
> +
> +/* { dg-final { scan-assembler-times "ascii \"0:1:1.0\"\[\t 
> \]+\[^\n\]*btf_aux_string" 1 } } */
> +/* { dg-final { scan-assembler-times "ascii \"0:2:0.0\"\[\t 
> \]+\[^\n\]*btf_aux_string" 1 } } */
> +
> +/* { dg-final { scan-assembler-times "bpfcr_type" 2 } } */
> diff --git a/gcc/testsuite/gcc.target/bpf/core-attr-4.c 
> b/gcc/testsuite/gcc.target/bpf/core-attr-4.c
> new file mode 100644
> index 000..30d859a1c57
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-attr-4.c
> @@ -0,0 +1,35 @@
> +/* Test for BPF CO-RE __attribute__((preserve_access_index)) with accesses on
> +   LHS and both LHS and RHS of assignment.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O0 -dA -gbtf -mcore" } */
> +
> +struct T {
> +  int a;
> +  int b;
> +

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Richard Biener via Gcc-patches]

On Tue, 10 Aug 2021, Qing Zhao wrote:

> 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 think that the above .DEFEERED_INIT is not correct?
> It should be:
> 
> *arr.1 = .DEFERRED_INIT (D.1952. 2, 1);
> 
> ?

Yes.

> > 
> >> What do you mean by “such” decl? A decl whole “DECL_VALUE_EXPR(DECL)” is 
> >> valid?
> > 
> > A 'decl' that has a DECL_VALUE_EXPR should not appear in the IL, it should
> > always be refered to as its DECL_VALUE_EXPR.
> 
> Okay.

I'm going to test

diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index ebf7eea3b04..15c73b6d6f4 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -799,10 +799,11 @@ operands_scanner::get_expr_operands (tree *expr_p, 
int flags)
 flags | opf_not_non_addressable | 
opf_addres

Re: GCC documentation: porting to Sphinx

[Martin Liška]

Hello.

I've just pushed the rebased branch here:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v4

which I force push once I rebase it. One can fetch the branch with:
$ git fetch origin refs/users/marxin/heads/sphinx-v4

Generated output (directly made from GCC source tree) can be seen here:
https://splichal.eu/gccsphinx-final/

Changes since the previous version:

1) rebased on the current master (including addition of new target hooks, etc.)
2) two new directive/roles were added in order to not abuse 'option' directive:
   gcc-attr (function/label/... attribute) and gcc-param (--param foo=bar).
   Addition was quite straightforward and we would benefit as these attributes
   and parameters will be listed grouped in the Index:
   https://splichal.eu/gccsphinx-final/html/gcc/genindex.html
3) default syntax language was set to 'none'; made issue for e.g. chunks in 
license pages
   where a random Python keywords were highlighted

What needs to be done (TODO list):

1) Cross manual references are missing - we have some of them and Sphinx has 
nice support for it:
   https://docs.readthedocs.io/en/stable/guides/intersphinx.html
2) Remove `Texinfo Manuals` section in GCC internal manual
3) Document required packages for PDF, MAN, HTML, ..
4) Write How to write documentation, we can take inspiration from Kernel:
   https://www.kernel.org/doc/html/latest/doc-guide/index.html
5) Update update_web_docs_git - that will simply run Sphinx' Makefile
6) URL emission code needs to be changed in diagnostics.c
7) link emission should be ignored in Info builder
8) epub target should be added to Makefiles
9) function/struct/type attribute definition should be simplified as
   :gcc-attr: attr_name ("options")
   does not work with a reference to it: :gcc-atr:`attr_name`
   An attribute format should be placed into the attr description.
10) default domain should be switched to cpp, will lead to warnings as seen 
here:
https://github.com/sphinx-doc/sphinx/issues/9535
11) many function and macros in gccint should promoted to '.. function::' and
'.. macro::' directive
12) various smaller formatting issues need to be addressed

Known limitations:
1) chapter description (in TOC listing) is dropped in info pages
2) PDF output puts item description on the same line as item definition - 
noticed by Tamar

As previously mentioned, I'm willing to work on the majority of the points 
mentioned in the TODO list.
Now I see the current patchset in a reasonable shape and I'm asking the 
community for approval of the changes?
And I would appreciate a help with any of the items listed in the TODO list.

Thanks,
Martin

Re: [PATCH,V2 1/3] bpf: Add new -mcore option for BPF CO-RE

[Jose E. Marchesi via Gcc-patches]

> 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.

I agree -mco-re is more clear than -mcore.

Other than that this looks OK BPF-wise.

>>  }
>>
>>  #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
>>

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Eric Botcazou]

> ISTR it was changed because at least with location info generated
> by gas there's no way to have "no location" for a portion of code.
> Instead the assigned location will be that of the previous .loc
> directive which results in random and confusing results for the
> pc range of the DECL_INGORED_P function.

Yes in the general case, but no if you put them at the beginning of the 
assembly file (what the Ada compiler precisely does), at least if you do not 
pass any -gdwarf-n switch now.  This had worked for 2 decades at least...

> I guess we should really revisit the decision to rely on gas
> to produce line info.  What's the advantage of doing so (apart
> from "nice" annotated assembly)?

Not a small advantage in my opinion, and I don't think that we want to change 
it because of a corner case in Ada in any case.

I guess Bernd's patch is acceptable, modulo a small tweak for -gnatD.  Let me 
experiment a little bit though.

-- 
Eric Botcazou

Re: [Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

[Michael Matz via Gcc-patches]

Hello,

On Tue, 10 Aug 2021, Jakub Jelinek via Gcc-patches wrote:

> > +# Place ISO_Fortran_binding.h also under include/ in the build directory 
> > such
> > +# that it can be used for in-built-tree testsuite runs without 
> > interference of
> > +# other files in the build dir - like intrinsic .mod files or other .h 
> > files.
> >  ISO_Fortran_binding.h: $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
> >$(srcdir)/ISO_Fortran_binding-2-tmpl.h \
> >$(srcdir)/ISO_Fortran_binding-3-tmpl.h \
> > @@ -1085,6 +1088,8 @@ ISO_Fortran_binding.h: 
> > $(srcdir)/ISO_Fortran_binding-1-tmpl.h \
> > $(COMPILE) -E -dD $(srcdir)/ISO_Fortran_binding-2-tmpl.h \
> > | grep '^#define CFI_type' >> $@
> > cat $(srcdir)/ISO_Fortran_binding-3-tmpl.h >> $@
> > +   $(MKDIR_P) include
> > +   cp $@ include/ISO_Fortran_binding.h
> 
> I see many Makefile.* in GCC doing rm -f file before cp whatever file,
> but don't know if that is just trying to be extra cautious or if it is
> needed for portability.  coreutils cp (and what POSIX says) is that
> overwriting the destination file should be fine and shouldn't cause
> failures, at least when the destination is writable.

I think this is to deal cautiously with symlinks: if the destination 
filename is a symlink to an existing file that target file is overwritten 
by cp, not the symlink (which continues to point to the now changed target 
file).


Ciao,
Michael.

Re: [PATCH] Optimize macro: make it more predictable

[Martin Liška]

PING^1

On 7/1/21 3:13 PM, Martin Liška wrote:

On 10/23/20 1:47 PM, Martin Liška wrote:

Hey.


Hello.

I deferred the patch for GCC 12. Since the time, I messed up with options
I feel more familiar with the option handling. So ...



This is a follow-up of the discussion that happened in thread about 
no_stack_protector
attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html

The current optimize attribute works in the following way:
- 1) we take current global_options as base
- 2) maybe_default_options is called for the currently selected optimization 
level, which
  means all rules in default_options_table are executed
- 3) attribute values are applied (via decode_options)

So the step 2) is problematic: in case of -O2 -fno-omit-frame-pointer and 
__attribute__((optimize("-fno-stack-protector")))
ends basically with -O2 -fno-stack-protector because -fno-omit-frame-pointer is 
default:
 /* -O1 and -Og optimizations.  */
 { OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },

My patch handled and the current optimize attribute really behaves that same as 
appending attribute value
to the command line. So far so good. We should also reflect that in 
documentation entry which is quite
vague right now:


^^^ all these are still valid arguments, plus I'm adding a new test-case that 
tests that.



"""
The optimize attribute is used to specify that a function is to be compiled 
with different optimization options than specified on the command line.
"""


I addressed that with documentation changes, should be more clear to users. 
Moreover, I noticed that we declare 'optimize' attribute
as something not for a production use:

"The optimize attribute should be used for debugging purposes only. It is not 
suitable in production code."

Are we sure about the statement? I know that e.g. glibc uses that.



and we may want to handle -Ox in the attribute in a special way. I guess many 
macro/pragma users expect that

-O2 -ftree-vectorize and __attribute__((optimize(1))) will end with -O1 and not
with -ftree-vectorize -O1 ?


The situation with 'target' attribute is different. When parsing the attribute, 
we intentionally drop all existing target flags:

$ cat -n gcc/config/i386/i386-options.c
...
   1245    if (opt == IX86_FUNCTION_SPECIFIC_ARCH)
   1246  {
   1247    /* If arch= is set,  clear all bits in 
x_ix86_isa_flags,
   1248   except for ISA_64BIT, ABI_64, ABI_X32, and CODE16
   1249   and all bits in x_ix86_isa_flags2.  */
   1250    opts->x_ix86_isa_flags &= (OPTION_MASK_ISA_64BIT
   1251   | OPTION_MASK_ABI_64
   1252   | OPTION_MASK_ABI_X32
   1253   | OPTION_MASK_CODE16);
   1254    opts->x_ix86_isa_flags_explicit &= 
(OPTION_MASK_ISA_64BIT
   1255    | 
OPTION_MASK_ABI_64
   1256    | 
OPTION_MASK_ABI_X32
   1257    | 
OPTION_MASK_CODE16);
   1258    opts->x_ix86_isa_flags2 = 0;
   1259    opts->x_ix86_isa_flags2_explicit = 0;
   1260  }

That seems logical because target attribute is used for e.g. ifunc 
multi-versioning and one needs
to be sure all existing ISA flags are dropped. However, I noticed clang behaves 
differently:

$ cat hreset.c
#pragma GCC target "arch=geode"
#include 
void foo(unsigned int eax)
{
   _hreset (eax);
}

$ clang hreset.c -mhreset  -c -O2 -m32
$ gcc hreset.c -mhreset  -c -O2 -m32
In file included from 
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/include/x86gprintrin.h:97,
  from 
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/include/immintrin.h:27,
  from hreset.c:2:
hreset.c: In function ‘foo’:
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/include/hresetintrin.h:39:1:
 error: inlining failed in call to ‘always_inline’ ‘_hreset’: target specific 
option mismatch
    39 | _hreset (unsigned int __EAX)
   | ^~~
hreset.c:5:3: note: called from here
     5 |   _hreset (eax);
   |   ^

Anyway, I think the current target attribute handling should be preserved.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin



I'm also planning to take a look at the target macro/attribute, I expect 
similar problems:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469

Thoughts?
Thanks,
Martin

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

[Richard Biener via Gcc-patches]

On Tue, Aug 10, 2021 at 1:41 PM Richard Biener via Gcc-patches
 wrote:
>
> 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.
[...]

> The question is whether we instead want to amend build3 to
> set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
> it set.

A change along that line also passes bootstrap and regtest.

Any preference?

Thanks,
Richard.

>  At least for the Fortran FE cases the gimplifier
> fails to see some volatile references and thus can generate
> wrong code which is a latent issue.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> 2021-08-09  Richard Biener  
>
> gcc/
> * tree-ssa-operands.c (operands_scanner::get_expr_operands):
> Do not look at COMPONENT_REF FIELD_DECLs TREE_THIS_VOLATILE
> to determine has_volatile_ops.
>
> gcc/fortran/
> * trans-common.c (create_common): Set TREE_THIS_VOLATILE on the
> COMPONENT_REF if the field is volatile.
> ---
>  gcc/fortran/trans-common.c | 9 +
>  gcc/tree-ssa-operands.c| 7 +--
>  2 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
> index a11cf4c839e..7bcf18dc475 100644
> --- a/gcc/fortran/trans-common.c
> +++ b/gcc/fortran/trans-common.c
> @@ -759,10 +759,11 @@ create_common (gfc_common_head *com, segment_info 
> *head, bool saw_equiv)
>else
> gfc_add_decl_to_function (var_decl);
>
> -  SET_DECL_VALUE_EXPR (var_decl,
> -  fold_build3_loc (input_location, COMPONENT_REF,
> -   TREE_TYPE (s->field),
> -   decl, s->field, NULL_TREE));
> +  tree comp = build3_loc (input_location, COMPONENT_REF,
> + TREE_TYPE (s->field), decl, s->field, 
> NULL_TREE);
> +  if (TREE_THIS_VOLATILE (s->field))
> +   TREE_THIS_VOLATILE (comp) = 1;
> +  SET_DECL_VALUE_EXPR (var_decl, comp);
>DECL_HAS_VALUE_EXPR_P (var_decl) = 1;
>GFC_DECL_COMMON_OR_EQUIV (var_decl) = 1;
>
> diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
> index c15575416dd..ebf7eea3b04 100644
> --- a/gcc/tree-ssa-operands.c
> +++ b/gcc/tree-ssa-operands.c
> @@ -834,12 +834,7 @@ operands_scanner::get_expr_operands (tree *expr_p, int 
> flags)
> get_expr_operands (&TREE_OPERAND (expr, 0), flags);
>
> if (code == COMPONENT_REF)
> - {
> -   if (!(flags & opf_no_vops)
> -   && TREE_THIS_VOLATILE (TREE_OPERAND (expr, 1)))
> - gimple_set_has_volatile_ops (stmt, true);
> -   get_expr_operands (&TREE_OPERAND (expr, 2), uflags);
> - }
> + get_expr_operands (&TREE_OPERAND (expr, 2), uflags);
> else if (code == ARRAY_REF || code == ARRAY_RANGE_REF)
>   {
> get_expr_operands (&TREE_OPERAND (expr, 1), uflags);
> --
> 2.31.1

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

> On Aug 10, 2021, at 10:22 AM, Richard Biener  wrote:
> 
> On Tue, 10 Aug 2021, Qing Zhao wrote:
> 
>> 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 think that the above .DEFEERED_INIT is not correct?
>> It should be:
>> 
>> *arr.1 = .DEFERRED_INIT (D.1952. 2, 1);
>> 
>> ?
> 
> Yes.
> 
>>> 
 What do you mean by “such” decl? A decl whole “DECL_VALUE_EXPR(DECL)” is 
 valid?
>>> 
>>> A 'decl' that has a DECL_VALUE_EXPR should not appear in the IL, it should
>>> always be refered to as its DECL_VALUE_EXPR.
>> 
>> Okay.
> 
> I'm going to test
> 
> diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
> index ebf7eea3b04..15c73b6d6f4 100644
> --- a/gcc/tree-ssa-operands.c
> +++ b/gcc/tree-ssa-operands.c
> @@ -799,10 +799,11 @@ operands_scanne

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

[Sandra Loosemore]

On 8/10/21 2:29 AM, Tobias Burnus wrote:


[snip]

OK.  I now think it's correct that the Fortran front end doesn't 
support c_float128 and c_float128_complex on this target, but that the 
code that initializes those constants is still buggy. The reason why 
it shouldn't support them is that all 3 128-bit floating-point modes 
on PowerPC would map onto kind=16,


Side note: in rs6000-modes.h, there is:
   #define FLOAT_PRECISION_IFmode  128
   #define FLOAT_PRECISION_TFmode  127
   #define FLOAT_PRECISION_KFmode  126
with IFmode (IBM 128-bit floating point), TFmode (long double mode), 
KFmode (explicit __float128).


As written above, there is nothing in Fortran (the language) which
prevents those to be mapped to, e.g., kind=14, 15, 16. Thus, I do not
see the conclusion that all of them would be kind=16 – neither from the 
code

(which filters out all but TFmode for kind=16) nor from the language.
(On the other hand, support for multiple 128bit FP is also not in the FE 
- nor

the support for real kind != 4,8,10,16.)


Just to quickly address this one point:

It's not in Fortran (the language), but gfc_init_kinds says:

/* Let the kind equal the precision divided by 8, rounding up.  Again,
   this insulates the programmer from the underlying byte size. [...]  */

kind = (GET_MODE_PRECISION (mode) + 7) / 8;

and indeed all 3 of those modes would map onto kind 16 -- unless we want 
to make some exception in the general formula, e.g. using a target hook. 
 I'm not terribly inclined to go down that path, myself.  All I really 
want to do is make c_float128 and c_float128_complex get defined 
properly for the types Fortran already supports.


I need to think some more about your other comments but I'll try to come 
up with a revised patch to address them.


-Sandra

[committed] openmp: Fix up cp/parser.c build with GCC 4.8 to 6

[Jakub Jelinek via Gcc-patches]

Hi!

Christophe Lyon reported that cp/parser.c no longer compiles with
GCC 4.8.5 after my recent OpenMP changes.
A goto out; there crosses odsd variable declaration, and odsd has
a vec<...> member where vec has = default; default constructor
and gcc before r7-2822-gd0b0fbd9fce2f30a82558bf2308b3a7b56c2f364
treated that as error.

Fixed by moving the declaration earlier before the goto.

Tested on x86_64-linux with GCC 4.8.5 system gcc, committed to trunk.

2021-08-10  Jakub Jelinek  

* parser.c (cp_parser_member_declaration): Move odsd declaration
before cp_parser_using_declaration call to avoid errors with
GCC 4.8 to 6.

--- gcc/cp/parser.c.jj  2021-08-10 11:22:14.440607503 +0200
+++ gcc/cp/parser.c 2021-08-10 17:55:50.239528646 +0200
@@ -26651,8 +26651,9 @@ cp_parser_member_declaration (cp_parser*
 
   parser->colon_corrects_to_scope_p = false;
 
+  cp_omp_declare_simd_data odsd;
   if (cp_parser_using_declaration (parser, /*access_declaration=*/true))
-  goto out;
+goto out;
 
   /* Parse the decl-specifier-seq.  */
   decl_spec_token_start = cp_lexer_peek_token (parser->lexer);
@@ -26662,7 +26663,6 @@ cp_parser_member_declaration (cp_parser*
&decl_specifiers,
&declares_class_or_enum);
 
-  cp_omp_declare_simd_data odsd;
   if (decl_specifiers.attributes && (flag_openmp || flag_openmp_simd))
 cp_parser_handle_directive_omp_attributes (parser,
   &decl_specifiers.attributes,


Jakub

Re: [PATCH 04/34] rs6000: Add VSX builtins

[will schmidt via Gcc-patches]

On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07  Bill Schmidt  
> 


Hi,

> gcc/
>   * config/rs6000/rs6000-builtin-new.def: Add vsx stanza.
> ---
>  gcc/config/rs6000/rs6000-builtin-new.def | 857 +++
>  1 file changed, 857 insertions(+)
> 


ok

> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def 
> b/gcc/config/rs6000/rs6000-builtin-new.def
> index f1aa5529cdd..974cdc8c37c 100644
> --- a/gcc/config/rs6000/rs6000-builtin-new.def
> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
> @@ -1028,3 +1028,860 @@
>  
>const vss __builtin_vec_set_v8hi (vss, signed short, const int<3>);
>  VEC_SET_V8HI nothing {set}
> +
> +
> +; VSX builtins.
> +[vsx]
> +  pure vd __builtin_altivec_lvx_v2df (signed long, const void *);
> +LVX_V2DF altivec_lvx_v2df {ldvec}
> +
> +  pure vsll __builtin_altivec_lvx_v2di (signed long, const void *);
> +LVX_V2DI altivec_lvx_v2di {ldvec}
> +
> +  pure vd __builtin_altivec_lvxl_v2df (signed long, const void *);
> +LVXL_V2DF altivec_lvxl_v2df {ldvec}
> +
> +  pure vsll __builtin_altivec_lvxl_v2di (signed long, const void *);
> +LVXL_V2DI altivec_lvxl_v2di {ldvec}
> +
> +  const vd __builtin_altivec_nabs_v2df (vd);
> +NABS_V2DF vsx_nabsv2df2 {}
> +
> +  const vsll __builtin_altivec_nabs_v2di (vsll);
> +NABS_V2DI nabsv2di2 {}
> +
> +  void __builtin_altivec_stvx_v2df (vd, signed long, void *);
> +STVX_V2DF altivec_stvx_v2df {stvec}
> +
> +  void __builtin_altivec_stvx_v2di (vsll, signed long, void *);
> +STVX_V2DI altivec_stvx_v2di {stvec}
> +
> +  void __builtin_altivec_stvxl_v2df (vd, signed long, void *);
> +STVXL_V2DF altivec_stvxl_v2df {stvec}
> +
> +  void __builtin_altivec_stvxl_v2di (vsll, signed long, void *);
> +STVXL_V2DI altivec_stvxl_v2di {stvec}
> +
> +  const vd __builtin_altivec_vand_v2df (vd, vd);
> +VAND_V2DF andv2df3 {}
> +
> +  const vsll __builtin_altivec_vand_v2di (vsll, vsll);
> +VAND_V2DI andv2di3 {}
> +
> +  const vull __builtin_altivec_vand_v2di_uns (vull, vull);
> +VAND_V2DI_UNS andv2di3 {}
> +
> +  const vd __builtin_altivec_vandc_v2df (vd, vd);
> +VANDC_V2DF andcv2df3 {}
> +
> +  const vsll __builtin_altivec_vandc_v2di (vsll, vsll);
> +VANDC_V2DI andcv2di3 {}
> +
> +  const vull __builtin_altivec_vandc_v2di_uns (vull, vull);
> +VANDC_V2DI_UNS andcv2di3 {}
> +
> +  const vsll __builtin_altivec_vcmpequd (vull, vull);
> +VCMPEQUD vector_eqv2di {}
> +
> +  const int __builtin_altivec_vcmpequd_p (int, vsll, vsll);
> +VCMPEQUD_P vector_eq_v2di_p {pred}
> +
> +  const vsll __builtin_altivec_vcmpgtsd (vsll, vsll);
> +VCMPGTSD vector_gtv2di {}
> +
> +  const int __builtin_altivec_vcmpgtsd_p (int, vsll, vsll);
> +VCMPGTSD_P vector_gt_v2di_p {pred}
> +
> +  const vsll __builtin_altivec_vcmpgtud (vull, vull);
> +VCMPGTUD vector_gtuv2di {}
> +
> +  const int __builtin_altivec_vcmpgtud_p (int, vsll, vsll);
> +VCMPGTUD_P vector_gtu_v2di_p {pred}
> +
> +  const vd __builtin_altivec_vnor_v2df (vd, vd);
> +VNOR_V2DF norv2df3 {}
> +
> +  const vsll __builtin_altivec_vnor_v2di (vsll, vsll);
> +VNOR_V2DI norv2di3 {}
> +
> +  const vull __builtin_altivec_vnor_v2di_uns (vull, vull);
> +VNOR_V2DI_UNS norv2di3 {}
> +
> +  const vd __builtin_altivec_vor_v2df (vd, vd);
> +VOR_V2DF iorv2df3 {}
> +
> +  const vsll __builtin_altivec_vor_v2di (vsll, vsll);
> +VOR_V2DI iorv2di3 {}
> +
> +  const vull __builtin_altivec_vor_v2di_uns (vull, vull);
> +VOR_V2DI_UNS iorv2di3 {}
> +
> +  const vd __builtin_altivec_vperm_2df (vd, vd, vuc);
> +VPERM_2DF altivec_vperm_v2df {}
> +
> +  const vsll __builtin_altivec_vperm_2di (vsll, vsll, vuc);
> +VPERM_2DI altivec_vperm_v2di {}
> +
> +  const vull __builtin_altivec_vperm_2di_uns (vull, vull, vuc);
> +VPERM_2DI_UNS altivec_vperm_v2di_uns {}
> +
> +  const vd __builtin_altivec_vreve_v2df (vd);
> +VREVE_V2DF altivec_vrevev2df2 {}
> +
> +  const vsll __builtin_altivec_vreve_v2di (vsll);
> +VREVE_V2DI altivec_vrevev2di2 {}
> +
> +  const vd __builtin_altivec_vsel_2df (vd, vd, vd);
> +VSEL_2DF vector_select_v2df {}
> +
> +  const vsll __builtin_altivec_vsel_2di (vsll, vsll, vsll);
> +VSEL_2DI_B vector_select_v2di {}
> +
> +  const vull __builtin_altivec_vsel_2di_uns (vull, vull, vull);
> +VSEL_2DI_UNS vector_select_v2di_uns {}
> +
> +  const vd __builtin_altivec_vsldoi_2df (vd, vd, const int<4>);
> +VSLDOI_2DF altivec_vsldoi_v2df {}
> +
> +  const vsll __builtin_altivec_vsldoi_2di (vsll, vsll, const int<4>);
> +VSLDOI_2DI altivec_vsldoi_v2di {}
> +
> +  const vd __builtin_altivec_vxor_v2df (vd, vd);
> +VXOR_V2DF xorv2df3 {}
> +
> +  const vsll __builtin_altivec_vxor_v2di (vsll, vsll);
> +VXOR_V2DI xorv2di3 {}
> +
> +  const vull __builtin_altivec_vxor_v2di_uns (vull, vull);
> +VXOR_V2DI_UNS xorv2di3 {}
> +
> +  const signed __int128 __builtin_vec_ext_v1ti (vsq, signed int);
> +VEC_EXT_V1TI nothing {extract}
> +
> +  const double __builtin_vec_ex

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[will schmidt via Gcc-patches]

On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07  Bill Schmidt  
> 
> gcc/
>   * config/rs6000/rs6000-builtin-new.def: Add always, power5, and
>   power6 stanzas.
> ---
>  gcc/config/rs6000/rs6000-builtin-new.def | 72 
>  1 file changed, 72 insertions(+)
> 
> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def 
> b/gcc/config/rs6000/rs6000-builtin-new.def
> index 974cdc8c37c..ca694be1ac3 100644
> --- a/gcc/config/rs6000/rs6000-builtin-new.def
> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
> @@ -184,6 +184,78 @@
>  
>  
>  
> +; Builtins that have been around since time immemorial or are just
> +; considered available everywhere.
> +[always]
> +  void __builtin_cpu_init ();
> +CPU_INIT nothing {cpu}
> +
> +  bool __builtin_cpu_is (string);
> +CPU_IS nothing {cpu}
> +
> +  bool __builtin_cpu_supports (string);
> +CPU_SUPPORTS nothing {cpu}
> +
> +  unsigned long long __builtin_ppc_get_timebase ();
> +GET_TB rs6000_get_timebase {}
> +
> +  double __builtin_mffs ();
> +MFFS rs6000_mffs {}
> +
> +; This will break for long double == _Float128.  libgcc history.

Add a few more words to provide bigger hints for future archeological
digs?  (This is perhaps an obvious issue, but I'd need to do some
spelunking)
I see similar comments below, maybe just a wordier comment for the
first occurance.   Unsure...  

> +  const long double __builtin_pack_longdouble (double, double);
> +PACK_TF packtf {}
> +
> +  unsigned long __builtin_ppc_mftb ();
> +MFTB rs6000_mftb_di {32bit}
> +
> +  void __builtin_mtfsb0 (const int<5>);
> +MTFSB0 rs6000_mtfsb0 {}
> +
> +  void __builtin_mtfsb1 (const int<5>);
> +MTFSB1 rs6000_mtfsb1 {}
> +
> +  void __builtin_mtfsf (const int<8>, double);
> +MTFSF rs6000_mtfsf {}
> +
> +  const __ibm128 __builtin_pack_ibm128 (double, double);
> +PACK_IF packif {}
> +
> +  void __builtin_set_fpscr_rn (const int[0,3]);
> +SET_FPSCR_RN rs6000_set_fpscr_rn {}
> +
> +  const double __builtin_unpack_ibm128 (__ibm128, const int<1>);
> +UNPACK_IF unpackif {}
> +
> +; This will break for long double == _Float128.  libgcc history.
> +  const double __builtin_unpack_longdouble (long double, const int<1>);
> +UNPACK_TF unpacktf {}
> +
> +
> +; Builtins that have been around just about forever, but not quite.
> +[power5]
> +  fpmath double __builtin_recipdiv (double, double);
> +RECIP recipdf3 {}
> +
> +  fpmath float __builtin_recipdivf (float, float);
> +RECIPF recipsf3 {}
> +
> +  fpmath double __builtin_rsqrt (double);
> +RSQRT rsqrtdf2 {}
> +
> +  fpmath float __builtin_rsqrtf (float);
> +RSQRTF rsqrtsf2 {}
> +
> +
> +; Power6 builtins.

I see in subsequent patches you also call out the ISA version in the
comment.  so perhaps
; Power6 builtins (ISA 2.05).

Similar comment for Power5 reference
above.


> +[power6]
> +  const signed long __builtin_p6_cmpb (signed long, signed long);
> +CMPB cmpbdi3 {}
> +
> +  const signed int __builtin_p6_cmpb_32 (signed int, signed int);
> +CMPB_32 cmpbsi3 {}
> +
> +

ok.


>  ; AltiVec builtins.
>  [altivec]
>const vsc __builtin_altivec_abs_v16qi (vsc);

Re: [PATCH 06/34] rs6000: Add power7 and power7-64 builtins

[will schmidt via Gcc-patches]

On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-04-02  Bill Schmidt  
> 

Hi,


> gcc/
>   * config/rs6000/rs6000-builtin-new.def: Add power7 and power7-64
>   stanzas.


ok

> ---
>  gcc/config/rs6000/rs6000-builtin-new.def | 39 
>  1 file changed, 39 insertions(+)
> 
> diff --git a/gcc/config/rs6000/rs6000-builtin-new.def 
> b/gcc/config/rs6000/rs6000-builtin-new.def
> index ca694be1ac3..bffce52ee47 100644
> --- a/gcc/config/rs6000/rs6000-builtin-new.def
> +++ b/gcc/config/rs6000/rs6000-builtin-new.def
> @@ -1957,3 +1957,42 @@
>  
>const vsll __builtin_vsx_xxspltd_2di (vsll, const int<1>);
>  XXSPLTD_V2DI vsx_xxspltd_v2di {}
> +
> +
> +; Power7 builtins (ISA 2.06).
> +[power7]
> +  const unsigned int __builtin_addg6s (unsigned int, unsigned int);
> +ADDG6S addg6s {}

Add all of the sixes...   (ok).

> +
> +  const signed long __builtin_bpermd (signed long, signed long);
> +BPERMD bpermd_di {}
> +
> +  const unsigned int __builtin_cbcdtd (unsigned int);
> +CBCDTD cbcdtd {}
> +
> +  const unsigned int __builtin_cdtbcd (unsigned int);
> +CDTBCD cdtbcd {}
> +
> +  const signed int __builtin_divwe (signed int, signed int);
> +DIVWE dive_si {}
> +
> +  const unsigned int __builtin_divweu (unsigned int, unsigned int);
> +DIVWEU diveu_si {}
> +
> +  const vsq __builtin_pack_vector_int128 (unsigned long long, unsigned long 
> long);
> +PACK_V1TI packv1ti {}
> +
> +  void __builtin_ppc_speculation_barrier ();
> +SPECBARR speculation_barrier {}
> +
> +  const unsigned long __builtin_unpack_vector_int128 (vsq, const int<1>);
> +UNPACK_V1TI unpackv1ti {}
> +
> +
> +; Power7 builtins requiring 64-bit GPRs (even with 32-bit addressing).
> +[power7-64]
> +  const signed long long __builtin_divde (signed long long, signed long 
> long);
> +DIVDE dive_di {}
> +
> +  const unsigned long long __builtin_divdeu (unsigned long long, unsigned 
> long long);
> +DIVDEU diveu_di {}

ok

thanks
-Will

Re: [PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase

[David Faust via Gcc-patches]

On 8/10/21 5:00 AM, Richard Biener via Gcc-patches wrote:

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?


This is unfortunately not quite the case. The CO-RE relocation records 
themselves are placed in the .BTF.ext section. But a key component of 
each record is an "access string," a string which encodes the accessed 
field via a sequence of field or array indices.


The .BTF.ext section does not have a string table of its own, so these 
"access strings" are placed in the .BTF section string table. The CO-RE 
relocation records refer to them by offset into the .BTF string table.


As a result, the CO-RE information spills into the regular .BTF section,
and we need to delay writing out the .BTF section until after these 
strings can be added.


Personally I don't think this way of splitting the CO-RE information is 
ideal, but hopefully now the issue is more clear?


Thank you for your reviews!


Example of access string encoding:

struct S {
  int a;
  union {
int _unused;
int b;
char c;
  } u[4];
};

struct S *foo = ...;
int x  = foo->a;  /* encoded as "0:0" */
int y  = foo[4]->u[2].b   /* encoded as "4:1:2:1" */
char z = foo->u[3].c  /* encoded as "0:1:3:2" */





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 infor

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

[Joseph Myers]

On Mon, 9 Aug 2021, Uecker, Martin wrote:

> I am still trying to figure out what the branch guarded
> by c_vla_type_p is for in c_expr_sizeof_type. The comment
> talks about [*], but how would you apply sizeof to
> such an array?  One can form something like

The comment describes a requirement on what happens for [*], but that 
branch in the code isn't restricted to cases involving [*]; it covers any 
case where (the type is a VLA and) groktypename has returned an expression 
to be evaluated before the type name.

E.g. take your vla-stexp-1.c test but with sizeof(typeof(...)) instead of 
sizeof(...) - that aborts, but I'd hope such a fix in c_expr_sizeof_type 
would make it pass.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

[Joseph Myers]

On Tue, 10 Aug 2021, Sebastian Huber wrote:

> If -fprofile-update=atomic is used, then the target must provide atomic
> operations for the counters of the type returned by get_gcov_type().
> This is a 64-bit type for targets which have a 64-bit long long type.
> On 32-bit targets this could be an issue since they may not provide
> 64-bit atomic operations.  Allow targets to override the default type
> size with the new GCOV_TYPE_SIZE target macro.

Any target macro needs to be documented in tm.texi.in (and tm.texi 
regenerated).

Please don't add new target macros that are used in both host and target 
code; every such macro is an obstruction to removing inclusion of the host 
tm.h from libgcc.  The appropriate way to handle sharing such 
configuration information is to provide a target hook in the host compiler 
code, and then make c-cppbuiltin.c:c_cpp_builtins define a corresponding 
predefined macro under the "if (flag_building_libgcc)" conditional.  
(Although a target hook is generally preferable to a target macro for 
host-side configuration, when a target macro is used on the host it's 
still desirable not to use it directly in target libraries but to use a 
predefined macro instead.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[Segher Boessenkool]

On Tue, Aug 10, 2021 at 11:17:05AM -0500, will schmidt wrote:
> On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> > +; This will break for long double == _Float128.  libgcc history.
> > +  const long double __builtin_pack_longdouble (double, double);
> > +PACK_TF packtf {}
> 
> Add a few more words to provide bigger hints for future archeological
> digs?  (This is perhaps an obvious issue, but I'd need to do some
> spelunking)

It is for __ibm128 only, not for other long double formats (we have
three: plain double, double double, IEEE QP).  So maybe the return type
should be changed?  The name of the builtin of course is unfortunate,
but it is too late to change :-)


Segher

Re: [PATCH 06/34] rs6000: Add power7 and power7-64 builtins

[Segher Boessenkool]

On Tue, Aug 10, 2021 at 11:16:41AM -0500, will schmidt wrote:
> On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> > +  const unsigned int __builtin_addg6s (unsigned int, unsigned int);
> > +ADDG6S addg6s {}
> 
> Add all of the sixes...   (ok).

"Add and generate sixes."  Look it up in the ISA if you aren't confused
enough yet :-)


Segher

Re: [PATCH 04/34] rs6000: Add VSX builtins

[Segher Boessenkool]

On Thu, Jul 29, 2021 at 08:30:51AM -0500, Bill Schmidt wrote:
>   * config/rs6000/rs6000-builtin-new.def: Add vsx stanza.

Okay for trunk.  Thanks!


Segher

Re: [PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

[Sebastian Huber]

On 10/08/2021 19:30, Joseph Myers wrote:

On Tue, 10 Aug 2021, Sebastian Huber wrote:


If -fprofile-update=atomic is used, then the target must provide atomic
operations for the counters of the type returned by get_gcov_type().
This is a 64-bit type for targets which have a 64-bit long long type.
On 32-bit targets this could be an issue since they may not provide
64-bit atomic operations.  Allow targets to override the default type
size with the new GCOV_TYPE_SIZE target macro.

Any target macro needs to be documented in tm.texi.in (and tm.texi
regenerated).

Please don't add new target macros that are used in both host and target
code; every such macro is an obstruction to removing inclusion of the host
tm.h from libgcc.  The appropriate way to handle sharing such
configuration information is to provide a target hook in the host compiler
code, and then make c-cppbuiltin.c:c_cpp_builtins define a corresponding
predefined macro under the "if (flag_building_libgcc)" conditional.
(Although a target hook is generally preferable to a target macro for
host-side configuration, when a target macro is used on the host it's
still desirable not to use it directly in target libraries but to use a
predefined macro instead.)


Ok, I understood how I can add a compiler provided define for libgcov. 
What is not clear to me is how I can add a target hook, set a default 
value, and customize it for a target/system. Is this described here


https://gcc.gnu.org/onlinedocs/gccint/Target-Structure.html

?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[Segher Boessenkool]

On Thu, Jul 29, 2021 at 08:30:52AM -0500, Bill Schmidt wrote:
>   * config/rs6000/rs6000-builtin-new.def: Add always, power5, and
>   power6 stanzas.

> +  unsigned long __builtin_ppc_mftb ();
> +MFTB rs6000_mftb_di {32bit}

I'm not sure what {32bit} means...  The builtin exists on both 32-bit
and on 64-bit, and returns what is a "long" in both cases.  The point
is that it is just a single "mfspr 268" always, which is fast, and
importantly has fixed and low latency.

Modulo perhaps that, okay for trunk.  Thanks!


Segher

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[Bill Schmidt via Gcc-patches]

Hi Segher,

On 8/10/21 1:38 PM, Segher Boessenkool wrote:

On Thu, Jul 29, 2021 at 08:30:52AM -0500, Bill Schmidt wrote:

* config/rs6000/rs6000-builtin-new.def: Add always, power5, and
power6 stanzas.
+  unsigned long __builtin_ppc_mftb ();
+MFTB rs6000_mftb_di {32bit}

I'm not sure what {32bit} means...  The builtin exists on both 32-bit
and on 64-bit, and returns what is a "long" in both cases.  The point
is that it is just a single "mfspr 268" always, which is fast, and
importantly has fixed and low latency.



Right.  The implementation of this thing is that we have two different 
patterns in the machine description that get invoked depending on 
whether the target is 32-bit or 64-bit.  The syntax in the built-ins 
file only allows for one pattern.  So the {32bit} flag allows us to 
perform special processing for TARGET_32BIT, in this case to override 
the pattern.  Later in the patch series you'll find:


  if (bif_is_32bit (*bifaddr) && TARGET_32BIT)
{
  if (fcode == RS6000_BIF_MFTB)
icode = CODE_FOR_rs6000_mftb_si;
  else
gcc_unreachable ();
}

This is the only {32bit} built-in for now, and probably ever...

I'm sure there's a better way of dealing with the mode dependency on 
TARGET_32BIT, but for now this matches the old behavior as closely as 
possible. I'm happy to take suggestions on this.


Thanks for the review!
Bill


Modulo perhaps that, okay for trunk.  Thanks!


Segher

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

Hi, Richard,

> On Aug 10, 2021, at 10:22 AM, Richard Biener  wrote:
>>> 
>>> 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 think that the above .DEFEERED_INIT is not correct?
>> It should be:
>> 
>> *arr.1 = .DEFERRED_INIT (D.1952. 2, 1);
>> 
>> ?
> 
> Yes.
> 

I updated gimplify.c for VLA and now it emits the call to .DEFERRED_INIT as:

  arr.1 = __builtin_alloca_with_align (D.1954, 32);
  *arr.1 = .DEFERRED_INIT (D.1952, 2, 1);

However, this call triggered the assertion failure in verify_gimple_call of 
tree-cfg.c because the LHS is not a valid LHS. 
Then I modify tree-cfg.c as:

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 330eb7dd89bf..180d4f1f9e32 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -3375,7 +3375,11 @@ verify_gimple_call (gcall *stmt)
  }
 
   tree lhs = gimple_call_lhs (stmt);
+  /* For .DEFERRED_INIT call, the LHS might be an indirection of
+ a pointer for the VLA variable, which is not a valid LHS of
+ a gimple call, we ignore the asssertion on this.  */ 
   if (lhs
+  && (!gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
   && (!is_gimple_reg (lhs)
  && (!is_gimple_lvalue (lhs)
  || verify_types_in_gimple_reference

The assertion failure in tree-cfg.c got resolved, but I got another assertion 
failure in operands_scanner::get_expr_operands (tree *expr_p, int flags), line 
945:

 939   /* If we get here, something has gone wrong.  */
 940   if (flag_checking)
 941 {
 942   fprintf (stderr, "unhandled expression in get_expr_operands():\n");
 943   debug_tree (expr);
 944   fputs ("\n", stderr);
 945   gcc_unreachable ();
 946 }

Looks like that  the gimple statement:
*arr.1 = .DEFERRED_INIT (D.1952, 2, 1);

Is not valid.  i.e, the LHS should not be an indirection to a pointer. 

How to resolve this issue?

Thanks a lot for your help.

Qing
>>> 
 What do you mean by “such” decl? A decl whole “DECL_VALUE_EXPR(DECL)” is 
 valid?
>>> 
>>> A 'decl' that has a DECL_VALUE_EXPR should not appear in the IL, it should
>>> always be refered to as its DECL_VALUE_EXPR.
>> 
>> Okay.
> 
> I'm going to test
> 
> diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
> index ebf7eea3b04..15c73b6d6f4 100644
> --- a/gcc/tree-ssa-operands.c
> +++ b/gcc/tree-ssa-operands.c
> @@ -799,10 +799,11 @@ operands_scanner::get_expr_operands (tree *expr_p, 
> int flags)
> flags | opf_not_non_addressable | 
> opf_address_taken);
>   return;
> 
> -case SSA_NAME:
> case VAR_DECL:
> case PARM_DECL:
> case RESULT_DECL:
> +  gcc_checking_assert (!DECL_HAS_VALUE_EXPR_P (expr));
> +case SSA_NAME:
> case STRING_CST:
> case CONST_DECL:
>   if (!(flags & opf_address_taken))
> 
> which should pass on unmodified trunk (fingers crossing ;)), but
> it would likely trip on the current -ftrivial-auto-init patch.
> 
> The issue with the current IL is that nothing keeps arr.1 live
> and thus the allocation could be DCEd but the .DEFERRED_INIT
> call would remain, eventually being expanded to zero storage
> that isn't there.
> 
> Richard.

Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

[Eric Botcazou]

> Yes, it breaks Ada. I already found this out in the meanwhile.

OK, thanks for checking.

> My understanding of this is that this is for referring
> to some field of an outer struct which is then used in the
> size expression, e.g. something like this (using
> C syntax):
> 
> struct foo {
>   int len;
>   float (*x)[3][len];
> };

Yes, just

struct foo {
  int len;
  float a[len];
}

but it's also used for unconstrained array types and this seems to be the 
problem here, e.g. for:

package Vect1 is

   type Varray is array (Integer range <>) of Long_Float;
   for Varray'Alignment use 16;

   procedure Add (X, Y : not null access Varray; R : not null access Varray);

end Vect1;

package body Vect1 is

   procedure Add (X, Y : not null access Varray; R : not null access Varray) 
is
   begin
  for I in X'Range loop
 R(I) := X(I) + Y(I);
  end loop;
   end;

end Vect1;

> But then why would you gimplify the size expression before
> the base expression?  I would assume that you also want
> to process the base expression first, because it is the
> source of the struct which we access in the size expression.

For the above testcase, we have a dangling PLACEHOLDER_EXPRs

+===GNAT BUG DETECTED==+
| 12.0.0 20210805 (experimental) [master revision e314cfc371d:
5eb84b79079:ead235f60139edc6eb408d8d083cbb15e417b447] (x86_64-suse-linux) GCC 
error:|
| in gimplify_expr, at gimplify.c:15019|
| Error detected around vect1.adb:6:23

probably because array_ref_low_bound, where it is normally eliminated, cannot 
do its jub properly when it is called after the base expression is gimplified.

-- 
Eric Botcazou

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[Segher Boessenkool]

On Tue, Aug 10, 2021 at 01:56:58PM -0500, Bill Schmidt wrote:
> On 8/10/21 1:38 PM, Segher Boessenkool wrote:
> >On Thu, Jul 29, 2021 at 08:30:52AM -0500, Bill Schmidt wrote:
> >>* config/rs6000/rs6000-builtin-new.def: Add always, power5, and
> >>power6 stanzas.
> >>+  unsigned long __builtin_ppc_mftb ();
> >>+MFTB rs6000_mftb_di {32bit}
> >I'm not sure what {32bit} means...  The builtin exists on both 32-bit
> >and on 64-bit, and returns what is a "long" in both cases.  The point
> >is that it is just a single "mfspr 268" always, which is fast, and
> >importantly has fixed and low latency.
> 
> Right.  The implementation of this thing is that we have two different 
> patterns in the machine description that get invoked depending on 
> whether the target is 32-bit or 64-bit.  The syntax in the built-ins 
> file only allows for one pattern.  So the {32bit} flag allows us to 
> perform special processing for TARGET_32BIT, in this case to override 
> the pattern.  Later in the patch series you'll find:

[ snip ]

Ah ok.

> I'm sure there's a better way of dealing with the mode dependency on 
> TARGET_32BIT, but for now this matches the old behavior as closely as 
> possible. I'm happy to take suggestions on this.

You could try to use something with Pmode, but it's not going to be
pretty in any case.  You also might have to deal with -m32 -mpowerpc64,
depending on if the original did.


Segher

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

[Eric Botcazou]

> Ah, thanks, I tried it but the defs__struct1IP function has
> DECL_IGNORED_P = false when I build it with -gnatD.
> 
> So that would not be affected by setting DECL_SOURCE_LOCATION to
> UNKNOWN_LOCATION as done in the proposed patch, because that is only
> done for functions with DECL_IGNORED_P = true.

Ouch, I should have checked it myself...  Thanks for doing the investigation.

> Then we have ordinary functions with DECL_IGNORED_P = false,
> but they are morphed into a thunk calling a similar looking function
> and the thunk has now DECL_IGNORED_P = true, and all debug info
> removed, except the DECL_SOURCE_LOCATION.  To make this even worse,
> the similar looking function is inlined into the thunk again, and
> all debug info is again stripped away.
> 
> And when this happens it is desirable to at least see the source line where
> the original function was declared.
> 
> 
> As an example, please consider this test case:
> 
> $ cat test.ads
> package test is
> 
>type Func_Ptr is access function (X : Integer) return Integer;
> 
>function Test1 (X : Integer) return Integer;
>function Test2 (X : Integer) return Integer;
>function DoIt (X : Integer; Func : Func_Ptr) return Integer;
> 
> end test;
> $ cat test.ads
> package test is
> 
>type Func_Ptr is access function (X : Integer) return Integer;
> 
>function Test1 (X : Integer) return Integer;
>function Test2 (X : Integer) return Integer;
>function DoIt (X : Integer; Func : Func_Ptr) return Integer;
> 
> end test;
> 
> $ cat test.adb
> package body test is
> 
>function Test1 (X : Integer) return Integer is
>begin
>   return X;
>end Test1;
> 
>function Test2 (X : Integer) return Integer is
>begin
>   return X;
>end Test2;
> 
>function DoIt (X : Integer; Func : Func_Ptr) return Integer is
>begin
>   return Func (X);
>end DoIt;
> 
> end test;
> 
> $ cat main.adb
> with Ada.Text_IO; use Ada.Text_IO;
> with test; use test;
> 
> procedure Main is
> 
>X : Integer := 7;
>Y : Integer := DoIt (X, Test1'Access);
>Z : Integer := DoIt (X, Test2'Access);
> 
> begin
>Put_Line (X'Img & " " & Y'Img & " " & Z'Img);
> end Main;
> 
> $ gnatmake -f -g -O2 main.adb -save-temp -fdump-tree-all-lineno
> 
> Now Test1 and Test2 are ordinary functions, but Test2 ends up as
> DECL_IGNORED_P = true, that happens between test.adb.052t.local-fnsummary2
> and test.adb.092t.fixup_cfg3:

Ouch (bis).  Quite unexpected that DECL_IGNORED_P is set out of nowhere.  It's 
Identical Code Folding which turns Test2 into a thunk?

> in test.adb.052t.local-fnsummary2 we have:
> 
> integer test.test1 (integer x)
> {
>[local count: 1073741824]:
>   [test.adb:5:7] return x_1(D);
> 
> }
> 
> and
> 
> integer test.test2 (integer x)
> {
>[local count: 1073741824]:
>   [test.adb:10:7] return x_1(D);
> 
> }
> 
> 
> but in test.adb.092t.fixup_cfg3
> 
> we have
> 
> integer test.test1 (integer x)
> {
>[local count: 1073741824]:
>   [test.adb:5:7] return x_1(D);
> 
> }
> 
> and
> 
> integer test.test2 (integer x)
> {
>   integer D.4674;
>   integer retval.5;
>   integer _4;
> 
>[local count: 1073741824]:
>   # DEBUG x => x_1(D)
>   _4 = x_1(D);
>   # DEBUG x => NULL
>   retval.5_2 = _4;
>   return retval.5_2;
> 
> }
> 
> 
> the line numbers are gone, and the function has DECL_IGNORED_P,
> but still a useful DECL_SOURCE_LOCATION, I don't know
> where the DECL_SOURCE_LOCATION can be seen in the dump files,
> but from debugging this effect, I know that quite well.
> 
> This second effect is why as a special case DECL_IGNORED_P functions
> with valid looking DECL_SOURCE_LOCATION have now a .loc statement,
> because that is less surprising to a user than having no line numbers
> at all here.

OK, thanks for the explanation, the patch is OK then.

-- 
Eric Botcazou

Re: [PATCH][v2] Adjust volatile handling of the operand scanner

[Eric Botcazou]

> The question is whether we instead want to amend build3 to
> set TREE_THIS_VOLATILE automatically when the FIELD_DECL has
> it set.  At least for the Fortran FE cases the gimplifier
> fails to see some volatile references and thus can generate
> wrong code which is a latent issue.

What do we do for other similar flags, e.g. TREE_READONLY?

-- 
Eric Botcazou

Re: [PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

[Joseph Myers]

On Tue, 10 Aug 2021, Sebastian Huber wrote:

> Ok, I understood how I can add a compiler provided define for libgcov. What is
> not clear to me is how I can add a target hook, set a default value, and
> customize it for a target/system. Is this described here
> 
> https://gcc.gnu.org/onlinedocs/gccint/Target-Structure.html

Yes.

It's simplest when the hook definition depends only on the target 
architecture and not the target OS, but you can work around that when the 
OS affects the definition (have an architecture-specific function used as 
the hook definition, with a #if condition inside that function based on 
definitions from architecture-and-OS-specific headers, for example).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 05/34] rs6000: Add available-everywhere and ancient builtins

[Bill Schmidt via Gcc-patches]

Hi Segher,

On 8/10/21 12:34 PM, Segher Boessenkool wrote:

On Tue, Aug 10, 2021 at 11:17:05AM -0500, will schmidt wrote:

On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:

+; This will break for long double == _Float128.  libgcc history.
+  const long double __builtin_pack_longdouble (double, double);
+PACK_TF packtf {}

Add a few more words to provide bigger hints for future archeological
digs?  (This is perhaps an obvious issue, but I'd need to do some
spelunking)

It is for __ibm128 only, not for other long double formats (we have
three: plain double, double double, IEEE QP).  So maybe the return type
should be changed?  The name of the builtin of course is unfortunate,
but it is too late to change :-)



Yeah...I'm not sure how much flexibility we have here to avoid breaking 
code in the field, but it's not a big break because whoever may be using 
it has to be assuming long double = __ibm128, and probably has work to 
do anyway.


Perhaps I should commit as is for now, and then prepare a separate patch 
to change this builtin?  There may be test suite fallout, not sure offhand.


Thanks!
Bill




Segher

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> Hi, Richard,
> 
>> On Aug 10, 2021, at 10:22 AM, Richard Biener  wrote:
 
 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 think that the above .DEFEERED_INIT is not correct?
>>> It should be:
>>> 
>>> *arr.1 = .DEFERRED_INIT (D.1952. 2, 1);
>>> 
>>> ?
>> 
>> Yes.
>> 
> 
> I updated gimplify.c for VLA and now it emits the call to .DEFERRED_INIT as:
> 
>  arr.1 = __builtin_alloca_with_align (D.1954, 32);
>  *arr.1 = .DEFERRED_INIT (D.1952, 2, 1);
> 
> However, this call triggered the assertion failure in verify_gimple_call of 
> tree-cfg.c because the LHS is not a valid LHS. 
> Then I modify tree-cfg.c as:
> 
> diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> index 330eb7dd89bf..180d4f1f9e32 100644
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -3375,7 +3375,11 @@ verify_gimple_call (gcall *stmt)
>  }
> 
>   tree lhs = gimple_call_lhs (stmt);
> +  /* For .DEFERRED_INIT call, the LHS might be an indirection of
> + a pointer for the VLA variable, which is not a valid LHS of
> + a gimple call, we ignore the asssertion on this.  */ 
>   if (lhs
> +  && (!gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
>   && (!is_gimple_reg (lhs)
>  && (!is_gimple_lvalue (lhs)
>  || verify_types_in_gimple_reference
> 
> The assertion failure in tree-cfg.c got resolved, but I got another assertion 
> failure in operands_scanner::get_expr_operands (tree *expr_p, int flags), 
> line 945:
> 
> 939   /* If we get here, something has gone wrong.  */
> 940   if (flag_checking)
> 941 {
> 942   fprintf (stderr, "unhandled expression in get_expr_operands():\n");
> 943   debug_tree (expr);
> 944   fputs ("\n", stderr);
> 945   gcc_unreachable ();
> 946 }
> 
> Looks like that  the gimple statement:
>*arr.1 = .DEFERRED_INIT (D.1952, 2, 1);
> 
> Is not valid.  i.e, the LHS should not be an indirection to a pointer. 
> 
> How to resolve this issue?

I came up with the following solution:

Define the IFN_DEFERRED_INIT function as:

   LHS = DEFERRED_INIT (SIZE of the DECL, INIT_TYPE, IS_VLA);

   if IS_VLA is false, the LHS is the DECL itself,
   if IS_VLA is true, the LHS is the pointer to this DECL that created by
   gimplify_vla_decl.


The benefit of this solution are:

1. Resolved the invalid IR issue;
2. The call stmt carries the address of the VLA natually;

The issue with this solution is:

For VLA and non-VLA, the LHS will be different, 

Do you see any other potential issues with this solution?

thanks.

Qing

Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

[Sandra Loosemore]

On 8/10/21 2:29 AM, Tobias Burnus wrote:


[snip]

To conclude: I like the code changes (LGTM); the
'__float128' -> 'TFmode' comment change also matches the code.

However, I think both longer comments need to be updated.


OK.  I used your wording verbatim for the first one.  For the second 
one, I'm still pretty confused as I think it is at least theoretically 
possible on PowerPC to have a target with 64-bit long double (AIX?) that 
also supports the __ibm128 format, and it would be wrong to assume that 
*any* 128-bit mode that's not long double is IEEE.  So I decided the 
best thing is just to replace the FIXME with a pointer to the issue I 
opened yesterday


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101835

and folks who actually understand this stuff can add some more 
discussion there.


Here's a new version of the patch with changes to the two comments only. 
 OK to commit this one?


-Sandra
commit e496723ec6ee0fcf5b0c58920c74b1c9afa831de
Author: Sandra Loosemore 
Date:   Tue Aug 3 16:21:16 2021 -0700

Fix c_float128 and c_float128_complex definitions.

gfc_float128_type_node is only non-NULL on targets that support a
128-bit type that is not long double.  Use float128_type_node instead
when computing the value of the kind constants c_float128 and
c_float128_complex from the ISO_C_BINDING intrinsic module; this also
ensures it actually corresponds to __float128 (the IEEE encoding) and
not some other 128-bit floating-point type.

2021-08-10  Sandra Loosemore  

gcc/fortran/
	* iso-c-binding.def (c_float128, c_float128_complex): Check
	float128_type_node instead of gfc_float128_type_node.
	* trans-types.c (gfc_init_kinds, gfc_build_real_type):
	Update comments re supported 128-bit floating-point types.

diff --git a/gcc/fortran/iso-c-binding.def b/gcc/fortran/iso-c-binding.def
index 8bf69ef..e65c750 100644
--- a/gcc/fortran/iso-c-binding.def
+++ b/gcc/fortran/iso-c-binding.def
@@ -114,9 +114,14 @@ NAMED_REALCST (ISOCBINDING_DOUBLE, "c_double", \
get_real_kind_from_node (double_type_node), GFC_STD_F2003)
 NAMED_REALCST (ISOCBINDING_LONG_DOUBLE, "c_long_double", \
get_real_kind_from_node (long_double_type_node), GFC_STD_F2003)
+
+/* GNU Extension.  Note that the equivalence here is specifically to
+   the IEEE 128-bit type __float128; if that does not map onto a type
+   otherwise supported by the Fortran front end, get_real_kind_from_node
+   will reject it as unsupported.  */
 NAMED_REALCST (ISOCBINDING_FLOAT128, "c_float128", \
-	   gfc_float128_type_node == NULL_TREE \
-		  ? -4 : get_real_kind_from_node (gfc_float128_type_node), \
+		(float128_type_node == NULL_TREE \
+		 ? -4 : get_real_kind_from_node (float128_type_node)), \
 	   GFC_STD_GNU)
 NAMED_CMPXCST (ISOCBINDING_FLOAT_COMPLEX, "c_float_complex", \
get_real_kind_from_node (float_type_node), GFC_STD_F2003)
@@ -124,9 +129,11 @@ NAMED_CMPXCST (ISOCBINDING_DOUBLE_COMPLEX, "c_double_complex", \
get_real_kind_from_node (double_type_node), GFC_STD_F2003)
 NAMED_CMPXCST (ISOCBINDING_LONG_DOUBLE_COMPLEX, "c_long_double_complex", \
get_real_kind_from_node (long_double_type_node), GFC_STD_F2003)
+
+/* GNU Extension.  Similar issues to c_float128 above.  */
 NAMED_CMPXCST (ISOCBINDING_FLOAT128_COMPLEX, "c_float128_complex", \
-	   gfc_float128_type_node == NULL_TREE \
-		  ? -4 : get_real_kind_from_node (gfc_float128_type_node), \
+		(float128_type_node == NULL_TREE \
+		 ? -4 : get_real_kind_from_node (float128_type_node)), \
 	   GFC_STD_GNU)
 
 NAMED_LOGCST (ISOCBINDING_BOOL, "c_bool", \
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 50fda43..26dbbd8 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -446,7 +446,7 @@ gfc_init_kinds (void)
   if (!targetm.scalar_mode_supported_p (mode))
 	continue;
 
-  /* Only let float, double, long double and __float128 go through.
+  /* Only let float, double, long double and TFmode go through.
 	 Runtime support for others is not provided, so they would be
 	 useless.  */
   if (!targetm.libgcc_floating_mode_supported_p (mode))
@@ -471,7 +471,14 @@ gfc_init_kinds (void)
 	 We round up so as to handle IA-64 __floatreg (RFmode), which is an
 	 82 bit type.  Not to be confused with __float80 (XFmode), which is
 	 an 80 bit type also supported by IA-64.  So XFmode should come out
-	 to be kind=10, and RFmode should come out to be kind=11.  Egads.  */
+	 to be kind=10, and RFmode should come out to be kind=11.  Egads.
+
+	 TODO: The kind calculation has to be modified to support all
+	 three 128-bit floating-point modes on PowerPC as IFmode, KFmode,
+	 and TFmode since the following line would all map to kind=16.
+	 However, currently only float, double, long double, and TFmode
+	 reach this code.
+  */
 
   kind = (GET_MODE_PRECISION (mode) + 7) / 8;
 
@@ -851,6 +858,7 @@ gfc_bui

[PATCH] rs6000: Fix ICE expanding lxvp and stxvp gimple built-ins [PR101849]

[Peter Bergner via Gcc-patches]

PR101849 shows we ICE on a test case when we pass a non __vector_pair *
pointer to the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins
that is cast to __vector_pair *.  The problem is that when we expand
the built-in, the cast has already been removed from gimple and we are
only given the base pointer.  The solution used here (which fixes the ICE)
is to catch this case and convert the pointer to a __vector_pair * pointer
when expanding the built-in.

This passed bootstrap and regression testing on powerpc64le-linux with
no regressions.  Ok for mainline?  This also affects GCC 11 and 10, so
ok there too after it has baked on trunk for a few days?

Peter


gcc/
PR target/101849
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
pointer to __vector_pair *.

gcc/testsuite/
PR target/101849
* gcc.target/powerpc/pr101849.c: New test.


diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 904e104c058..d04011c0489 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -11919,6 +11919,9 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi)
   tree offset = gimple_call_arg (stmt, 0);
   tree ptr = gimple_call_arg (stmt, 1);
   tree lhs = gimple_call_lhs (stmt);
+  if (TREE_TYPE (TREE_TYPE (ptr)) != vector_pair_type_node)
+   ptr = build1 (VIEW_CONVERT_EXPR,
+ build_pointer_type (vector_pair_type_node), ptr);
   tree mem = build_simple_mem_ref (build2 (POINTER_PLUS_EXPR,
   TREE_TYPE (ptr), ptr, offset));
   gimplify_assign (lhs, mem, &new_seq);
@@ -11932,6 +11935,9 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi)
   tree src = gimple_call_arg (stmt, 0);
   tree offset = gimple_call_arg (stmt, 1);
   tree ptr = gimple_call_arg (stmt, 2);
+  if (TREE_TYPE (TREE_TYPE (ptr)) != vector_pair_type_node)
+   ptr = build1 (VIEW_CONVERT_EXPR,
+ build_pointer_type (vector_pair_type_node), ptr);
   tree mem = build_simple_mem_ref (build2 (POINTER_PLUS_EXPR,
   TREE_TYPE (ptr), ptr, offset));
   gimplify_assign (mem, src, &new_seq);
diff --git a/gcc/testsuite/gcc.target/powerpc/pr101849.c 
b/gcc/testsuite/gcc.target/powerpc/pr101849.c
new file mode 100644
index 000..6d2e3b79282
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr101849.c
@@ -0,0 +1,19 @@
+/* PR target/101849 */
+/* { dg-do compile } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Verify we do not ICE on the tests below.  */
+
+__vector_pair vp;
+void
+foo (double *x)
+{
+   vp = __builtin_vsx_lxvp (0, (__vector_pair *)(void *)x);
+}
+
+void
+bar (__vector_pair *src, double *x)
+{
+  __builtin_vsx_stxvp (*src, 0, (__vector_pair *)(void *)x);
+}

Committed: gcc.dg/uninit-pred-9_b.c: Xfail for CRIS too

[Hans-Peter Nilsson via Gcc-patches]

Adding to the growing list, for autotester accounting purposes.

FWIW I see this fails for m68k too:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712395.html
and moxie:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712389.html
and pru:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712366.html

testsuite:
PR middle-end/101674
* gcc.dg/uninit-pred-9_b.c: Xfail for cris-*-* too.
---
 gcc/testsuite/gcc.dg/uninit-pred-9_b.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c 
b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
index 9383c559507c..8c2d28cbe78c 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
@@ -20,7 +20,7 @@ int foo (int n, int l, int m, int r)
   blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
 
   if ( (n <= 8) &&  (m < 99)  && (r < 19) )
-  blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail powerpc64*-*-* 
mmix-*-* } } */
+  blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail powerpc64*-*-* 
mmix-*-* cris-*-* } } */
 
   return 0;
 }
-- 
2.11.0

Re: [PATCH] Adding target hook allows to reject initialization of register

[Jojo R via Gcc-patches]

— Jojo
在 2021年8月10日 +0800 PM7:03，Richard Biener ，写道：
> 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.

Yes, it is visible. I make a simple demo as:

vuint8m1_t
foo (vuint8m1_t a, vuint8m2_t b, int vl)
{
  vuint8m2_t tmp;
  tmp = vset_v_u8m1_u8m2(tmp, 0, a);
  tmp = vadd_vv_u8m2 (tmp, b, vl);
  return vget_v_u8m2_u8m1(tmp, 0);
}

The intrinsic spec refer to:
https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv-intrinsic-api.md#vector-insertion-functions

The problematic intrinsic is vset_v_u8m1_u8m2() here,
Only half of it is operated, and

RTL dump from ‘266r.auto_inc_dec’ is :

(insn 11 8 12 2 (set (reg:VNx32QI 138 [ _10 ])
 (unspec:VNx32QI [
 (reg/v:VNx32QI 135 [ tmp ])
 (reg:SI 66 vl)
 ] UNSPEC_USEVL)) "riscv_vector.h":235:1 21133 {*movvnx32qi}
 (expr_list:REG_DEAD (reg/v:VNx32QI 135 [ tmp ])
 (nil)))

(insn 12 11 13 2 (set (subreg:VNx16QI (reg:VNx32QI 138 [ _10 ]) 0)
 (unspec:VNx16QI [
 (reg/v:VNx16QI 141 [ a ])
 (reg:SI 66 vl)
 ] UNSPEC_USEVL)) "riscv_vector.h":235:1 21132 {*movvnx16qi}
 (expr_list:REG_DEAD (reg/v:VNx16QI 141 [ a ])
 (expr_list:REG_DEAD (reg:SI 66 vl)
 (nil

RTL dump from ‘267r.init-regs’ is :

starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
scanning new insn with uid = 24.
scanning new insn with uid = 25.
scanning new insn with uid = 26.
scanning new insn with uid = 27.
adding initialization in foo of reg 135 at in block 2 for insn 11.
starting the processing of deferred insns
ending the processing of deferred insns

… …
>
> 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{

Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

[Matt Jacobson via Gcc-patches]

> On Aug 3, 2021, at 2:39 PM, Iain Sandoe  wrote:
> 
> 
> 
>> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches 
>>  wrote:
>> 
>>> On Aug 2, 2021, at 5:09 PM, Eric Gallager  wrote:
>>> 
>>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>>>  wrote:
 
 As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 
 crashes,
 unless target-specific code adds an implicit -fno-objc-sjlj-exceptions 
 (which
 Darwin does).
 
 This patch makes the general case not crash.
 
 I don't have commit access, so if this patch is suitable, I'd need someone 
 else
 to commit it for me.  Thanks.
>>> 
>>> Is there a bug open for the issue that this fixes? Just wondering for
>>> cross-referencing purposes...
>> 
>> No, I didn’t file a bug for this one, just sent the patch directly.  Hope 
>> that’s OK.  If not, happy to file one.
> 
> I have this on my TODO (and in my “to apply” patch queue - IMO it’s OK as an 
> interim
> solution - but I think in the longer term it would be better to make 
> fobjc-sjlj-exceptions
> into a NOP, since the exception models are fixed for NeXT runtime (unless you 
> have
> some intent to update the 32bit one to use DWARF unwinding ;-) ).

Thanks.

It certainly isn’t crystal clear just from the diff in the mail, but with this 
patch, -fobjc-sjlj-exceptions *is* essentially a no-op (modulo a small warning) 
under NeXT v2.

Prior to this patch, it’s also a no-op, but (a) it’s initially on by default 
for NeXT v2, which (b) causes a crash unless `-fobjc-exceptions` is also 
specified.

Matt