Re: V2 [PATCH 3/3] Build x86 libatomic with -march=i486 or better

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 04:08:20PM -0800, H.J. Lu wrote:

I think best would be to revert the i386-options.c change
until this is all fixed, keeping the trunk broken too long is undesirable.

Second, I didn't mean to talk specifically about libatomic, but about all
the 3 configure.tgt changes.
And while for the i486 and cmpxchg16b cases you now use a functional test,
for the i686 test you still use macros, and I don't e.g. see how __SSE__ is
relevant, one could have in CFLAGS -march=skylake-avx512 -mno-sse and it
wouldn't be considered an i686.
Now that I look at it, I think what you should be looking at is whether
the compiler with the ${CC} ${CFLAGS} predefines:
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 - if not, then -march=i486 needs to be
added,
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 for 32-bit code resp.
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 for 64-bit code, then
maybe try_ifunc=no (but it needs verification that the code will in the end
always use cmpxchg8b or cmpxchg16b rather than never).

Jakub

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

[Olivier Hainque]

Hi Alex,

> On 14 Jan 2021, at 22:13, Alexandre Oliva  wrote:
> 
> Hello, Olivier,
> 
> On Dec 18, 2020, Olivier Hainque  wrote:
> 
>> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
>> (copied below for convenience), please ?
> 
> I think defining alloca as a macro in analyzer-alloca.h might conflict
> with system headers included before or after analyzer-alloca.h
> 
> Say, if a system header #defines alloca(n), GCC might warn when
> encountering a different #define in analyzer-alloca.h, included later.
> 
> OTOH, if analyzer-alloca.h is included first, then a later system header
> that attempts to declare alloca as a function could be macro-substituted
> into declaring __builtin_alloca, which probably wouldn't end well.
> 
> While the alloca macro would render other changes from alloca to
> __builtin_alloca unnecessary, there's such an explicit change in the
> patch.
> 
> If it were up to me, I'd rather use __builtin_alloca explicitly all
> over.  I think we already do that in several other tests, for similar
> reasons (that some target systems don't have alloca.h or alloca)
> 
> Would you mind if I submitted an alternate patch to do so?

Not at all, thanks for your feedback and for proposing
an alternative!

Olivier

Re: [PATCH] keep scope blocks for all inlined functions (PR 98664)

[Richard Biener via Gcc-patches]

On Thu, Jan 14, 2021 at 8:13 PM Martin Sebor via Gcc-patches
 wrote:
>
> One aspect of PR 98465 - Bogus warning stringop-overread for std::string
> is the inconsistency between -g and -g0 which turns out to be due to
> GCC eliminating apparently unused scope blocks from inlined functions
> that aren't explicitly declared inline and artificial.  PR 98664 tracks
> just this part of PR 98465.
>
> To resolve just the PR 98664 subset the attached change has
> the tree-ssa-live.c pass preserve these blocks for all inlined
> functions, not just artificial ones.  Besides avoiding the interaction
> between -g and warnings it also seems to improve the inlining context
> by including more inlined call sites.  This can be seen in the adjusted
> tests.  (Its effect on PR 98465 is that the false positive is issued
> consistently, regardless of -g.  Avoiding the false positive is my
> next step.)
>
> Jakub, you raised a concern yesterday in PR 98465 c#13 about the memory
> footprint of this change.  Can you please comment on whether it's in
> line with what you were suggesting?

 {
   tree ao = BLOCK_ABSTRACT_ORIGIN (block);
-  if (TREE_CODE (ao) == FUNCTION_DECL)
-   loc = BLOCK_SOURCE_LOCATION (block);
-  else if (TREE_CODE (ao) != BLOCK)
-   break;
+   if (TREE_CODE (ao) == FUNCTION_DECL)
+loc = BLOCK_SOURCE_LOCATION (block);
+   else if (TREE_CODE (ao) != BLOCK)
+break;

you are replacing tabs with spaces?

@@ -558,16 +558,13 @@ remove_unused_scope_block_p (tree scope, bool
in_ctor_dtor_block)
else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE
&& !optinfo_wants_inlining_info_p ())
  {
-   /* Even for -g0 don't prune outer scopes from artificial
- functions, otherwise diagnostics using tree_nonartificial_location
- will not be emitted properly.  */
+   /* Even for -g0 don't prune outer scopes from inlined functions,
+ otherwise late diagnostics from such functions will not be
+ emitted or suppressed properly.  */
if (inlined_function_outer_scope_p (scope))
 {
   tree ao = BLOCK_ORIGIN (scope);
-  if (ao
-  && TREE_CODE (ao) == FUNCTION_DECL
-  && DECL_DECLARED_INLINE_P (ao)
-  && lookup_attribute ("artificial", DECL_ATTRIBUTES (ao)))
+  if (ao && TREE_CODE (ao) == FUNCTION_DECL)
 unused = false;
 }
  }

so which inlined_function_outer_scope_p are you _not_ marking now?
BLOCK_ORIGIN is never NULL and all inlined scopes should have
an abstract origin - I believe always a FUNCTIN_DECL.  Which means
you could have simplified it further?

And yes, the main reason for the code above is memory use for
C++ with lots of inlining.  I suggest to try the patch on tramp3d
for example (there's about 10 inline instances per emitted
assembly op).

Richard.

> Martin

Re: [PATCH] combine: zeroing cost for new copies

[Kewen.Lin via Gcc-patches]

Hi Segher,

Thanks for the comments!

on 2021/1/15 上午4:43, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Dec 09, 2020 at 05:49:53PM +0800, Kewen.Lin wrote:
>> This patch is to treat those new pseudo-to-pseudo copies
>> after hard-reg-to-pseudo-copy as zero costs.  The
>> justification is that these new copies are closely after
>> the corresponding hard-reg-to-pseudo-copy insns, register
>> allocation should be able to coalesce them and get them
>> eliminated.
> 
> Costing things that are not free as cost zero is very problematic.

I totally agree this.  But I'd argue that these new pseudo-to-pseudo
copies aren't counted as "not free".  Assuming they are not free, we
need to have one postpass to clean them once they are not used in
combine pass.  These new copies are closely after the corresponding
hard-reg-to-pseudo-copy insns, register allocation should be able to
coalesce them and get them eliminated.  So I think they are free
in the context of combine cost modeling.

> Cost zero is problematic in combine anyway (it means unknown cost, not
> no cost).

Yeah, zeroing cost is a bad wording here, the patch actually treats
them as free in costing, not change their costs to zero (unknown).

> 
>> Now these copies follow the normal costing scheme, the
>> below case dump shows the unexpected combination:
>>
>> ``` dump
>>
>> Trying 3, 2 -> 13:
>> 3: r119:DI=r132:DI
>>   REG_DEAD r132:DI
>> 2: r118:DI=r131:DI
>>   REG_DEAD r131:DI
>>13: r128:DI=r118:DI&0x|r119:DI<<0x20
>>   REG_DEAD r119:DI
>>   REG_DEAD r118:DI
> 
> This should not combine if 2+13 and 3+13 do not combine already.  Why
> did those not combine?

```
Trying 2 -> 13:
2: r118:DI=r131:DI
  REG_DEAD r131:DI
   13: r128:DI=r118:DI&0x|r119:DI<<0x20
  REG_DEAD r119:DI
  REG_DEAD r118:DI
Failed to match this instruction:
(set (reg:DI 128)
(ior:DI (ashift:DI (reg/v:DI 119 [ f2 ])
(const_int 32 [0x20]))
(reg:DI 131)))

Trying 3 -> 13:
3: r119:DI=r132:DI
  REG_DEAD r132:DI
   13: r128:DI=r118:DI&0x|r119:DI<<0x20
  REG_DEAD r119:DI
  REG_DEAD r118:DI
Failed to match this instruction:
(set (reg:DI 128)
(ior:DI (ashift:DI (reg:DI 132)
(const_int 32 [0x20]))
(reg/v:DI 118 [ f1 ])))
```

We don't have the pattern to match it.  So the patch in another thread
"rs6000: Use rldimi for vec init instead of shift + ior" can't keep the
desirable *rotl3_insert_3 instructions without adjusting the
costs like this patch.  Later 2,3 -> 13 will split it into shift and or.

> 
>> Failed to match this instruction:
>> (set (reg:DI 128)
>> (ior:DI (ashift:DI (reg:DI 132)
>> (const_int 32 [0x20]))
>> (reg:DI 131)))
> 
> Likely because it results in this, and this insn isn't recognised.  So
> this can be fixed by adding a pattern for it (it needs to make sure all
> but the bottom 32 bits of reg 131 are zero; it can use nonzero_bits for
> that).
> 

Yeah, that's what I thought before, as another patch mentioned, I tried
to use nonzero_bits in define_insn but failed to.  I didn't found any
nonzero_bits usages in md files, the regression tesing also showed the
recog would have more rough nonzero_bits information than what we have
in combine and then fail to validate changes, so I did give up this
direction before.

Your patch below shows a brand new way to use nonzero_bits and avoid
the recog issue, it opens a window for me, so great!!!

> Long ago I had the following patch for this.  Not sure why I never
> submitted it, maybe there is something wronmg with it?
> 

If you don't mind, I'll do a check with bootstrappping and regression
testing and then get back to you.
BR,
Kewen

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

[Kewen.Lin via Gcc-patches]

Hi Segher,

on 2021/1/15 上午8:50, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote:
>> This patch is to make unsigned int vector init go with
>> rldimi to merge two integers instead of shift and ior.
>>
>> I tried to use nonzero_bits in md file to make it more
>> general, but the testing shows it isn't doable.  The
>> reason is that some passes would replace some pseudos
>> with other pseudos and do the recog again, but at that
>> time the nonzero_bits could get rough information and
>> lead the recog fails unexpectedly.
> 
> Aha.  So nonzero_bits is unusable for most purposes as well.  Great :-/
> 
>> btw, the test case would reply on the combine patch[1].
> 
> Can you make a different testcase perhaps?  This patch looks fine
> otherwise.
> 

Thanks!  But I'm sorry that there is a typo, it should be "rely on"
rather than "reply on", without the patch[1] "combine: zeroing cost
for new copies", this test case doesn't get the desirable result.
I'll explain it more in that patch's thread.  If your uncommitted
patch there with define_split and nonzero_bits works, this patch
can be discarded totally.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561413.html

> (Ideally the compiler would just form those insert insns itself, of
> course.  Why doesn't that work?  This is important for quite a lot of
> code, we really can advantageously use the rl*imi insns often!)
> 
The reason why it doesn't work is that the *rotl3_insert_3
pattern requires one explicit AND (with some masks) there but in
this case the AND is optimized away due to that nonzero_bits
indicates the AND is redundant.

BR,
Kewen

[PATCH] c++: ICE with USING_DECL redeclaration [PR98687]

[Marek Polacek via Gcc-patches]

My recent patch that introduced push_using_decl_bindings didn't
handle USING_DECL redeclaration, therefore things broke.  This
patch amends that.  Note that I don't know if the other parts of
finish_nonmember_using_decl are needed (e.g. the binding->type
setting) -- I couldn't trigger it by any of my hand-made testcases.

Sorry for not thinking harder about redeclarations in the original
patch :(.

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

gcc/cp/ChangeLog:

PR c++/98687
* name-lookup.c (push_using_decl_bindings): If we found an
existing local binding, update it if it's not identical.

gcc/testsuite/ChangeLog:

PR c++/98687
* g++.dg/lookup/using64.C: New test.
* g++.dg/lookup/using65.C: New test.
---
 gcc/cp/name-lookup.c  | 20 -
 gcc/testsuite/g++.dg/lookup/using64.C | 60 +++
 gcc/testsuite/g++.dg/lookup/using65.C | 17 
 3 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/lookup/using64.C
 create mode 100644 gcc/testsuite/g++.dg/lookup/using65.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index b4b6c0b81b5..857d90914ca 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9285,8 +9285,24 @@ push_operator_bindings ()
 void
 push_using_decl_bindings (tree decl)
 {
-  push_local_binding (DECL_NAME (decl), USING_DECL_DECLS (decl),
- /*using*/true);
+  tree name = DECL_NAME (decl);
+  tree value = USING_DECL_DECLS (decl);
+
+  cxx_binding *binding = find_local_binding (current_binding_level, name);
+  if (binding)
+{
+  if (value == binding->value)
+   /* Redeclaration of this USING_DECL.  */;
+  else if (binding->value && TREE_CODE (value) == OVERLOAD)
+   {
+ /* We already have this binding, so replace it.  */
+ update_local_overload (IDENTIFIER_BINDING (name), value);
+ IDENTIFIER_BINDING (name)->value = value;
+   }
+}
+  else
+/* Install the new binding.  */
+push_local_binding (DECL_NAME (decl), value, /*using*/true);
 }
 
 #include "gt-cp-name-lookup.h"
diff --git a/gcc/testsuite/g++.dg/lookup/using64.C 
b/gcc/testsuite/g++.dg/lookup/using64.C
new file mode 100644
index 000..42bce331e19
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/using64.C
@@ -0,0 +1,60 @@
+// PR c++/98687
+// { dg-do compile }
+
+struct S { };
+
+namespace N {
+  template 
+  bool operator==(T, int);
+
+  template 
+  void X(T);
+}
+
+namespace M {
+  template 
+  bool operator==(T, double);
+}
+
+template
+bool fn1 (T t)
+{
+  using N::operator==;
+  return t == 1;
+}
+
+template
+bool fn2 (T t)
+{
+  // Redeclaration.
+  using N::operator==;
+  using N::operator==;
+  return t == 1;
+}
+
+template
+bool fn3 (T t)
+{
+  // Need update_local_overload.
+  using N::operator==;
+  using M::operator==;
+  return t == 1;
+}
+
+template
+void fn4 (T t)
+{
+  struct X { };
+  using N::X;
+  X(1);
+}
+
+void
+g ()
+{
+  S s;
+  fn1 (s);
+  fn2 (s);
+  fn3 (s);
+  fn4 (s);
+}
diff --git a/gcc/testsuite/g++.dg/lookup/using65.C 
b/gcc/testsuite/g++.dg/lookup/using65.C
new file mode 100644
index 000..bc6c086197f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/using65.C
@@ -0,0 +1,17 @@
+// PR c++/98687
+// { dg-do compile }
+
+extern "C" namespace std {
+  double log1p(double);
+}
+namespace std_fallback {
+  template  void log1p();
+}
+template  struct log1p_impl {
+  static int run() {
+using std::log1p;
+using std_fallback::log1p;
+return 0;
+  }
+};
+void log1p() { log1p_impl::run(); }

base-commit: 5fff80fd79c36a1a940b331d20905061d61ee5e6
-- 
2.29.2

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move.

[Michael Meissner via Gcc-patches]

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move.

This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.  Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal compares, and the other pattern for inverted compares).  I can go
back to a single pattern with a new predicate that allows either comparison.

Compared to the original code, these patterns do simplify the fpmask insns to
having one alternative instead of two.  In the original code, the first
alternative tried to use the result as a temporary register.  But that doesn't
work if you are doing a conditional move with SF/DF types, but the comparison
is KF/TF.  That is because the SF/DF types can use the traditional FPR
registers, but IEEE 128-bit floating point can only do arithmetic in the
traditional Altivec registers.

This code also has to insert a XXPERMDI if you are moving KF/TF values, but
the comparison is done with SF/DF values.  In this case, the set and compare
mask for SF/DF clears the bottom 64-bits of the register, and the XXPERMDI is
needed to fill it.

I have tested this on little endian power9 servers, and there were no
regressions.  I have also done unit tests on power10 hardware and the code
generates the min/max instructions.  Can I check this into the master branch?

gcc/
2021-01-14 Michael Meissner  

* config/rs6000/rs6000.c (have_compare_and_set_mask): Add IEEE
128-bit floating point types.
* config/rs6000/rs6000.md (FPMASK): New iterator.
(FPMASK2): New iterator.
(Fv mode attribute): Add KFmode and TFmode.
(movcc_fpmask): Replace
movcc_p9.  Add IEEE 128-bit fp support.
(movcc_invert_fpmask): Replace
movcc_invert_p9.  Add IEEE 128-bit fp
support.
(fpmask): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.
(xxsel): Add IEEE 128-bit fp support.  Enable generator to
build te RTL.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-cmove.c: New test.
* gcc.target/powerpc/float128-minmax-3.c: New test.
---
 gcc/config/rs6000/rs6000.c|   8 +-
 gcc/config/rs6000/rs6000.md   | 188 --
 .../gcc.target/powerpc/float128-cmove.c   |  93 +
 .../gcc.target/powerpc/float128-minmax-3.c|  15 ++
 4 files changed, 237 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-cmove.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 08b407030a3..47a56912e27 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15337,8 +15337,8 @@ rs6000_emit_vector_cond_expr (rtx dest, rtx op_true, 
rtx op_false,
   return 1;
 }
 
-/* Possibly emit the xsmaxcdp and xsmincdp instructions to emit a maximum or
-   minimum with "C" semantics.
+/* Possibly emit the xsmaxc{dp,qp} and xsminc{dp,qp} instructions to emit a
+   maximum or minimum with "C" semantics.
 
Unless you use -ffast-math, you can't use these instructions to replace
conditions that implicitly reverse the condition because the comparison
@@ -15474,6 +15474,10 @@ have_compare_and_set_mask (machine_mode mode)
 case E_DFmode:
   return TARGET_P9_MINMAX;
 
+case E_KFmode:
+case E_TFmode:
+  return FLOAT128_MIN_MAX_FPMASK_P (mode);
+
 default:
   break;
 }
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 45be9c381bc..d658b45ee3a 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -564,6 +564,19 @@ (define_mode_iterator SFDF [SF DF])
 ; And again, for when we need two FP modes in a pattern.
 (define_mode_iterator SFDF2 [SF DF])
 
+; Floating scalars that supports the set compare mask instruction.
+(define_mode_iterator FPMASK [SF
+ DF
+ (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+ (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
+; And again, for patterns that need two (potentially) different floating point
+; scalars that support the set compare mask instruction.
+(define_mode_iterator FPMASK2 [SF
+  DF
+  (KF "FLOAT128_MIN_MAX_FPMASK_P (KFmode)")
+  (TF "FLOAT128_MIN_MAX_FPMASK_P (TFmode)")])
+
 ; A generic s/d attribute, for sp/dp for example.
 (define_mode_attr sd [(SF   "s") (DF   "d")
  (V4SF "s") (V2DF "d")])
@@ -597,8 +610,13 @@ (define_mode_attr Ff   [(SF "f") (DF "d") (DI 
"d")])
 ; SF/DF constraint for arithmetic on VSX registers using instructions added in
 ; ISA 2.06 (power7).  This includes instructions that normally target DF mode,
 ; but are used on SFmode, since internally 

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] Power10: Add IEEE 128-bit min/max support.

This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions.  The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.

Rather than trying to overload the current SF/DF min/max support, it was
simpler to just provide the new instructions as a separate insn.

I have tested this on little endian power9 servers, and there were no
regressions.  I have also done unit tests on power10 hardware and the code
generates the min/max instructions.  Can I check this into the master branch?

gcc/
2021-01-14  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
* config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
* config/rs6000/rs6000.md (s3): Add support for the
ISA 3.1 IEEE 128-bit minimum and maximum instructions.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-minmax-2.c: New test.
---
 gcc/config/rs6000/rs6000.c|  3 ++-
 gcc/config/rs6000/rs6000.h|  5 +
 gcc/config/rs6000/rs6000.md   | 11 +++
 .../gcc.target/powerpc/float128-minmax-2.c| 15 +++
 4 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b9e90ae0468..08b407030a3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15742,7 +15742,8 @@ rs6000_emit_minmax (rtx dest, enum rtx_code code, rtx 
op0, rtx op1)
   /* VSX/altivec have direct min/max insns.  */
   if ((code == SMAX || code == SMIN)
   && (VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)
- || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode
+ || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode))
+ || FLOAT128_MIN_MAX_FPMASK_P (mode)))
 {
   emit_insn (gen_rtx_SET (dest, gen_rtx_fmt_ee (code, mode, op0, op1)));
   return;
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index b05dd827b13..1ff07345a93 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -345,6 +345,11 @@ extern const char *host_detect_local_cpu (int argc, const 
char **argv);
|| ((MODE) == TDmode)   \
|| (!TARGET_FLOAT128_TYPE && FLOAT128_IEEE_P (MODE)))
 
+/* Macro whether the float128 minimum, maximum, and set compare mask
+   instructions are enabled.  */
+#define FLOAT128_MIN_MAX_FPMASK_P(MODE)
\
+  (TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (MODE))
+
 /* Return true for floating point that does not use a vector register.  */
 #define SCALAR_FLOAT_MODE_NOT_VECTOR_P(MODE)   \
   (SCALAR_FLOAT_MODE_P (MODE) && !FLOAT128_VECTOR_P (MODE))
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index bb9fb42f82a..45be9c381bc 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5163,6 +5163,17 @@ (define_insn "*s3_vsx"
 }
   [(set_attr "type" "fp")])
 
+;; Min/max for ISA 3.1 IEEE 128-bit floating point
+(define_insn "s3"
+  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
+   (fp_minmax:IEEE128
+(match_operand:IEEE128 1 "altivec_register_operand" "v")
+(match_operand:IEEE128 2 "altivec_register_operand" "v")))]
+  "TARGET_POWER10"
+  "xscqp %0,%1,%2"
+  [(set_attr "type" "vecfloat")
+   (set_attr "size" "128")])
+
 ;; The conditional move instructions allow us to perform max and min operations
 ;; even when we don't have the appropriate max/min instruction using the FSEL
 ;; instruction.
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c 
b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
new file mode 100644
index 000..c71ba08c9f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2 -ffast-math" } */
+
+#ifndef TYPE
+#define TYPE _Float128
+#endif
+
+/* Test that the fminf128/fmaxf128 functions generate if/then/else and not a
+   call.  */
+TYPE f128_min (TYPE a, TYPE b) { return __builtin_fminf128 (a, b); }
+TYPE f128_max (TYPE a, TYPE b) { return __builtin_fmaxf128 (a, b); }
+
+/* { dg-final { scan-assembler {\mxsmaxcqp\M} } } */
+/* { dg-final { scan-assembler {\mxsmincqp\M} } } */
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 0/2] PowerPC: Add power10 IEEE 128-bit min/max/cmove

[Michael Meissner via Gcc-patches]

These patches have been kicking around for awhile, and I really would like to
get them in.  They aren't as important as the other float128 patches I've
submitted today, since many of those patches are designed to allow switching
the long double format to IEEE 128-bit, which we need in GCC 11.

I have rewritten these patches based on the last review.  Hopefully I have made
them simpler.

The first patch adds the basic min/max insns.  Originally I tried to overload
min/max insns, but it was rather clunky because of the different rules for
DF/SF min/max insns vs. KF/TF insns.  Now, I just create separate min/max
patterns for IEEE 128-bit.

The second patch enables conditional move.  Because the conditional move is
based on using XXSEL, you can have one of the 4 floating point types being
compared and do a conditional move with another floating point type.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

[Michael Meissner via Gcc-patches]

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
the IBM 128-bit extended double format.  In particular, some of the tests
expect an infinity to be created if decimal values that are converted that are
too large for IBM extended double.  However, the numbers do fit in the range
for IEEE 128-bit format, since it has a larger exponent than the IBM 128-bit
format.  The test fails because an infinity is not generated.

This patch explicitly sets the long double type to IBM extended double.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: Force using IBM 128-bit long
double.  Remove check for 64-bit long double.
---
 .../c-c++-common/dfp/convert-bfp-11.c  | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..35da07d1fa4 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -1,9 +1,14 @@
-/* { dg-skip-if "" { ! "powerpc*-*-linux*" } } */
+/* { dg-require-effective-target dfp } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
-/* Test decimal float conversions to and from IBM 128-bit long double. 
-   Checks are skipped at runtime if long double is not 128 bits.
-   Don't force 128-bit long doubles because runtime support depends
-   on glibc.  */
+/* We force the long double type to be IBM 128-bit because the CONVERT_TO_PINF
+   tests will fail if we use IEEE 128-bit floating point.  This is due to IEEE
+   128-bit having a larger exponent range than IBM 128-bit extended double.  So
+   tests that would generate an infinity with IBM 128-bit will generate a
+   normal number with IEEE 128-bit.  */
+
+/* Test decimal float conversions to and from IBM 128-bit long double.   */
 
 #include "convert.h"
 
@@ -36,9 +41,6 @@ CONVERT_TO_PINF (312, tf, sd, 1.6e+308L, d32)
 int
 main ()
 {
-  if (sizeof (long double) != 16)
-return 0;
-
   convert_101 ();
   convert_102 ();
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit.

[Michael Meissner via Gcc-patches]

[PATCH 2/3] PowerPC: PR target/70117, Force long double to be IBM 128-bit.

This patch fixes the pr70117 test to use IBM 128-bit long double.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

PR target/70117
* gcc.target/powerpc/pr70117.c: Force the long double type to use
the IBM 128-bit format.
---
 gcc/testsuite/gcc.target/powerpc/pr70117.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..8a5fad1dee0 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -1,5 +1,7 @@
-/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* powerpc*-*-aix* 
rs6000-*-* } } } */
-/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
+/* { dg-do run } */
+/* { dg-require-effective-target ppc_long_double_override_ibm128 } */
+/* { dg-options "-std=c99 -O2" } */
+/* { dg-add-options ppc_long_double_override_ibm128 } */
 
 #include 
 
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

[PATCH 1/3] PowerPC: Add long double target-supports.

This patch add several more selections to target-supports.exp:

*   3 selections for the current long double format;
*   3 selections if we can change the long double format to a particular
value.
*   3 functions to return the options needed to switch the long double
format for use with dg-add-options.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

Can I check this patch into the master branch?

gcc/testsuite/
2021-01-14  Michael Meissner  

* lib/target-supports.exp
(check_effective_target_ppc_long_double_ibm128): New function.
(check_effective_target_ppc_long_double_ieee128): New function.
(check_effective_target_ppc_long_double_64bit): New function.
(add_options_for_ppc_long_double_override_ibm128): New function.
(check_effective_target_ppc_long_double_override_ibm128): New
function.
(add_options_for_ppc_long_double_override_ieee128): New function.
(check_effective_target_ppc_long_double_override_ieee128): New
function.
(add_options_for_ppc_long_double_override_64bit): New function.
(check_effective_target_ppc_long_double_override_64bit): New
function.
---
 gcc/testsuite/lib/target-supports.exp | 155 ++
 1 file changed, 155 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 47d4c45e9eb..2badb495adc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2354,6 +2354,161 @@ proc check_effective_target_ppc_ieee128_ok { } {
 }]
 }
 
+# See if the target is a powerpc with the long double format that uses the IBM
+# extended double format.
+
+proc check_effective_target_ppc_long_double_ibm128 { } {
+return [check_cached_effective_target ppc_long_double_ibm {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that uses the IEEE
+# 128-bit format.
+
+proc check_effective_target_ppc_long_double_ieee128 { } {
+return [check_cached_effective_target ppc_long_double_ieee {
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
+   return 1;
+ #else
+   return 0;
+ #endif
+   }
+}]
+}
+
+# See if the target is a powerpc with the long double format that is 64-bit.
+
+proc check_effective_target_ppc_long_double_64bit { } {
+return [check_cached_effective_target ppc_long_double_64bit {
+   int main()
+   {
+ #ifndef _ARCH_PPC
+   return 1;
+ #else
+   return sizeof (long double) != 8;
+ #endif
+   }
+}]
+}
+
+# Like check_effective_target_ppc_long_double_ibm128, but check if we can
+# explicitly override the long double format to use the IBM 128-bit extended
+# double format, and GLIBC supports doing this override by switching the
+# sprintf to handle long double.
+
+proc add_options_for_ppc_long_double_override_ibm128 { flags } {
+if { [istarget powerpc*-*-*] } {
+   return "$flags -mlong-double-128 -Wno-psabi -mabi=ibmlongdouble"
+}
+return "$flags"
+}
+
+proc check_effective_target_ppc_long_double_override_ibm128 { } {
+return [check_runtime_nocache ppc_long_double_ovveride_ibm128 {
+   #include 
+   #include 
+   volatile __ibm128 a = (__ibm128) 3.0;
+   volatile long double one = 1.0L;
+   volatile long double two = 2.0L;
+   volatile long double b;
+   char buffer[20];
+   int main()
+   {
+ #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
+   return 1;
+ #else
+   b = one + two;
+   if (memcmp ((void *), (void *), sizeof (long double)) != 0)
+ return 1;
+   sprintf (buffer, "%lg", b);
+   return strcmp (buffer, "3") != 0;
+ #endif
+   }
+} [add_options_for_ppc_long_double_override_ibm128 ""]]
+}
+
+# Like check_effective_target_ppc_long_double_ieee, but check if we can
+# explicitly override the long double format to use the IEEE 128-bit format,
+# and GLIBC supports doing this override by switching the sprintf to handle
+# long double.
+
+proc add_options_for_ppc_long_double_override_ieee128 { flags } {
+if { [istarget powerpc*-*-*] } {
+   return "$flags -mlong-double-128 -Wno-psabi -mabi=ieeelongdouble"
+}
+return "$flags"
+}
+
+proc 

[PATCH 0/3] PowerPC: Fix up tests for IEEE 128-bit long double

[Michael Meissner via Gcc-patches]

In November, I submitted a patch to fix up some of the tests for when IEEE
128-bit is used as the long double format.  Segher had some suggestions.  These
patches are based on those suggestions:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559836.html

These patches add several more selections to target-supports.exp:

*   3 selections for the current long double format;
*   3 selections if we can change the long double format to a particular
value.
*   3 functions to return the options needed to switch the long double
format for use with dg-add-options.

And there are the 2 tests (pr70117, convert-bfp-11.c) that need to be
configured run with IBM 128-bit long double because the test itself was written
knowing about the format of IBM 128-bit floating point.

I have run tests on a little endian power9 system with 3 compilers:
*   One compiler using the default IBM 128-bit format;
*   One compiler using the IEEE 128-bit format; (and)
*   One compiler using 64-bit long doubles.

I have also tested compilers on a big endian power8 system with a compiler
defaulting to power8 code generation and another with the default cpu set.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: Ping ^ 4: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

[Xionghu Luo via Gcc-patches]

Ping^4, thanks.


On 2020/12/23 10:18, Xionghu Luo via Gcc-patches wrote:

Ping^3 for stage 3.

And this followed patch:
[PATCH 4/4] rs6000: Update testcases' instruction count.

Thanks:)


On 2020/12/3 22:16, Xionghu Luo via Gcc-patches wrote:

Ping. Thanks.


On 2020/11/27 09:04, Xionghu Luo via Gcc-patches wrote:

Hi Segher,
Thanks for the approval of [PATCH 1/4] and [PATCH 2/4], what's your
opinion of this [PATCH 3/4] for P8, please?  xxinsertw only exists since
v3.0, so we had to implement by another way.


Xionghu


On 2020/10/10 16:08, Xionghu Luo wrote:

gcc/ChangeLog:

2020-10-10  Xionghu Luo  

* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Generate ARRAY_REF(VIEW_CONVERT_EXPR) for P8 and later
platforms.
* config/rs6000/rs6000.c (rs6000_expand_vector_set_var): Update
to call different path for P8 and P9.
(rs6000_expand_vector_set_var_p9): New function.
(rs6000_expand_vector_set_var_p8): New function.

gcc/testsuite/ChangeLog:

2020-10-10  Xionghu Luo  

* gcc.target/powerpc/pr79251.p8.c: New test.
---
   gcc/config/rs6000/rs6000-c.c  |  27 +++-
   gcc/config/rs6000/rs6000.c    | 117 
+-

   gcc/testsuite/gcc.target/powerpc/pr79251.p8.c |  17 +++
   3 files changed, 155 insertions(+), 6 deletions(-)
   create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251.p8.c

diff --git a/gcc/config/rs6000/rs6000-c.c 
b/gcc/config/rs6000/rs6000-c.c

index 5551a21d738..4bea8001ec6 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -1599,10 +1599,29 @@ altivec_resolve_overloaded_builtin 
(location_t loc, tree fndecl,

 SET_EXPR_LOCATION (stmt, loc);
 stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
   }
-  stmt = build_array_ref (loc, stmt, arg2);
-  stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt,
-  convert (TREE_TYPE (stmt), arg0));
-  stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+
+  if (TARGET_P8_VECTOR)
+    {
+  stmt = build_array_ref (loc, stmt, arg2);
+  stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt,
+  convert (TREE_TYPE (stmt), arg0));
+  stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+    }
+  else
+    {
+  tree arg1_inner_type;
+  tree innerptrtype;
+  arg1_inner_type = TREE_TYPE (arg1_type);
+  innerptrtype = build_pointer_type (arg1_inner_type);
+
+  stmt = build_unary_op (loc, ADDR_EXPR, stmt, 0);
+  stmt = convert (innerptrtype, stmt);
+  stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
+  stmt = build_indirect_ref (loc, stmt, RO_NULL);
+  stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
+ convert (TREE_TYPE (stmt), arg0));
+  stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+    }
 return stmt;
   }
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 96f76c7a74c..33ca839cb28 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -6806,10 +6806,10 @@ rs6000_expand_vector_set (rtx target, rtx 
val, rtx elt_rtx)

   }
   /* Insert VAL into IDX of TARGET, VAL size is same of the vector 
element, IDX

-   is variable and also counts by vector element size.  */
+   is variable and also counts by vector element size for p9 and 
above.  */

   void
-rs6000_expand_vector_set_var (rtx target, rtx val, rtx idx)
+rs6000_expand_vector_set_var_p9 (rtx target, rtx val, rtx idx)
   {
 machine_mode mode = GET_MODE (target);
@@ -6852,6 +6852,119 @@ rs6000_expand_vector_set_var (rtx target, 
rtx val, rtx idx)

 emit_insn (perml);
   }
+/* Insert VAL into IDX of TARGET, VAL size is same of the vector 
element, IDX

+   is variable and also counts by vector element size for p8.  */
+
+void
+rs6000_expand_vector_set_var_p8 (rtx target, rtx val, rtx idx)
+{
+  machine_mode mode = GET_MODE (target);
+
+  gcc_assert (VECTOR_MEM_VSX_P (mode) && !CONST_INT_P (idx));
+
+  gcc_assert (GET_MODE (idx) == E_SImode);
+
+  machine_mode inner_mode = GET_MODE (val);
+  HOST_WIDE_INT mode_mask = GET_MODE_MASK (inner_mode);
+
+  rtx tmp = gen_reg_rtx (GET_MODE (idx));
+  int width = GET_MODE_SIZE (inner_mode);
+
+  gcc_assert (width >= 1 && width <= 4);
+
+  if (!BYTES_BIG_ENDIAN)
+    {
+  /*  idx = idx * width.  */
+  emit_insn (gen_mulsi3 (tmp, idx, GEN_INT (width)));
+  /*  idx = idx + 8.  */
+  emit_insn (gen_addsi3 (tmp, tmp, GEN_INT (8)));
+    }
+  else
+    {
+  emit_insn (gen_mulsi3 (tmp, idx, GEN_INT (width)));
+  emit_insn (gen_subsi3 (tmp, GEN_INT (24 - width), tmp));
+    }
+
+  /*  lxv vs33, mask.
+  DImode: 0x
+  SImode: 0x
+  HImode: 0x.
+  QImode: 0x00ff.  */
+  rtx mask = gen_reg_rtx (V16QImode);
+  rtx mask_v2di = gen_reg_rtx (V2DImode);
+  rtvec v = rtvec_alloc (2);
+  

Go patch committed: Add support for reading embedcfg files

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend adds support for reading embedcfg files.
An embedcfg file is a JSON file created by the go command when it sees
a go:embed directive, and passed to the Go frontend via the new
-fgo-embedcfg option.  This code is not yet called, and does not yet
do anything.  It's being sent as a separate patch to isolate just the
JSON parsing code.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

* Make-lang.in (GO_OBJS): Add go/embed.o.
e87ed7d4e9642e6a7c73aa57e1f8b1068bb78612
diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in
index 84dd6cc0f18..4bdc8f6ea5a 100644
--- a/gcc/go/Make-lang.in
+++ b/gcc/go/Make-lang.in
@@ -51,6 +51,7 @@ go-warn = $(STRICT_WARN)
 
 GO_OBJS = \
go/ast-dump.o \
+   go/embed.o \
go/escape.o \
go/export.o \
go/expressions.o \
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 8cfc63248a7..82f43f5f21f 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-fd5396b1af389a55d1e3612702cfdad6755084e9
+22ce16e28220d446c4557f47129024e3561f3d77
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/embed.cc b/gcc/go/gofrontend/embed.cc
new file mode 100644
index 000..19c6930d0c3
--- /dev/null
+++ b/gcc/go/gofrontend/embed.cc
@@ -0,0 +1,628 @@
+// embed.cc -- Go frontend go:embed handling.
+
+// Copyright 2021 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+#include "go-system.h"
+
+#include "operator.h"
+#include "go-diagnostics.h"
+#include "lex.h"
+#include "gogo.h"
+
+#ifndef O_BINARY
+#define O_BINARY 0
+#endif
+
+// Read a file into *DATA.  Returns false on error.
+
+static bool
+read_file(const char* filename, Location loc, std::string* data)
+{
+  int fd = open(filename, O_RDONLY | O_BINARY);
+  if (fd < 0)
+{
+  go_error_at(loc, "%s: %m", filename);
+  return false;
+}
+
+  struct stat st;
+  if (fstat(fd, ) < 0)
+{
+  go_error_at(loc, "%s: %m", filename);
+  return false;
+}
+  off_t want = st.st_size;
+
+  // Most files read here are going to be incorporated into the object file
+  // and then the executable.  Set a limit on the size we will accept.
+  if (want > 20)
+{
+  go_error_at(loc, "%s: file too large", filename);
+  return false;
+}
+
+  data->resize(want);
+  off_t got = 0;
+  while (want > 0)
+{
+  // C++11 requires that std::string use contiguous bytes, so this
+  // is safe.
+  ssize_t n = read(fd, &(*data)[got], want);
+  if (n < 0)
+   {
+ close(fd);
+ go_error_at(loc, "%s: %m", filename);
+ return false;
+   }
+  if (n == 0)
+   {
+ data->resize(got);
+ break;
+   }
+  got += n;
+  want -= n;
+}
+
+  close(fd);
+  return true;
+}
+
+// A JSON value as read from an embedcfg file.  For our purposes a
+// JSON value is a string, or a list of strings, or a mapping from
+// strings to values.  We don't expect any numbers.  We also don't
+// expect an array of anything other than strings; that is, we don't
+// accept an array of general JSON values.
+
+class Json_value
+{
+ public:
+  // The types of values.
+  enum Json_value_classification
+{
+  JSON_VALUE_UNKNOWN,
+  JSON_VALUE_STRING,
+  JSON_VALUE_ARRAY,
+  JSON_VALUE_MAP
+};
+
+  Json_value()
+: classification_(JSON_VALUE_UNKNOWN), string_(), array_(), map_()
+  { }
+
+  ~Json_value();
+
+  Json_value_classification
+  classification() const
+  { return this->classification_; }
+
+  // Set to a string value.
+  void
+  set_string(const std::string& str)
+  {
+go_assert(this->classification_ == JSON_VALUE_UNKNOWN);
+this->classification_ = JSON_VALUE_STRING;
+this->string_ = str;
+  }
+
+  // Start an array value.
+  void
+  start_array()
+  {
+go_assert(this->classification_ == JSON_VALUE_UNKNOWN);
+this->classification_ = JSON_VALUE_ARRAY;
+  }
+
+  // Add an array entry.
+  void
+  add_array_entry(const std::string& s)
+  {
+go_assert(this->classification_ == JSON_VALUE_ARRAY);
+this->array_.push_back(s);
+  }
+
+  // Start a map value.
+  void
+  start_map()
+  {
+go_assert(this->classification_ == JSON_VALUE_UNKNOWN);
+this->classification_ = JSON_VALUE_MAP;
+  }
+
+  // Add a map entry.
+  void
+  add_map_entry(const std::string& key, Json_value* val)
+  {
+go_assert(this->classification_ == JSON_VALUE_MAP);
+this->map_[key] = val;
+  }
+
+  // Return the strings from a string value.
+  const std::string&
+  to_string() const
+  {
+go_assert(this->classification_ == JSON_VALUE_STRING);
+return this->string_;
+  }
+
+  // Fetch a vector of strings, and drop them from the JSON value.
+  void
+  get_and_clear_array(std::vector* v)
+  {
+

Re: [PATCH] libstdc++: c++2b, implement WG21 P1679R3

[Paul Fee via Gcc-patches]

On Thu, Jan 14, 2021 at 5:06 PM Jonathan Wakely  wrote:
>
> On 13/01/21 01:21 +, Paul Fee via Libstdc++ wrote:
> >Add contains member function to basic_string_view and basic_string.
> >
> >The new method is enabled for -std=gnu++20, gnu++2b and c++2b.  This allows
> >users to access the method as a GNU extension to C++20.  The conditional
> >test may be reduced to "__cplusplus > 202011L" once GCC has a c++2b switch.
>
> Thanks for the patch.
>
> A few comments below.
>

Thanks for the feedback, see "[PATCH v2] libstdc++: C++23, implement
WG21 P1679R3" for fixes.

[PATCH v2] libstdc++: C++23, implement WG21 P1679R3

[Paul Fee via Gcc-patches]

Add contains member function to basic_string_view and basic_string.

The new method is enabled for -std=gnu++20, gnu++2b and c++2b.  This allows
users to access the method as a GNU extension to C++20.  The conditional
test may be reduced to "__cplusplus > 202011L" once GCC has a c++2b switch.

Changes since v1 (13th Jan 2021)
* New:
  Test __cplusplus >= 202011L, rather than __cplusplus > 202011L.

* As suggested by Jonathan Wakely:
  Adjust formatting.
  Test feature-test macro is defined by  and .
  Correct copyright dates on new files.
  Fix comment typo.

libstdc++-v3/

Add contains member function to basic_string_view.
Likewise to basic_string_view, both with and without _GLIBCXX_USE_CXX11_ABI.
Enabled with -std=gnu++20, gnu++2b and c++2b.
* include/bits/basic_string.h (basic_string::contains): New.
* libstdc++-v3/include/std/string_view (basic_string_view::contains): New.
* testsuite/21_strings/basic_string/operations/contains/char/1.cc: New test.
* testsuite/21_strings/basic_string/operations/contains/wchar_t/1.cc:
New test.
* testsuite/21_strings/basic_string_view/operations/contains/char/1.cc:
New test.
* testsuite/21_strings/basic_string_view/operations/contains/wchar_t/1.cc:
New test.
---
 libstdc++-v3/include/bits/basic_string.h
   |   30 
 libstdc++-v3/include/std/string_view
   |   16 ++
 libstdc++-v3/include/std/version
   |9 +
 libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/char/1.cc
|   65 ++
 libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/wchar_t/1.cc
 |   65 ++
 libstdc++-v3/testsuite/21_strings/basic_string/operations/starts_with/char/1.cc
 |2
 
libstdc++-v3/testsuite/21_strings/basic_string/operations/starts_with/wchar_t/1.cc
  |2
 
libstdc++-v3/testsuite/21_strings/basic_string_view/operations/contains/char/1.cc
   |   57 
 
libstdc++-v3/testsuite/21_strings/basic_string_view/operations/contains/char/2.cc
   |   27 
 
libstdc++-v3/testsuite/21_strings/basic_string_view/operations/contains/wchar_t/1.cc
|   51 +++
 10 files changed, 320 insertions(+), 4 deletions(-)


diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index e272d332934..ec0abca2a5d 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3073,6 +3073,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   { return __sv_type(this->data(), this->size()).ends_with(__x); }
 #endif // C++20

+#if __cplusplus >= 202011L \
+  || (__cplusplus == 202002L && !defined __STRICT_ANSI__)
+  bool
+  contains(basic_string_view<_CharT, _Traits> __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(_CharT __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(const _CharT* __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+#endif // C++23
+
   // Allow basic_stringbuf::__xfer_bufptrs to call _M_length:
   template friend class basic_stringbuf;
 };
@@ -5998,6 +6013,21 @@ _GLIBCXX_END_NAMESPACE_CXX11
   { return __sv_type(this->data(), this->size()).ends_with(__x); }
 #endif // C++20

+#if __cplusplus >= 202011L \
+  || (__cplusplus == 202002L && !defined __STRICT_ANSI__)
+  bool
+  contains(basic_string_view<_CharT, _Traits> __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(_CharT __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(const _CharT* __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+#endif // C++23
+
 # ifdef _GLIBCXX_TM_TS_INTERNAL
   friend void
   ::_txnal_cow_string_C1_for_exceptions(void* that, const char* s,
diff --git a/libstdc++-v3/include/std/string_view
b/libstdc++-v3/include/std/string_view
index e33e1bc4b79..6a6863cf189 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -352,6 +352,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return this->ends_with(basic_string_view(__x)); }
 #endif // C++20

+#if __cplusplus >= 202011L \
+  || (__cplusplus == 202002L && !defined __STRICT_ANSI__)
+#define __cpp_lib_string_contains 202011L
+  constexpr bool
+  contains(basic_string_view __x) const noexcept
+  { return this->find(__x) != npos; }
+
+  constexpr bool
+  contains(_CharT __x) const noexcept
+  { return this->find(__x) != npos; }
+
+  constexpr bool
+  contains(const _CharT* __x) const noexcept
+  { return this->find(__x) != npos; }
+#endif // C++23
+
   // [string.view.find], searching

   constexpr size_type
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

[Segher Boessenkool]

Hi!

On Tue, Dec 22, 2020 at 04:08:26PM +0800, Kewen.Lin wrote:
> This patch is to make unsigned int vector init go with
> rldimi to merge two integers instead of shift and ior.
> 
> I tried to use nonzero_bits in md file to make it more
> general, but the testing shows it isn't doable.  The
> reason is that some passes would replace some pseudos
> with other pseudos and do the recog again, but at that
> time the nonzero_bits could get rough information and
> lead the recog fails unexpectedly.

Aha.  So nonzero_bits is unusable for most purposes as well.  Great :-/

> btw, the test case would reply on the combine patch[1].

Can you make a different testcase perhaps?  This patch looks fine
otherwise.

(Ideally the compiler would just form those insert insns itself, of
course.  Why doesn't that work?  This is important for quite a lot of
code, we really can advantageously use the rl*imi insns often!)


Segher

Re: [PATCH/RFC] combine: Tweak the condition of last_set invalidation

[Segher Boessenkool]

Hi!

On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote:
> When I was investigating unsigned int vec_init issue on Power,
> I happened to find there seems something we can enhance in how
> combine pass invalidate last_set (set last_set_invalid nonzero).
> 
> Currently we have the check:
> 
>   if (!insn
> || (value && rsp->last_set_table_tick >= label_tick_ebb_start))
>   rsp->last_set_invalid = 1; 
> 
> which means if we want to record some value for some reg and
> this reg got refered before in a valid scope, we invalidate the
> set of reg (last_set_invalid to 1).  It avoids to find the wrong
> set for one reg reference, such as the case like:
> 
>... op regX  // this regX could find wrong last_set below
>regX = ...   // if we think this set is valid
>... op regX
> 
> But because of retry's existence, the last_set_table_tick could

It is not just because of retry: combine can change other insns than
just i2 and i3, too.  And even changing i2 requires this!

The whole reg_stat stuff is an ugly hack that does not work well.  For
example, as in your example, some "known" value can be invalidated
before the combination that wants to know that value is tried.

We need to have this outside of combine, in a dataflow(-like) thing
for example.  This could take the place of REG_EQ* as well probably
(which is good, there are various problems with that as well).

> This proposal is to check whether the last_set_table safely happens
> after the current set, make the set still valid if so.

I don't think this is safe to do like this, unfortunately.  There are
more places that set last_set_invalid (well, one more), so at the very
minimum this needs a lot more justification.


Segher

V2 [PATCH 3/3] Build x86 libatomic with -march=i486 or better

[H.J. Lu via Gcc-patches]

On Thu, Jan 14, 2021 at 3:01 PM Jakub Jelinek  wrote:
>
> On Thu, Jan 14, 2021 at 01:04:31PM -0800, H.J. Lu via Gcc-patches wrote:
> > If x86 libatomic isn't compiled with -march=i486 or better, append
> > -march=i486 XCFLAGS for x86 libatomic build.  Set try_ifunc to yes
> > if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or
> > better isn't used to compile x86 libatomic.
> >
> >   PR target/70454
> >   * configure.tgt (XCFLAGS): Append -march=i486 to compile x86
> >   libatomic if needed.
> >   (try_ifunc): Set to yes only if needed.
> > ---
> >  libatomic/configure.tgt | 73 -
> >  1 file changed, 50 insertions(+), 23 deletions(-)
> >
> > diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
> > index 2f24817b454..1f3a3ad6c7c 100644
> > --- a/libatomic/configure.tgt
> > +++ b/libatomic/configure.tgt
> > @@ -81,32 +81,59 @@ case "${target_cpu}" in
> >   ARCH=sparc
> >   ;;
> >
> > -  i[3456]86)
> > - case " ${CC} ${CFLAGS} " in
> > -   *" -m64 "*|*" -mx32 "*)
> > - ;;
> > -   *)
> > - if test -z "$with_arch"; then
> > -   XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
> > -   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
> > - fi
> > - esac
> > - ARCH=x86
> > - # ??? Detect when -march=i686 is already enabled.
> > - try_ifunc=yes
> > - ;;
> > -  x86_64)
> > - case " ${CC} ${CFLAGS} " in
> > -   *" -m32 "*)
> > +  i[3456]86 | x86_64)
> > + # Need i486 or better.
> > + cat > conftestx.c < > +#if defined __x86_64__ || defined __i486__ || defined __pentium__ \
> > +  || defined __pentiumpro__ || defined __pentium4__ \
> > +  || defined __geode__ || defined __SSE__
> > +# error Need i486 or better
> > +#endif
>
> Rather than hoping we got all the defines right, wouldn't it be better to
> compile with -S a testcase like:
> int
> foo (int *p, int x, int y)
> {
>   return __sync_val_compare_and_swap (p, x, y);
> }
> and if there is __sync_val_compare_and_swap_4 in the assembly assume
> -march=i486 needs to be added?
> I.e. test for what exactly we need (working atomics).
>
> Jakub
>

Here is the updated patch.  OK for master?

Thanks.

-- 
H.J.
From f847185c4faa94b6dbb52327c13d5d5bfec9b259 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 2 May 2016 09:44:07 -0700
Subject: [PATCH] Build x86 libatomic with -march=i486 or better

If x86 libatomic isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libatomic build.  Set try_ifunc to yes
if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or
better isn't used to compile x86 libatomic.

	PR target/70454
	* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
	libatomic if needed.
	(try_ifunc): Set to yes only if needed.
---
 libatomic/configure.tgt | 74 -
 1 file changed, 51 insertions(+), 23 deletions(-)

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 2f24817b454..3530c992264 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -81,32 +81,60 @@ case "${target_cpu}" in
 	ARCH=sparc
 	;;
 
-  i[3456]86)
-	case " ${CC} ${CFLAGS} " in
-	  *" -m64 "*|*" -mx32 "*)
-	;;
-	  *)
-	if test -z "$with_arch"; then
-	  XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
-	  XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-	fi
-	esac
-	ARCH=x86
-	# ??? Detect when -march=i686 is already enabled.
-	try_ifunc=yes
-	;;
-  x86_64)
-	case " ${CC} ${CFLAGS} " in
-	  *" -m32 "*)
+  i[3456]86 | x86_64)
+	# Need i486 or better.
+	cat > conftestx.c < /dev/null 2>&1 \
+	   && grep -q __sync_val_compare_and_swap conftestx.s /dev/null; then
+	  if test "${target_cpu}" = x86_64; then
 	XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
 	XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-	;;
-	  *)
-	;;
-	esac
+	  else
+	XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
+	XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
+	  fi
+	fi
+	# Detect if -march=i686/-mcx16 is already enabled.
+	cat > conftestx.c < /dev/null 2>&1; then
+	  if grep cmpxchg16b conftestx.s >/dev/null; then
+	# This is the 64-bit library.
+	try_ifunc=no
+	  elif grep i686 conftestx.s >/dev/null; then
+	# This is the 32-bit library.
+	try_ifunc=no
+	  else
+	try_ifunc=yes
+	  fi
+	fi
+	rm -f conftestx.c conftestx.s
 	ARCH=x86
-	# ??? Detect when -mcx16 is already enabled.
-	try_ifunc=yes
 	;;
 
   *)			ARCH="${target_cpu}" ;;
-- 
2.29.2

Re: [committed] jit: remove "Alpha" warning from docs

[Andrea Corallo via Gcc-patches]

David Malcolm  writes:

> On Thu, 2021-01-14 at 23:23 +0100, Andrea Corallo wrote:
>> Hi Dave and all,
>> 
>> libgccjit is still advertized as alpha state in the documentation
>> despite having being introduced few years ago.
>> 
>> I think we may want to evaluate to promote it as beta with the
>> following
>> motivations:
>> 
>> - The API has been incerementally refined over the years since its
>>   introduction and it looks reasonably complete for fruition now.
>> 
>> - Example as the Emacs native compiler proves it can be used to
>> create
>>   production software.
>> 
>> My main concern (the main issue we are facing) is that the alpha
>> state
>> shows up as a limiting factor for certain distributions to package it
>> [1].  Needless to say this is also a potential limitaiton for other
>> software to adopt it.
>> 
>> WDYT?
>> 
>> Thanks and Regards
>> 
>>   Andrea
>> 
>> [1] 
>
> Thanks for pointing this out.  I've pushed the following patch to master
> for gcc 11, as b95d97f1a5f54f55c15bca65ec79b626b53cd40c:

Super! Thanks!

  Andrea

[committed] jit: remove "Alpha" warning from docs

[David Malcolm via Gcc-patches]

On Thu, 2021-01-14 at 23:23 +0100, Andrea Corallo wrote:
> Hi Dave and all,
> 
> libgccjit is still advertized as alpha state in the documentation
> despite having being introduced few years ago.
> 
> I think we may want to evaluate to promote it as beta with the
> following
> motivations:
> 
> - The API has been incerementally refined over the years since its
>   introduction and it looks reasonably complete for fruition now.
> 
> - Example as the Emacs native compiler proves it can be used to
> create
>   production software.
> 
> My main concern (the main issue we are facing) is that the alpha
> state
> shows up as a limiting factor for certain distributions to package it
> [1].  Needless to say this is also a potential limitaiton for other
> software to adopt it.
> 
> WDYT?
> 
> Thanks and Regards
> 
>   Andrea
> 
> [1] 

Thanks for pointing this out.  I've pushed the following patch to master
for gcc 11, as b95d97f1a5f54f55c15bca65ec79b626b53cd40c:

I removed the "Alpha" warning from the JIT wiki page on
2020-05-18:
  https://gcc.gnu.org/wiki/JIT?action=diff=47=48
but forgot to remove it from the documentation, which this
patch does.

gcc/jit/ChangeLog:
* docs/cp/index.rst: Remove "Alpha" warning.
* docs/index.rst: Likewise.
---
 gcc/jit/docs/cp/index.rst | 4 
 gcc/jit/docs/index.rst| 4 
 2 files changed, 8 deletions(-)

diff --git a/gcc/jit/docs/cp/index.rst b/gcc/jit/docs/cp/index.rst
index 254ad59819e..3bffc98a3de 100644
--- a/gcc/jit/docs/cp/index.rst
+++ b/gcc/jit/docs/cp/index.rst
@@ -28,10 +28,6 @@ This is a collection of "thin" wrapper classes around the C 
API.
 Everything is an inline function, implemented in terms of the C API,
 so there is nothing extra to link against.
 
-Note that libgccjit is currently of "Alpha" quality;
-the APIs are not yet set in stone, and they shouldn't be used in
-production yet.
-
 Contents:
 
 .. toctree::
diff --git a/gcc/jit/docs/index.rst b/gcc/jit/docs/index.rst
index 4db1ddd8307..fe3d741d345 100644
--- a/gcc/jit/docs/index.rst
+++ b/gcc/jit/docs/index.rst
@@ -21,10 +21,6 @@ libgccjit
 This document describes `libgccjit `_, an API
 for embedding GCC inside programs and libraries.
 
-Note that libgccjit is currently of "Alpha" quality;
-the APIs are not yet set in stone, and they shouldn't be used in
-production yet.
-
 There are actually two APIs for the library:
 
 * a pure C API: ``libgccjit.h``
-- 
2.26.2

Re: [PATCH 3/3] Build x86 libatomic with -march=i486 or better

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 01:04:31PM -0800, H.J. Lu via Gcc-patches wrote:
> If x86 libatomic isn't compiled with -march=i486 or better, append
> -march=i486 XCFLAGS for x86 libatomic build.  Set try_ifunc to yes
> if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or
> better isn't used to compile x86 libatomic.
> 
>   PR target/70454
>   * configure.tgt (XCFLAGS): Append -march=i486 to compile x86
>   libatomic if needed.
>   (try_ifunc): Set to yes only if needed.
> ---
>  libatomic/configure.tgt | 73 -
>  1 file changed, 50 insertions(+), 23 deletions(-)
> 
> diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
> index 2f24817b454..1f3a3ad6c7c 100644
> --- a/libatomic/configure.tgt
> +++ b/libatomic/configure.tgt
> @@ -81,32 +81,59 @@ case "${target_cpu}" in
>   ARCH=sparc
>   ;;
>  
> -  i[3456]86)
> - case " ${CC} ${CFLAGS} " in
> -   *" -m64 "*|*" -mx32 "*)
> - ;;
> -   *)
> - if test -z "$with_arch"; then
> -   XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
> -   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
> - fi
> - esac
> - ARCH=x86
> - # ??? Detect when -march=i686 is already enabled.
> - try_ifunc=yes
> - ;;
> -  x86_64)
> - case " ${CC} ${CFLAGS} " in
> -   *" -m32 "*)
> +  i[3456]86 | x86_64)
> + # Need i486 or better.
> + cat > conftestx.c < +#if defined __x86_64__ || defined __i486__ || defined __pentium__ \
> +  || defined __pentiumpro__ || defined __pentium4__ \
> +  || defined __geode__ || defined __SSE__
> +# error Need i486 or better
> +#endif

Rather than hoping we got all the defines right, wouldn't it be better to
compile with -S a testcase like:
int
foo (int *p, int x, int y)
{
  return __sync_val_compare_and_swap (p, x, y);
}
and if there is __sync_val_compare_and_swap_4 in the assembly assume
-march=i486 needs to be added?
I.e. test for what exactly we need (working atomics).

Jakub

Re: Add dg-require-wchars to libstdc++ testsuite

[Alexandre Oliva]

On Jan 14, 2021, Jonathan Wakely  wrote:

> The problem is that  uses wchar_t in default
> template arguments:

> I think we should fix the header, not disable tests that don't use
> that default template argument. The attached patch should allow you to
> use wstring_convert and wbuffer_convert without wchar_t support. The
> tests which instantiate it with char16_t or char32_t instead of
> wchar_t should work with this patch, right?

Thanks, I'll give it a spin.  That said, ...

> 
> Is it the case that the wchar_t type is defined on this target, it's
> just that libc doesn't have support for wcslen etc?

... it is definitely the case that the target currently defines wchar_t,
and it even offers wchar.h and a lot of (maybe all?) wcs* functions.
This was likely not the case when the patch was first written.

I'll double check whether any of the patch is still needed for current
versions.

I figured it would a waste to just discard Corentin's identification of
testcases that failed when glibc wchar_t support was not enabled.

This also means that the test results I'm going to get are likely to not
reflect the conditions for which these patches were originally written.


FWIW, I like very much the notion of offering a fallback wchar_t
implementation within libstdc++-v3, so that users get the expected C++
functionality even when libc doesn't offer it.  Even a (conditional?)
typedef to introduce wchar_t could be there.

Perhaps the test that sets or clears _GLIBCXX_USE_WCHAR_T should be used
to decide whether or not to offer a wchar.h header in libstdc++, and
then (pipe dream?) all other uses of this macro would be just gone?


> As François said, this could use the new proc. I'd also prefer if it
> was defined as an effective-target keyword so we can use:

> // { dg-require-effective-target wchars }

*nod*


> But we might not even need this new proc if the codecvt tests can be
> made to work using the attached patch.

Thanks,

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: [PATCH] Handle fancy_abort before diagnostic initialization [PR98586]

[David Malcolm via Gcc-patches]

On Tue, 2021-01-12 at 08:44 +0100, Richard Biener wrote:
> On Mon, Jan 11, 2021 at 10:57 PM David Malcolm via Gcc-patches
>  wrote:
> > If fancy_abort is called before the diagnostic subsystem is
> > initialized,
> > internal_error will crash internally in a way that prevents a
> > useful
> > message reaching the user.
> > 
> > This can happen with libgccjit in the case of gcc_assert failures
> > that occur outside of the libgccjit mutex that guards the rest of
> > gcc's state, including global_dc (when global_dc may not be
> > initialized yet, or might be in use by another thread).
> > 
> > I tried a few approaches to fixing this as noted in PR jit/98586
> > e.g. using a temporary diagnostic_context and initializing it for
> > the call to internal_error, however the more code that runs, the
> > more chance there is for other errors to occur.
> > 
> > The best fix appears to be to simply fall back to a minimal abort
> > implementation that only relies on i18n, as implemented by this
> > patch.
> > 
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > 
> > Is there a better way to fix this?  If not I plan to push this
> > to master in a few days.
> 
> The only other idea I can come up with is to somehow statically
> initialize global_dc to a minimal implementation to catch those.

We sort of do that already, given that it points at a global
diagnostic_context.  I think trying to integrate this handling with the
diagnostic subsystem any further will run into issues for the case of
libgccjit linked into a multithreaded program, given that global_dc is
global state.  Thinking about those kinds of cases makes me feel that
this crash-handling for the crash handler ought to be as simple as
possible.

> Otherwise your approach is entirely reasonable.

Thanks.  I've gone ahead and pushed this to master as r11-6700-
g387f6c15d303a8f8da508e419fea10a6ef0e2590.

Dave

Re: [PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints

[Lewis Hyatt via Gcc-patches]

On Thu, Jan 14, 2021 at 4:34 PM David Malcolm via Gcc-patches
 wrote:
...
> > One remaining issue raised in that Emacs bug is the encoding of these
> > lines, and, indeed, the encoding of GCC's stderr in general:
> > currently we emit a mixture of bytes and UTF-8; I believe we emit
> > filenames as bytes, diagnostic messages as UTF-8, and quote source
> > code
> > in the original encoding (PR other/93067 covers converting it to UTF-
> > 8 on
> > output).  Currently this patch prints octal-escaped bytes for bytes
> > within filenames and replacement text that aren't printable (which
> > is what -fdiagnostics-parseable-fixits also does).  Doing so at least
> > allows the common case of ASCII-encoded sources and filenames to
> > work,
> > whilst allowing for future formats that address the encoding issues.
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > Thoughts?
> > Dave
>
> In the absence of feedback, I've rebased the patch, retested it as
> above, and pushed it to master
> (as f10960558540636800cf5d3d6355969621fbc17e)
>
> Dave
>

I just wanted to note that a patch to fix PR other/93067 is waiting
for review here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562316.html
in case it may be desirable to get this in the same release as the new
GCC_EXTRA_DIAGNOSTIC_OUTPUT feature. Thanks!


-Lewis

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of __builtin_pack_longdouble.

[Michael Meissner via Gcc-patches]

[PATCH 2/2] PowerPC: Use __builtin_pack_ibm128 instead of 
__builtin_pack_longdouble.

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

This patch fixes the libgcc library to use __builtin_pack_ibm128 all of
the time.


I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  I have verified that ibm-ldouble does use the ibm128 pack
built-in function.  Can i check this patch into the master branch once the
previous patch has been commited?

libgcc/
2021-01-13  Michael Meissner  

* config/rs6000/ibm-ldouble.c (pack_ldouble): Use
__builtin_pack_ibm128 instead of __builtin_pack_longdouble.
---
 libgcc/config/rs6000/ibm-ldouble.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/rs6000/ibm-ldouble.c 
b/libgcc/config/rs6000/ibm-ldouble.c
index 4c13453f975..92b4b4c583d 100644
--- a/libgcc/config/rs6000/ibm-ldouble.c
+++ b/libgcc/config/rs6000/ibm-ldouble.c
@@ -102,9 +102,9 @@ __asm__ (".symver __gcc_qadd,_xlqadd@GCC_3.4\n\t"
 static inline IBM128_TYPE
 pack_ldouble (double dh, double dl)
 {
-#if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)  \
+#if defined (__LONG_DOUBLE_128__)  \
 && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
-  return __builtin_pack_longdouble (dh, dl);
+  return __builtin_pack_ibm128 (dh, dl);
 #else
   union
   {
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] PowerPC: Allow __ibm128 on older systems.

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

This patch fixes the compiler to allow __ibm128 on older systems, and it
adjusts the two ibm128 built-in functions to accomidate this change.  The next
patch will be to change libgcc/ibm-ldouble.c to always use the
__builtin_pack_ibm128 function.


I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  Can I check this patch into the master branch?

gcc/
2021-01-13  Michael Meissner  

* config/rs6000/rs6000-builtin.def (BU_IBM128_2): Rename
RS6000_BTM_IBM128 from RS6000_BTM_FLOAT128.
* config/rs6000/rs6000-call.c (rs6000_invalid_builtin): Update
error message for __ibm128 built-in functions.
(rs6000_init_builtins): Create the __ibm128 keyword on older
systems where long double uses the IBM extended double format,
even if they don't support IEEE 128-bit floating point.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Rename
RS6000_BTM_IBM128 from RS6000_BTM_FLOAT128.
(rs6000_builtin_mask_names): Rename RS6000_BTM_IBM128 from
RS6000_BTM_FLOAT128.
* config/rs6000/rs6000.h (TARGET_IBM128): New macro.
(RS6000_BTM_IBM128): Rename from RS6000_BTM_FLOAT128.
(RS6000_BTM_COMMON): Rename RS6000_BTM_IBM128 from
RS6000_BTM_FLOAT128.
---
 gcc/config/rs6000/rs6000-builtin.def |  5 ++---
 gcc/config/rs6000/rs6000-call.c  | 14 ++
 gcc/config/rs6000/rs6000.c   |  4 ++--
 gcc/config/rs6000/rs6000.h   | 12 +---
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 8aa31ad0a06..1bf76eedadf 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -728,13 +728,12 @@
 | RS6000_BTC_BINARY),  \
CODE_FOR_ ## ICODE) /* ICODE */
 
-/* 128-bit __ibm128 floating point builtins (use -mfloat128 to indicate that
-   __ibm128 is available).  */
+/* 128-bit __ibm128 floating point builtins.  */
 #define BU_IBM128_2(ENUM, NAME, ATTR, ICODE)   \
   RS6000_BUILTIN_2 (MISC_BUILTIN_ ## ENUM, /* ENUM */  \
"__builtin_" NAME,  /* NAME */  \
(RS6000_BTM_HARD_FLOAT  /* MASK */  \
-| RS6000_BTM_FLOAT128),\
+| RS6000_BTM_IBM128),  \
(RS6000_BTC_ ## ATTR/* ATTR */  \
 | RS6000_BTC_BINARY),  \
CODE_FOR_ ## ICODE) /* ICODE */
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 519313bc0d6..5e58bea7e7a 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -11485,8 +11485,8 @@ rs6000_invalid_builtin (enum rs6000_builtins fncode)
 error ("%qs requires the %qs option", name, "-mhard-float");
   else if ((fnmask & RS6000_BTM_FLOAT128_HW) != 0)
 error ("%qs requires ISA 3.0 IEEE 128-bit floating point", name);
-  else if ((fnmask & RS6000_BTM_FLOAT128) != 0)
-error ("%qs requires the %qs option", name, "%<-mfloat128%>");
+  else if ((fnmask & RS6000_BTM_IBM128) != 0)
+error ("%qs requires the IBM 128-bit floating point", name);
   else if ((fnmask & (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
   == (RS6000_BTM_POPCNTD | RS6000_BTM_POWERPC64))
 error ("%qs requires the %qs (or newer), and %qs or %qs options",
@@ -13181,7 +13181,7 @@ rs6000_init_builtins (void)
  For IEEE 128-bit floating point, always create the type __ieee128.  If the
  user used -mfloat128, rs6000-c.c will create a define from __float128 to
  __ieee128.  */
-  if (TARGET_FLOAT128_TYPE)
+  if (TARGET_IBM128)
 {
   if (!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128)
ibm128_float_type_node = long_double_type_node;
@@ -13195,7 +13195,13 @@ rs6000_init_builtins (void)
 
   lang_hooks.types.register_builtin_type (ibm128_float_type_node,
  "__ibm128");
+}
+
+ 

[PATCH 0/2] PowerPC: Add __ibm128 to PowerPC targets without float128 support

[Michael Meissner via Gcc-patches]

In the patch submitted on October 22nd, 2020:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556869.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557529.html

Segher suggested that rather than add #ifdef code in libgcc's ibm-ldouble.c to
use __builtin_pack_ibm128 instead of __builtin_pack_longdouble, that I should
instead make __ibm128 available in targets that have 128-bit IBM long double,
but don't support __float128/_Float128.

These two patches add this support.  The first patch adds __ibm128 to those
systems that don't support __float128/_Float128 and have 128-bit IBM long
double.  The second patch changes the libgcc ibm-ldouble.c function to use
__builtin_pack_ibm128 insted of __builtin_pack_longdouble.

I have tested these patches on a little endian power9 server system and there
were no regressions.  I have also tested the paches on a big endian power8
server system and there were no regressions.  On the big endian system, I have
built both compilers with power8 being the default cpu and power5 being the
default cpu.  I have verified that ibm-ldouble does use the ibm128 pack
built-in function.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints

[David Malcolm via Gcc-patches]

On Sat, 2020-11-14 at 14:43 -0500, David Malcolm wrote:
> GCC has had the ability to emit fix-it hints in machine-readable form
> since GCC 7 via -fdiagnostics-parseable-fixits and
> -fdiagnostics-generate-patch.
> 
> The former emits additional specially-formatted lines to stderr; the
> option and its format were directly taken from a pre-existing option
> in clang.
> 
> Ideally this could be used by IDEs so that the user can select
> specific
> fix-it hints and have the IDE apply them to the user's source code
> (perhaps turning them into clickable elements, perhaps with an
> "Apply All" option, etc).  Eclipse CDT has supported this option in
> this way for a few years:
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=497670
> 
> As a user of Emacs I would like Emacs to support such a feature.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25987 tracks supporting
> GCC fix-it output in Emacs.  The discussion there identifies some
> issues with the existing option:
> 
> (a) columns in the output are specified as byte-offsets within the
> line (for exact compatibility with the option in clang), whereas
> emacs
> would prefer to consume them as what GCC 11 calls "display columns".
> https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-column-unit
> 
> (b) injecting a command-line option into the build is a fiddly manual
> step, varying between build systems.  It's far easier for the
> user if Emacs simply sets an environment variable when compiling,
> GCC uses this to enable the option if it recognizes the value, and
> the emacs compilation buffer decodes the additional lines of output
> and adds appropriate widgets.  In some ways it is a workaround for
> not having a language server.  Doing it this way means that for the
> various combinations of older and newer GCC and older and newer Emacs
> that a sufficiently modern combination of both can automatically
> support the rich fix-it UI, whereas other combinations will either
> not provide the envvar, or silently ignore it, gracefully doing
> nothing extra.
> 
> Hence this patch adds a new GCC_EXTRA_DIAGNOSTIC_OUTPUT environment
> variable to GCC which enables output of machine-parseable fix-it
> hints.
> 
> GCC_EXTRA_DIAGNOSTIC_OUTPUT=fixits-v1 is equivalent to the existing
> -fdiagnostics-parseable-fixits option.
> 
> GCC_EXTRA_DIAGNOSTIC_OUTPUT=fixits-v2 is the same, but changes the
> column output mode to "display columns" rather than bytes, as
> required by Emacs.
> 
> One remaining issue raised in that Emacs bug is the encoding of these
> lines, and, indeed, the encoding of GCC's stderr in general:
> currently we emit a mixture of bytes and UTF-8; I believe we emit
> filenames as bytes, diagnostic messages as UTF-8, and quote source
> code
> in the original encoding (PR other/93067 covers converting it to UTF-
> 8 on
> output).  Currently this patch prints octal-escaped bytes for bytes
> within filenames and replacement text that aren't printable (which
> is what -fdiagnostics-parseable-fixits also does).  Doing so at least
> allows the common case of ASCII-encoded sources and filenames to
> work,
> whilst allowing for future formats that address the encoding issues.
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> Thoughts?
> Dave

In the absence of feedback, I've rebased the patch, retested it as
above, and pushed it to master
(as f10960558540636800cf5d3d6355969621fbc17e)

Dave

[PATCH, rs6000] Update pr88233.c test (pr91799)

[will schmidt via Gcc-patches]

[PATCH, rs6000] Update pr88233.c test (pr91799)

Hi,

This is a follow-up fix to clean up pr91799.  Per review of test results,
it appears that the combination of target and dg-require stanzas is
not sufficient to properly limit the test to 64-bit only on darwin.

This adds additional clauses to limit the test to 64-bit environments, and
to configs that support at least power8 codegen.

Tested on power7 and power8 using assorted variations of
  make -k check-gcc-c "RUNTESTFLAGS=powerpc.exp=pr88233.c
  --target_board=unix/'{-mcpu=power7,-mcpu=power6,-mcpu=power8}''{-m32,-m64}'"

OK for trunk?

PR target/91799

2021-01-14  Will Schmidt 

gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr88233.c: Update dg-require stanzas.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr88233.c 
b/gcc/testsuite/gcc.target/powerpc/pr88233.c
index 8e5f15b83b50..acea7a586867 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr88233.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr88233.c
@@ -1,6 +1,7 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-require-effective-target has_arch_pwr8 } */
 /* { dg-options "-O2 -mdejagnu-cpu=power8" } */
 
 typedef struct { double a[2]; } A;
 A
 foo (const A *a)

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

[Qing Zhao via Gcc-patches]

Hi, 

More data on code size and compilation time with CPU2017:

Compilation time data:   the numbers are the slowdown against the 
default “no”:

benchmarks   A/no   D/no

500.perlbench_r 5.19%   1.95%
502.gcc_r   0.46%   -0.23%
505.mcf_r   0.00%   0.00%
520.omnetpp_r   0.85%   0.00%
523.xalancbmk_r 0.79%   -0.40%
525.x264_r  -4.48%  0.00%
531.deepsjeng_r 16.67%  16.67%
541.leela_r  0.00%   0.00%
557.xz_r0.00%0.00%

507.cactuBSSN_r 1.16%   0.58%
508.namd_r  9.62%   8.65%
510.parest_r0.48%   1.19%
511.povray_r3.70%   3.70%
519.lbm_r   0.00%   0.00%
521.wrf_r   0.05%   0.02%
526.blender_r   0.33%   1.32%
527.cam4_r  -0.93%  -0.93%
538.imagick_r   1.32%   3.95%
544.nab_r   0.00%   0.00%

From the above data, looks like that the compilation time impact from 
implementation A and D are almost the same.

***code size data: the numbers are the code size increase against the 
default “no”:
benchmarks  A/noD/no

500.perlbench_r 2.84%   0.34%
502.gcc_r   2.59%   0.35%
505.mcf_r   3.55%   0.39%
520.omnetpp_r   0.54%   0.03%
523.xalancbmk_r 0.36%0.39%
525.x264_r  1.39%   0.13%
531.deepsjeng_r 2.15%   -1.12%
541.leela_r 0.50%   -0.20%
557.xz_r0.31%   0.13%

507.cactuBSSN_r 5.00%   -0.01%
508.namd_r  3.64%   -0.07%
510.parest_r1.12%   0.33%
511.povray_r4.18%   1.16%
519.lbm_r   8.83%   6.44%
521.wrf_r   0.08%   0.02%
526.blender_r   1.63%   0.45%
527.cam4_r   0.16%  0.06%
538.imagick_r   3.18%   -0.80%
544.nab_r   5.76%   -1.11%
Avg 2.52%   0.36%

From the above data, the implementation D is always better than A, it’s a 
surprising to me, not sure what’s the reason for this.

stack usage data, I added -fstack-usage to the compilation line when 
compiling CPU2017 benchmarks. And all the *.su files were generated for each of 
the modules.
Since there a lot of such files, and the stack size information are embedded in 
each of the files.  I just picked up one benchmark 511.povray to check. Which 
is the one that 
has the most runtime overhead when adding initialization (both A and D). 

I identified all the *.su files that are different between A and D and do a 
diff on those *.su files, and looks like that the stack size is much higher 
with D than that with A, for example:

$ diff build_base_auto_init.D./bbox.su build_base_auto_init.A./bbox.su
5c5
< bbox.cpp:1782:12:int pov::sort_and_split(pov::BBOX_TREE**, pov::BBOX_TREE**&, 
long int*, long int, long int)  160 static
---
> bbox.cpp:1782:12:int pov::sort_and_split(pov::BBOX_TREE**, pov::BBOX_TREE**&, 
> long int*, long int, long int)  96  static

$ diff build_base_auto_init.D./image.su build_base_auto_init.A./image.su
9c9
< image.cpp:240:6:void pov::bump_map(double*, pov::TNORMAL*, double*)   624 
static
---
> image.cpp:240:6:void pov::bump_map(double*, pov::TNORMAL*, double*)   272 
> static
….

Looks like that implementation D has more stack size impact than A. 

Do you have any insight on what the reason for this?

Let me know if you have any comments and suggestions.

thanks.

Qing
> On Jan 13, 2021, at 1:39 AM, Richard Biener  wrote:
> 
> On Tue, 12 Jan 2021, Qing Zhao wrote:
> 
>> Hi, 
>> 
>> Just check in to see whether you have any comments and suggestions on this:
>> 
>> FYI, I have been continue with Approach D implementation since last week:
>> 
>> D. Adding  calls to .DEFFERED_INIT during gimplification, expand the 
>> .DEFFERED_INIT during expand to
>> real initialization. Adjusting uninitialized pass with the new refs with 
>> “.DEFFERED_INIT”.
>> 
>> For the remaining work of Approach D:
>> 
>> ** complete the implementation of -ftrivial-auto-var-init=pattern;
>> ** complete the implementation of uninitialized warnings maintenance work 
>> for D. 
>> 
>> I have completed the uninitialized warnings maintenance work for D.
>> And finished partial of the -ftrivial-auto-var-init=pattern implementation. 
>> 
>> The following are remaining work of Approach D:
>> 
>>   ** -ftrivial-auto-var-init=pattern for VLA;
>>   **add a new attribute for variable:
>> __attribute((uninitialized)
>> the marked variable is uninitialized intentionaly for performance purpose.
>>   ** adding complete testing cases;
>> 
>> 
>> Please let me know if you have any objection on my current decision on 
>> implementing approach D. 
> 
> Did you do any analysis on how stack usage and code size are changed 
> with approach D?  How does compile-time behave (we could gobble up
> lots of .DEFERRED_INIT calls I guess)?
> 

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

[Alexandre Oliva]

Hello, Olivier,

On Dec 18, 2020, Olivier Hainque  wrote:

> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
> (copied below for convenience), please ?

I think defining alloca as a macro in analyzer-alloca.h might conflict
with system headers included before or after analyzer-alloca.h

Say, if a system header #defines alloca(n), GCC might warn when
encountering a different #define in analyzer-alloca.h, included later.

OTOH, if analyzer-alloca.h is included first, then a later system header
that attempts to declare alloca as a function could be macro-substituted
into declaring __builtin_alloca, which probably wouldn't end well.

While the alloca macro would render other changes from alloca to
__builtin_alloca unnecessary, there's such an explicit change in the
patch.

If it were up to me, I'd rather use __builtin_alloca explicitly all
over.  I think we already do that in several other tests, for similar
reasons (that some target systems don't have alloca.h or alloca)

Would you mind if I submitted an alternate patch to do so?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[PATCH]middle-end (committed) slp: Add Tests for complex mul, mls and mla"

[Tamar Christina via Gcc-patches]

Hi All,

This adds the initial tests for the complex mul, mls and mla.
These will be enabled in the commits that add the optabs.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Committed as obvious variations of existing tests.

Thanks,
Tamar

gcc/testsuite/ChangeLog:

* gcc.dg/vect/complex/complex-mla-template.c: New test.
* gcc.dg/vect/complex/complex-mls-template.c: New test.
* gcc.dg/vect/complex/complex-mul-template.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-double.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-half-float.c: New 
test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-double.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-float.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-half-float.c: New 
test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-double.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: New test.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-half-float.c: New 
test.
* gcc.dg/vect/complex/fast-math-complex-mla-double.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mla-float.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mls-double.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mls-float.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mul-double.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mul-float.c: New test.
* gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: New test.

--- inline copy of patch -- 
diff --git a/gcc/testsuite/gcc.dg/vect/complex/complex-mla-template.c 
b/gcc/testsuite/gcc.dg/vect/complex/complex-mla-template.c
new file mode 100644
index 
..8995e0a9f6bbfa535fa3630dc65bc3baad1016e5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/complex/complex-mla-template.c
@@ -0,0 +1,101 @@
+#include 
+
+void fma0 (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+  _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * b[i];
+}
+
+void fma90snd (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+  _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * (b[i] * I);
+}
+
+void fma180snd (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+   _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * (b[i] * I * I);
+}
+
+void fma270snd (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+   _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * (b[i] * I * I * I);
+}
+
+void fma90fst (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+  _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += (a[i] * I) * b[i];
+}
+
+void fma180fst (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+   _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += (a[i] * I * I) * b[i];
+}
+
+void fma270fst (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+   _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += (a[i] * I * I * I) * b[i];
+}
+
+void fmaconjfst (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+_Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += ~a[i] * b[i];
+}
+
+void fmaconjsnd (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+_Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * ~b[i];
+}
+
+void fmaconjboth (_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
+ _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += ~a[i] * ~b[i];
+}
+
+void fma_elem (_Complex TYPE a[restrict N], _Complex TYPE b,
+  _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * b;
+}
+
+
+void fma_elemconjfst (_Complex TYPE a[restrict N], _Complex TYPE b,
+ _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += ~a[i] * b;
+}
+
+void fma_elemconjsnd (_Complex TYPE a[restrict N], _Complex TYPE b,
+ _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += a[i] * ~b;
+}
+
+void fma_elemconjboth (_Complex TYPE a[restrict N], _Complex TYPE b,
+  _Complex TYPE c[restrict N])
+{
+  for (int i+=0; i < N; i++)
+c[i] += ~a[i] * ~b;
+}
+
diff --git a/gcc/testsuite/gcc.dg/vect/complex/complex-mls-template.c 
b/gcc/testsuite/gcc.dg/vect/complex/complex-mls-template.c
new file mode 

[PATCH 3/3] Build x86 libatomic with -march=i486 or better

[H.J. Lu via Gcc-patches]

If x86 libatomic isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libatomic build.  Set try_ifunc to yes
if -mcx16 isn't used to compile x86-64 libatomic or -march=i686 or
better isn't used to compile x86 libatomic.

PR target/70454
* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
libatomic if needed.
(try_ifunc): Set to yes only if needed.
---
 libatomic/configure.tgt | 73 -
 1 file changed, 50 insertions(+), 23 deletions(-)

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 2f24817b454..1f3a3ad6c7c 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -81,32 +81,59 @@ case "${target_cpu}" in
ARCH=sparc
;;
 
-  i[3456]86)
-   case " ${CC} ${CFLAGS} " in
- *" -m64 "*|*" -mx32 "*)
-   ;;
- *)
-   if test -z "$with_arch"; then
- XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
- XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-   fi
-   esac
-   ARCH=x86
-   # ??? Detect when -march=i686 is already enabled.
-   try_ifunc=yes
-   ;;
-  x86_64)
-   case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+  i[3456]86 | x86_64)
+   # Need i486 or better.
+   cat > conftestx.c < /dev/null 2>&1; then
+ if test "${target_cpu}" = x86_64; then
XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-   ;;
- *)
-   ;;
-   esac
+ else
+   XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
+   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
+ fi
+   fi
+   # Detect if -march=i686/-mcx16 is already enabled.
+   cat > conftestx.c < /dev/null 2>&1; then
+ if ${GREP} cmpxchg16b conftestx.s >/dev/null; then
+   # This is the 64-bit library.
+   try_ifunc=no
+ elif ${GREP} i686 conftestx.s >/dev/null; then
+   # This is the 32-bit library.
+   try_ifunc=no
+ else
+   try_ifunc=yes
+ fi
+   fi
+   rm -f conftestx.c conftestx.o conftestx.s
ARCH=x86
-   # ??? Detect when -mcx16 is already enabled.
-   try_ifunc=yes
;;
 
   *)   ARCH="${target_cpu}" ;;
-- 
2.29.2

[PATCH 0/3] Build x86 libitm/libgomp/libatomic with -march=i486 or better

[H.J. Lu via Gcc-patches]

Starting from

commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu 
Date:   Thu Jan 14 05:56:46 2021 -0800

x86: Error on -fcf-protection with incompatible target

GCC issues an error on -fcf-protection with incompatible target.  CET
is enabled in run-time libraries on x86 when GCC is configured with

--with-arch=XXX

where XXX enables SSE2.  But libitm/libgomp/libatomic are hardcoded to
compile with -march=i486 which is incompatible with CET.  We should
compile libitm/libgomp/libatomic -march=i486 only if the default -march=
is lower than i486.

H.J. Lu (3):
  Build x86 libitm with -march=i486 or better
  Build x86 libgomp with -march=i486 or better
  Build x86 libatomic with -march=i486 or better

 libatomic/configure.tgt | 73 -
 libgomp/configure.tgt   | 36 +---
 libitm/configure.tgt| 39 +++---
 3 files changed, 85 insertions(+), 63 deletions(-)

-- 
2.29.2

[PATCH 2/3] Build x86 libgomp with -march=i486 or better

[H.J. Lu via Gcc-patches]

If x86 libgomp isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libgomp build.

PR target/70454
* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
libgomp if needed.
---
 libgomp/configure.tgt | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index 1863287fa0d..83b5f92727d 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
@@ -73,28 +73,24 @@ if test x$enable_linux_futex = xyes; then
;;
 
 # Note that bare i386 is not included here.  We need cmpxchg.
-i[456]86-*-linux*)
+i[456]86-*-linux* | x86_64-*-linux*)
config_path="linux/x86 linux posix"
-   case " ${CC} ${CFLAGS} " in
- *" -m64 "*|*" -mx32 "*)
-   ;;
- *)
-   if test -z "$with_arch"; then
- XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
+   # Need i486 or better.
+   cat > conftestx.c < /dev/null 2>&1; then
+   if test "${target_cpu}" = x86_64; then
+   XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
+   else
+   XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
fi
-   esac
-   ;;
-
-# Similar jiggery-pokery for x86_64 multilibs, except here we
-# can't rely on the --with-arch configure option, since that
-# applies to the 64-bit side.
-x86_64-*-linux*)
-   config_path="linux/x86 linux posix"
-   case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
-   XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
-   ;;
-   esac
+   fi
+   rm -f conftestx.c conftestx.o
;;
 
 # Note that sparcv7 and sparcv8 is not included here.  We need cas.
-- 
2.29.2

[PATCH 1/3] Build x86 libitm with -march=i486 or better

[H.J. Lu via Gcc-patches]

If x86 libitm isn't compiled with -march=i486 or better, append
-march=i486 XCFLAGS for x86 libitm build.

PR target/70454
* configure.tgt (XCFLAGS): Append -march=i486 to compile x86
libitm if needed.
---
 libitm/configure.tgt | 39 +++
 1 file changed, 19 insertions(+), 20 deletions(-)

diff --git a/libitm/configure.tgt b/libitm/configure.tgt
index 6ac206f1005..316896c1b31 100644
--- a/libitm/configure.tgt
+++ b/libitm/configure.tgt
@@ -59,16 +59,25 @@ case "${target_cpu}" in
 
   arm*)ARCH=arm ;;
 
-  i[3456]86)
-   case " ${CC} ${CFLAGS} " in
- *" -m64 "*|*" -mx32 "*)
-   ;;
- *)
-   if test -z "$with_arch"; then
- XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
- XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-   fi
-   esac
+  i[3456]86 | x86_64)
+   # Need i486 or better.
+   cat > conftestx.c < /dev/null 2>&1; then
+ if test "${target_cpu}" = x86_64; then
+   XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
+   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
+ else
+   XCFLAGS="${XCFLAGS} -march=i486 -mtune=${target_cpu}"
+   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
+ fi
+   fi
+   rm -f conftestx.c conftestx.o
XCFLAGS="${XCFLAGS} -mrtm"
ARCH=x86
;;
@@ -103,16 +112,6 @@ case "${target_cpu}" in
ARCH=sparc
;;
 
-  x86_64)
-   case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
-   XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
-   XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
-   ;;
-   esac
-   XCFLAGS="${XCFLAGS} -mrtm"
-   ARCH=x86
-   ;;
   s390|s390x)
XCFLAGS="${XCFLAGS} -mzarch -mhtm"
ARCH=s390
-- 
2.29.2

RE: [EXTERNAL] Re: [PATCH][tree-optimization]Optimize combination of comparisons to dec+compare

[Eugene Rozenfeld via Gcc-patches]

I got more feedback for the patch from Gabriel Ravier and Jakub Jelinek in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674 and re-worked it accordingly.

The changes from the previous patch are:
1. Switched the tests to use __attribute__((noipa)) instead of 
__attribute__((noinline)) .
2. Fixed a type in the pattern comment.
3. Added :c for top-level bit_ior expression.
4. Added :s for the subexpressions.
5. Added a pattern for the negated expression:
x >= y && y != XXX_MIN --> x > y - 1
and the corresponding tests.

The new patch is attached.

Eugene

-Original Message-
From: Richard Biener  
Sent: Tuesday, January 5, 2021 4:21 AM
To: Eugene Rozenfeld 
Cc: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH][tree-optimization]Optimize combination of 
comparisons to dec+compare

On Mon, Jan 4, 2021 at 9:50 PM Eugene Rozenfeld 
 wrote:
>
> Ping.
>
> -Original Message-
> From: Eugene Rozenfeld
> Sent: Tuesday, December 22, 2020 3:01 PM
> To: Richard Biener ; 
> gcc-patches@gcc.gnu.org
> Subject: RE: Optimize combination of comparisons to dec+compare
>
> Re-sending my question and re-attaching the patch.
>
> Richard, can you please clarify your feedback?

Hmm, OK.

The patch is OK.

Thanks,
Richard.


> Thanks,
>
> Eugene
>
> -Original Message-
> From: Gcc-patches  On Behalf Of 
> Eugene Rozenfeld via Gcc-patches
> Sent: Tuesday, December 15, 2020 2:06 PM
> To: Richard Biener 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [EXTERNAL] Re: Optimize combination of comparisons to 
> dec+compare
>
> Richard,
>
> > Do we already handle x < y || x <= CST to x <= y - CST?
>
> That is an invalid transformation: e.g., consider x=3, y=4, CST=2.
> Can you please clarify?
>
> Thanks,
>
> Eugene
>
> -Original Message-
> From: Richard Biener 
> Sent: Thursday, December 10, 2020 12:21 AM
> To: Eugene Rozenfeld 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Optimize combination of comparisons to dec+compare
>
> On Thu, Dec 10, 2020 at 1:52 AM Eugene Rozenfeld via Gcc-patches 
>  wrote:
> >
> > This patch adds a pattern for optimizing x < y || x == XXX_MIN to x 
> > <=
> > y-1 if y is an integer with TYPE_OVERFLOW_WRAPS.
>
> Do we already handle x < y || x <= CST to x <= y - CST?
> That is, the XXX_MIN case is just a special-case of generic anti-range 
> testing?  For anti-range testing with signed types we pun to unsigned when 
> possible.
>
> > This fixes pr96674.
> >
> > Tested on x86_64-pc-linux-gnu.
> >
> > For this function
> >
> > bool f(unsigned a, unsigned b)
> > {
> > return (b == 0) | (a < b);
> > }
> >
> > the code without the patch is
> >
> > test   esi,esi
> > sete   al
> > cmpesi,edi
> > seta   dl
> > or eax,edx
> > ret
> >
> > the code with the patch is
> >
> > subesi,0x1
> > cmpesi,edi
> > setae  al
> > ret
> >
> > Eugene
> >
> > gcc/
> > PR tree-optimization/96674
> > * match.pd: New pattern x < y || x == XXX_MIN --> x <= y - 1
> >
> > gcc/testsuite
> > * gcc.dg/pr96674.c: New test.
> >


0002-Optimize-combination-of-comparisons-to-dec-compare.patch
Description: 0002-Optimize-combination-of-comparisons-to-dec-compare.patch

[committed] analyzer: fixes to -fdump-analyzer-json

[David Malcolm via Gcc-patches]

I've been implementing a PyGTK viewer for the output of
-fdump-analyzer-json, to help me debug analyzer issues:
  https://github.com/davidmalcolm/gcc-analyzer-viewer
The viewer is very much just a work in progress.

This patch adds some fields that were missing from the dump, and
fixes some mistakes I spotted whilst working on the viewer.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as dea4a32b24fb888532c47f3920f6910b3c94a8a0.

gcc/analyzer/ChangeLog:
* engine.cc (strongly_connected_components::to_json): New.
(worklist::to_json): New.
(exploded_graph::to_json): JSON-ify the worklist.
* exploded-graph.h (strongly_connected_components::to_json): New
decl.
(worklist::to_json): New decl.
* store.cc (store::to_json): Fix comment.
* supergraph.cc (supernode::to_json): Fix reference to
"returning_call" in comment.  Add optional "fun" to JSON.
(edge_kind_to_string): New.
(superedge::to_json): Add "kind" to JSON.
---
 gcc/analyzer/engine.cc| 29 -
 gcc/analyzer/exploded-graph.h |  4 
 gcc/analyzer/store.cc |  2 +-
 gcc/analyzer/supergraph.cc| 29 +++--
 4 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 8bc9adf5ee6..fc81e7523fb 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1772,6 +1772,17 @@ strongly_connected_components::dump () const
 }
 }
 
+/* Return a new json::array of per-snode SCC ids.  */
+
+json::array *
+strongly_connected_components::to_json () const
+{
+  json::array *scc_arr = new json::array ();
+  for (int i = 0; i < m_sg.num_nodes (); i++)
+scc_arr->append (new json::integer_number (get_scc_id (i)));
+  return scc_arr;
+}
+
 /* Subroutine of strongly_connected_components's ctor, part of Tarjan's
SCC algorithm.  */
 
@@ -1968,6 +1979,22 @@ worklist::key_t::cmp (const worklist::key_t , const 
worklist::key_t )
   return ka.m_enode->m_index - kb.m_enode->m_index;
 }
 
+/* Return a new json::object of the form
+   {"scc" : [per-snode-IDs]},  */
+
+json::object *
+worklist::to_json () const
+{
+  json::object *worklist_obj = new json::object ();
+
+  worklist_obj->set ("scc", m_scc.to_json ());
+
+  /* The following field isn't yet being JSONified:
+ queue_t m_queue;  */
+
+  return worklist_obj;
+}
+
 /* exploded_graph's ctor.  */
 
 exploded_graph::exploded_graph (const supergraph , logger *logger,
@@ -3315,10 +3342,10 @@ exploded_graph::to_json () const
   /* m_sg is JSONified at the top-level.  */
 
   egraph_obj->set ("ext_state", m_ext_state.to_json ());
+  egraph_obj->set ("worklist", m_worklist.to_json ());
   egraph_obj->set ("diagnostic_manager", m_diagnostic_manager.to_json ());
 
   /* The following fields aren't yet being JSONified:
- worklist m_worklist;
  const state_purge_map *const m_purge_map;
  const analysis_plan _plan;
  stats m_global_stats;
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-graph.h
index 84f8862fb96..7ce1e85800d 100644
--- a/gcc/analyzer/exploded-graph.h
+++ b/gcc/analyzer/exploded-graph.h
@@ -622,6 +622,8 @@ public:
 
   void dump () const;
 
+  json::array *to_json () const;
+
 private:
   struct per_node_data
   {
@@ -664,6 +666,8 @@ public:
 return m_scc.get_scc_id (snode.m_index);
   }
 
+  json::object *to_json () const;
+
 private:
   class key_t
   {
diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index bbd2e7c2d40..abdb336da91 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1740,7 +1740,7 @@ store::dump (bool simple) const
{PARENT_REGION_DESC: {BASE_REGION_DESC: object for binding_map,
 ... for each cluster within parent region},
 ...for each parent region,
-"called_unknown_function": true/false}.  */
+"called_unknown_fn": true/false}.  */
 
 json::object *
 store::to_json () const
diff --git a/gcc/analyzer/supergraph.cc b/gcc/analyzer/supergraph.cc
index 40acfbd16a8..0c69f139334 100644
--- a/gcc/analyzer/supergraph.cc
+++ b/gcc/analyzer/supergraph.cc
@@ -679,8 +679,9 @@ supernode::dump_dot_id (pretty_printer *pp) const
 
 /* Return a new json::object of the form
{"idx": int,
+"fun": optional str
 "bb_idx": int,
-"m_returning_call": optional str,
+"returning_call": optional str,
 "phis": [str],
 "stmts" : [str]}.  */
 
@@ -691,6 +692,8 @@ supernode::to_json () const
 
   snode_obj->set ("idx", new json::integer_number (m_index));
   snode_obj->set ("bb_idx", new json::integer_number (m_bb->index));
+  if (function *fun = get_function ())
+snode_obj->set ("fun", new json::string (function_name (fun)));
 
   if (m_returning_call)
 {
@@ -798,6 +801,26 @@ supernode::get_stmt_index (const gimple *stmt) const
   gcc_unreachable ();
 }
 
+/* Get a string for PK.  */
+
+static const char *
+edge_kind_to_string (enum 

[committed] analyzer: const fixes [PR98679]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-6689-g8a18261afd923151b8d2a37f667e4673b27acd3f

gcc/analyzer/ChangeLog:
PR analyzer/98679
* analyzer.h (region_offset::operator==): Make const.
* pending-diagnostic.h (pending_diagnostic::equal_p): Likewise.
* store.h (binding_cluster::for_each_value): Likewise.
(binding_cluster::for_each_binding): Likewise.
---
 gcc/analyzer/analyzer.h   | 2 +-
 gcc/analyzer/pending-diagnostic.h | 2 +-
 gcc/analyzer/store.h  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index f603802c0d6..6996092717c 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -169,7 +169,7 @@ public:
 return m_offset;
   }
 
-  bool operator== (const region_offset )
+  bool operator== (const region_offset ) const
   {
 return (m_base_region == other.m_base_region
&& m_offset == other.m_offset
diff --git a/gcc/analyzer/pending-diagnostic.h 
b/gcc/analyzer/pending-diagnostic.h
index 79dc83edc32..571fc1b56b9 100644
--- a/gcc/analyzer/pending-diagnostic.h
+++ b/gcc/analyzer/pending-diagnostic.h
@@ -157,7 +157,7 @@ class pending_diagnostic
   /* Compare for equality with OTHER, which might be of a different
  subclass.  */
 
-  bool equal_p (const pending_diagnostic )
+  bool equal_p (const pending_diagnostic ) const
   {
 /* Check for pointer equality on the IDs from get_kind.  */
 if (get_kind () != other.get_kind ())
diff --git a/gcc/analyzer/store.h b/gcc/analyzer/store.h
index 366439ce2dd..2bcef6c398a 100644
--- a/gcc/analyzer/store.h
+++ b/gcc/analyzer/store.h
@@ -425,7 +425,7 @@ public:
 
   template 
   void for_each_value (void (*cb) (const svalue *sval, T user_data),
-  T user_data)
+  T user_data) const
   {
 for (map_t::iterator iter = m_map.begin (); iter != m_map.end (); ++iter)
   cb ((*iter).second, user_data);
@@ -459,7 +459,7 @@ public:
   const svalue *maybe_get_simple_value (store_manager *mgr) const;
 
   template 
-  void for_each_binding (BindingVisitor )
+  void for_each_binding (BindingVisitor ) const
   {
 for (map_t::iterator iter = m_map.begin (); iter != m_map.end (); ++iter)
   {
-- 
2.26.2

Re: [PATCH] combine: zeroing cost for new copies

[Segher Boessenkool]

Hi!

On Wed, Dec 09, 2020 at 05:49:53PM +0800, Kewen.Lin wrote:
> This patch is to treat those new pseudo-to-pseudo copies
> after hard-reg-to-pseudo-copy as zero costs.  The
> justification is that these new copies are closely after
> the corresponding hard-reg-to-pseudo-copy insns, register
> allocation should be able to coalesce them and get them
> eliminated.

Costing things that are not free as cost zero is very problematic.
Cost zero is problematic in combine anyway (it means unknown cost, not
no cost).

> Now these copies follow the normal costing scheme, the
> below case dump shows the unexpected combination:
> 
> ``` dump
> 
> Trying 3, 2 -> 13:
> 3: r119:DI=r132:DI
>   REG_DEAD r132:DI
> 2: r118:DI=r131:DI
>   REG_DEAD r131:DI
>13: r128:DI=r118:DI&0x|r119:DI<<0x20
>   REG_DEAD r119:DI
>   REG_DEAD r118:DI

This should not combine if 2+13 and 3+13 do not combine already.  Why
did those not combine?

> Failed to match this instruction:
> (set (reg:DI 128)
> (ior:DI (ashift:DI (reg:DI 132)
> (const_int 32 [0x20]))
> (reg:DI 131)))

Likely because it results in this, and this insn isn't recognised.  So
this can be fixed by adding a pattern for it (it needs to make sure all
but the bottom 32 bits of reg 131 are zero; it can use nonzero_bits for
that).

Long ago I had the following patch for this.  Not sure why I never
submitted it, maybe there is something wronmg with it?


Segher

=
>From 04c44ad71941310c84b376744cfbcc87c93a8d68 Mon Sep 17 00:00:00 2001
Message-Id: 
<04c44ad71941310c84b376744cfbcc87c93a8d68.1528751010.git.seg...@kernel.crashing.org>
From: Segher Boessenkool 
Date: Mon, 11 Jun 2018 20:46:31 +
Subject: [PATCH] rs6000: Add a splitter for a rl*imi case

An rl*imi is usually written as an IOR of an ASHIFT or similar, and an
AND of a register with a constant mask.  In some cases combine knows
that that AND doesn't do anything (because all zero bits in that mask
correspond to bits known to be already zero), and then no pattern
matches.  This patch adds a define_split for such cases.  It uses
nonzero_bits in the condition of the splitter, but does not need it
afterwards for the instruction to be recognised.  This is necessary
because later passes can see fewer nonzero_bits.

Because it is a splitter, combine will only use it when starting with
three insns (or more), even though the result is just one.  This isn't
a huge problem in practice, but some possible combinations still won't
happen.

---
 gcc/config/rs6000/rs6000.md | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 38555f5..bc9781b 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -3920,6 +3920,24 @@ (define_insn "*rotl3_insert_3"
 }
   [(set_attr "type" "insert")])
 
+(define_code_iterator plus_ior_xor [plus ior xor])
+
+(define_split
+  [(set (match_operand:GPR 0 "gpc_reg_operand")
+   (plus_ior_xor:GPR (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand")
+ (match_operand:SI 2 "const_int_operand"))
+ (match_operand:GPR 3 "gpc_reg_operand")))]
+  "nonzero_bits (operands[3], mode)
+   < HOST_WIDE_INT_1U << INTVAL (operands[2])"
+  [(set (match_dup 0)
+   (ior:GPR (and:GPR (match_dup 3)
+ (match_dup 4))
+(ashift:GPR (match_dup 1)
+(match_dup 2]
+{
+  operands[4] = GEN_INT ((HOST_WIDE_INT_1U << INTVAL (operands[2])) - 1);
+})
+
 (define_insn "*rotl3_insert_4"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
(ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
-- 
1.8.3.1

Re: [r11-6672 Regression] Failed to bootstrap on Linux/x86_64

[H.J. Lu via Gcc-patches]

On Thu, Jan 14, 2021 at 12:33 PM Jakub Jelinek  wrote:
>
> On Thu, Jan 14, 2021 at 10:52:24AM -0800, sunil.k.pandey via Gcc-patches 
> wrote:
> > On Linux/x86_64,
>
> It breaks x86_64-linux build pretty much everywhere.
> libatomic (but as well libgomp and libitm) uses -march=i486 in certain cases.
> While for --with-arch or --with-arch_32 configured compilers it wouldn't be
> that hard to just check if the provided arch isn't i386 only, we shouldn't
> stop supporting compiler built with the defaults and I'm afraid that means
> -march=i386 by default for 32-bit code.
>
> Jakub

This is an old bug:

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

I am reviving my old patches now.

-- 
H.J.

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 12:21:05PM -0800, Fangrui Song wrote:
> On 2021-01-14, Martin Liška wrote:
> > On 1/14/21 11:07 AM, Richard Biener wrote:
> > > I see no particular reason to allow arbitrary garbage to be used as
> > > linker.  It just asks for users to shoot themselves in the foot and
> > > for strange bugreports to pop up.
> > 
> > Well, for a strange bug report, we'll see eventually usage of the 
> > --ld-path= option.
> > 
> > I see it handy when developing a ld feature to be able to point to a built 
> > ld
> > (without need to build GCC with it). Yes, one can use --save-temps --verbose
> > and invoke the built linker, but it's not handy.
> > 
> > Martin
> > 
> 
> I did this when I worked on some GNU ld features.
> clang --ld-path=/path/to/binutils/out/debug/ld/ld-new
> or debugging some Linux kernel issues related to ld.
> 
> Having --ld-path= in GCC will be handy.

If the linker is called ld and there isn't random unrelated stuff in the
same directory, one can always just use -B path/to/ld/

Jakub

Re: [r11-6672 Regression] Failed to bootstrap on Linux/x86_64

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 10:52:24AM -0800, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,

It breaks x86_64-linux build pretty much everywhere.
libatomic (but as well libgomp and libitm) uses -march=i486 in certain cases.
While for --with-arch or --with-arch_32 configured compilers it wouldn't be
that hard to just check if the provided arch isn't i386 only, we shouldn't
stop supporting compiler built with the defaults and I'm afraid that means
-march=i386 by default for 32-bit code.

Jakub

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

On 2021-01-14, Martin Liška wrote:

On 1/14/21 11:07 AM, Richard Biener wrote:

I see no particular reason to allow arbitrary garbage to be used as
linker.  It just asks for users to shoot themselves in the foot and
for strange bugreports to pop up.


Well, for a strange bug report, we'll see eventually usage of the --ld-path= 
option.

I see it handy when developing a ld feature to be able to point to a built ld
(without need to build GCC with it). Yes, one can use --save-temps --verbose
and invoke the built linker, but it's not handy.

Martin



I did this when I worked on some GNU ld features.
clang --ld-path=/path/to/binutils/out/debug/ld/ld-new
or debugging some Linux kernel issues related to ld.

Having --ld-path= in GCC will be handy.

[pushed] c++: Tweak g++.dg/template/pr98372.C.

[Marek Polacek via Gcc-patches]

This test was failing in C++11 because variable templates are only
available in C++14.

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

gcc/testsuite/ChangeLog:

* g++.dg/template/pr98372.C: Only run in C++14 and up.
---
 gcc/testsuite/g++.dg/template/pr98372.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/template/pr98372.C 
b/gcc/testsuite/g++.dg/template/pr98372.C
index f1e8b0f3323..054c94d9edb 100644
--- a/gcc/testsuite/g++.dg/template/pr98372.C
+++ b/gcc/testsuite/g++.dg/template/pr98372.C
@@ -1,5 +1,5 @@
 // PR 98372 ICE due to incorrect type compare
-// { dg-do compile { target c++11 } }
+// { dg-do compile { target c++14 } }
 
 template  using remove_pointer_t = typename _Tp ::type;
 template  struct enable_if;

base-commit: bdd1b1f55529da00b867ef05a53a08fbfc3d1c2e
-- 
2.29.2

Re: [PATCH] libgomp_g.h: Include stdint.h instead of gstdint.h

[Thomas Schwinge]

Hi!

On 2019-09-30T00:03:00-0700, Frederik Harwath  wrote:
> The patch changes libgomp/libgomp_g.h to include stdint.h instead of the 
> internal gstdint.h. The inclusion of gstdint.h has been
> introduced by GCC trunk r265930, presumably because this introduced uses of 
> uintptr_t. Since gstdint.h is not part of GCC's
> installation, several libgomp test cases fail to compile when running the 
> tests with the installed GCC.

This got into Subversion trunk in time for GCC 10, but is also necessary
for GCC 9; I've thus just pushed to releases/gcc-9 branch "libgomp_g.h:
Include stdint.h instead of gstdint.h" in commit
8d491db06a606f45d7c46e219fc075a3fea22e32, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 8d491db06a606f45d7c46e219fc075a3fea22e32 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 30 Sep 2019 14:16:34 +
Subject: [PATCH] libgomp_g.h: Include stdint.h instead of gstdint.h.

2019-09-30  Kwok Cheung Yeung  

	* libgomp_g.h: Include stdint.h instead of gstdint.h.

(cherry picked from commit d7f9ee981f32bdbc6916cb8c6b9435cfc06f88a0, r276301)
---
 libgomp/libgomp_g.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/libgomp_g.h b/libgomp/libgomp_g.h
index 32a9d8aade9..dfb55fb66dc 100644
--- a/libgomp/libgomp_g.h
+++ b/libgomp/libgomp_g.h
@@ -31,7 +31,7 @@
 
 #include 
 #include 
-#include "gstdint.h"
+#include 
 
 /* barrier.c */
 
-- 
2.17.1

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

[Jonathan Wakely via Gcc-patches]

On 14/01/21 19:33 +0100, François Dumont wrote:

On 14/01/21 6:10 pm, Jonathan Wakely wrote:

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it 
impacts all _GLIBCXX_DEBUG iterators.


However unordered containers local_iterator was more complicated 
to handle. Because of c++/65816 I prefer to review 
_Node_iterator_default constructor to set _M_cur to nullptr even 
if in principle it is not necessary except for the 
_Local_iterator_base constructor when hash code is not cached.


    libstdc++: Implement N3644 for _GLIBCXX_DEBUG iterators

    libstdc++-v3/ChangeLog

            PR libstdc++/98466
            * include/bits/hashtable_policy.h 
(_Node_iterator_base()): Set _M_cur to nullptr.

            (_Node_iterator()): Make default.
            (_Node_const_iterator()): Make 
default.
            * include/debug/macros.h 
(__glibcxx_check_erae_range_after): Add _M_singular

            iterator checks.
            * include/debug/safe_iterator.h
            (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if 
both iterator are value initialized.
            * include/debug/safe_local_iterator.h 
(_GLIBCXX_DEBUG_VERIFY_OPERANDS):

            Likewise.
            * include/debug/safe_iterator.tcc 
(_Safe_iterator<>::_M_valid_range): Add

            _M_singular checks on input 
iterators.
            * src/c++11/debug.cc 
(_Safe_iterator_base::_M_can_compare): Remove _M_singular

            checks.
            * 
testsuite/23_containers/deque/debug/98466.cc: New test.
            * 
testsuite/23_containers/unordered_map/debug/98466.cc: New test.


Tested under Linux x86_64 normal and debug mode.

Ok to commit ?


Yes, thanks.

One question about the deque test ...


diff --git 
a/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc 
b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc

new file mode 100644
index 000..720977e5622
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc
@@ -0,0 +1,38 @@
+// Copyright (C) 2021 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }


Does this need to be limited to c++11 and later? Could it just use
{ dg-do run } instead?


Good point, a bad copy/paste from the unordered test I guess.

But I try to remove it and it complained about invalid '{}' syntax in 
C++98 for the iterator value initialization. I try to replace with 
'()' but then ambiguity with a function declaration, I gave up !


As N3644 is talking about value initialization it doesn't sound that 
bad to limit it to C++11, isn't it a C++11 concept ?


No, it was added in C++03.

You can do this to avoid it being treated as a function declaration:

__gnu_debug::deque::iterator it = __gnu_debug::deque::iterator();


OK to commit with that change if it passes in C++98 mode.

[gcn offloading] Only supported in 64-bit configurations (was: [PATCH 7/7 libgomp,amdgcn] GCN Libgomp Plugin)

[Thomas Schwinge]

Hi!

On 2019-11-12T13:29:16+, Andrew Stubbs  wrote:
> This patch contributes the GCN libgomp plugin, with the various
> configure and make bits to go with it.

> --- a/libgomp/plugin/configfrag.ac
> +++ b/libgomp/plugin/configfrag.ac

> +  amdgcn*)
> + case "${target}" in
> +   x86_64-*-*)
> + case " ${CC} ${CFLAGS} " in
> +   *" -m32 "*)
> + PLUGIN_GCN=0

That means, for good reasons, the GCN libgomp plugin is only built in
64-bit configurations.

However, in a (standard) bi-arch x86_64-pc-linux-gnu '-m64'/'-m32' build,
the compiler will still attempt 32-bit GCN offloading code generation,
which will often fail horribly (several classes of ICEs), is untested,
and not intended to be supported, as Andrew confirmed to me months ago.
So, we shouldn't try to do that; similar to nvptx offloading, see PR65099
"nvptx offloading: hard-coded 64-bit assumptions".

As obvious, I've just pushed "[gcn offloading] Only supported in 64-bit
configurations" to master branch in commit
505caa7295b93ecdec8ac9b31595eb34dbd48c9f, and cherry-picked into
releases/gcc-10 branch in commit
d697bf91a5457dfb06b4112b89dec2e43f472830, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 505caa7295b93ecdec8ac9b31595eb34dbd48c9f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 28 Apr 2020 20:43:38 +0200
Subject: [PATCH] [gcn offloading] Only supported in 64-bit configurations

Similar to nvptx offloading, see PR65099 "nvptx offloading: hard-coded 64-bit
assumptions".

	gcc/
	* config/gcn/mkoffload.c (main): Create an offload image only in
	64-bit configurations.
---
 gcc/config/gcn/mkoffload.c | 260 +++--
 1 file changed, 134 insertions(+), 126 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.c b/gcc/config/gcn/mkoffload.c
index 7d00aaf507e..eb1c717e6e9 100644
--- a/gcc/config/gcn/mkoffload.c
+++ b/gcc/config/gcn/mkoffload.c
@@ -755,11 +755,6 @@ main (int argc, char **argv)
   FILE *cfile = stdout;
   const char *outname = 0;
 
-  const char *gcn_s1_name;
-  const char *gcn_s2_name;
-  const char *gcn_o_name;
-  const char *gcn_cfile_name;
-
   progname = "mkoffload";
   diagnostic_initialize (global_dc, 0);
 
@@ -905,145 +900,158 @@ main (int argc, char **argv)
   if (!dumppfx)
 dumppfx = outname;
 
-  const char *mko_dumpbase = concat (dumppfx, ".mkoffload", NULL);
-  const char *hsaco_dumpbase = concat (dumppfx, ".mkoffload.hsaco", NULL);
   gcn_dumpbase = concat (dumppfx, ".c", NULL);
 
+  const char *gcn_cfile_name;
   if (save_temps)
-{
-  gcn_s1_name = concat (mko_dumpbase, ".1.s", NULL);
-  gcn_s2_name = concat (mko_dumpbase, ".2.s", NULL);
-  gcn_o_name = hsaco_dumpbase;
-  gcn_cfile_name = gcn_dumpbase;
-}
+gcn_cfile_name = gcn_dumpbase;
   else
-{
-  gcn_s1_name = make_temp_file (".mkoffload.1.s");
-  gcn_s2_name = make_temp_file (".mkoffload.2.s");
-  gcn_o_name = make_temp_file (".mkoffload.hsaco");
-  gcn_cfile_name = make_temp_file (".c");
-}
-  obstack_ptr_grow (_to_cleanup, gcn_s1_name);
-  obstack_ptr_grow (_to_cleanup, gcn_s2_name);
-  obstack_ptr_grow (_to_cleanup, gcn_o_name);
+gcn_cfile_name = make_temp_file (".c");
   obstack_ptr_grow (_to_cleanup, gcn_cfile_name);
 
-  obstack_ptr_grow (_argv_obstack, "-dumpdir");
-  obstack_ptr_grow (_argv_obstack, "");
-  obstack_ptr_grow (_argv_obstack, "-dumpbase");
-  obstack_ptr_grow (_argv_obstack, mko_dumpbase);
-  obstack_ptr_grow (_argv_obstack, "-dumpbase-ext");
-  obstack_ptr_grow (_argv_obstack, "");
-
-  obstack_ptr_grow (_argv_obstack, "-o");
-  obstack_ptr_grow (_argv_obstack, gcn_s1_name);
-  obstack_ptr_grow (_argv_obstack, NULL);
-  const char **cc_argv = XOBFINISH (_argv_obstack, const char **);
-
-  /* Build arguments for assemble/link pass.  */
-  struct obstack ld_argv_obstack;
-  obstack_init (_argv_obstack);
-  obstack_ptr_grow (_argv_obstack, driver);
-
-  /* Extract early-debug information from the input objects.
- This loop finds all the inputs that end ".o" and aren't the output.  */
-  int dbgcount = 0;
-  for (int ix = 1; ix != argc; ix++)
+  cfile = fopen (gcn_cfile_name, "w");
+  if (!cfile)
+fatal_error (input_location, "cannot open '%s'", gcn_cfile_name);
+
+  /* Currently, we only support offloading in 64-bit configurations.  */
+  if (offload_abi == OFFLOAD_ABI_LP64)
 {
-  if (!strcmp (argv[ix], "-o") && ix + 1 != argc)
-	++ix;
+  const char *mko_dumpbase = concat (dumppfx, ".mkoffload", NULL);
+  const char *hsaco_dumpbase = concat (dumppfx, ".mkoffload.hsaco", NULL);
+
+  const char *gcn_s1_name;
+  const char *gcn_s2_name;
+  const char *gcn_o_name;
+  if (save_temps)
+	{
+	  gcn_s1_name = concat (mko_dumpbase, ".1.s", NULL);
+	  gcn_s2_name = concat (mko_dumpbase, ".2.s", NULL);
+	  

[PATCH 2/2] RTEMS: Add -mcustom-fpu-cfg=fph2 multilib

[Sebastian Huber]

This multilib supports Nios II configurations with the "Nios II Floating
Point Hardware 2 Component".

gcc/

* config/nios2/t-rtems: Reset all MULTILIB_* variables.  Shorten
multilib directory names.  Use MULTILIB_REQUIRED instead of
MULTILIB_EXCEPTIONS.  Add -mhw-mul -mhw-mulx -mhw-div
-mcustom-fpu-cfg=fph2 multilib.
---
 gcc/config/nios2/t-rtems | 146 +--
 1 file changed, 18 insertions(+), 128 deletions(-)

diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems
index f95fa3c4717..beda8328bd2 100644
--- a/gcc/config/nios2/t-rtems
+++ b/gcc/config/nios2/t-rtems
@@ -1,133 +1,23 @@
 # Custom RTEMS multilibs
 
-MULTILIB_OPTIONS = mhw-mul mhw-mulx mhw-div mcustom-fadds=253 
mcustom-fdivs=255 mcustom-fmuls=252 mcustom-fsubs=254
+# Reset all MULTILIB variables
+
+MULTILIB_OPTIONS   =
+MULTILIB_DIRNAMES  =
+MULTILIB_EXCEPTIONS=
+MULTILIB_REUSE =
+MULTILIB_MATCHES   =
+MULTILIB_REQUIRED  =
 
 # Enumeration of multilibs
 
-# MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fsubs=254
-# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253
-MULTILIB_EXCEPTIONS += 
mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += mhw-mul/mhw-div
-MULTILIB_EXCEPTIONS += 
mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254
-MULTILIB_EXCEPTIONS += 

[PATCH 1/2] nios2: Add -mcustom-fpu-cfg=fph2

[Sebastian Huber]

The new -mcustom-fpu-cfg=fph2 option variant is useful to build a
multilib for the "Nios II Floating Point Hardware 2 Component":

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf

Directly using the corresponding -mcustom-insn=N options for this
floating-point unit leads to a combinatorial explosion in the potential
count of multilibs which may break the build.

The following instructions supported by this component are not enabled
by this option:

* -mcustom-fmins
* -mcustom-fmaxs
* -mcustom-round

The reason is that these instructions are only in effect in combination
with other options. If they are not set, then a build error occurs in
libatomic since -Werror is used for building this library:

cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' 
is specified [-Werror]
cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' 
is specified [-Werror]
cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is 
specified [-Werror]

gcc/

* config/nios2/nios2.c (NIOS2_FPU_CONFIG_NUM): Adjust value.
(nios2_init_fpu_configs): Provide register values for new
-mcustom-fpu-cfg=fph2 option variant.
* doc/invoke.texi (-mcustom-fpu-cfg=fph2): Document new option
variant.
---
 gcc/config/nios2/nios2.c | 20 +++-
 gcc/doc/invoke.texi  | 25 +
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index 3bffabe9856..fc9c8b70807 100644
--- a/gcc/config/nios2/nios2.c
+++ b/gcc/config/nios2/nios2.c
@@ -1236,7 +1236,7 @@ struct nios2_fpu_config
   int code[n2fpu_code_num];
 };
 
-#define NIOS2_FPU_CONFIG_NUM 3
+#define NIOS2_FPU_CONFIG_NUM 4
 static struct nios2_fpu_config custom_fpu_config[NIOS2_FPU_CONFIG_NUM];
 
 static void
@@ -1280,6 +1280,24 @@ nios2_init_fpu_configs (void)
   cfg->code[n2fpu_fsubs]   = 254;
   cfg->code[n2fpu_fdivs]   = 255;
 
+  NEXT_FPU_CONFIG;
+  cfg->name = "fph2";
+  cfg->code[n2fpu_fabss]   = 224;
+  cfg->code[n2fpu_fnegs]   = 225;
+  cfg->code[n2fpu_fcmpnes] = 226;
+  cfg->code[n2fpu_fcmpeqs] = 227;
+  cfg->code[n2fpu_fcmpges] = 228;
+  cfg->code[n2fpu_fcmpgts] = 229;
+  cfg->code[n2fpu_fcmples] = 230;
+  cfg->code[n2fpu_fcmplts] = 231;
+  cfg->code[n2fpu_fixsi]   = 249;
+  cfg->code[n2fpu_floatis] = 250;
+  cfg->code[n2fpu_fsqrts]  = 251;
+  cfg->code[n2fpu_fmuls]   = 252;
+  cfg->code[n2fpu_fadds]   = 253;
+  cfg->code[n2fpu_fsubs]   = 254;
+  cfg->code[n2fpu_fdivs]   = 255;
+
 #undef NEXT_FPU_CONFIG
   gcc_assert (i == NIOS2_FPU_CONFIG_NUM);
 }
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 298f1f873e3..91fd980550f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -26121,6 +26121,23 @@ Currently, the following sets are defined:
 -mcustom-fdivs=255 @gol
 -fsingle-precision-constant}
 
+@option{-mcustom-fpu-cfg=fph2} is equivalent to:
+@gccoptlist{-mcustom-fabss=224 @gol
+-mcustom-fnegs=225 @gol
+-mcustom-fcmpnes=226 @gol
+-mcustom-fcmpeqs=227 @gol
+-mcustom-fcmpges=228 @gol
+-mcustom-fcmpgts=229 @gol
+-mcustom-fcmples=230 @gol
+-mcustom-fcmplts=231 @gol
+-mcustom-fixsi=249 @gol
+-mcustom-floatis=250 @gol
+-mcustom-fsqrts=251 @gol
+-mcustom-fmuls=252 @gol
+-mcustom-fadds=253 @gol
+-mcustom-fsubs=254 @gol
+-mcustom-fdivs=255 @gol}
+
 Custom instruction assignments given by individual
 @option{-mcustom-@var{insn}=} options override those given by
 @option{-mcustom-fpu-cfg=}, regardless of the
@@ -26131,6 +26148,14 @@ configuration by using the 
@code{target("custom-fpu-cfg=@var{name}")}
 function attribute (@pxref{Function Attributes})
 or pragma (@pxref{Function Specific Option Pragmas}).
 
+The name @var{fph2} is an abbreviation for @emph{Nios II Floating Point
+Hardware 2 Component}.  This component supports also the custom instructions
+@option{-mcustom-fmins=233}, @option{-mcustom-fmaxs=234}, and
+@option{-mcustom-round=248}.  These options are not enabled by
+@option{-mcustom-fpu-cfg=fph2} since they are only in effect if other options
+are enabled.  In contrast to the other configurations,
+@option{-fsingle-precision-constant} is not set.
+
 @end table
 
 These additional @samp{-m} options are available for the Altera Nios II
-- 
2.26.2

[PATCH] keep scope blocks for all inlined functions (PR 98664)

[Martin Sebor via Gcc-patches]

One aspect of PR 98465 - Bogus warning stringop-overread for std::string
is the inconsistency between -g and -g0 which turns out to be due to
GCC eliminating apparently unused scope blocks from inlined functions
that aren't explicitly declared inline and artificial.  PR 98664 tracks
just this part of PR 98465.

To resolve just the PR 98664 subset the attached change has
the tree-ssa-live.c pass preserve these blocks for all inlined
functions, not just artificial ones.  Besides avoiding the interaction
between -g and warnings it also seems to improve the inlining context
by including more inlined call sites.  This can be seen in the adjusted
tests.  (Its effect on PR 98465 is that the false positive is issued
consistently, regardless of -g.  Avoiding the false positive is my
next step.)

Jakub, you raised a concern yesterday in PR 98465 c#13 about the memory
footprint of this change.  Can you please comment on whether it's in
line with what you were suggesting?

Martin
PR middle-end/98664 - inconsistent -Wfree-nonheap-object for inlined calls to system headers

gcc/ChangeLog:

	PR middle-end/98664
	* tree-ssa-live.c (remove_unused_scope_block_p): Keep scopes for
	all functions, even if they're not declared artificial or inline.
	* tree.c (tree_inlined_location): Use macro expansion location
	only if scope traversal fails to expose one.

gcc/testsuite/ChangeLog:

	PR middle-end/98664
	* gcc.dg/Wvla-larger-than-4.c: Adjust expected output.
	* gcc.dg/plugin/diagnostic-test-inlining-3.c: Same.
	* g++.dg/warn/Wfree-nonheap-object-5.C: New test.
	* gcc.dg/Wfree-nonheap-object-4.c: New test.

diff --git a/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object-5.C b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object-5.C
new file mode 100644
index 000..742dba0cf58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object-5.C
@@ -0,0 +1,129 @@
+/* PR middle-end/98664 - inconsistent --Wfree-nonheap-object for inlined
+   calls to system headers
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+# 7 "Wfree-nonheap-object-5.h" 1 3
+
+struct A0
+{
+  void *p;
+
+  void f0 (void *q) { p = q; }
+  void g0 (void) {
+__builtin_free (p);   // { dg-warning "\\\[-Wfree-nonheap-object" }
+  }
+};
+
+struct A1
+{
+  void *p;
+
+  void f0 (void *q) { p = q; }
+  void f1 (void *q) { f0 (q); }
+
+  void g0 (void) {
+__builtin_free (p);   // { dg-warning "\\\[-Wfree-nonheap-object" }
+  }
+  void g1 (void) { g0 (); }
+};
+
+struct A2
+{
+  void *p;
+
+  void f0 (void *q) { p = q; }
+  void f1 (void *q) { f0 (q); }
+  void f2 (void *q) { f1 (q); }
+
+  void g0 (void) {
+__builtin_free (p);   // { dg-warning "\\\[-Wfree-nonheap-object" }
+  }
+  void g1 (void) { g0 (); }
+  void g2 (void) { g1 (); }
+};
+
+# 47 "Wfree-nonheap-object-5.C"
+
+#define NOIPA __attribute__ ((noipa))
+
+extern int array[];
+
+/* Verify the warning is issued even for calls in a system header inlined
+   into a function outside the header.  */
+
+NOIPA void warn_g0 (struct A0 *p)
+{
+  int *q = array + 1;
+
+  p->f0 (q);
+  p->g0 ();
+}
+
+// { dg-message "inlined from 'void warn_g0\\(A0\\*\\)'" "" { target *-*-* } 0 }
+
+
+/* Also verify the warning can be suppressed.  */
+
+NOIPA void nowarn_g0 (struct A0 *p)
+{
+  int *q = array + 2;
+
+  p->f0 (q);
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
+  p->g0 ();
+#pragma GCC diagnostic pop
+}
+
+
+NOIPA void warn_g1 (struct A1 *p)
+{
+  int *q = array + 3;
+
+  p->f1 (q);
+  p->g1 ();
+}
+
+// { dg-message "inlined from 'void A1::g1\\(\\)'" "" { target *-*-* } 0 }
+// { dg-message "inlined from 'void warn_g1\\(A1\\*\\)'" "" { target *-*-* } 0 }
+
+
+NOIPA void nowarn_g1 (struct A2 *p)
+{
+  int *q = array + 4;
+
+  p->f1 (q);
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
+  p->g1 ();
+#pragma GCC diagnostic pop
+}
+
+
+NOIPA void warn_g2 (struct A2 *p)
+{
+  int *q = array + 5;
+
+  p->f2 (q);
+  p->g2 ();
+}
+
+// { dg-message "inlined from 'void A2::g1\\(\\)'" "" { target *-*-* } 0 }
+// { dg-message "inlined from 'void A2::g2\\(\\)'" "" { target *-*-* } 0 }
+// { dg-message "inlined from 'void warn_g2\\(A2\\*\\)'" "" { target *-*-* } 0 }
+
+
+NOIPA void nowarn_g2 (struct A2 *p)
+{
+  int *q = array + 6;
+
+  p->f2 (q);
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
+  p->g2 ();
+#pragma GCC diagnostic pop
+}
diff --git a/gcc/testsuite/gcc.dg/Wfree-nonheap-object-4.c b/gcc/testsuite/gcc.dg/Wfree-nonheap-object-4.c
new file mode 100644
index 000..a7d921248c4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wfree-nonheap-object-4.c
@@ -0,0 +1,107 @@
+/* PR middle-end/98664 - inconsistent --Wfree-nonheap-object for inlined
+   calls to system headers
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+# 7 "Wfree-nonheap-object-4.h" 1 3
+
+struct A
+{
+  void *p;
+};
+
+void f0 (struct A *p, void *q) { p->p = q; }
+void f1 (struct A *p, void *q) { 

Re: calibrate intervals to avoid zero in futures poll test

[Alexandre Oliva]

On Jan 14, 2021, Jonathan Wakely  wrote:

>> +  /* Got for some 10 cycles, but we're already past that and still

> I can't parse "Got for some 10 cycles". If that's just a typo

Yeah, I meant "Go for ... but if ..." and managed to double-mangle it.
Thanks for spotting it.  Here's the patch I'm installing, with the typos
fixed.  Thanks!


calibrate intervals to avoid zero in futures poll test

From: Alexandre Oliva 

We get occasional failures of 30_threads/future/members/poll.cc
on some platforms whose high resolution clock doesn't have such a high
resolution; wait_for_0 ends up as 0, and then some asserts fail as
intervals measured as longer than zero are tested for less than
several times zero.

This patch adds some calibration in the iteration count to set a
measurable base time interval with some additional margin.


for  libstdc++-v3/ChangeLog

* testsuite/30_threads/future/members/poll.cc: Calibrate
iteration count.
---
 .../testsuite/30_threads/future/members/poll.cc|   33 +++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc 
b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
index 91f685b172d73..133dae15ac471 100644
--- a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
+++ b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-const int iterations = 200;
+int iterations = 200;
 
 using namespace std;
 
@@ -45,10 +45,41 @@ int main()
   promise p;
   future f = p.get_future();
 
+ start_over:
   auto start = chrono::high_resolution_clock::now();
   for(int i = 0; i < iterations; i++)
 f.wait_for(chrono::seconds(0));
   auto stop = chrono::high_resolution_clock::now();
+
+  /* We've run too few iterations for the clock resolution.
+ Attempt to calibrate it.  */
+  if (start == stop)
+{
+  /* Loop until the clock advances, so that start is right after a
+time increment.  */
+  do
+   start = chrono::high_resolution_clock::now();
+  while (start == stop);
+  int i = 0;
+  /* Now until the clock advances again, so that stop is right
+after another time increment.  */
+  do
+   {
+ f.wait_for(chrono::seconds(0));
+ stop = chrono::high_resolution_clock::now();
+ i++;
+   }
+  while (start == stop);
+  /* Go for some 10 cycles, but if we're already past that and
+still get into the calibration loop, double the iteration
+count and try again.  */
+  if (iterations < i * 10)
+   iterations = i * 10;
+  else
+   iterations *= 2;
+  goto start_over;
+}
+
   double wait_for_0 = print("wait_for(0s)", stop - start);
 
   start = chrono::high_resolution_clock::now();


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[r11-6672 Regression] Failed to bootstrap on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

77d372abec0fbf2cfe922e3140ee3410248f979e is the first bad commit
commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu 
Date:   Thu Jan 14 05:56:46 2021 -0800

x86: Error on -fcf-protection with incompatible target

caused build failure when configured with:

../gcc/configure --with-arch=skylake-avx512 --with-cpu=skylake-avx512  
--enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet 
--with-demangler-in-ld --enable-libmpx --with-fpmath=sse 

Build log(last 100 lines):

config.status: creating src/c++17/Makefile
Adding multilib support to src/c++17/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating src/c++20/Makefile
Adding multilib support to src/c++20/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating src/filesystem/Makefile
Adding multilib support to src/filesystem/Makefile in 
../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating doc/Makefile
Adding multilib support to doc/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating po/Makefile
Adding multilib support to po/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating testsuite/Makefile
Adding multilib support to testsuite/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating python/Makefile
Adding multilib support to python/Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in ../../../../../gcc/libstdc++-v3
with_multisubdir=32
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
make[3]: Entering directory 
'/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/r11-6672/bld/x86_64-linux/32/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1754: x86_64-linux/bits/largefile-config.h] Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
sed -e '/^#pragma/b' \
-e 
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g'
 \
-e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
-e 's,^#include "\(.*\)",#include ,g' \
< 
/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/gcc/libstdc++-v3/../libgcc/gthr.h
 > x86_64-linux/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
-e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
< 
/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/gcc/libstdc++-v3/../libgcc/gthr-single.h
 > x86_64-linux/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
-e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
-e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
< 
/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/gcc/libstdc++-v3/../libgcc/gthr-posix.h
 > x86_64-linux/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
-e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
-e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
-e 's,^#include "\(.*\)",#include ,g' \
< 
/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/gcc/libstdc++-v3/../libgcc/gthr-posix.h
 > x86_64-linux/bits/gthr-default.h
make[3]: Leaving directory 
'/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/r11-6672/bld/x86_64-linux/32/libstdc++-v3/include'
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
make[3]: Entering directory 
'/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/r11-6672/bld/x86_64-linux/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[3]: [Makefile:1753: x86_64-linux/bits/largefile-config.h] Error 1 (ignored)
make[3]: [Makefile:1754: x86_64-linux/bits/largefile-config.h] Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
sed -e '/^#pragma/b' \
-e 
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g'
 \
-e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
-e 's,^#include "\(.*\)",#include ,g' \
< 
/local/skpandey/gccwork/toolwork/gcc-bisect-build-master/master/gcc/libstdc++-v3/../libgcc/gthr.h
 

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

[François Dumont via Gcc-patches]

On 14/01/21 6:15 pm, Jonathan Wakely wrote:

On 14/01/21 17:10 +, Jonathan Wakely wrote:

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it 
impacts all _GLIBCXX_DEBUG iterators.


However unordered containers local_iterator was more complicated to 
handle. Because of c++/65816 I prefer to review 
_Node_iterator_default constructor to set _M_cur to nullptr even if 
in principle it is not necessary except for the _Local_iterator_base 
constructor when hash code is not cached.


    libstdc++: Implement N3644 for _GLIBCXX_DEBUG iterators

    libstdc++-v3/ChangeLog

            PR libstdc++/98466
            * include/bits/hashtable_policy.h 
(_Node_iterator_base()): Set _M_cur to nullptr.

            (_Node_iterator()): Make default.
            (_Node_const_iterator()): Make default.
            * include/debug/macros.h 
(__glibcxx_check_erae_range_after): Add _M_singular

            iterator checks.
            * include/debug/safe_iterator.h
            (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if 
both iterator are value initialized.
            * include/debug/safe_local_iterator.h 
(_GLIBCXX_DEBUG_VERIFY_OPERANDS):

            Likewise.
            * include/debug/safe_iterator.tcc 
(_Safe_iterator<>::_M_valid_range): Add

            _M_singular checks on input iterators.
            * src/c++11/debug.cc 
(_Safe_iterator_base::_M_can_compare): Remove _M_singular

            checks.
            * 
testsuite/23_containers/deque/debug/98466.cc: New test.
            * 
testsuite/23_containers/unordered_map/debug/98466.cc: New test.


Tested under Linux x86_64 normal and debug mode.

Ok to commit ?


Yes, thanks.


I've just realised that this C++14 change used to be noted in the
C++14 status table:

    
  
  
   http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3644.pdf;>

 N3644
   
  
  Null Forward Iterators
  Partial
  Only affects Debug Mode
 

But I removed that last year when replacing the list of proposals with
the Table of Contents taken from the standard, in commit
57ede05c6a0b443943e312bf205cb79233c9396f (oops!)

For the branches we should either document that missing feature in a
note, or backport your fix in a few weeks.




I'll keep the backport in my TODOs.

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

[François Dumont via Gcc-patches]

On 14/01/21 6:10 pm, Jonathan Wakely wrote:

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it 
impacts all _GLIBCXX_DEBUG iterators.


However unordered containers local_iterator was more complicated to 
handle. Because of c++/65816 I prefer to review 
_Node_iterator_default constructor to set _M_cur to nullptr even if 
in principle it is not necessary except for the _Local_iterator_base 
constructor when hash code is not cached.


    libstdc++: Implement N3644 for _GLIBCXX_DEBUG iterators

    libstdc++-v3/ChangeLog

            PR libstdc++/98466
            * include/bits/hashtable_policy.h 
(_Node_iterator_base()): Set _M_cur to nullptr.

            (_Node_iterator()): Make default.
            (_Node_const_iterator()): Make default.
            * include/debug/macros.h 
(__glibcxx_check_erae_range_after): Add _M_singular

            iterator checks.
            * include/debug/safe_iterator.h
            (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if 
both iterator are value initialized.
            * include/debug/safe_local_iterator.h 
(_GLIBCXX_DEBUG_VERIFY_OPERANDS):

            Likewise.
            * include/debug/safe_iterator.tcc 
(_Safe_iterator<>::_M_valid_range): Add

            _M_singular checks on input iterators.
            * src/c++11/debug.cc 
(_Safe_iterator_base::_M_can_compare): Remove _M_singular

            checks.
            * 
testsuite/23_containers/deque/debug/98466.cc: New test.
            * 
testsuite/23_containers/unordered_map/debug/98466.cc: New test.


Tested under Linux x86_64 normal and debug mode.

Ok to commit ?


Yes, thanks.

One question about the deque test ...


diff --git 
a/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc 
b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc

new file mode 100644
index 000..720977e5622
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc
@@ -0,0 +1,38 @@
+// Copyright (C) 2021 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }


Does this need to be limited to c++11 and later? Could it just use
{ dg-do run } instead?


Good point, a bad copy/paste from the unordered test I guess.

But I try to remove it and it complained about invalid '{}' syntax in 
C++98 for the iterator value initialization. I try to replace with '()' 
but then ambiguity with a function declaration, I gave up !


As N3644 is talking about value initialization it doesn't sound that bad 
to limit it to C++11, isn't it a C++11 concept ?




OK to commit anyway, thanks.

[PATCH] c-family, v2: Improve MEM_REF printing for diagnostics [PR98597]

[Jakub Jelinek via Gcc-patches]

On Thu, Jan 14, 2021 at 10:49:42AM -0700, Martin Sebor wrote:
> > In the light of Martins patch this is probably reasonable but still
> > the general direction is wrong (which is why I didn't approve Martins
> > original patch).  I'm also somewhat disappointed we're breaking this
> > so late in the cycle.
> 
> So am I.  I didn't test this change as exhaustively as I could and
> (in light of the poor test coverage) should have.  That's my bad.
> FWIW, I did do it for the first patch (by instrumenting GCC and
> formatting every MEM_REF it came across), but it didn't occur to
> me to do it this time around.  I have now completed this testing
> (it found one more ICE elsewhere that I'll fix soon).

Ok, here is an updated patch which fixes what I found, and implements what
has been discussed on the mailing list and on IRC, i.e. if the types
are compatible as well as alias sets are same, then it prints
what c_fold_indirect_ref_for_warn managed to create, otherwise it uses
that info for printing offsets using offsetof (except when it starts
with ARRAY_REFs, because one can't have offsetof (struct T[2][2], [1][0].x.y)

The uninit-38.c test (which was the only one I believe which had tests on the
exact spelling of MEM_REF printing) contains mainly changes to have space
before * for pointer types (as that is how the C pretty-printers normally
print types, int * rather than int*), plus what might be considered a
regression from what Martin printed, but it is actually a correctness fix.

When the arg is a pointer with type pointer to VLA with char element type
(let's say the pointer is p), which is what happens in several of the
uninit-38.c tests, omitting the (char *) cast is incorrect, as p + 1
is not the 1 byte after p, but pointer to the end of the VLA.
It only happened to work because of the hacks (which I don't like at all
and are dangerous, DECL_ARTIFICIAL var names with dot inside can be pretty
much anything, e.g. a lot of passes construct their helper vars from some
prefix that designates intended use of the var plus numeric suffix), where
the a.1 pointer to VLA is printed as a which if one is lucky happens to be
a variable with VLA type (rather than pointer to it), and for such vars
a + 1 is indeed [0] + 1 rather than  + 1.  But if we want to do this
reliably, we'd need to make sure it comes from VLA (e.g. verify that the
SSA_NAME is defined to __builtin_alloca_with_align and that there exists
a corresponding VAR_DECL with DECL_VALUE_EXPR that has the a.1 variable
in it).

Is this ok for trunk if it passes bootstrap/regtest?

2021-01-14  Jakub Jelinek  

PR tree-optimization/98597
* c-pretty-print.c (c_fold_indirect_ref_for_warn): New function.
(print_mem_ref): Use it.  If it returns something that has compatible
type and is TBAA compatible with zero offset, print it and return,
otherwise print it using offsetof syntax or array ref syntax.  Fix up
printing if MEM_REFs first operand is ADDR_EXPR, or when the first
argument has pointer to array type.  Print pointers using the standard
formatting.

* gcc.dg/uninit-38.c: Expect a space in between type name and asterisk.
Expect for now a (char *) cast for VLAs.
* gcc.dg/uninit-40.c: New test.

--- gcc/c-family/c-pretty-print.c.jj2021-01-13 15:27:09.822834600 +0100
+++ gcc/c-family/c-pretty-print.c   2021-01-14 19:02:21.299138891 +0100
@@ -1809,6 +1809,113 @@ pp_c_call_argument_list (c_pretty_printe
   pp_c_right_paren (pp);
 }
 
+/* Try to fold *(type *) into op.fld.fld2[1] if possible.
+   Only used for printing expressions.  Should punt if ambiguous
+   (e.g. in unions).  */
+
+static tree
+c_fold_indirect_ref_for_warn (location_t loc, tree type, tree op,
+ offset_int )
+{
+  tree optype = TREE_TYPE (op);
+  if (off == 0)
+{
+  if (lang_hooks.types_compatible_p (optype, type))
+   return op;
+  /* *(foo *) => __real__ complexfoo */
+  else if (TREE_CODE (optype) == COMPLEX_TYPE
+  && lang_hooks.types_compatible_p (type, TREE_TYPE (optype)))
+   return build1_loc (loc, REALPART_EXPR, type, op);
+}
+  /* ((foo*))[1] => __imag__ complexfoo */
+  else if (TREE_CODE (optype) == COMPLEX_TYPE
+  && lang_hooks.types_compatible_p (type, TREE_TYPE (optype))
+  && tree_to_uhwi (TYPE_SIZE_UNIT (type)) == off)
+{
+  off = 0;
+  return build1_loc (loc, IMAGPART_EXPR, type, op);
+}
+  /* ((foo *))[x] => fooarray[x] */
+  if (TREE_CODE (optype) == ARRAY_TYPE
+  && TYPE_SIZE_UNIT (TREE_TYPE (optype))
+  && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (optype))) == INTEGER_CST
+  && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (optype
+{
+  tree type_domain = TYPE_DOMAIN (optype);
+  tree min_val = size_zero_node;
+  if (type_domain && TYPE_MIN_VALUE (type_domain))
+   min_val = TYPE_MIN_VALUE (type_domain);
+  offset_int el_sz = wi::to_offset 

[nvptx libgomp plugin] Build only in supported configurations (was: [nvptx offloading] Only 64-bit configurations are currently supported)

[Thomas Schwinge]

Hi!

On 2015-07-08T17:03:02+0200, I wrote:
> On Wed, 18 Feb 2015 09:50:15 +0100, I wrote:
>> So far, we have concentrated only on the 64-bit x86_64 configuration;
>> 32-bit has several known issues to be resolved.
>>  filed.

(This still holds, and is unlikely to ever get addressed.)

> I have committed the following patch in r225560.  This gets us rid of the
> lots of "expected FAILs" in the 32-bit part of
> RUNTESTFLAGS='--target_board=unix\{-m64,-m32\}' testing, for example.
>
> commit fe265ad3c9624da88f43be349137696449148f4f
> Author: tschwinge 
> Date:   Wed Jul 8 14:59:59 2015 +
>
> [nvptx offloading] Only 64-bit configurations are currently supported
>
>   PR libgomp/65099
>   gcc/
>   * config/nvptx/mkoffload.c (main): Create an offload image only in
>   64-bit configurations.

(That remains in place.)

>   libgomp/
>   * plugin/plugin-nvptx.c (nvptx_get_num_devices): Return 0 if not
>   in a 64-bit configuration.

That, for reasons given in the commit log, I've just refined, pushed
"[nvptx libgomp plugin] Build only in supported configurations" to master
branch in commit 6106dfb9f73a33c87108ad5b2dcd4842bdd7828e, and
cherry-picked into releases/gcc-10 branch in commit
1e56a7c9a6631b217299b2ddcd5c4d497bb3445e, releases/gcc-9 branch in commit
0f1e1069a753e912b058f0d4bf599f0edde28408, releases/gcc-8 branch in commit
f9267925c648f2ccd9e4680b699e581003125bcf, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 6106dfb9f73a33c87108ad5b2dcd4842bdd7828e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 30 Nov 2020 15:15:20 +0100
Subject: [PATCH] [nvptx libgomp plugin] Build only in supported configurations

As recently again discussed in  "[nvptx] -m32
support", nvptx offloading other than for 64-bit host has never been
implemented, tested, supported.  So we simply should buildn't the nvptx libgomp
plugin in this case.

This avoids build problems if, for example, in a (standard) bi-arch
x86_64-pc-linux-gnu '-m64'/'-m32' build, libcuda is available only in a 64-bit
variant but not in a 32-bit one, which, for example, is the case if you build
GCC against the CUDA toolkit's 'stubs/libcuda.so' (see
).

This amends PR65099 commit a92defdab79a1268f4b9dcf42b937e4002a4cf15 (r225560)
"[nvptx offloading] Only 64-bit configurations are currently supported" to
match the way we're doing this for the HSA/GCN plugins.

	libgomp/
	PR libgomp/65099
	* plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
	configurations.
	* configure: Regenerate.
	* plugin/plugin-nvptx.c (nvptx_get_num_devices): Remove 64-bit
	check.
---
 libgomp/configure | 86 +++-
 libgomp/plugin/configfrag.ac  | 92 ---
 libgomp/plugin/plugin-nvptx.c |  9 
 3 files changed, 105 insertions(+), 82 deletions(-)

diff --git a/libgomp/configure b/libgomp/configure
index 89c17c571b7..48bf8e4a72c 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15272,21 +15272,30 @@ if test x"$enable_offload_targets" != x; then
 	tgt_plugin=intelmic
 	;;
   nvptx*)
-	tgt_plugin=nvptx
-	PLUGIN_NVPTX=$tgt
-	if test "x$CUDA_DRIVER_LIB" != xno \
-	   && test "x$CUDA_DRIVER_LIB" != xno; then
-	  PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS
-	  PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS
-	  PLUGIN_NVPTX_LIBS='-lcuda'
-
-	  PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS
-	  CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS"
-	  PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS
-	  LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS"
-	  PLUGIN_NVPTX_save_LIBS=$LIBS
-	  LIBS="$PLUGIN_NVPTX_LIBS $LIBS"
-	  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+	case "${target}" in
+	  aarch64*-*-* | powerpc64le-*-* | x86_64-*-*)
+	case " ${CC} ${CFLAGS} " in
+	  *" -m32 "* | *" -mx32 "*)
+		# PR libgomp/65099: Currently, we only support offloading in
+		# 64-bit configurations.
+		PLUGIN_NVPTX=0
+		;;
+	  *)
+		tgt_plugin=nvptx
+		PLUGIN_NVPTX=$tgt
+		if test "x$CUDA_DRIVER_LIB" != xno \
+		   && test "x$CUDA_DRIVER_LIB" != xno; then
+		  PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS
+		  PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS
+		  PLUGIN_NVPTX_LIBS='-lcuda'
+
+		  PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS
+		  CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS"
+		  PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS
+		  LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS"
+		  PLUGIN_NVPTX_save_LIBS=$LIBS
+		  LIBS="$PLUGIN_NVPTX_LIBS $LIBS"
+		  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 #include "cuda.h"
 int
@@ -15302,28 +15311,35 @@ if ac_fn_c_try_link "$LINENO"; then :
 fi
 rm -f core conftest.err conftest.$ac_objext \
 conftest$ac_exeext conftest.$ac_ext
-	  CPPFLAGS=$PLUGIN_NVPTX_save_CPPFLAGS
-	  LDFLAGS=$PLUGIN_NVPTX_save_LDFLAGS

Re: [Patch, RFC] PR fortran/93340 - [8/9/10/11 Regression] fix missed substring simplifications

[Paul Richard Thomas via Gcc-patches]

Hi Harald,

It looks OK to me. I can see why you are asking about the implementation
but cannot offer a better solution.

OK for master.

Thanks

Paul


On Tue, 12 Jan 2021 at 22:03, Harald Anlauf via Fortran 
wrote:

> Dear all,
>
> when playing around with the issues exposed by PR93340, particularly
> visible
> in the tree dump, I tried to find ways to simplify substrings in those
> cases
> where they are eligible as designator, which is required e.g. in DATA
> statements.
>
> Given my limited understanding, I finally arrived at a potential solution
> which
> does that simplification near the end of match_string_constant in
> primary.c.
> I couldn't find a better place, but I am open to better suggestions.
>
> The simplification below does an even better job at detecting invalid
> substring
> starting or ending indices than HEAD, and regtests cleanly on
> x86_64-pc-linux-gnu.
>
> Feedback appreciated.  Is this potentially ok for master, or should this
> be done
> differently?
>
> Thanks,
> Harald
>
>
> PR fortran/93340 - fix missed substring simplifications
>
> Substrings were not reduced early enough for use in initializations,
> such as DATA statements.  Add an early simplification for substrings
> with constant starting and ending points.
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (gfc_resolve_substring): Add prototype.
> * primary.c (match_string_constant): Simplify substrings with
> constant starting and ending points.
> * resolve.c: Rename resolve_substring to gfc_resolve_substring.
> (gfc_resolve_ref): Use renamed function gfc_resolve_substring.
>
> gcc/testsuite/ChangeLog:
>
> * substr_10.f90: New test.
> * substr_9.f90: New test.
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [PATCH] PR fortran/98661 - valgrind issues with error recovery

[Paul Richard Thomas via Gcc-patches]

Hi Harald,

That's OK for master.

Thanks

Paul


On Wed, 13 Jan 2021 at 21:25, Harald Anlauf via Fortran 
wrote:

> Dear all,
>
> the former Fortran testcase charlen_03.f90, which some time ago used to
> ICE, could still display issues during error recovery.  As Dominique
> pointed out, this required either an instrumented compiler, or valgrind.
>
> The issue turned out to not have anything to do with CHARACTER, but
> with an invalid attempt resolve an invalid array specification.
>
> Regtested on x86_64-pc-linux-gnu, and checked for the testcase with
> valgrind.
>
> OK for master?
>
> Thanks,
> Harald
>
>
> PR fortran/98661 - valgrind issues with error recovery
>
> During error recovery after an invalid derived type specification it was
> possible to try to resolve an invalid array specification.  We now skip
> this if the component has the ALLOCATABLE or POINTER attribute and the
> shape is not deferred.
>
> gcc/fortran/ChangeLog:
>
> PR fortran/98661
> * resolve.c (resolve_component): Derived type components with
> ALLOCATABLE or POINTER attribute shall have a deferred shape.
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/98661
> * gfortran.dg/pr98661.f90: New test.
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

libgo patch committed: Update hurd support

[Ian Lance Taylor via Gcc-patches]

This libgo patch by Svante Signell updates the hurd support.  This
fixes GCC PR 98496.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
ab5bf5f728be354427a5b06784f34011fea555bc
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index cd95c3d0755..8cfc63248a7 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-255657dc8d61ab26121ca68f124412ef37599166
+fd5396b1af389a55d1e3612702cfdad6755084e9
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index 2e8c37e170d..6188725f73b 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -881,7 +881,7 @@ GOBENCH =
 CHECK = \
GC="$(GOC) $(GOCFLAGS) $($(subst /,_,$@)_GOCFLAGS) -L `${PWD_COMMAND}` 
-L `${PWD_COMMAND}`/.libs"; \
export GC; \
-   GOLIBS="$(extra_check_libs_$(subst .,_,$(subst /,_,$(@D 
$(MATH_LIBS) $(NET_LIBS) $(LIBS)"; \
+   GOLIBS="$(extra_check_libs_$(subst .,_,$(subst /,_,$(@D 
$(PTHREAD_LIBS) $(MATH_LIBS) $(NET_LIBS) $(LIBS)"; \
export GOLIBS; \
RUNTESTFLAGS="$(RUNTESTFLAGS)"; \
export RUNTESTFLAGS; \
diff --git a/libgo/Makefile.in b/libgo/Makefile.in
index 34b0e1d0056..daae4f842d7 100644
--- a/libgo/Makefile.in
+++ b/libgo/Makefile.in
@@ -1029,7 +1029,7 @@ GOBENCH =
 CHECK = \
GC="$(GOC) $(GOCFLAGS) $($(subst /,_,$@)_GOCFLAGS) -L `${PWD_COMMAND}` 
-L `${PWD_COMMAND}`/.libs"; \
export GC; \
-   GOLIBS="$(extra_check_libs_$(subst .,_,$(subst /,_,$(@D 
$(MATH_LIBS) $(NET_LIBS) $(LIBS)"; \
+   GOLIBS="$(extra_check_libs_$(subst .,_,$(subst /,_,$(@D 
$(PTHREAD_LIBS) $(MATH_LIBS) $(NET_LIBS) $(LIBS)"; \
export GOLIBS; \
RUNTESTFLAGS="$(RUNTESTFLAGS)"; \
export RUNTESTFLAGS; \
diff --git a/libgo/go/crypto/x509/root_hurd.go 
b/libgo/go/crypto/x509/root_hurd.go
index 59e9ff0c81b..a25b8a1bc08 100644
--- a/libgo/go/crypto/x509/root_hurd.go
+++ b/libgo/go/crypto/x509/root_hurd.go
@@ -9,3 +9,9 @@ package x509
 var certFiles = []string{
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
 }
+
+// Possible directories with certificate files; stop after successfully
+// reading at least one file from a directory.
+var certDirectories = []string{
+   "/etc/ssl/certs", // SLES10/SLES11, https://golang.org/issue/12139
+}
diff --git a/libgo/go/runtime/export_pipe2_test.go 
b/libgo/go/runtime/export_pipe2_test.go
index 9d580d33134..209c6b14a11 100644
--- a/libgo/go/runtime/export_pipe2_test.go
+++ b/libgo/go/runtime/export_pipe2_test.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build freebsd linux netbsd openbsd solaris
+// +build freebsd hurd linux netbsd openbsd solaris
 
 package runtime
 
diff --git a/libgo/go/runtime/nbpipe_test.go b/libgo/go/runtime/nbpipe_test.go
index 981143ec27b..d7c5d45c854 100644
--- a/libgo/go/runtime/nbpipe_test.go
+++ b/libgo/go/runtime/nbpipe_test.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build aix darwin dragonfly freebsd linux netbsd openbsd solaris
+// +build aix darwin dragonfly freebsd hurd linux netbsd openbsd solaris
 
 package runtime_test
 
diff --git a/libgo/go/runtime/os_hurd.go b/libgo/go/runtime/os_hurd.go
index 1613b410e2c..8bde23edb81 100644
--- a/libgo/go/runtime/os_hurd.go
+++ b/libgo/go/runtime/os_hurd.go
@@ -27,19 +27,19 @@ func libc_malloc(uintptr) unsafe.Pointer
 
 //go:noescape
 //extern sem_init
-func sem_init(sem *_sem_t, pshared int32, value uint32) int32
+func sem_init(sem *semt, pshared int32, value uint32) int32
 
 //go:noescape
 //extern sem_wait
-func sem_wait(sem *_sem_t) int32
+func sem_wait(sem *semt) int32
 
 //go:noescape
 //extern sem_post
-func sem_post(sem *_sem_t) int32
+func sem_post(sem *semt) int32
 
 //go:noescape
 //extern sem_timedwait
-func sem_timedwait(sem *_sem_t, timeout *timespec) int32
+func sem_timedwait(sem *semt, timeout *timespec) int32
 
 //go:noescape
 //extern clock_gettime
@@ -51,12 +51,12 @@ func semacreate(mp *m) {
return
}
 
-   var sem *_sem_t
+   var sem *semt
 
// Call libc's malloc rather than malloc. This will
// allocate space on the C heap. We can't call malloc
// here because it could cause a deadlock.
-   sem = (*_sem_t)(libc_malloc(unsafe.Sizeof(*sem)))
+   sem = (*semt)(libc_malloc(unsafe.Sizeof(*sem)))
if sem_init(sem, 0, 0) != 0 {
throw("sem_init")
}
@@ -86,7 +86,7 @@ func semasleep(ns int64) int32 {
ts.tv_sec = timespec_sec_t(sec)
ts.tv_nsec = timespec_nsec_t(nsec)
 
-   if sem_timedwait((*_sem_t)(unsafe.Pointer(_m_.waitsema)), ) 
!= 0 {
+   if sem_timedwait((*semt)(unsafe.Pointer(_m_.waitsema)), ) != 
0 {

Re: [PATCH] c-family: Improve MEM_REF printing for diagnostics [PR98597]

[Martin Sebor via Gcc-patches]

On 1/14/21 12:43 AM, Richard Biener wrote:

On Wed, 13 Jan 2021, Jakub Jelinek wrote:


Hi!

The following patch doesn't actually fix the print_mem_ref bugs, I've kept
it for now as broken as it was, but at least improves the cases where
we can unambiguously map back MEM[ + off] into some particular
reference (e.g. something.foo[1].bar etc.).
In the distant past I think we were folding such MEM_REFs back to
COMPONENT_REFs and ARRAY_REFs, but we've stopped doing that.


Yeah, because it has different semantics - *(((int *)t + 3)
accesses an int object while t.u.b accesses a 't' object from the TBAA
perspective.


  But for
diagnostics that is what the user actually want to see IMHO.
So on the attached testcase, instead of printing what is in left column
it prints what is in right column:
((int*)t) + 3   t.u.b
((int*)t) + 6   t.u.e.i
((int*)t) + 8   t.v
s + 1   s[1]


so while that's "nice" in general, for TBAA diagnostics it might actually
be misleading.

I wonder whether we absolutely need to print a C expression here.
We could print, instead of *((int *)t + 3), "access to a memory
object of type 'int' at offset 12 bytes from 't'", thus explain
in plain english.

That said, *((int *)t + 3) is exactly what the access is,
semantically.  There's the case of a mismatch of the access type
and the TBAA type which we cannot write down in C terms but maybe
we want to have a builtin for this?  __builtin_access (ptr, lvalue-type,
tbaa-type)?


Of course, print_mem_ref needs to be also fixed to avoid printing the
nonsense it is printing right now, t is a structure type, so it can't be
cast to int* in C and in C++ only using some user operator, and
the result of what it printed is a pointer, while the uninitialized reads
are int.

I was hoping Martin would fix that, but given his comment in the PR I think
I'll fix it myself tomorrow.

Anyway, this patch is useful on its own.  Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?


In the light of Martins patch this is probably reasonable but still
the general direction is wrong (which is why I didn't approve Martins
original patch).  I'm also somewhat disappointed we're breaking this
so late in the cycle.


So am I.  I didn't test this change as exhaustively as I could and
(in light of the poor test coverage) should have.  That's my bad.
FWIW, I did do it for the first patch (by instrumenting GCC and
formatting every MEM_REF it came across), but it didn't occur to
me to do it this time around.  I have now completed this testing
(it found one more ICE elsewhere that I'll fix soon).

That said, as I mentioned in the patch submission, most middle end
warnings don't format MEM_REFs.  -Wuninitialized is an outlier here.
Most middle end warnings about invalid accesses print the decl or
allocation call with either a type or size of the access, followed
by either an array index or a byte offset in to the target of
the access.  For consistency I'd like to converge most middle end
warnings on the same style (formatted by the same code).  When
that happens, the MEM_REF format should become much less important,
so I wouldn't invest too much effort into perfecting it.

Martin

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Segher Boessenkool]

On Thu, Jan 07, 2021 at 11:20:39AM -0300, Raoni Fassina Firmino wrote:
> On Wed, Nov 18, 2020 at 06:38:22AM -0600, Segher Boessenkool wrote:
> > We can handle the constants issue similarly to what we do for
> > __builtin_fpclassify, too.
> 
> I think that if we must safe-guard for future or unforeseen libc
> implementations doing what __builtin_fpclassify does is the way to go.
> I don't know what is the GCC police here, but IMHO I don't think we
> should add complexity before it is needed in this case.  And looking at
> __builtin_fpclassify, it seems a lot, IIUC this solution needs
> fixinclude to work, seems to me too much add maintenance for something
> that is not needed yet, because SPARC don't have this expands, none has
> for now.

This way the compiler does not need to know the values of the macros
*at all*, that is the whole point!  You simply pass all the standard
values to the builtin as extra arguments.  This may seem inconvenient
to use, but you put the whole thing in a header file anyway, all is
hidden.


Segher

[PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves

[Michael Meissner via Gcc-patches]

>From 84ae44abc7a79b9c2e6d9f18a30516d3e8f65b1f Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Wed, 13 Jan 2021 21:45:20 -0500
Subject: [PATCH 2/2] PowerPC: PR 97791: Do not set gnu attributes on moves

This patch eliminates the code in rs6000_emit_move to set the long double
attribute.  This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type.  However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.

This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works well.
This patch is highly desirable to be able to build a toolchain where the
default long double is IEEE 128-bit.  Can I check this patch into the master
branch for GCC 11?

gcc/
2021-01-14  Michael Meissner  

PR gcc/97791
* config/rs6000/rs6000.c (rs6000_emit_move): Delete code that sets
whether long double was passed based on the modes used in moves.

gcc/testsuite/
2021-01-14  Michael Meissner  

PR target/97791
* gcc.target/powerpc/gnuattr1.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr2.c: Mark as XFAIL.
* gcc.target/powerpc/gnuattr3.c: Mark as XFAIL.
---
 gcc/config/rs6000/rs6000.c  | 17 -
 gcc/testsuite/gcc.target/powerpc/gnuattr1.c |  9 +++--
 gcc/testsuite/gcc.target/powerpc/gnuattr2.c |  9 +++--
 gcc/testsuite/gcc.target/powerpc/gnuattr3.c |  9 +++--
 4 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 47a56912e27..6f48dd6566d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10077,23 +10077,6 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
   && GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
 gcc_unreachable ();
 
-#ifdef HAVE_AS_GNU_ATTRIBUTE
-  /* If we use a long double type, set the flags in .gnu_attribute that say
- what the long double type is.  This is to allow the linker's warning
- message for the wrong long double to be useful, even if the function does
- not do a call (for example, doing a 128-bit add on power9 if the long
- double type is IEEE 128-bit.  Do not set this if __ibm128 or __floa128 are
- used if they aren't the default long dobule type.  */
-  if (rs6000_gnu_attr && (HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT))
-{
-  if (TARGET_LONG_DOUBLE_128 && (mode == TFmode || mode == TCmode))
-   rs6000_passes_float = rs6000_passes_long_double = true;
-
-  else if (!TARGET_LONG_DOUBLE_128 && (mode == DFmode || mode == DCmode))
-   rs6000_passes_float = rs6000_passes_long_double = true;
-}
-#endif
-
   /* See if we need to special case SImode/SFmode SUBREG moves.  */
   if ((mode == SImode || mode == SFmode) && SUBREG_P (source)
   && rs6000_emit_move_si_sf_subreg (dest, source, mode))
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c 
b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
index cf46777849a..9c7680aabae 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr1.c
@@ -1,11 +1,16 @@
 /* { dg-do compile { target { powerpc*-linux-* } } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-O2 -mvsx -mlong-double-64" } */
-/* { dg-final { scan-assembler "gnu_attribute 4, 9" } } */
+/* { dg-final { scan-assembler "gnu_attribute 4, 9" {xfail *-*-*} } } */
 
 /* Check that if we can do the long double operation without doing an emulator
call, such as with 64-bit long double support, that we still set the
-   appropriate .gnu_attribute.  */
+   appropriate .gnu_attribute.
+
+   However, the code that did this in rs6000_emit_move has been removed because
+   it could not differentiate between long double and another type that uses
+   the same mode.  This test is marked as xfail until a gimple pass is added to
+   track the use of long double types.  */
 
 long double a;
 
diff --git a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c 
b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
index 32a4ba255a8..4ca60d63261 100644
--- a/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
+++ b/gcc/testsuite/gcc.target/powerpc/gnuattr2.c
@@ -1,13 +1,18 @@
 /* { dg-do compile { target { powerpc*-linux-* && lp64 } } } */
 /* 

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] PowerPC: PR 97791: Fix an issue with gnu attributes.

This patch patch fixes the problem that we set the GNU attribute for long
double if a type were passed or returned that uses the same representation as
the long double type (i.e. passing explicit __float128/_Float128 when long
double is IEEE 128-bit or passing __ibm128 when long double is IBM 128-bit).

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works well.
This patch is highly desirable to be able to build a toolchain where the
default long double is IEEE 128-bit.  Can I check this patch into the master
branch for GCC 11?

gcc/
2021-01-14  Michael Meissner  
Alan Modra  

PR gcc/97791
* config/rs6000/rs6000-call.c (init_cumulative_args): Only set
that long double was returned if the type is actually long
double.
(rs6000_function_arg_advance_1): Only set that long double was
passed if the type is actually long double.
---
 gcc/config/rs6000/rs6000-call.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..519313bc0d6 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -6554,12 +6554,14 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype,
  if (SCALAR_FLOAT_MODE_P (return_mode))
{
  rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function returns
+long double.  We do not mark if the function returns a type
+such as __ibm128 that uses the same modes as the current long
+double type, only if an actual long double type was used.  */
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (return_mode)
- || FLOAT128_IEEE_P (return_mode)
- || (return_type != NULL
- && (TYPE_MAIN_VARIANT (return_type)
- == long_double_type_node
+ && return_type != NULL
+ && TYPE_MAIN_VARIANT (return_type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed
@@ -6994,11 +6996,14 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS *cum, 
machine_mode mode,
   if (SCALAR_FLOAT_MODE_P (mode))
{
  rs6000_passes_float = true;
+
+ /* If GNU attributes are enabled, mark if the function passes long
+double.  We do not mark if the function returns a type such as
+__ibm128 that uses the same modes as the current long double type,
+only if an actual long double type was used.  */
  if ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)
- && (FLOAT128_IBM_P (mode)
- || FLOAT128_IEEE_P (mode)
- || (type != NULL
- && TYPE_MAIN_VARIANT (type) == long_double_type_node)))
+ && type != NULL
+ && TYPE_MAIN_VARIANT (type) == long_double_type_node)
rs6000_passes_long_double = true;
 
  /* Note if we passed or return a IEEE 128-bit type.  We changed the
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH 0/2] PowerPC: PR 97791: Fix attribute problems

[Michael Meissner via Gcc-patches]

There are many issues with the current implementation of GNU attributes to mark
functions that use long double.  The idea of .gnu_attributes was to mark
objects with ABI requirements.

The two patches in this thread fixes a small subset of the GNU attributes
problems.  It does not fix all of the problems.

The first patch fixes the problem that we set the GNU attribute for long double
if a type were passed or returned that uses the same representation as the long
double type (i.e. passing explicit __float128/_Float128 when long double is
IEEE 128-bit or passing __ibm128 when long double is IBM 128-bit).

The second patch eliminates the code in rs6000_emit_move to set the long double
attribute.  This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type.  However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.

This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.

The current problems with GNU attributes are:

1) Probably the most annoying bug is that they apply at an object level.
   So for example libgcc_s.so.1 is marked as using IBM long double causing
   warnings when linking against code that uses 64-bit long doubles even
   though such code won't use any of the libgcc 128-bit long double
   functions.

   a) Versions of ld prior to 2.35 did not check shared library
  .gnu_attributes, a bug that might allow a user to link a
  soft-float shared library with hard-float code.

2) The original implementation Alan Modra wrote in 2016 to mark relocatable
   object files with attributes had, and still has, bugs.

   a) It is possible for an object to be marked as using IBM long
  double when a function has a long double parameter that is not
  used.

   b) It is possible for an object to not be marked as using IBM long
  double when it does.  For example, a function with a pointer to
  long double parameter is not recognized as using long double.
  This is conceptually difficult to fix.  Does merely passing a
  pointer to another function constitute a use?  What about a
  pointer to a union containing a long double?

   c) An object that defines a global long double variables is not
  marked.

   d) Variable argument functions that process a long double in an
  argument corresponding to the ellipsis are not marked.

3) One of the problems with GNU attributes is that it would signal a long
   double was used when in reality an alternate type was returned or passed,
   such as passing __ibm128 or __float128 that just happens to use the same
   representation as the current long double type.  This is the bug being fixed
   in this patch.

4) In an attempt to fix some of these problems, Mike Meissner applied a patch
   to rs6000_emit_move that set the long double attribute whenever a move to or
   from a register involved a long double mode, but that has bugs too.

   a) With -mlong-double-64 an object that moves doubles to or from a
  register would by marked as using 64-bit long double.

   b) Functions that only use long double internally would wrongly
  cause their object to be marked with the long double attribute.

   c) 2c is not fixed by this patch, unless code in the object uses
  the global variable.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

[Jonathan Wakely via Gcc-patches]

On 14/01/21 17:10 +, Jonathan Wakely wrote:

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it 
impacts all _GLIBCXX_DEBUG iterators.


However unordered containers local_iterator was more complicated to 
handle. Because of c++/65816 I prefer to review 
_Node_iterator_default constructor to set _M_cur to nullptr even if 
in principle it is not necessary except for the _Local_iterator_base 
constructor when hash code is not cached.


    libstdc++: Implement N3644 for _GLIBCXX_DEBUG iterators

    libstdc++-v3/ChangeLog

            PR libstdc++/98466
            * include/bits/hashtable_policy.h 
(_Node_iterator_base()): Set _M_cur to nullptr.

            (_Node_iterator()): Make default.
            (_Node_const_iterator()): Make default.
            * include/debug/macros.h 
(__glibcxx_check_erae_range_after): Add _M_singular

            iterator checks.
            * include/debug/safe_iterator.h
            (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if both 
iterator are value initialized.
            * include/debug/safe_local_iterator.h 
(_GLIBCXX_DEBUG_VERIFY_OPERANDS):

            Likewise.
            * include/debug/safe_iterator.tcc 
(_Safe_iterator<>::_M_valid_range): Add

            _M_singular checks on input iterators.
            * src/c++11/debug.cc 
(_Safe_iterator_base::_M_can_compare): Remove _M_singular

            checks.
            * testsuite/23_containers/deque/debug/98466.cc: New test.
            * testsuite/23_containers/unordered_map/debug/98466.cc: 
New test.


Tested under Linux x86_64 normal and debug mode.

Ok to commit ?


Yes, thanks.


I've just realised that this C++14 change used to be noted in the
C++14 status table:


  
  
   http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3644.pdf;>
 N3644
   
  
  Null Forward Iterators
  Partial
  Only affects Debug Mode
 

But I removed that last year when replacing the list of proposals with
the Table of Contents taken from the standard, in commit
57ede05c6a0b443943e312bf205cb79233c9396f (oops!)

For the branches we should either document that missing feature in a
note, or backport your fix in a few weeks.

Re: [PATCH] libstdc++/98466 Fix _GLIBCXX_DEBUG N3644 integration

[Jonathan Wakely via Gcc-patches]

On 01/01/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I think the PR is not limited to unordered containers iterator, it 
impacts all _GLIBCXX_DEBUG iterators.


However unordered containers local_iterator was more complicated to 
handle. Because of c++/65816 I prefer to review _Node_iterator_default 
constructor to set _M_cur to nullptr even if in principle it is not 
necessary except for the _Local_iterator_base constructor when hash 
code is not cached.


    libstdc++: Implement N3644 for _GLIBCXX_DEBUG iterators

    libstdc++-v3/ChangeLog

            PR libstdc++/98466
            * include/bits/hashtable_policy.h (_Node_iterator_base()): 
Set _M_cur to nullptr.

            (_Node_iterator()): Make default.
            (_Node_const_iterator()): Make default.
            * include/debug/macros.h 
(__glibcxx_check_erae_range_after): Add _M_singular

            iterator checks.
            * include/debug/safe_iterator.h
            (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Accept if both iterator 
are value initialized.
            * include/debug/safe_local_iterator.h 
(_GLIBCXX_DEBUG_VERIFY_OPERANDS):

            Likewise.
            * include/debug/safe_iterator.tcc 
(_Safe_iterator<>::_M_valid_range): Add

            _M_singular checks on input iterators.
            * src/c++11/debug.cc 
(_Safe_iterator_base::_M_can_compare): Remove _M_singular

            checks.
            * testsuite/23_containers/deque/debug/98466.cc: New test.
            * testsuite/23_containers/unordered_map/debug/98466.cc: 
New test.


Tested under Linux x86_64 normal and debug mode.

Ok to commit ?


Yes, thanks.

One question about the deque test ...



diff --git a/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc 
b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc
new file mode 100644
index 000..720977e5622
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/debug/98466.cc
@@ -0,0 +1,38 @@
+// Copyright (C) 2021 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }


Does this need to be limited to c++11 and later? Could it just use
{ dg-do run } instead?

OK to commit anyway, thanks.

[PATCH] PowerPC: Add float128/Decimal conversions.

[Michael Meissner via Gcc-patches]

[PATCH] PowerPC: Add float128/Decimal conversions.

This patch replaces the following two patches:

September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>

October 22nd, 2020:
Message-ID: <2020100603.ga11...@ibm-toto.the-meissners.org>

This patch rewrites those patches.  In order to run with older GLIBC's, this
patch uses weak references to the IEEE 128-bit conversions to/from string that
are found in GLIBC 2.32.

If the user uses GLIBC 2.32 or later, the Decimal <-> Float128 conversions will
call the functions in that library.  This isn't ideal, as IEEE 128-bit has more
exponent range than IBM 128-bit.

If an older library is used, these patches will convert IEEE 128-bit to IBM
128-bit and do the conversion with IBM 128-bit.  I have tested this with a
compiler configured to use an older library, and it worked for the conversion
if the number could be represented in the IBM 128-bit format.

While most of the Decimal <-> Long double tests now pass when long doubles are
IEEE 128-bit, there are two tests that fails:

*   c-c++-common/dfp/convert-bfp-6.c
*   c-c++-common/dfp/convert-bfp-11.c

I have patches for the bfp-11 test (which requires that long double be IBM
128-bit).  I have not looked at the bfp-6 test but I will shortly.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

libgcc/
2021-01-14  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
---
 libgcc/config/rs6000/_dd_to_kf.c | 37 ++
 libgcc/config/rs6000/_kf_to_dd.c | 37 ++
 libgcc/config/rs6000/_kf_to_sd.c | 37 ++
 libgcc/config/rs6000/_kf_to_td.c | 37 ++
 libgcc/config/rs6000/_sd_to_kf.c | 37 ++
 libgcc/config/rs6000/_sprintfkf.c| 57 
 libgcc/config/rs6000/_sprintfkf.h| 28 ++
 libgcc/config/rs6000/_strtokf.c  | 56 +++
 libgcc/config/rs6000/_strtokf.h  | 27 +
 libgcc/config/rs6000/_td_to_kf.c | 37 ++
 libgcc/config/rs6000/quad-float128.h |  8 
 libgcc/config/rs6000/t-float128  | 37 +-
 libgcc/dfp-bit.c | 12 +-
 libgcc/dfp-bit.h | 26 +
 14 files changed, 470 insertions(+), 3 deletions(-)
 create mode 100644 libgcc/config/rs6000/_dd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_kf_to_dd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_sd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_td.c
 create mode 100644 libgcc/config/rs6000/_sd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_sprintfkf.c
 create mode 100644 libgcc/config/rs6000/_sprintfkf.h
 create mode 100644 libgcc/config/rs6000/_strtokf.c
 create mode 100644 libgcc/config/rs6000/_strtokf.h
 create mode 100644 

Re: [PATCH] libstdc++: c++2b, implement WG21 P1679R3

[Jonathan Wakely via Gcc-patches]

On 13/01/21 01:21 +, Paul Fee via Libstdc++ wrote:

Add contains member function to basic_string_view and basic_string.

The new method is enabled for -std=gnu++20, gnu++2b and c++2b.  This allows
users to access the method as a GNU extension to C++20.  The conditional
test may be reduced to "__cplusplus > 202011L" once GCC has a c++2b switch.


Thanks for the patch.

A few comments below.


diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index e272d332934..a569ecd8c08 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3073,6 +3073,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
  { return __sv_type(this->data(), this->size()).ends_with(__x); }
#endif // C++20

+#if __cplusplus > 202011L || \
+  (__cplusplus == 202002L && !defined __STRICT_ANSI__)


Please put the line break before the binary operator i.e.

#if __cplusplus > 202011L \
  || (__cplusplus == 202002L && !defined __STRICT_ANSI__)

This has the advantage that the operator is at a predictable place,
so it's easier to see at a glance whether this is an && or ||
condition.


+  bool
+  contains(basic_string_view<_CharT, _Traits> __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(_CharT __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(const _CharT* __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+#endif // C++23
+
  // Allow basic_stringbuf::__xfer_bufptrs to call _M_length:
  template friend class basic_stringbuf;
};
@@ -5998,6 +6013,21 @@ _GLIBCXX_END_NAMESPACE_CXX11
  { return __sv_type(this->data(), this->size()).ends_with(__x); }
#endif // C++20

+#if __cplusplus > 202011L || \
+  (__cplusplus == 202002L && !defined __STRICT_ANSI__)
+  bool
+  contains(basic_string_view<_CharT, _Traits> __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(_CharT __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+
+  bool
+  contains(const _CharT* __x) const noexcept
+  { return __sv_type(this->data(), this->size()).contains(__x); }
+#endif // C++23
+
# ifdef _GLIBCXX_TM_TS_INTERNAL
  friend void
  ::_txnal_cow_string_C1_for_exceptions(void* that, const char* s,
diff --git a/libstdc++-v3/include/std/string_view
b/libstdc++-v3/include/std/string_view
index e33e1bc4b79..2f47ef6ed12 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -352,6 +352,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { return this->ends_with(basic_string_view(__x)); }
#endif // C++20

+#if __cplusplus > 202011L || \
+  (__cplusplus == 202002L && !defined __STRICT_ANSI__)
+#define __cpp_lib_string_contains 202011L


This macro should also be defined in , and should depend on
the same conditions.

There should also be tests that the macro is defined by 
and by .

You can add this to the top of any one of the new tests for
string_view::contains:

#ifndef __cpp_lib_string_contains
# error "Feature-test macro for contains missing in "
#elif __cpp_lib_string_contains != 202011L
# error "Feature-test macro for contains has wrong value in "
#endif

And then add a new version.cc test adjacent to that file, which
includes  (and nothing else) and tests the same conditions:

#include 

#ifndef __cpp_lib_string_contains
# error "Feature-test macro for contains missing in "
#elif __cpp_lib_string_contains != 202011L
# error "Feature-test macro for contains has wrong value in "
#endif




+  constexpr bool
+  contains(basic_string_view __x) const noexcept
+  { return this->find(__x) != npos; }
+
+  constexpr bool
+  contains(_CharT __x) const noexcept
+  { return this->find(__x) != npos; }
+
+  constexpr bool
+  contains(const _CharT* __x) const noexcept
+  { return this->find(__x) != npos; }
+#endif // C++23
+
  // [string.view.find], searching

  constexpr size_type
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/char/1.cc
b/libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/char/1.cc
new file mode 100644
index 000..5d81dcee0ad
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/char/1.cc
@@ -0,0 +1,65 @@
+// { dg-options "-std=gnu++2b" }
+// { dg-do run { target c++2b } }
+
+// Copyright (C) 2018-2020 Free Software Foundation, Inc.


These dates should be 2021 only.



diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/wchar_t/1.cc
b/libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/wchar_t/1.cc
new file mode 100644
index 000..21196add4dc
--- /dev/null
+++ 

[PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

[Michael Meissner via Gcc-patches]

>From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
From: Michael Meissner 
Date: Wed, 13 Jan 2021 21:47:03 -0500
Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-ins.

This patch replaces patches previously submitted:

September 24th, 2020:
Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>

October 9th, 2020:
Message-ID: <20201009043543.ga11...@ibm-toto.the-meissners.org>

October 24th, 2020:
Message-ID: <2020100346.ga8...@ibm-toto.the-meissners.org>

November 19th, 2020:
Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org>

This patch maps the built-in functions that take or return long double
arguments on systems where long double is IEEE 128-bit.

If long double is IEEE 128-bit, this patch goes through the built-in functions
and changes the name of the math, scanf, and printf built-in functions to use
the functions that GLIBC provides when long double uses the IEEE 128-bit
representation.

In addition, changing the name in GCC allows the Fortran compiler to
automatically use the correct name.

To map the math functions, typically this patch changes l to
__ieee128.  However there are some exceptions that are handled with this
patch.

To map the printf functions,  is mapped to __ieee128.

To map the scanf functions,  is mapped to __isoc99_ieee128.

I have tested this patch by doing builds, bootstraps, and make check with 3
builds on a power9 little endian server:

*   Build one used the default long double being IBM 128-bit;
*   Build two set the long double default to IEEE 128-bit; (and)
*   Build three set the long double default to 64-bit.

The compilers built fine providing I recompiled gmp, mpc, and mpfr with the
appropriate long double options.  There were a few differences in the test
suite runs that will be addressed in later patches, but over all it works
well.  This patch is required to be able to build a toolchain where the default
long double is IEEE 128-bit.  Can I check this patch into the master branch for
GCC 11?

gcc/
2021-01-14  Michael Meissner  

* config/rs6000/rs6000.c (ieee128_builtin_name): New function.
(built_in_uses_long_double): New function.
(identifier_ends_in_suffix): New function.
(rs6000_mangle_decl_assembler_name): Update support for mapping built-in
function names for long double built-in functions if long double is
IEEE 128-bit to catch all of the built-in functions that take or
return long double arguments.

gcc/testsuite/
2021-01-14  Michael Meissner  

* gcc.target/powerpc/float128-longdouble-math.c: New test.
* gcc.target/powerpc/float128-longdouble-stdio.c: New test.
* gcc.target/powerpc/float128-math.c: Adjust test for new name
being generated.  Add support for running test on power10.  Add
support for running if long double defaults to 64-bits.
---
 gcc/config/rs6000/rs6000.c| 239 --
 .../powerpc/float128-longdouble-math.c| 442 ++
 .../powerpc/float128-longdouble-stdio.c   |  36 ++
 .../gcc.target/powerpc/float128-math.c|  16 +-
 4 files changed, 694 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-math.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 6f48dd6566d..282703b9715 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27100,6 +27100,172 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
 #endif
 
 
+/* If long double uses the IEEE 128-bit representation, return the name used
+   within GLIBC for the IEEE 128-bit long double built-in, instead of the
+   default IBM 128-bit long double built-in.  Or return NULL if the built-in
+   function does not use long double.  */
+
+static const char *
+ieee128_builtin_name (built_in_function fn)
+{
+  switch (fn)
+{
+default:   return NULL;
+case BUILT_IN_ACOSHL:  return "__acoshieee128";
+case BUILT_IN_ACOSL:   return "__acosieee128";
+case BUILT_IN_ASINHL:  return "__asinhieee128";
+case BUILT_IN_ASINL:   return "__asinieee128";
+case BUILT_IN_ATAN2L:  return "__atan2ieee128";
+case BUILT_IN_ATANHL:  return "__atanhieee128";
+case BUILT_IN_ATANL:   return "__atanieee128";
+case BUILT_IN_CABSL:   return "__cabsieee128";
+case BUILT_IN_CACOSHL: return "__cacoshieee128";
+case BUILT_IN_CACOSL:  return "__cacosieee128";
+case BUILT_IN_CARGL:   return "__cargieee128";
+case BUILT_IN_CASINHL: return "__casinhieee128";
+case BUILT_IN_CASINL:  return "__casinieee128";
+case BUILT_IN_CATANHL: return "__catanhieee128";
+case BUILT_IN_CATANL:  return "__catanieee128";
+case BUILT_IN_CBRTL:   return "__cbrtieee128";
+case BUILT_IN_CCOSHL:  return 

[committed] libstdc++: Define function to throw filesystem_error [PR 98471]

[Jonathan Wakely via Gcc-patches]

Fix ordering problem on Windows targets where filesystem_error was used
before being defined.

libstdc++-v3/ChangeLog:

PR libstdc++/98471
* include/bits/fs_path.h (__throw_conversion_error): New
function to throw or abort on character conversion errors.
(__wstr_from_utf8): Move definition after filesystem_error has
been defined. Use __throw_conversion_error.
(path::_S_convert<_EcharT>): Use __throw_conversion_error.
(path::_S_str_convert<_CharT, _Traits, _Allocator>): Likewise.
(path::u8string): Likewise.

Tested x86_64-linux and x86_64-mingw64. Committed to trunk.

commit 57a4f5e4eacfbbbd0ca5f1e3f946c27d63e2b533
Author: Jonathan Wakely 
Date:   Thu Jan 14 14:26:19 2021

libstdc++: Define function to throw filesystem_error [PR 98471]

Fix ordering problem on Windows targets where filesystem_error was used
before being defined.

libstdc++-v3/ChangeLog:

PR libstdc++/98471
* include/bits/fs_path.h (__throw_conversion_error): New
function to throw or abort on character conversion errors.
(__wstr_from_utf8): Move definition after filesystem_error has
been defined. Use __throw_conversion_error.
(path::_S_convert<_EcharT>): Use __throw_conversion_error.
(path::_S_str_convert<_CharT, _Traits, _Allocator>): Likewise.
(path::u8string): Likewise.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index 2897134c4c1..1645c53cf53 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -238,24 +238,6 @@ namespace __detail
return basic_string<_EcharT>(__first, __last);
 }
 
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-  template
-inline std::wstring
-__wstr_from_utf8(const _Tp& __str)
-{
-  static_assert(std::is_same_v);
-  std::wstring __wstr;
-  // XXX This assumes native wide encoding is UTF-16.
-  std::codecvt_utf8_utf16 __wcvt;
-  const auto __p = __str.data();
-  if (!__str_codecvt_in_all(__p, __p + __str.size(), __wstr, __wcvt))
-   _GLIBCXX_THROW_OR_ABORT(filesystem_error(
- "Cannot convert character sequence",
- std::make_error_code(errc::illegal_byte_sequence)));
-  return __wstr;
-}
-#endif
-
 } // namespace __detail
   /// @endcond
 
@@ -743,6 +725,37 @@ namespace __detail
 std::__shared_ptr _M_impl;
   };
 
+  /// @cond undocumented
+namespace __detail
+{
+  [[noreturn]] inline void
+  __throw_conversion_error()
+  {
+_GLIBCXX_THROW_OR_ABORT(filesystem_error(
+"Cannot convert character sequence",
+std::make_error_code(errc::illegal_byte_sequence)));
+  }
+
+#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  template
+inline std::wstring
+__wstr_from_utf8(const _Tp& __str)
+{
+  static_assert(std::is_same_v);
+  std::wstring __wstr;
+  // XXX This assumes native wide encoding is UTF-16.
+  std::codecvt_utf8_utf16 __wcvt;
+  const auto __p = __str.data();
+  if (!__str_codecvt_in_all(__p, __p + __str.size(), __wstr, __wcvt))
+   __detail::__throw_conversion_error();
+  return __wstr;
+}
+#endif
+
+} // namespace __detail
+  /// @endcond
+
+
   /** Create a path from a UTF-8-encoded sequence of char
*
* @relates std::filesystem::path
@@ -846,9 +859,7 @@ namespace __detail
  if (__str_codecvt_out_all(__f, __l, __str, __cvt))
return __str;
 #endif
- _GLIBCXX_THROW_OR_ABORT(filesystem_error(
-   "Cannot convert character sequence",
-   std::make_error_code(errc::illegal_byte_sequence)));
+ __detail::__throw_conversion_error();
}
 }
 
@@ -1058,9 +1069,7 @@ namespace __detail
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
   } }
 #endif
-  _GLIBCXX_THROW_OR_ABORT(filesystem_error(
-   "Cannot convert character sequence",
-   std::make_error_code(errc::illegal_byte_sequence)));
+  __detail::__throw_conversion_error();
 }
   /// @endcond
 
@@ -1097,9 +1106,7 @@ namespace __detail
 const value_type* __last = __first + _M_pathname.size();
 if (__str_codecvt_out_all(__first, __last, __str, __cvt))
   return __str;
-_GLIBCXX_THROW_OR_ABORT(filesystem_error(
- "Cannot convert character sequence",
- std::make_error_code(errc::illegal_byte_sequence)));
+__detail::__throw_conversion_error();
 #else
 return _M_pathname;
 #endif

[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS

[Paul Richard Thomas via Gcc-patches]

Hi All,

This patch was triggered by a thread on clf. Some years ago Tobias and I
discussed the remaining conditions where finalization should be triggered
and is not. Intrinsic assignment was one of the glaring omissions for which
implementation looked like a heavy lift job. As it happens, it wasn't too
bad :-)

Most of the work was suppressing partial finalization, as a prelude to
reallocation on assignment, and ensuring that finalization happened in the
right circumstances. gfc_assignment_finalizer_call does the work for
intrinsic assignment and is straightforward. Care has to be taken to place
the result between evaluation of the rhs and any reallocation of the lhs
that might occur.

I thought it to be a good idea to squeeze this in before Stage 4 and so the
testcase is not yet finished.I will post it separately once complete and
before pushing the patch. The process is a bit tedious since it involves
checking that the finalization is occurring at the correct point in the
assignment, that the results are consistent with my understanding of
7.5.6.3 and that another brand gives the same results.

Regtests on FC33/x86_64 - OK for master? It occurs to me that this should
also be backported to the 10-branch at very least.

Paul

Fortran:Implement finalization on intrinsic assignment [PR64290]

2021-01-14  Paul Thomas  

gcc/fortran
PR fortran/64290
* resolve.c (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
* trans-array.c (structure_alloc_comps): Add boolean argument
to suppress finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
* trans-array.h : Add the new boolean argument to the prototype
of gfc_deallocate_alloc_comp_no_caf with a default of false.
* trans-expr.c (gfc_trans_scalar_assign): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
(gfc_assignment_finalizer_call): New function to provide
finalization on intrinsic assignment.
(gfc_trans_assignment_1): Call it and add the block between the
rhs evaluation and any reallocation on assignment that there
might be.

gcc/testsuite/
PR fortran/64290
* gfortran.dg/finalize_38.f90 : New test.
* gfortran.dg/allocate_with_source_16.f90 : The number of final
calls goes down from 6 to 4.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index f243bd185b0..05f52185b8b 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -10415,6 +10415,10 @@ resolve_where (gfc_code *code, gfc_expr *mask)
 	  if (e && !resolve_where_shape (cnext->expr1, e))
 	   gfc_error ("WHERE assignment target at %L has "
 			  "inconsistent shape", >expr1->where);
+
+	  if (cnext->op == EXEC_ASSIGN)
+		cnext->expr1->must_finalize = 1;
+
 	  break;
 
 
@@ -10502,6 +10506,10 @@ gfc_resolve_where_code_in_forall (gfc_code *code, int nvar,
 	/* WHERE assignment statement */
 	case EXEC_ASSIGN:
 	  gfc_resolve_assign_in_forall (cnext, nvar, var_expr);
+
+	  if (cnext->op == EXEC_ASSIGN)
+		cnext->expr1->must_finalize = 1;
+
 	  break;
 
 	/* WHERE operator assignment statement */
@@ -10548,6 +10556,10 @@ gfc_resolve_forall_body (gfc_code *code, int nvar, gfc_expr **var_expr)
 	case EXEC_ASSIGN:
 	case EXEC_POINTER_ASSIGN:
 	  gfc_resolve_assign_in_forall (c, nvar, var_expr);
+
+	  if (c->op == EXEC_ASSIGN)
+	c->expr1->must_finalize = 1;
+
 	  break;
 
 	case EXEC_ASSIGN_CALL:
@@ -11947,6 +11959,9 @@ start:
 	  && code->expr1->ts.u.derived->attr.defined_assign_comp)
 	generate_component_assignments (, ns);
 
+	  if (code->op == EXEC_ASSIGN)
+	code->expr1->must_finalize = 1;
+
 	  break;
 
 	case EXEC_LABEL_ASSIGN:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 4bd4db877bd..8ac6b9e88fb 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8661,7 +8661,7 @@ static gfc_actual_arglist *pdt_param_list;
 static tree
 structure_alloc_comps (gfc_symbol * der_type, tree decl,
 		   tree dest, int rank, int purpose, int caf_mode,
-		   gfc_co_subroutines_args *args)
+		   gfc_co_subroutines_args *args, bool no_finalization)
 {
   gfc_component *c;
   gfc_loopinfo loop;
@@ -8749,11 +8749,12 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
 	 gfc_conv_array_data (dest));
 	  dref = gfc_build_array_ref (tmp, index, NULL);
 	  tmp = structure_alloc_comps (der_type, vref, dref, rank,
-   COPY_ALLOC_COMP, caf_mode, args);
+   COPY_ALLOC_COMP, caf_mode, args,
+   no_finalization);
 	}
   else
 	tmp = structure_alloc_comps (der_type, vref, NULL_TREE, rank, purpose,
- caf_mode, args);
+ caf_mode, args, no_finalization);
 
   gfc_add_expr_to_block (, tmp);
 
@@ -8787,13 +8788,15 @@ 

[PATCH][pushed] gcov: add one more pytest

[Martin Liška]

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov-17.C: New test.
* g++.dg/gcov/test-gcov-17.py: New test.
---
 gcc/testsuite/g++.dg/gcov/gcov-17.C   | 40 +++
 gcc/testsuite/g++.dg/gcov/test-gcov-17.py | 37 +
 2 files changed, 77 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-17.C
 create mode 100644 gcc/testsuite/g++.dg/gcov/test-gcov-17.py

diff --git a/gcc/testsuite/g++.dg/gcov/gcov-17.C 
b/gcc/testsuite/g++.dg/gcov/gcov-17.C
new file mode 100644
index 000..d11883cfd39
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gcov/gcov-17.C
@@ -0,0 +1,40 @@
+/* { dg-options "--coverage -std=c++11" } */
+/* { dg-do run { target native } } */
+
+template  class Foo
+{
+public:
+  Foo () : b (1000) {}
+
+  void inc () { b++; }
+
+private:
+  int b;
+};
+
+template class Foo;
+template class Foo;
+
+int
+main (void)
+{
+  int i, total;
+  Foo counter;
+
+  counter.inc ();
+  counter.inc ();
+  total = 0;
+
+  for (i = 0; i < 10; i++)
+total += i;
+
+  int v = total > 100 ? 1 : 2;
+
+  if (total != 45)
+__builtin_printf ("Failure\n");
+  else
+__builtin_printf ("Success\n");
+  return 0;
+}
+
+/* { dg-final { run-gcov-pytest gcov-17.C "test-gcov-17.py" } } */
diff --git a/gcc/testsuite/g++.dg/gcov/test-gcov-17.py 
b/gcc/testsuite/g++.dg/gcov/test-gcov-17.py
new file mode 100644
index 000..ec5df3dec03
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gcov/test-gcov-17.py
@@ -0,0 +1,37 @@
+from gcov import gcov_from_env
+
+import pytest
+
+
+@pytest.fixture(scope='function', autouse=True)
+def gcov():
+return gcov_from_env()
+
+
+def test_basics(gcov):
+files = gcov['files']
+assert len(files) == 1
+functions = files[0]['functions']
+assert len(functions) == 5
+
+
+def test_lines(gcov):
+lines = gcov['files'][0]['lines']
+linesdict = {}
+for line in lines:
+lineno = int(line['line_number'])
+linesdict.setdefault(lineno, [])
+linesdict[lineno].append(line)
+
+line9 = linesdict[9]
+assert len(line9) == 2
+assert line9[0]['function_name'] == '_ZN3FooIcE3incEv'
+assert line9[1]['function_name'] == '_ZN3FooIiE3incEv'
+assert line9[0]['count'] == 0
+assert line9[1]['count'] == 2
+assert line9[0]['unexecuted_block']
+assert not line9[1]['unexecuted_block']
+assert linesdict[31][0]['unexecuted_block']
+assert linesdict[34][0]['unexecuted_block']
+assert not linesdict[37][0]['unexecuted_block']
+assert 32 not in linesdict
--
2.29.2

[PATCH][pushed] mklog: skip unsupported files

[Martin Liška]

This fixes an infinite loop one could see for:
git show b87ec922c40 | ./contrib/mklog.py

contrib/ChangeLog:

* mklog.py: Fix infinite loop for unsupported files.
---
 contrib/mklog.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index bf51e56337e..a70536a6849 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -133,6 +133,9 @@ def generate_changelog(data, no_functions=False, 
fill_pr_titles=False):
 diff = PatchSet(data)
 
 for file in diff:

+# skip files that can't be parsed
+if file.path == '/dev/null':
+continue
 changelog = find_changelog(file.path)
 if changelog not in changelogs:
 changelogs[changelog] = []
--
2.29.2

Re: [PATCH] RTEMS: Fix Ada build for riscv

[Arnaud Charlet]

This is OK, thanks.

> gcc/ada/
> 
>   PR ada/98595
>   Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use
>   wraplf version of Aux_Long_Long_Float.
> ---
>  gcc/ada/Makefile.rtl | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
> index 81df1e8babc..35faf13ea46 100644
> --- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile.rtl
> @@ -2168,11 +2168,16 @@ ifeq ($(strip $(filter-out rtems%,$(target_os))),)
>s-tpopsp.adbs-stchop.adbs-interr.adb +
>ifeq ($(strip $(filter-out arm%, $(target_cpu))),)
>  EH_MECHANISM=-arm
>else
>  EH_MECHANISM=-gcc
>endif
> +
> +  ifeq ($(strip $(filter-out riscv%,$(target_cpu))),)
> +LIBGNAT_TARGET_PAIRS += a-nallfl.ads +  endif
>  endif
>  
>  # PikeOS
> -- 
> 2.26.2
> 

[PATCH] RTEMS: Fix Ada build for riscv

[Sebastian Huber]

gcc/ada/

PR ada/98595
Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use
wraplf version of Aux_Long_Long_Float.
---
 gcc/ada/Makefile.rtl | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
index 81df1e8babc..35faf13ea46 100644
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -2168,11 +2168,16 @@ ifeq ($(strip $(filter-out rtems%,$(target_os))),)
   s-tpopsp.adb

[PATCH] i386: Resolve variable shadowing in i386-options.c [PR98671]

[Uros Bizjak via Gcc-patches]

Also change global variable pta_size to unsigned.

2021-01-14  Uroš Bizjak  

gcc/
PR target/98671
* config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
Remove declaration and initialization of shadow variable "ret".
(ix86_option_override_internal): Remove declaration of
shadow variable "i".  Redeclare shadowed variable to unsigned.
* common/config/i386/i386-common.c (pta_size): Redeclare to unsigned.
* config/i386/i386-builtins.c (get_builtin_code_for_version):
Update for redeclaration.
* config/i386/i386.h (pta_size): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu{,-m32}.

Pushed to mainline.

Uros.
diff --git a/gcc/common/config/i386/i386-common.c 
b/gcc/common/config/i386/i386-common.c
index 00843d4bd93..eea8af12f48 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -2051,7 +2051,7 @@ const pta processor_alias_table[] =
 };
 
 /* NB: processor_alias_table stops at the "generic" entry.  */
-int const pta_size = ARRAY_SIZE (processor_alias_table) - 6;
+unsigned int const pta_size = ARRAY_SIZE (processor_alias_table) - 6;
 unsigned int const num_arch_names = ARRAY_SIZE (processor_alias_table);
 
 /* Provide valid option values for -march and -mtune options.  */
diff --git a/gcc/config/i386/i386-builtins.c b/gcc/config/i386/i386-builtins.c
index 5b37fc7b75e..4fcdf4b89ee 100644
--- a/gcc/config/i386/i386-builtins.c
+++ b/gcc/config/i386/i386-builtins.c
@@ -1888,7 +1888,7 @@ get_builtin_code_for_version (tree decl, tree 
*predicate_list)
   gcc_assert (new_target);
   
   if (new_target->arch_specified && new_target->arch > 0)
-   for (i = 0; i < (unsigned int) pta_size; i++)
+   for (i = 0; i < pta_size; i++)
  if (processor_alias_table[i].processor == new_target->arch)
{
  const pta *arch_info = _alias_table[i];
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 4e0165ff32c..6819a042389 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -1088,8 +1088,6 @@ ix86_valid_target_attribute_inner_p (tree fndecl, tree 
args, char *p_strings[],
   /* If this is a list, recurse to get the options.  */
   if (TREE_CODE (args) == TREE_LIST)
 {
-  bool ret = true;
-
   for (; args; args = TREE_CHAIN (args))
if (TREE_VALUE (args)
&& !ix86_valid_target_attribute_inner_p (fndecl, TREE_VALUE (args),
@@ -1782,7 +1780,7 @@ ix86_option_override_internal (bool main_args_p,
   struct gcc_options *opts,
   struct gcc_options *opts_set)
 {
-  int i;
+  unsigned int i;
   unsigned HOST_WIDE_INT ix86_arch_mask;
   const bool ix86_tune_specified = (opts->x_ix86_tune_string != NULL);
 
@@ -2852,7 +2850,7 @@ ix86_option_override_internal (bool main_args_p,
 {
   char *p = ASTRDUP (opts->x_ix86_recip_name);
   char *q;
-  unsigned int mask, i;
+  unsigned int mask;
   bool invert;
 
   while ((q = strtok (p, ",")) != NULL)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index f032746d222..272b1957b47 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2562,7 +2562,7 @@ public:
 };
 
 extern const pta processor_alias_table[];
-extern int const pta_size;
+extern unsigned int const pta_size;
 extern unsigned int const num_arch_names;
 #endif
 

Re: [PATCH] x86: Error on -fcf-protection with incompatible target

[H.J. Lu via Gcc-patches]

On Thu, Jan 14, 2021 at 6:51 AM Uros Bizjak  wrote:
>
> On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu  wrote:
> >
> > -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
> > ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
> > processors.  Issue an error for -fcf-protection with CF_BRANCH when
> > compiling for 32-bit non-TARGET_CMOVE targets.
> >
> > gcc/
> >
> > PR target/98667
> > * config/i386/i386-options.c (ix86_option_override_internal):
> > Issue an error for -fcf-protection with CF_BRANCH when compiling
> > for 32-bit non-TARGET_CMOVE targets.
> >
> > gcc/testsuite/
> >
> > PR target/98667
> > * gcc.target/i386/pr98667-1.c: New file.
> > * gcc.target/i386/pr98667-2.c: Likewise.
> > * gcc.target/i386/pr98667-3.c: Likewise.
> > ---
> >  gcc/config/i386/i386-options.c| 9 -
> >  gcc/testsuite/gcc.target/i386/pr98667-1.c | 9 +
> >  gcc/testsuite/gcc.target/i386/pr98667-2.c | 9 +
> >  gcc/testsuite/gcc.target/i386/pr98667-3.c | 7 +++
> >  4 files changed, 33 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-3.c
> >
> > diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> > index 4e0165ff32c..1489871b36f 100644
> > --- a/gcc/config/i386/i386-options.c
> > +++ b/gcc/config/i386/i386-options.c
> > @@ -3016,8 +3016,15 @@ ix86_option_override_internal (bool main_args_p,
> >  }
> >
> >if (opts->x_flag_cf_protection != CF_NONE)
> > -opts->x_flag_cf_protection
> > +{
> > +  if ((opts->x_flag_cf_protection & CF_BRANCH) == CF_BRANCH
> > + && !TARGET_64BIT
> > + && !TARGET_CMOVE)
>
> You need TARGET_CMOV (note, no E) here. Also, please put both tests on one 
> line.
>
> LGTM with the above change.

This is the patch I am checking in.

Thanks.

-- 
H.J.
From c5ba570aeb0985f99ba2f723a4bc3f01801cf555 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 14 Jan 2021 05:56:46 -0800
Subject: [PATCH] x86: Error on -fcf-protection with incompatible target

-fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOV
processors.  Issue an error for -fcf-protection with CF_BRANCH when
compiling for 32-bit non-TARGET_CMOV targets.

gcc/

	PR target/98667
	* config/i386/i386-options.c (ix86_option_override_internal):
	Issue an error for -fcf-protection with CF_BRANCH when compiling
	for 32-bit non-TARGET_CMOV targets.

gcc/testsuite/

	PR target/98667
	* gcc.target/i386/pr98667-1.c: New file.
	* gcc.target/i386/pr98667-2.c: Likewise.
	* gcc.target/i386/pr98667-3.c: Likewise.
---
 gcc/config/i386/i386-options.c| 8 +++-
 gcc/testsuite/gcc.target/i386/pr98667-1.c | 9 +
 gcc/testsuite/gcc.target/i386/pr98667-2.c | 9 +
 gcc/testsuite/gcc.target/i386/pr98667-3.c | 7 +++
 4 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-3.c

diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 4e0165ff32c..d62cd6f661a 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -3016,8 +3016,14 @@ ix86_option_override_internal (bool main_args_p,
 }
 
   if (opts->x_flag_cf_protection != CF_NONE)
-opts->x_flag_cf_protection
+{
+  if ((opts->x_flag_cf_protection & CF_BRANCH) == CF_BRANCH
+	  && !TARGET_64BIT && !TARGET_CMOV)
+	error ("%<-fcf-protection%> is not compatible with this target");
+
+  opts->x_flag_cf_protection
   = (cf_protection_level) (opts->x_flag_cf_protection | CF_SET);
+}
 
   if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
 SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 256);
diff --git a/gcc/testsuite/gcc.target/i386/pr98667-1.c b/gcc/testsuite/gcc.target/i386/pr98667-1.c
new file mode 100644
index 000..5bf0c9285a8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98667-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -fcf-protection -march=i486" } */
+
+void
+test (void)
+{
+}
+
+/* { dg-error "'-fcf-protection' is not compatible with this target" "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/i386/pr98667-2.c b/gcc/testsuite/gcc.target/i386/pr98667-2.c
new file mode 100644
index 000..bc3a78c9641
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98667-2.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -fcf-protection=branch -march=i486" } */
+
+void
+test (void)
+{
+}
+
+/* { dg-error "'-fcf-protection' is not compatible with this target" "" { target *-*-* } 0 } */
diff --git 

Re: [PATCH] i386: Update PR target/95021 tests

[Uros Bizjak via Gcc-patches]

On Thu, Jan 14, 2021 at 4:00 PM H.J. Lu  wrote:
>
> Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid
> disabling STV by:
>
>   /* Disable STV if -mpreferred-stack-boundary={2,3} or
>  -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
>  stack realignment will be extra cost the pass doesn't take into
>  account and the pass can't realign the stack.  */
>   if (ix86_preferred_stack_boundary < 128
>   || ix86_incoming_stack_boundary < 128
>   || opts->x_ix86_force_align_arg_pointer)
> opts->x_target_flags &= ~MASK_STV;
>
> PR target/98676
> * gcc.target/i386/pr95021-1.c: Add -mpreferred-stack-boundary=4
> -mno-stackrealign.
> * gcc.target/i386/pr95021-3.c: Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/testsuite/gcc.target/i386/pr95021-1.c | 2 +-
>  gcc/testsuite/gcc.target/i386/pr95021-3.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr95021-1.c 
> b/gcc/testsuite/gcc.target/i386/pr95021-1.c
> index a0b9a262a87..ec58596959c 100644
> --- a/gcc/testsuite/gcc.target/i386/pr95021-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr95021-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile { target ia32 } } */
> -/* { dg-options "-O2 -msse2 -mstv -W" } */
> +/* { dg-options "-O2 -msse2 -mstv -mpreferred-stack-boundary=4 
> -mno-stackrealign -W" } */
>  /* { dg-final { scan-assembler "movq\[ \t\]%xmm\[0-9\]+, \\(%esp\\)" } } */
>  /* { dg-final { scan-assembler-not "psrlq" } } */
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr95021-3.c 
> b/gcc/testsuite/gcc.target/i386/pr95021-3.c
> index 52f9e4569b3..0f16b16f793 100644
> --- a/gcc/testsuite/gcc.target/i386/pr95021-3.c
> +++ b/gcc/testsuite/gcc.target/i386/pr95021-3.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile { target ia32 } } */
> -/* { dg-options "-O2 -msse2 -mstv -mregparm=3 -W -mtune=generic" } */
> +/* { dg-options "-O2 -msse2 -mstv -mpreferred-stack-boundary=4 
> -mno-stackrealign -mregparm=3 -W -mtune=generic" } */
>  /* { dg-final { scan-assembler "movq\[ \t\]+\[^\n\]*, %xmm" } } */
>
>  #include "pr95021-1.c"
> --
> 2.29.2
>

Re: [PATCH] match.pd: Add ~(X - Y) -> ~X + Y simplification [PR96685]

[Richard Biener]

On Thu, 14 Jan 2021, Maciej W. Rozycki wrote:

> On Tue, 12 Jan 2021, Richard Biener wrote:
> 
> > >>> The point of the match.pd changes is to canonicalize GIMPLE on some form
> > >>> when there are several from GIMPLE POV equivalent or better forms of
> > >>> writing
> > >>> the same thing.  The advantage of having one canonical way is that ICF,
> > >>> SCCVN etc. optimizations can then understand the different forms are
> > >>> equivalent.
> > >> Fair enough, though in cases like this I think it is unclear which of the
> > >> two forms is going to be ultimately better, especially as it may depend 
> > >> on
> > >> the exact form of the operands used, e.g. values of any immediates, so I
> > >> think a way to make the reverse transformation (whether to undo one made
> > >> here or genuinely) needs to be available at a later compilation stage.
> > >> One size doesn't fit all.
> > >>
> > >>  With this in mind...
> > > So in this case the number of operations are the same before/after and
> > > parallelism is the same before/after, register lifetimes, etc.   I doubt
> > > either form is particularly better suited for CSE or gives better VRP
> > > data, etc.   The fact that we can't always do ~(X +C) -> ~X + -C
> > > probably argues against that form ever so slightly.
> 
>  FWIW I agree with Jakub here, that having one canonical form for the 
> middle end to operate on is advantageous.  It is just that when we 
> eventually get to the backend we may want to do the reverse transformation 
> in some cases, which may be specific immediate operand values or whatever 
> the backend may see fit.
> 
> > >>> If another form is then better for a particular machine, it should be 
> > >>> done
> > >>> either during expansion (being able to produce both RTLs and computing
> > >>> their
> > >>> costs), or during combine with either combine splitters or
> > >>> define_insn_and_split in the backend, or, if it can't be done in RTL,
> > >>> during
> > >>> the isel pass.
> > >> Hmm, maybe it has been discussed before, so please forgive me if I write
> > >> something silly, but it seems to me like this should be done in a generic
> > >> way like match.pd so that all the targets do not have to track the 
> > >> changes
> > >> made there and then perhaps repeat the same or similar code each.  So I
> > >> think it would make sense to make a change like this include that reverse
> > >> transformation as well, so that ultimately both forms are tried with RTL,
> > >> as there is no clear advantage to either here.
> > > The idea we've kicked around in the past was to use the same syntax as
> > > match.pd, but have it be target dependent to reform expressions in ways
> > > that are beneficial to the target and have it run at the end of the
> > > gimple/ssa pipeline.  Nobody's implemented this though.
> 
>  Hmm, but why does it have to be target dependent?  For match.pd we do 
> things unconditionally, to have a uniform intermediate representation, 
> however here we wouldn't have to, as we can check the costs respectively 
> of the original and the transformed expression and choose the cheaper of 
> the two.  Would that be so we don't waste cycles with targets we know 
> beforehand a given transformation won't buy anything?
> 
>  In that case however no code quality regression would happen anyway, so I 
> think it would be more productive if we still had all transformations 
> defined in a generic manner and then possibly the hopeless ones excluded 
> by hand for targets listed.  This way if anything is omitted by chance, 
> i.e. not excluded for a given target, then good code will still be 
> produced and only some compilation performance lost.
> 
>  While if we require all port maintainers to qualify individual 
> transformations by hand as they are added by someone to their pet target, 
> we'll end up with a lot of duplicate effort and missed bits.  Of course 
> some very exotic transformations that match unique target machine 
> instructions may indeed best be added to a single target only.
> 
> > Yes.  And while a gimple-to-gimple transform is indeed quite simple
> > to make eventually a match.pd-like gimple-to-RTL would be more
> > useful in the end.  Note RTL can eventually be emulated close enough
> > via the use of internal functions mapping to optabs.  But still
> > complex combined instructions will need expander help unless we
> > expose all named instruction RTL patterns as target specific
> > internal functions to use from that .pd file.
> 
>  Hmm, why aren't the standard named patterns we already have going to be 
> sufficient?

Because two standard name pattern expansions can later be combined
to a non-standard define-insn which may have lower cost and we'd
of course like to see such instruction selection opportunities here.

Richard.

[PATCH] i386: Update PR target/95021 tests

[H.J. Lu via Gcc-patches]

Also pass -mpreferred-stack-boundary=4 -mno-stackrealign to avoid
disabling STV by:

  /* Disable STV if -mpreferred-stack-boundary={2,3} or
 -mincoming-stack-boundary={2,3} or -mstackrealign - the needed
 stack realignment will be extra cost the pass doesn't take into
 account and the pass can't realign the stack.  */
  if (ix86_preferred_stack_boundary < 128
  || ix86_incoming_stack_boundary < 128
  || opts->x_ix86_force_align_arg_pointer)
opts->x_target_flags &= ~MASK_STV;

PR target/98676
* gcc.target/i386/pr95021-1.c: Add -mpreferred-stack-boundary=4
-mno-stackrealign.
* gcc.target/i386/pr95021-3.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/pr95021-1.c | 2 +-
 gcc/testsuite/gcc.target/i386/pr95021-3.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr95021-1.c 
b/gcc/testsuite/gcc.target/i386/pr95021-1.c
index a0b9a262a87..ec58596959c 100644
--- a/gcc/testsuite/gcc.target/i386/pr95021-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr95021-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv -W" } */
+/* { dg-options "-O2 -msse2 -mstv -mpreferred-stack-boundary=4 
-mno-stackrealign -W" } */
 /* { dg-final { scan-assembler "movq\[ \t\]%xmm\[0-9\]+, \\(%esp\\)" } } */
 /* { dg-final { scan-assembler-not "psrlq" } } */
 
diff --git a/gcc/testsuite/gcc.target/i386/pr95021-3.c 
b/gcc/testsuite/gcc.target/i386/pr95021-3.c
index 52f9e4569b3..0f16b16f793 100644
--- a/gcc/testsuite/gcc.target/i386/pr95021-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr95021-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv -mregparm=3 -W -mtune=generic" } */
+/* { dg-options "-O2 -msse2 -mstv -mpreferred-stack-boundary=4 
-mno-stackrealign -mregparm=3 -W -mtune=generic" } */
 /* { dg-final { scan-assembler "movq\[ \t\]+\[^\n\]*, %xmm" } } */
 
 #include "pr95021-1.c"
-- 
2.29.2

Re: [PATCH] match.pd: Add ~(X - Y) -> ~X + Y simplification [PR96685]

[Maciej W. Rozycki]

On Tue, 12 Jan 2021, Richard Biener wrote:

> >>> The point of the match.pd changes is to canonicalize GIMPLE on some form
> >>> when there are several from GIMPLE POV equivalent or better forms of
> >>> writing
> >>> the same thing.  The advantage of having one canonical way is that ICF,
> >>> SCCVN etc. optimizations can then understand the different forms are
> >>> equivalent.
> >> Fair enough, though in cases like this I think it is unclear which of the
> >> two forms is going to be ultimately better, especially as it may depend on
> >> the exact form of the operands used, e.g. values of any immediates, so I
> >> think a way to make the reverse transformation (whether to undo one made
> >> here or genuinely) needs to be available at a later compilation stage.
> >> One size doesn't fit all.
> >>
> >>  With this in mind...
> > So in this case the number of operations are the same before/after and
> > parallelism is the same before/after, register lifetimes, etc.   I doubt
> > either form is particularly better suited for CSE or gives better VRP
> > data, etc.   The fact that we can't always do ~(X +C) -> ~X + -C
> > probably argues against that form ever so slightly.

 FWIW I agree with Jakub here, that having one canonical form for the 
middle end to operate on is advantageous.  It is just that when we 
eventually get to the backend we may want to do the reverse transformation 
in some cases, which may be specific immediate operand values or whatever 
the backend may see fit.

> >>> If another form is then better for a particular machine, it should be done
> >>> either during expansion (being able to produce both RTLs and computing
> >>> their
> >>> costs), or during combine with either combine splitters or
> >>> define_insn_and_split in the backend, or, if it can't be done in RTL,
> >>> during
> >>> the isel pass.
> >> Hmm, maybe it has been discussed before, so please forgive me if I write
> >> something silly, but it seems to me like this should be done in a generic
> >> way like match.pd so that all the targets do not have to track the changes
> >> made there and then perhaps repeat the same or similar code each.  So I
> >> think it would make sense to make a change like this include that reverse
> >> transformation as well, so that ultimately both forms are tried with RTL,
> >> as there is no clear advantage to either here.
> > The idea we've kicked around in the past was to use the same syntax as
> > match.pd, but have it be target dependent to reform expressions in ways
> > that are beneficial to the target and have it run at the end of the
> > gimple/ssa pipeline.  Nobody's implemented this though.

 Hmm, but why does it have to be target dependent?  For match.pd we do 
things unconditionally, to have a uniform intermediate representation, 
however here we wouldn't have to, as we can check the costs respectively 
of the original and the transformed expression and choose the cheaper of 
the two.  Would that be so we don't waste cycles with targets we know 
beforehand a given transformation won't buy anything?

 In that case however no code quality regression would happen anyway, so I 
think it would be more productive if we still had all transformations 
defined in a generic manner and then possibly the hopeless ones excluded 
by hand for targets listed.  This way if anything is omitted by chance, 
i.e. not excluded for a given target, then good code will still be 
produced and only some compilation performance lost.

 While if we require all port maintainers to qualify individual 
transformations by hand as they are added by someone to their pet target, 
we'll end up with a lot of duplicate effort and missed bits.  Of course 
some very exotic transformations that match unique target machine 
instructions may indeed best be added to a single target only.

> Yes.  And while a gimple-to-gimple transform is indeed quite simple
> to make eventually a match.pd-like gimple-to-RTL would be more
> useful in the end.  Note RTL can eventually be emulated close enough
> via the use of internal functions mapping to optabs.  But still
> complex combined instructions will need expander help unless we
> expose all named instruction RTL patterns as target specific
> internal functions to use from that .pd file.

 Hmm, why aren't the standard named patterns we already have going to be 
sufficient?

  Maciej

Re: [PATCH] x86: Error on -fcf-protection with incompatible target

[Uros Bizjak via Gcc-patches]

On Thu, Jan 14, 2021 at 3:05 PM H.J. Lu  wrote:
>
> -fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
> ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
> processors.  Issue an error for -fcf-protection with CF_BRANCH when
> compiling for 32-bit non-TARGET_CMOVE targets.
>
> gcc/
>
> PR target/98667
> * config/i386/i386-options.c (ix86_option_override_internal):
> Issue an error for -fcf-protection with CF_BRANCH when compiling
> for 32-bit non-TARGET_CMOVE targets.
>
> gcc/testsuite/
>
> PR target/98667
> * gcc.target/i386/pr98667-1.c: New file.
> * gcc.target/i386/pr98667-2.c: Likewise.
> * gcc.target/i386/pr98667-3.c: Likewise.
> ---
>  gcc/config/i386/i386-options.c| 9 -
>  gcc/testsuite/gcc.target/i386/pr98667-1.c | 9 +
>  gcc/testsuite/gcc.target/i386/pr98667-2.c | 9 +
>  gcc/testsuite/gcc.target/i386/pr98667-3.c | 7 +++
>  4 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-3.c
>
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 4e0165ff32c..1489871b36f 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -3016,8 +3016,15 @@ ix86_option_override_internal (bool main_args_p,
>  }
>
>if (opts->x_flag_cf_protection != CF_NONE)
> -opts->x_flag_cf_protection
> +{
> +  if ((opts->x_flag_cf_protection & CF_BRANCH) == CF_BRANCH
> + && !TARGET_64BIT
> + && !TARGET_CMOVE)

You need TARGET_CMOV (note, no E) here. Also, please put both tests on one line.

LGTM with the above change.

Thanks,
Uros.

> +   error ("%<-fcf-protection%> is not compatible with this target");
> +
> +  opts->x_flag_cf_protection
>= (cf_protection_level) (opts->x_flag_cf_protection | CF_SET);
> +}
>
>if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
>  SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 256);
> diff --git a/gcc/testsuite/gcc.target/i386/pr98667-1.c 
> b/gcc/testsuite/gcc.target/i386/pr98667-1.c
> new file mode 100644
> index 000..5bf0c9285a8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr98667-1.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile { target ia32 } } */
> +/* { dg-options "-O2 -fcf-protection -march=i486" } */
> +
> +void
> +test (void)
> +{
> +}
> +
> +/* { dg-error "'-fcf-protection' is not compatible with this target" "" { 
> target *-*-* } 0 } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr98667-2.c 
> b/gcc/testsuite/gcc.target/i386/pr98667-2.c
> new file mode 100644
> index 000..bc3a78c9641
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr98667-2.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile { target ia32 } } */
> +/* { dg-options "-O2 -fcf-protection=branch -march=i486" } */
> +
> +void
> +test (void)
> +{
> +}
> +
> +/* { dg-error "'-fcf-protection' is not compatible with this target" "" { 
> target *-*-* } 0 } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr98667-3.c 
> b/gcc/testsuite/gcc.target/i386/pr98667-3.c
> new file mode 100644
> index 000..a6ea6d04331
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr98667-3.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile { target ia32 } } */
> +/* { dg-options "-O2 -fcf-protection=return -march=i486" } */
> +
> +void
> +test (void)
> +{
> +}
> --
> 2.29.2
>

Re: [PATCH 1/4] Remove build dependence on HSA run-time

[Thomas Schwinge]

Hi!

I'm raising here an issue with HSA libgomp plugin code changes from a
while ago.  While HSA is now no longer relevant for GCC master branch,
the same code has also been copied into the GCN libgomp plugin.

This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
build dependence on HSA run-time":

On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:
> --- a/libgomp/plugin/configfrag.ac
> +++ b/libgomp/plugin/configfrag.ac

> @@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
>   tgt_name=hsa
>   PLUGIN_HSA=$tgt
>   PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
> - PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
> - PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
> + PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
> + PLUGIN_HSA_LIBS="-ldl"

So this switched from directly linking against 'libhsa-runtime64.so' to a
'libdl'-based runtime linking variant.

Previously, 'libhsa-runtime64.so' would've been found at run time via the
standard search paths.

> +if test "$HSA_RUNTIME_LIB" != ""; then
> +  HSA_RUNTIME_LIB="$HSA_RUNTIME_LIB/"
> +fi
> +
> +AC_DEFINE_UNQUOTED([HSA_RUNTIME_LIB], ["$HSA_RUNTIME_LIB"],
> +  [Define path to HSA runtime.])

That's new, to propagate '--with-hsa-runtime'/'--with-hsa-runtime-lib'
into the HSA plugin source code.

> --- a/libgomp/plugin/plugin-hsa.c
> +++ b/libgomp/plugin/plugin-hsa.c

> +static const char *hsa_runtime_lib;

>  static void
>  init_enviroment_variables (void)
>  {

> +  hsa_runtime_lib = secure_getenv ("HSA_RUNTIME_LIB");

Unless overridden via the 'HSA_RUNTIME_LIB' environment variable...

> +  if (hsa_runtime_lib == NULL)
> +hsa_runtime_lib = HSA_RUNTIME_LIB "libhsa-runtime64.so";

... we now default to '[HSA_RUNTIME_LIB]/libhsa-runtime64.so' (note
'HSA_RUNTIME_LIB' prefix!)...

> +static bool
> +init_hsa_runtime_functions (void)
> +{
> +  void *handle = dlopen (hsa_runtime_lib, RTLD_LAZY);

..., which is then 'dlopen'ed here.

That means, contrary to before, the GCC configure-time
'--with-hsa-runtime' (by definition only valid for GCC configure/build as
well as build-tree testing) leaks into the installed HSA libgomp plugin.
That's a problem if your GCC build system (and build-tree testing)
requires '--with-hsa-runtime' to specify a non-standard location (not in
default search paths) but that location is not valid on your GCC
deployment system (but it has leaked into the HSA libgomp plugin),
meaning that (unless overridden via the 'HSA_RUNTIME_LIB' environment
variable) 'libhsa-runtime64.so' is now no longer found via the standard
search paths, because of the 'HSA_RUNTIME_LIB' prefix passed into
'dlopen'.

Per my understanding this cannot be intentional, so I suggest to restore
the previous behavior as per the attached "libgomp HSA/GCN plugins: don't
prepend the 'HSA_RUNTIME_LIB' path to 'libhsa-runtime64.so'".  OK to push
such changes?  I was tempted to push "as obvious", but maybe I fail to
see the rationale behind this change?

For avoidance of doubt, this change doesn't affect (build-tree) testsuite
usage, where we have:

libgomp/testsuite/libgomp-test-support.exp.in:set hsa_runtime_lib 
"@HSA_RUNTIME_LIB@"

libgomp/testsuite/lib/libgomp.exp:  append always_ld_library_path 
":$hsa_runtime_lib"

And, another data point:

gcc/config/gcn/gcn-run.c:#define HSA_RUNTIME_LIB "libhsa-runtime64.so.1"
[...]
gcc/config/gcn/gcn-run.c:  void *handle = dlopen (HSA_RUNTIME_LIB, 
RTLD_LAZY);

Here, 'libhsa-runtime64.so.1' is 'dlopen'ed without prefix, and thus
found via the standard search paths (as expected).


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 936e7ee10349a6be2bd0a6a2198f70239a8e1ec1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 25 Jun 2020 11:59:42 +0200
Subject: [PATCH] libgomp HSA/GCN plugins: don't prepend the 'HSA_RUNTIME_LIB'
 path to 'libhsa-runtime64.so'

For unknown reasons, this had gotten added for the libgomp HSA plugin in commit
b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove build dependence on
HSA run-time", and later propagated into the GCN plugin.

	libgomp/
	* plugin/plugin-hsa.c (init_enviroment_variables): Don't prepend
	the 'HSA_RUNTIME_LIB' path to 'libhsa-runtime64.so'.
	* plugin/plugin-gcn.c (init_environment_variables): Likewise.
	* plugin/configfrag.ac (HSA_RUNTIME_LIB): Clean up.
	* configure: Regenerate.
---
 libgomp/configure| 10 --
 libgomp/plugin/configfrag.ac |  7 ---
 libgomp/plugin/plugin-gcn.c  |  2 +-
 libgomp/plugin/plugin-hsa.c  |  2 +-
 4 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/libgomp/configure b/libgomp/configure
index d8d98f182d4..9765a9068fe 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15483,16 +15483,6 @@ cat >>confdefs.h <<_ACEOF
 

Re: [PATCH] libstdc++: Add support for C++20 barriers

[Jonathan Wakely via Gcc-patches]

On 07/01/21 12:56 -0800, Thomas Rodgers via Libstdc++ wrote:


Tested x86_64-pc-linux-gnu, committed to master.


The copyright years need updating. Pushed to master.


commit 194a9d67be45568d81bb8c17e9102e31c1309e5f
Author: Jonathan Wakely 
Date:   Thu Jan 14 14:25:05 2021

libstdc++: Update copyright dates on new files

The patch adding these files was approved in 2020 but it wasn't
committed until 2021, so the copyright years were not updated along with
the years in all the existing files.

libstdc++-v3/ChangeLog:

* include/std/barrier: Update copyright years. Fix whitespace.
* include/std/version: Fix whitespace.
* testsuite/30_threads/barrier/1.cc: Update copyright years.
* testsuite/30_threads/barrier/2.cc: Likewise.
* testsuite/30_threads/barrier/arrive.cc: Likewise.
* testsuite/30_threads/barrier/arrive_and_drop.cc: Likewise.
* testsuite/30_threads/barrier/arrive_and_wait.cc: Likewise.
* testsuite/30_threads/barrier/completion.cc: Likewise.

diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index f1143da89b4..e09212dfcb9 100644
--- a/libstdc++-v3/include/std/barrier
+++ b/libstdc++-v3/include/std/barrier
@@ -1,6 +1,6 @@
 //  -*- C++ -*-
 
-// Copyright (C) 2020 Free Software Foundation, Inc.
+// Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -103,7 +103,7 @@ It looks different from literature pseudocode for two main reasons:
 			   static_cast<__barrier_phase_t>(__old_phase_val + 2);
 
 	size_t __current_expected = _M_expected;
-	std::hash__hasher;
+	std::hash __hasher;
 	size_t __current = __hasher(std::this_thread::get_id())
 	  % ((_M_expected + 1) >> 1);
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 9516558d8b4..e3d52b88c21 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -200,8 +200,8 @@
 #if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX
 # define __cpp_lib_atomic_wait 201907L
 # if __cpp_aligned_new
-# define __cpp_lib_barrier 201907L
-#endif
+#  define __cpp_lib_barrier 201907L
+# endif
 #endif
 #define __cpp_lib_bind_front 201907L
 #if __has_builtin(__builtin_bit_cast)
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/1.cc b/libstdc++-v3/testsuite/30_threads/barrier/1.cc
index 4c15deb1398..a21fae32127 100644
--- a/libstdc++-v3/testsuite/30_threads/barrier/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/barrier/1.cc
@@ -1,4 +1,4 @@
-// Copyright (C) 2020 Free Software Foundation, Inc.
+// Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/2.cc b/libstdc++-v3/testsuite/30_threads/barrier/2.cc
index 0fac1ef3f3c..94e37d739da 100644
--- a/libstdc++-v3/testsuite/30_threads/barrier/2.cc
+++ b/libstdc++-v3/testsuite/30_threads/barrier/2.cc
@@ -1,4 +1,4 @@
-// Copyright (C) 2019-2020 Free Software Foundation, Inc.
+// Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/arrive.cc b/libstdc++-v3/testsuite/30_threads/barrier/arrive.cc
index 6e64e378cb0..fb0f56292c0 100644
--- a/libstdc++-v3/testsuite/30_threads/barrier/arrive.cc
+++ b/libstdc++-v3/testsuite/30_threads/barrier/arrive.cc
@@ -3,7 +3,7 @@
 // { dg-require-gthreads "" }
 // { dg-additional-options "-pthread" { target pthread } }
 
-// Copyright (C) 2020 Free Software Foundation, Inc.
+// Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_drop.cc b/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_drop.cc
index 55f40e17062..22b40200c80 100644
--- a/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_drop.cc
+++ b/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_drop.cc
@@ -3,7 +3,7 @@
 // { dg-require-gthreads "" }
 // { dg-additional-options "-pthread" { target pthread } }
 
-// Copyright (C) 2020 Free Software Foundation, Inc.
+// Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_wait.cc b/libstdc++-v3/testsuite/30_threads/barrier/arrive_and_wait.cc
index 2a3a69ae3c0..f9b4fa29063 100644
--- 

RE: [PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for vcge and vcle intrinsics

[Kyrylo Tkachov via Gcc-patches]

Hi Prathamesh,

> -Original Message-
> From: Prathamesh Kulkarni 
> Sent: 14 January 2021 14:04
> To: gcc Patches ; Kyrylo Tkachov
> 
> Subject: [PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for
> vcge and vcle intrinsics
> 
> Hi,
> The attached patch removes __builtin_neon_vcge* function with >= and
> <= operators for vcge and vcle intrinsics respectively.
> Cross tested on arm*-*-*.
> OK for trunk ?

Looks like it's the same way we do it on aarch64.
So ok.
Thanks,
Kyrill

> 
> Thanks,
> Prathamesh

Re: [PATCH]middle-end slp: elide intermediate nodes for complex add and avoid truncate

[Richard Biener]

On Thu, 14 Jan 2021, Tamar Christina wrote:

> Hi All,
> 
> This applies the same feedback received for MUL and the rest to
> ADD which was already committed.  In short it elides the intermediate
> nodes vec and avoids the use of truncate on the SLP child.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

OK.

Thanks,
Richard.

> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * tree-vect-slp-patterns.c (complex_add_pattern::build):
> 
> --- inline copy of patch -- 
> diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
> index 
> be066b08310b72320fdbeb88a6b2969151f73cdc..e9f70958fdc32427ab0e1cceadfed41dfa091b47
>  100644
> --- a/gcc/tree-vect-slp-patterns.c
> +++ b/gcc/tree-vect-slp-patterns.c
> @@ -645,23 +645,21 @@ class complex_add_pattern : public complex_pattern
>  void
>  complex_add_pattern::build (vec_info *vinfo)
>  {
> -  auto_vec nodes;
> +  SLP_TREE_CHILDREN (*this->m_node).reserve_exact (2);
> +
>slp_tree node = this->m_ops[0];
>vec children = SLP_TREE_CHILDREN (node);
>  
>/* First re-arrange the children.  */
> -  nodes.create (children.length ());
> -  nodes.quick_push (children[0]);
> -  nodes.quick_push (vect_build_swap_evenodd_node (children[1]));
> +  SLP_TREE_CHILDREN (*this->m_node)[0] = children[0];
> +  SLP_TREE_CHILDREN (*this->m_node)[1] =
> +vect_build_swap_evenodd_node (children[1]);
>  
> -  SLP_TREE_REF_COUNT (nodes[0])++;
> -  SLP_TREE_REF_COUNT (nodes[1])++;
> +  SLP_TREE_REF_COUNT (SLP_TREE_CHILDREN (*this->m_node)[0])++;
> +  SLP_TREE_REF_COUNT (SLP_TREE_CHILDREN (*this->m_node)[1])++;
>vect_free_slp_tree (this->m_ops[0]);
>vect_free_slp_tree (this->m_ops[1]);
>  
> -  SLP_TREE_CHILDREN (*this->m_node).truncate (0);
> -  SLP_TREE_CHILDREN (*this->m_node).safe_splice (nodes);
> -
>complex_pattern::build (vinfo);
>  }
>  
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH] x86: Error on -fcf-protection with incompatible target

[H.J. Lu via Gcc-patches]

-fcf-protection with CF_BRANCH inserts ENDBR32 at function entries.
ENDBR32 is NOP only on 64-bit processors and 32-bit TARGET_CMOVE
processors.  Issue an error for -fcf-protection with CF_BRANCH when
compiling for 32-bit non-TARGET_CMOVE targets.

gcc/

PR target/98667
* config/i386/i386-options.c (ix86_option_override_internal):
Issue an error for -fcf-protection with CF_BRANCH when compiling
for 32-bit non-TARGET_CMOVE targets.

gcc/testsuite/

PR target/98667
* gcc.target/i386/pr98667-1.c: New file.
* gcc.target/i386/pr98667-2.c: Likewise.
* gcc.target/i386/pr98667-3.c: Likewise.
---
 gcc/config/i386/i386-options.c| 9 -
 gcc/testsuite/gcc.target/i386/pr98667-1.c | 9 +
 gcc/testsuite/gcc.target/i386/pr98667-2.c | 9 +
 gcc/testsuite/gcc.target/i386/pr98667-3.c | 7 +++
 4 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr98667-3.c

diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 4e0165ff32c..1489871b36f 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -3016,8 +3016,15 @@ ix86_option_override_internal (bool main_args_p,
 }
 
   if (opts->x_flag_cf_protection != CF_NONE)
-opts->x_flag_cf_protection
+{
+  if ((opts->x_flag_cf_protection & CF_BRANCH) == CF_BRANCH
+ && !TARGET_64BIT
+ && !TARGET_CMOVE)
+   error ("%<-fcf-protection%> is not compatible with this target");
+
+  opts->x_flag_cf_protection
   = (cf_protection_level) (opts->x_flag_cf_protection | CF_SET);
+}
 
   if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
 SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 256);
diff --git a/gcc/testsuite/gcc.target/i386/pr98667-1.c 
b/gcc/testsuite/gcc.target/i386/pr98667-1.c
new file mode 100644
index 000..5bf0c9285a8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98667-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -fcf-protection -march=i486" } */
+
+void
+test (void)
+{
+}
+
+/* { dg-error "'-fcf-protection' is not compatible with this target" "" { 
target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/i386/pr98667-2.c 
b/gcc/testsuite/gcc.target/i386/pr98667-2.c
new file mode 100644
index 000..bc3a78c9641
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98667-2.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -fcf-protection=branch -march=i486" } */
+
+void
+test (void)
+{
+}
+
+/* { dg-error "'-fcf-protection' is not compatible with this target" "" { 
target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/i386/pr98667-3.c 
b/gcc/testsuite/gcc.target/i386/pr98667-3.c
new file mode 100644
index 000..a6ea6d04331
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98667-3.c
@@ -0,0 +1,7 @@
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "-O2 -fcf-protection=return -march=i486" } */
+
+void
+test (void)
+{
+}
-- 
2.29.2

[PR66791][ARM] Replace __builtin_neon_vcge* with >= and <= for vcge and vcle intrinsics

[Prathamesh Kulkarni via Gcc-patches]

Hi,
The attached patch removes __builtin_neon_vcge* function with >= and
<= operators for vcge and vcle intrinsics respectively.
Cross tested on arm*-*-*.
OK for trunk ?

Thanks,
Prathamesh


vcge-1.diff
Description: Binary data

Re: [PATCH] gimple UIDs, LTO and -fanalyzer [PR98599]

[Jan Hubicka]

> On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via Gcc-patches
>  wrote:
> >
> > gimple.h has this comment for gimple's uid field:
> >
> >   /* UID of this statement.  This is used by passes that want to
> >  assign IDs to statements.  It must be assigned and used by each
> >  pass.  By default it should be assumed to contain garbage.  */
> >   unsigned uid;
> >
> > and gimple_set_uid has:
> >
> >Please note that this UID property is supposed to be undefined at
> >pass boundaries.  This means that a given pass should not assume it
> >contains any useful value when the pass starts and thus can set it
> >to any value it sees fit.
> >
> > which suggests that any pass can use the uid field as an arbitrary
> > scratch space.
> >
> > PR analyzer/98599 reports a case where this error occurs in LTO mode:
> >   fatal error: Cgraph edge statement index out of range
> > on certain inputs with -fanalyzer.
> >
> > The error occurs in the LTRANS phase after -fanalyzer runs in the
> > WPA phase.  The analyzer pass writes to the uid fields of all stmts.
> >
> > The error occurs when LTRANS is streaming callgraph edges back in.
> > If I'm reading things correctly, the LTO format uses stmt uids to
> > associate call stmts with callgraph edges between WPA and LTRANS.
> > For example, in lto-cgraph.c, lto_output_edge writes out the
> > gimple_uid, and input_edge reads it back in.
> >
> > Hence IPA passes that touch the uids in WPA need to restore them,
> > or the stream-in at LTRANS will fail.
> >
> > Is it intended that the LTO machinery relies on the value of the uid
> > field being preserved during WPA (or, at least, needs to be saved and
> > restored by passes that touch it)?
> 
> I belive this is solely at the cgraph stream out to stream in boundary but
> this may be a blurred area since while we materialize the whole cgraph
> at once the function bodies are streamed in on demand.
> 
> Honza can probably clarify things.

Well, the uids are used to associate cgraph edges with statements.  At
WPA stage you do not have function bodies and thus uids serves role of
pointers to the statement.  If you load the body in (via get_body) the
uids are replaced by pointers and when you stream out uids are
recomputed again.

When do you touch the uids? At WPA time or from small IPA pass in
ltrans?

hozna
> 
> Note LTO uses this exactly because of this comment to avoid allocating
> extra memory for an 'index' but it could of course leave gimple_uid alone
> at some extra expense (eventually paid for in generic cgraph data structures
> and thus for not only the streaming time).
> 
> > On the assumption that this is the case, this patch updates the comments
> > in gimple.h referring to passes being able to set uid to any value to
> > note the caveat for IPA passes, and it updates the analyzer to save
> > and restore the UIDs, fixing the error.
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > OK for master?
> 
> The analyzer bits are OK, let's see how Honza can clarify the situation.
> 
> Thanks,
> Richard.
> 
> > gcc/analyzer/ChangeLog:
> > PR analyzer/98599
> > * supergraph.cc (saved_uids::make_uid_unique): New.
> > (saved_uids::restore_uids): New.
> > (supergraph::supergraph): Replace assignments to stmt->uid with
> > calls to m_stmt_uids.make_uid_unique.
> > (supergraph::~supergraph): New.
> > * supergraph.h (class saved_uids): New.
> > (supergraph::~supergraph): New decl.
> > (supergraph::m_stmt_uids): New field.
> >
> > gcc/ChangeLog:
> > PR analyzer/98599
> > * doc/gimple.texi: Document that UIDs must not change during IPA
> > passes.
> > * gimple.h (gimple::uid): Likewise.
> > (gimple_set_uid): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> > PR analyzer/98599
> > * gcc.dg/analyzer/pr98599-a.c: New test.
> > * gcc.dg/analyzer/pr98599-b.c: New test.
> > ---
> >  gcc/analyzer/supergraph.cc| 53 +--
> >  gcc/analyzer/supergraph.h | 15 +++
> >  gcc/doc/gimple.texi   |  6 +++
> >  gcc/gimple.h  | 13 +-
> >  gcc/testsuite/gcc.dg/analyzer/pr98599-a.c |  8 
> >  gcc/testsuite/gcc.dg/analyzer/pr98599-b.c |  1 +
> >  6 files changed, 90 insertions(+), 6 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr98599-a.c
> >  create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr98599-b.c
> >
> > diff --git a/gcc/analyzer/supergraph.cc b/gcc/analyzer/supergraph.cc
> > index 419f6424f76..40acfbd16a8 100644
> > --- a/gcc/analyzer/supergraph.cc
> > +++ b/gcc/analyzer/supergraph.cc
> > @@ -87,6 +87,46 @@ supergraph_call_edge (function *fun, gimple *stmt)
> >return edge;
> >  }
> >
> > +/* class saved_uids.
> > +
> > +   In order to ensure consistent results without relying on the ordering
> > +   of pointer values we assign a uid to each 

Re: Split wchars tests from the normal variant

[Jonathan Wakely via Gcc-patches]

On 28/12/20 19:39 +0100, François Dumont via Libstdc++ wrote:

On 22/12/20 10:27 pm, Alexandre Oliva wrote:

This change extracts apart the wchar specific parts of character
conversion tests to allow conditonalizating these parts on actual
wchar support while applying the rest more generally.

This turned out useful during our work on the libstdc++ support
for VxWorks, to expose the problematic areas more precisely.

Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
Ok to install?  (dg-requires-wchars is added by another patch by
Corentin, that I posted a few minutes ago)

While updating Corentin's patch for mainline, I brought over to the
split-out test even the preprocessor conditional that is present in the
current version of the test, but required/implied by dg-requires-wchars.
Maybe that's excessive.  Maybe the whole patch is excessive, given that
conditional, but I didn't want to just drop it without asking for
others' thoughts.


from Corentin Gay 
for  libstdc++-v3/ChangeLog

* testsuite/20_util/from_chars/1_neg.cc: Split wchar specific
part into...
* testsuite/20_util/from_chars/1_neg_wchar.cc: ... new file.
---
 libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc |8 -
 .../testsuite/20_util/from_chars/1_neg_wchar.cc|   35 
 2 files changed, 35 insertions(+), 8 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/1_neg_wchar.cc

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
index 0d2fe2b3e6594..a84b0f5efb075 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/1_neg.cc
@@ -23,14 +23,6 @@
 void
 test01(const char* first, const char* last)
 {
-#if _GLIBCXX_USE_WCHAR_T
-  wchar_t wc;
-#else
-  enum W { } wc;
-#endif
-  std::from_chars(first, last, wc); // { dg-error "no matching" }
-  std::from_chars(first, last, wc, 10); // { dg-error "no matching" }
-
   char16_t c16;
   std::from_chars(first, last, c16); // { dg-error "no matching" }
   std::from_chars(first, last, c16, 10); // { dg-error "no matching" }
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/1_neg_wchar.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/1_neg_wchar.cc
new file mode 100644
index 0..2d736a28a2da7
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/from_chars/1_neg_wchar.cc


AFAIK _neg should be last.


Yup.


Using wchar_t_neg.cc should even make the dg-require-wchars useless here.


Indeed, but I don't think we want this change anyway.

Re: Split wchars tests from the normal variant

[Jonathan Wakely via Gcc-patches]

On 22/12/20 18:27 -0300, Alexandre Oliva wrote:


This change extracts apart the wchar specific parts of character
conversion tests to allow conditonalizating these parts on actual
wchar support while applying the rest more generally.

This turned out useful during our work on the libstdc++ support
for VxWorks, to expose the problematic areas more precisely.

Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
Ok to install?  (dg-requires-wchars is added by another patch by
Corentin, that I posted a few minutes ago)

While updating Corentin's patch for mainline, I brought over to the
split-out test even the preprocessor conditional that is present in the
current version of the test, but required/implied by dg-requires-wchars.
Maybe that's excessive.  Maybe the whole patch is excessive, given that
conditional, but I didn't want to just drop it without asking for
others' thoughts.


I do think this is excessive. The point of the test is only to verify
that calling from_chars with wchar_t gives an error. I don't think we
need to make that conditional on whether wchar_t is supported or not.
Adding a whole new test and checking the dg-requires... condition adds
non-zero overhead to the testsuite.

Following the theme of my other replies, maybe _GLIBCXX_USE_WCHAR_T
isn't even the right thing to check here. We don't require any
support for wchar_t in this test, we only require the type to be
defined. Simple changing _GLIBCXX_USE_WCHAR_T to __SIZEOF_WCHAR_T__
seems like a better fix. That will mean that we use the type if it's
defined, and not otherwise. We don't care if the library actually
supports wchar_t specializations for std::char_traits etc. because we
are expecting to get an error anyway.

Re: Add dg-require-wchars to libstdc++ testsuite#

[Jonathan Wakely via Gcc-patches]

On 14/01/21 13:41 +, Jonathan Wakely wrote:


Is it the case that the wchar_t type is defined on this target, it's
just that libc doesn't have support for wcslen etc?  Because we should
probably audit all our uses of _GLIBCXX_USE_WCHAR_T and find which
ones actually need libc support and which just need the wchar_t type
to exist. Some things really do need the libc support, but I suspect
many others don't.

It seems wrong that we can provide full support for char16_t and
char32_t but not wchar_t, just because the former two don't depend on
anything being present in libc. Why can't we just implement the same
functionality for wchar_t without using libc?

In fact, if we just define std::char_traits generically
without using any libc functions (or just using them as optimisations)
we might be able to support std::basic_string and iostream
classes with almost no work. But that's something to consider in the
future.



Oops, I considered it already.

This untested patch should define std::char_traits so it is
available if wchar_t is defined by the front end (which I assume is
always true, is that right?), only using optimized libc routines if
available.

This would be the first step to enabling std::wstring etc for targets
with no wchar_t support in libc.


diff --git a/libstdc++-v3/include/bits/char_traits.h b/libstdc++-v3/include/bits/char_traits.h
index ea1e036f721..3a60478ea32 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -438,7 +438,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   };
 
 
-#ifdef _GLIBCXX_USE_WCHAR_T
+#ifdef __SIZEOF_WCHAR_T__
   /// 21.1.3.2  char_traits specializations
   template<>
 struct char_traits
@@ -469,23 +469,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	if (__n == 0)
 	  return 0;
-#if __cplusplus >= 201703L
-	if (__builtin_constant_p(__n)
-	&& __constant_char_array_p(__s1, __n)
-	&& __constant_char_array_p(__s2, __n))
-	  return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wmemcmp(__s1, __s2, __n);
 #endif
-	return wmemcmp(__s1, __s2, __n);
+	return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
   }
 
   static _GLIBCXX17_CONSTEXPR size_t
   length(const char_type* __s)
   {
-#if __cplusplus >= 201703L
-	if (__constant_string_p(__s))
-	  return __gnu_cxx::char_traits::length(__s);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wcslen(__s);
 #endif
-	return wcslen(__s);
+	return __gnu_cxx::char_traits::length(__s);
   }
 
   static _GLIBCXX17_CONSTEXPR const char_type*
@@ -493,13 +491,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	if (__n == 0)
 	  return 0;
-#if __cplusplus >= 201703L
-	if (__builtin_constant_p(__n)
-	&& __builtin_constant_p(__a)
-	&& __constant_char_array_p(__s, __n))
-	  return __gnu_cxx::char_traits::find(__s, __n, __a);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wmemchr(__s, __a, __n);
 #endif
-	return wmemchr(__s, __a, __n);
+	return __gnu_cxx::char_traits::find(__s, __n, __a);
   }
 
   static _GLIBCXX20_CONSTEXPR char_type*
@@ -507,11 +503,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	if (__n == 0)
 	  return __s1;
-#ifdef __cpp_lib_is_constant_evaluated
-	if (std::is_constant_evaluated())
-	  return __gnu_cxx::char_traits::move(__s1, __s2, __n);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wmemmove(__s1, __s2, __n);
 #endif
-	return wmemmove(__s1, __s2, __n);
+	return __gnu_cxx::char_traits::move(__s1, __s2, __n);
   }
 
   static _GLIBCXX20_CONSTEXPR char_type*
@@ -519,11 +515,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	if (__n == 0)
 	  return __s1;
-#ifdef __cpp_lib_is_constant_evaluated
-	if (std::is_constant_evaluated())
-	  return __gnu_cxx::char_traits::copy(__s1, __s2, __n);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wmemcpy(__s1, __s2, __n);
 #endif
-	return wmemcpy(__s1, __s2, __n);
+	return __gnu_cxx::char_traits::copy(__s1, __s2, __n);
   }
 
   static _GLIBCXX20_CONSTEXPR char_type*
@@ -531,11 +527,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	if (__n == 0)
 	  return __s;
-#ifdef __cpp_lib_is_constant_evaluated
-	if (std::is_constant_evaluated())
-	  return __gnu_cxx::char_traits::assign(__s, __n, __a);
+#ifdef _GLIBCXX_USE_WCHAR_T
+	if (!__builtin_is_constant_evaluated())
+	  return wmemset(__s, __a, __n);
 #endif
-	return wmemset(__s, __a, __n);
+	return __gnu_cxx::char_traits::assign(__s, __n, __a);
   }
 
   static _GLIBCXX_CONSTEXPR char_type
@@ -558,7 +554,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   not_eof(const int_type& __c) _GLIBCXX_NOEXCEPT
   { return eq_int_type(__c, eof()) ? 0 : __c; }
   };
-#endif //_GLIBCXX_USE_WCHAR_T
+#endif // __SIZEOF_WCHAR_T__
 
 #ifdef _GLIBCXX_USE_CHAR8_T
   template<>

Re: Add dg-require-wchars to libstdc++ testsuite

[Jonathan Wakely via Gcc-patches]

On 22/12/20 18:12 -0300, Alexandre Oliva wrote:

--- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc
@@ -16,6 +16,7 @@
// .

// { dg-do run { target c++11 } }
+// { dg-require-wchars "" }


This test doesn't use wchar_t, so it shouldn't depend on
_GLIBCXX_USE_WCHAR_T being defined.

The problem is that  uses wchar_t in default
template arguments:

#ifdef _GLIBCXX_USE_WCHAR_T

_GLIBCXX_BEGIN_NAMESPACE_CXX11

  /// String conversions
  template
Is it the case that the wchar_t type is defined on this target, it's
just that libc doesn't have support for wcslen etc?  Because we should
probably audit all our uses of _GLIBCXX_USE_WCHAR_T and find which
ones actually need libc support and which just need the wchar_t type
to exist. Some things really do need the libc support, but I suspect
many others don't.

It seems wrong that we can provide full support for char16_t and
char32_t but not wchar_t, just because the former two don't depend on
anything being present in libc. Why can't we just implement the same
functionality for wchar_t without using libc?

In fact, if we just define std::char_traits generically
without using any libc functions (or just using them as optimisations)
we might be able to support std::basic_string and iostream
classes with almost no work. But that's something to consider in the
future.



diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index b7d7b906de41c..2c22bcc0f0c94 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -702,6 +702,53 @@ proc v3-build_support { } {
}
}

+proc check_v3_target_wchars { } {
+global et_wchars
+global et_wchars_target_name
+global tool
+
+if { ![info exists et_wchars_target_name] } {
+   set et_wchars_target_name ""
+}
+
+# If the target has changed since we set the cached value, clear it.
+set current_target [current_target_name]
+if { $current_target != $et_wchars_target_name } {
+   verbose "check_v3_target_wchars: `$et_wchars_target_name'" 2
+   set et_wchars_target_name $current_target
+   if [info exists et_wchars] {
+   verbose "check_v3_target_wchars: removing cached result" 2
+   unset et_wchars
+   }
+}
+
+if [info exists et_wchars] {
+   verbose "check_v3_target_wchars: using cached result" 2
+} else {
+   set et_wchars 0
+
+   # Set up and preprocess a C++ test program that depends
+   # on wchars support being configured in the libstdc++.
+   set src wchars[pid].cc
+
+   set f [open $src "w"]
+   puts $f "#ifndef _GLIBCXX_USE_WCHAR_T"
+   puts $f "#  error No wchar header."


As François said, this could use the new proc. I'd also prefer if it
was defined as an effective-target keyword so we can use:

// { dg-require-effective-target wchars }

instead of the old fashioned { dg-require-wchars "" } form. I've
recently added effective-target keywords for several of the
dg-require-FOO directives, so we can move away from the old form. I
think new directives should be done as effective-target keywords. See
the recent changes to libstdc++-v3/testsuite/lib/libstdc++.exp for
examples, e.g. 10ee46adf44ae731fc4f9e9fdc25ad60c9d43a9c

But we might not even need this new proc if the codecvt tests can be
made to work using the attached patch.


diff --git a/libstdc++-v3/include/bits/locale_conv.h b/libstdc++-v3/include/bits/locale_conv.h
index 0e409da9876..d8a4d0851f4 100644
--- a/libstdc++-v3/include/bits/locale_conv.h
+++ b/libstdc++-v3/include/bits/locale_conv.h
@@ -222,11 +222,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif  // _GLIBCXX_USE_CHAR8_T
 
 #ifdef _GLIBCXX_USE_WCHAR_T
+# define _GLIBCXX_WCHAR_DEFAULT_TEMPL_ARG = wchar_t
+#else
+// wstring_convert and wbuffer_convert are still defined for targets without
+// wchar_t support, but the second template argument must be given explictly.
+# define _GLIBCXX_WCHAR_DEFAULT_TEMPL_ARG
+#endif
 
 _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
   /// String conversions
-  template,
 	   typename _Byte_alloc = allocator>
 class wstring_convert
@@ -382,7 +388,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 _GLIBCXX_END_NAMESPACE_CXX11
 
   /// Buffer conversions
-  template>
 class wbuffer_convert : public basic_streambuf<_Elem, _Tr>
 {
@@ -606,8 +612,6 @@ _GLIBCXX_END_NAMESPACE_CXX11
   bool			_M_always_noconv;
 };
 
-#endif  // _GLIBCXX_USE_WCHAR_T
-
   /// @} group locales
 
 _GLIBCXX_END_NAMESPACE_VERSION

[PATCH] tree-optimization/98674 - improve dependence analysis

[Richard Biener]

This improves dependence analysis on refs that access the same
array but with different typed but same sized accesses.  That's
obviously safe for the case of types that cannot have any
access function based off them.  For the testcase this is
signed short vs. unsigned short.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

2021-01-14  Richard Biener  

PR tree-optimization/98674
* tree-data-ref.c (base_supports_access_fn_components_p): New.
(initialize_data_dependence_relation): For two bases without
possible access fns resort to type size equality when determining
shape compatibility.

* gcc.dg/vect/pr98674.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr98674.c | 16 
 gcc/tree-data-ref.c | 26 --
 2 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr98674.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr98674.c 
b/gcc/testsuite/gcc.dg/vect/pr98674.c
new file mode 100644
index 000..0f1b6cb060b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr98674.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-msse2" { target sse2 } } */
+
+void swap(short *p, int cnt)
+{
+  while (cnt-- > 0)
+{
+  *p = ((*p << 8) & 0xFF00) | ((*p >> 8) & 0x00FF);
+  ++p;
+}
+}
+
+/* Dependence analysis should not fail.  */
+/* { dg-final { scan-tree-dump "dependence distance == 0" "vect" } } */
+/* On x86 with SSE2 we can vectorize this with psllw/psrlw.  */
+/* { dg-final { scan-tree-dump "loop vectorized" "vect" { target sse2 } } } */
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 394470af757..65fe6d5da91 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -1291,6 +1291,23 @@ access_fn_component_p (tree op)
 }
 }
 
+/* Returns whether BASE can have a access_fn_component_p with BASE
+   as base.  */
+
+static bool
+base_supports_access_fn_components_p (tree base)
+{
+  switch (TREE_CODE (TREE_TYPE (base)))
+{
+case COMPLEX_TYPE:
+case ARRAY_TYPE:
+case RECORD_TYPE:
+  return true;
+default:
+  return false;
+}
+}
+
 /* Determines the base object and the list of indices of memory reference
DR, analyzed in LOOP and instantiated before NEST.  */
 
@@ -3272,8 +3289,13 @@ initialize_data_dependence_relation (struct 
data_reference *a,
  && full_seq.start_b + full_seq.length == num_dimensions_b
  && DR_UNCONSTRAINED_BASE (a) == DR_UNCONSTRAINED_BASE (b)
  && operand_equal_p (base_a, base_b, OEP_ADDRESS_OF)
- && types_compatible_p (TREE_TYPE (base_a),
-TREE_TYPE (base_b))
+ && (types_compatible_p (TREE_TYPE (base_a),
+ TREE_TYPE (base_b))
+ || (!base_supports_access_fn_components_p (base_a)
+ && !base_supports_access_fn_components_p (base_b)
+ && operand_equal_p
+  (TYPE_SIZE (TREE_TYPE (base_a)),
+   TYPE_SIZE (TREE_TYPE (base_b)), 0)))
  && (!loop_nest.exists ()
  || (object_address_invariant_in_loop_p
  (loop_nest[0], base_a;
-- 
2.26.2

Re: [PATCH] Add pytest for a GCOV test-case

[Martin Liška]

On 1/14/21 2:22 PM, Rainer Orth wrote:

Hi Martin,


* Besides, the test outcomes are not generic message facilities but are
supposed to follow a common format:
:  []
with  the pathname to the test relative to (in this case)
gcc/testsuite.  In this case, this might be something like
UNSUPPORTED: g++.dg/gcov/pr98273.C run-gcov-pytest
Currently, you don't have the pathname in run-gcov-pytest, though.


All right, now one will see:

UNSUPPORTED: g++.dg/gcov/pr98273.C run-gcov-pytest could not find Python
interpreter and (or) pytest module


Hello.



please shorten this quite a bit: maybe

... run-gcov-pytest python3 pytest missing


Sure, done.




* If we now have an (even optional) dependency on python/pytest, this
(with the exact versions and use) needs to be documented in
install.texi.


Done that.


+be installed. Some optional tests also require Python3 and pytest module.

It would be better to be more specific here.  Or would Python 3.0 and
pytest 2.0.0 do ;-)


I would leave it as it is. Python3 is a well established term. About pytest:
I don't know how to investigate a minimal version right now.




* On to the implementation: your test for the presence of pytest is
wrong:
  set result [remote_exec host "pytest -m pytest --version"]
has nothing to do with what you actually use later: on all of Fedora
29, Ubuntu 20.04, and Solaris 11.4 (with a caveat) pytest is Python
2.7 based, but you don't check that.  It is well possible that pytest
for 2.7 is installed, but pytest for Python 3.x isn't.
Besides, while Solaris 11.4 does bundle pytest, they don't deliver
pytest, but only py.test due to a conflict with a different pytest from
logilab-common, cf. https://github.com/pytest-dev/pytest/issues/1833.
This is immaterial, however, since what you actually run is
  spawn -noecho python3 -m pytest --color=no -rA -s --tb=no
$srcdir/$subdir/$pytest_script
So you should just run python3 -m pytest --version instead to check
for the presence of the version you're going to use.
Btw., there's a mess with pytest on Fedora 29: running the above gives


I must confirm this is mess. I definitely don't want to support Python2 and
I think
the best way would be to use 'env python3', hope it's portable enough.
@David: What do you think?


As I mentioned, it's not: Solaris 11.3 has no python3, only (for the 3.x
series) python3.4.

However, I don't understand what you expect to gain from running

$ env python3

rather than just

$ python3

(or a suitable Python 3.x version by any name)?


All right, let's replace it just with 'python3'.



I just had a quick look and the autoconf-archive has AX_PYTHON which
claims to do that:

https://www.gnu.org/software/autoconf-archive/ax_python.html

Unfortunately, it doesn't know about Python 3.8+ yet.


When running the test on Solaris 11.4 (with the bundled pytest 4.4.0),
I get
= test session starts
==
platform sunos5 -- Python 3.7.9, pytest-4.4.0, py-1.8.0, pluggy-0.9.0
rootdir: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov
collected 2 items
../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py
..
=== 2 passed in 0.04 seconds
===
while 4.6.9 on Linux gives
= test session starts
==
platform linux -- Python 3.8.2, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
rootdir: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov
collected 2 items
../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py
..
=== short test summary info

PASSED
../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_basics
PASSED
../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_lines
=== 2 passed in 0.17 seconds
===
Obviously pytest -rA was introduced only after 4.4.0 and the 'A' is
silently ignored.  Fortunately, I can just use -rap instead which
works with both versions.


This will be fixed by this:
env python3 -m pytest --color=no -rA -s --tb=no --version


No, as I already wrote: pytest 4.4.0 silently ignores -rA and doesn't
print the PASSED (or FAILED) lines.  With both versions, pytest -rap
worked for me instead.


Ah, all right, I fixed that.




After this has been processed by gcov.exp, g++.sum contains
PASS:
../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_basic
PASS:
../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_line
which is again completely wrong in light of what I wrote above on the
format of test names: it lacks 

Re: [PATCH] Add pytest for a GCOV test-case

[Rainer Orth]

Hi Martin,

>>> * If we now have an (even optional) dependency on python/pytest, this
>>>(with the exact versions and use) needs to be documented in
>>>install.texi.
>>
>> Done that.
>
> +be installed. Some optional tests also require Python3 and pytest module.
>
> It would be better to be more specific here.  Or would Python 3.0 and
> pytest 2.0.0 do ;-)

and a nit I just noticed: two spaces after full stop.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Add pytest for a GCOV test-case

[Rainer Orth]

Hi Martin,

>> * Besides, the test outcomes are not generic message facilities but are
>>supposed to follow a common format:
>>:  []
>>with  the pathname to the test relative to (in this case)
>>gcc/testsuite.  In this case, this might be something like
>>UNSUPPORTED: g++.dg/gcov/pr98273.C run-gcov-pytest
>>Currently, you don't have the pathname in run-gcov-pytest, though.
>
> All right, now one will see:
>
> UNSUPPORTED: g++.dg/gcov/pr98273.C run-gcov-pytest could not find Python
> interpreter and (or) pytest module

please shorten this quite a bit: maybe

... run-gcov-pytest python3 pytest missing

>> * If we now have an (even optional) dependency on python/pytest, this
>>(with the exact versions and use) needs to be documented in
>>install.texi.
>
> Done that.

+be installed. Some optional tests also require Python3 and pytest module.

It would be better to be more specific here.  Or would Python 3.0 and
pytest 2.0.0 do ;-)

>> * On to the implementation: your test for the presence of pytest is
>>wrong:
>>  set result [remote_exec host "pytest -m pytest --version"]
>>has nothing to do with what you actually use later: on all of Fedora
>>29, Ubuntu 20.04, and Solaris 11.4 (with a caveat) pytest is Python
>>2.7 based, but you don't check that.  It is well possible that pytest
>>for 2.7 is installed, but pytest for Python 3.x isn't.
>>Besides, while Solaris 11.4 does bundle pytest, they don't deliver
>>pytest, but only py.test due to a conflict with a different pytest from
>>logilab-common, cf. https://github.com/pytest-dev/pytest/issues/1833.
>>This is immaterial, however, since what you actually run is
>>  spawn -noecho python3 -m pytest --color=no -rA -s --tb=no
>> $srcdir/$subdir/$pytest_script
>>So you should just run python3 -m pytest --version instead to check
>>for the presence of the version you're going to use.
>>Btw., there's a mess with pytest on Fedora 29: running the above gives
>
> I must confirm this is mess. I definitely don't want to support Python2 and
> I think
> the best way would be to use 'env python3', hope it's portable enough.
> @David: What do you think?

As I mentioned, it's not: Solaris 11.3 has no python3, only (for the 3.x
series) python3.4.

However, I don't understand what you expect to gain from running

$ env python3

rather than just

$ python3

(or a suitable Python 3.x version by any name)?

I just had a quick look and the autoconf-archive has AX_PYTHON which
claims to do that:

https://www.gnu.org/software/autoconf-archive/ax_python.html

Unfortunately, it doesn't know about Python 3.8+ yet.

>>When running the test on Solaris 11.4 (with the bundled pytest 4.4.0),
>>I get
>> = test session starts
>> ==
>> platform sunos5 -- Python 3.7.9, pytest-4.4.0, py-1.8.0, pluggy-0.9.0
>> rootdir: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov
>> collected 2 items
>> ../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py
>> ..
>> === 2 passed in 0.04 seconds
>> ===
>> while 4.6.9 on Linux gives
>> = test session starts
>> ==
>> platform linux -- Python 3.8.2, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
>> rootdir: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov
>> collected 2 items
>> ../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py
>> ..
>> === short test summary info
>> 
>> PASSED
>> ../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_basics
>> PASSED
>> ../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_lines
>> === 2 passed in 0.17 seconds
>> ===
>>Obviously pytest -rA was introduced only after 4.4.0 and the 'A' is
>>silently ignored.  Fortunately, I can just use -rap instead which
>>works with both versions.
>
> This will be fixed by this:
> env python3 -m pytest --color=no -rA -s --tb=no --version

No, as I already wrote: pytest 4.4.0 silently ignores -rA and doesn't
print the PASSED (or FAILED) lines.  With both versions, pytest -rap
worked for me instead.

>>After this has been processed by gcov.exp, g++.sum contains
>> PASS:
>> ../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_basic
>> PASS:
>> ../../../../../../../../../../vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/gcov/test-pr98273.py::test_line
>>which is again completely wrong in light of what I wrote above on the
>>format of test names: it lacks the testname part completely and
>>contains absolute pathnames which makes it impossible to compare
>>testresults