Sυbmіtting Μanuѕcripts to a Multidisciplinary Scientific Јournаl

[Elliana Joseph]

If you no longer wish to receive ҽmαils from us, please ᴄlіᴄk here
 to unѕubѕсribe.
Рαper Invіtatіon
Main Reasons for Рαper Publіcatіоn with the Јournаl
1. Fast Schedule Overview:

   1. Sυbmіt a ραρer
   2. Pre-rеᴠiеwed result sent within 1-2 weekdays
   3. Peer-rеᴠiеwed result within 2-4 weeks
   4. Revision of your artіᴄle
   5. Sυbmіtted ραρer accepted
   6. Αrtiсle ρսblished in 40-60 days from submіssіоn


2. Μanuѕcript Transferal to Relevant Јournаl:
Under one discipline, some interrelated јοurnals are listed, which offers
you the opportunity to transfer the mаnuscriрt if you decide not to
continue with the sυbmіtted јοurnal.

3. Prominent Edіtоrial Team Μеmbеrs:
*American Јournаl of Aerospace Engineering* has an eligible Edіtоrial
Cοmmіttee with extensive aᴄadҽmiᴄ qualifications and this guarantees that
the јοurnal has high scientific standards and wide international coverage.
American Јournаl of Aerospace Engineering
Dear Hohnka, MJ; Miller, JA; Dacumos, KM...,
Great aᴄadҽmiᴄ value has been seen in your work ρսblished before so that we
hope to have the opportunity to ρսblish your other ραρers in this
peer-rеᴠiеwed јοurnal: American Јournаl of Aerospace Engineering (IՏՏΝ
Online: 2376-4821).
PuƄlisհ with the Јournаl
If you have any interest, kindly ᴄlіᴄk the following weƄѕite to sυbmіt the
ραρer:
http://www.ajaeroe.org/sfln/ycuEA
Јournаl's Main Information

   1. Peer-rеᴠiеwing ѕᴄholarly јοurnal in the rеsеαrch field of aerospace
   engineering.
   2. With јοurnal famed databases, such as CΝКI, Crossref, ЈournаlSeek,
   etc.
   3. With a professional crew of еdіtorial commіttее mеmƄеrs.
   4. PuƄlisհing rеsеαrch works under CC BY 4.0, under which you maintain
   the ᴄοpyright of your ρսblished works.

We strongly believe your significant ᴄontribυtion will make this јοurnal
reach a higher level of standards.
Here enϲloѕed the details of your rеsеαrch which has impressed us most:
Your study's tіtlҽ: Evaluation of Compiler-Induced Vulnerabilities
Your study's αƄstrαct: This ραρer explores computer security
vulnerabilities that are generated inadvertently by a compiler. By using a
novel approach of examining the assembly language and other intermediate
files generated by the compilation process, it has been successfully
demonstrated that the compiler's processing of the high-level source code
can create a vulnerable end product. Proper software assurance is intended
to provide confidence that software is frее from vulnerabilities, and
compiler-induced vulnerabilities reduce this confidence level. The
discovered vulnerabilities can be related to standard vulnerability
classes, side channel attacks, undefined behavior, and persistent state
violations. Additionally, the rеsеαrch revealed that the executable machine
code generated by the compiler can differ in structure from the original
source code due to simplifications and optimizations performed during the
compilation process that cannot be disabled. This rеsеαrch examined both
the open-source GNU C compiler and the Microsoft C/C++ compiler that is
part of the Microsoft Visual Studio package. Both of these compilers are
widely used and represent typical compilers in use today.

[Bug target/81357] Extra mov for zero extend of add

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Severity|normal  |enhancement
   Assignee|qing.zhao at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #14 from Andrew Pinski  ---
We get now on the trunk:
adrpx1, .LANCHOR0
add w2, w0, 1
add w0, w0, 1
str x2, [x1, #:lo12:.LANCHOR0]
ret
Which started in GCC 9 which added 2->2 combine.

[PATCHv2] [aarch64] Fix target/95969: __builtin_aarch64_im_lane_boundsi interferes with gimple

[apinski--- via Gcc-patches]

From: Andrew Pinski 

This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
we are not going to error out. It fixes the problem by the removal
of the function from the IR.

OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.

gcc/ChangeLog:

PR target/95969
* config/aarch64/aarch64-builtins.c (aarch64_fold_builtin_lane_check):
New function.
(aarch64_general_fold_builtin): Handle AARCH64_SIMD_BUILTIN_LANE_CHECK.
(aarch64_general_gimple_fold_builtin): Likewise.

gcc/testsuite/ChangeLog:

PR target/95969
* gcc.target/aarch64/lane-bound-1.c: New test.
* gcc.target/aarch64/lane-bound-2.c: New test.
---
 gcc/config/aarch64/aarch64-builtins.c | 35 +++
 .../gcc.target/aarch64/lane-bound-1.c | 14 
 .../gcc.target/aarch64/lane-bound-2.c | 10 ++
 3 files changed, 59 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/lane-bound-1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/lane-bound-2.c

diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index eef9fc0f444..119f67d4e4c 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -29,6 +29,7 @@
 #include "rtl.h"
 #include "tree.h"
 #include "gimple.h"
+#include "ssa.h"
 #include "memmodel.h"
 #include "tm_p.h"
 #include "expmed.h"
@@ -2333,6 +2334,27 @@ aarch64_general_builtin_rsqrt (unsigned int fn)
   return NULL_TREE;
 }
 
+/* Return true if the lane check can be removed as there is no
+   error going to be emitted.  */
+static bool
+aarch64_fold_builtin_lane_check (tree arg0, tree arg1, tree arg2)
+{
+  if (TREE_CODE (arg0) != INTEGER_CST)
+return false;
+  if (TREE_CODE (arg1) != INTEGER_CST)
+return false;
+  if (TREE_CODE (arg2) != INTEGER_CST)
+return false;
+
+  auto totalsize = wi::to_widest (arg0);
+  auto elementsize = wi::to_widest (arg1);
+  if (totalsize == 0 || elementsize == 0)
+return false;
+  auto lane = wi::to_widest (arg2);
+  auto high = wi::udiv_trunc (totalsize, elementsize);
+  return wi::ltu_p (lane, high);
+}
+
 #undef VAR1
 #define VAR1(T, N, MAP, FLAG, A) \
   case AARCH64_SIMD_BUILTIN_##T##_##N##A:
@@ -2353,6 +2375,11 @@ aarch64_general_fold_builtin (unsigned int fcode, tree 
type,
   VAR1 (UNOP, floatv4si, 2, ALL, v4sf)
   VAR1 (UNOP, floatv2di, 2, ALL, v2df)
return fold_build1 (FLOAT_EXPR, type, args[0]);
+  case AARCH64_SIMD_BUILTIN_LANE_CHECK:
+   gcc_assert (n_args == 3);
+   if (aarch64_fold_builtin_lane_check (args[0], args[1], args[2]))
+ return void_node;
+   break;
   default:
break;
 }
@@ -2440,6 +2467,14 @@ aarch64_general_gimple_fold_builtin (unsigned int fcode, 
gcall *stmt)
}
  break;
}
+case AARCH64_SIMD_BUILTIN_LANE_CHECK:
+  if (aarch64_fold_builtin_lane_check (args[0], args[1], args[2]))
+   {
+ unlink_stmt_vdef (stmt);
+ release_defs (stmt);
+ new_stmt = gimple_build_nop ();
+   }
+  break;
 default:
   break;
 }
diff --git a/gcc/testsuite/gcc.target/aarch64/lane-bound-1.c 
b/gcc/testsuite/gcc.target/aarch64/lane-bound-1.c
new file mode 100644
index 000..bbbe679fd80
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/lane-bound-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+#include 
+
+void
+f (float32x4_t **ptr)
+{
+  float32x4_t res = vsetq_lane_f32 (0.0f, **ptr, 0);
+  **ptr = res;
+}
+/* GCC should be able to remove the call to "__builtin_aarch64_im_lane_boundsi"
+   and optimize out the second load from *ptr.  */
+/* { dg-final { scan-tree-dump-times "__builtin_aarch64_im_lane_boundsi" 0 
"optimized" } } */
+/* { dg-final { scan-tree-dump-times " = \\\*ptr_" 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/lane-bound-2.c 
b/gcc/testsuite/gcc.target/aarch64/lane-bound-2.c
new file mode 100644
index 000..923c94687c6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/lane-bound-2.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+void
+f (void)
+{
+  __builtin_aarch64_im_lane_boundsi (16, 4, 0);
+  __builtin_aarch64_im_lane_boundsi (8, 8, 0);
+}
+/* GCC should be able to optimize these out before gimplification. */
+/* { dg-final { scan-tree-dump-times "__builtin_aarch64_im_lane_boundsi" 0 
"original" } } */
-- 
2.17.1

[Bug target/82139] unnecessary movapd with _mm_castsi128_pd to use BLENDPD on __m128i results

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-04
   Keywords||ra
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
It is worse on the trunk:
.L2:
movdqu  (%rdi), %xmm1
movdqu  (%rdi), %xmm0
addq$16, %rdi
paddd   %xmm3, %xmm1
paddd   %xmm2, %xmm0
blendpd $2, %xmm0, %xmm1
movups  %xmm1, -16(%rdi)
cmpq%rdi, %rax
jne .L2

Why two loads from %rdi here?
This is done during RA as far as I can tell.

[Bug target/81085] inefficient union with long double argument on 32-bit x86

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Blocks||101926


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved

[Bug middle-end/57485] memcpy in aggregate return not eliminated

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-06-01 00:00:00 |2021-9-3
   Severity|normal  |enhancement

--- Comment #4 from Andrew Pinski  ---
Interesting clang/LLVM have same optimization issue.  ICC can do the
optimization though.

[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above

[deller at gmx dot de via Gcc-bugs]

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

--- Comment #32 from deller at gmx dot de ---
Fixed in Linux kernel by declaring the extern int32 as char:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c42813b71a06a2ff4a155aa87ac609feeab76cf3

Re: [PATCH] [aarch64] Fix target/95969: __builtin_aarch64_im_lane_boundsi interferes with gimple

[Andrew Pinski via Gcc-patches]

On Fri, Sep 3, 2021 at 2:42 AM Richard Sandiford via Gcc-patches
 wrote:
>
> apinski--- via Gcc-patches  writes:
> > From: Andrew Pinski 
> >
> > This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> > we are not going to error out. It fixes the problem by the removal
> > of the function from the IR.
> >
> > OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> >
> > gcc/ChangeLog:
> >
> >   * config/aarch64/aarch64-builtins.c (aarch64_fold_builtin_lane_check):
> >   New function.
> >   (aarch64_general_fold_builtin): Handle 
> > AARCH64_SIMD_BUILTIN_LANE_CHECK.
> >   (aarch64_general_gimple_fold_builtin): Likewise.
> > ---
> >  gcc/config/aarch64/aarch64-builtins.c | 35 +++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/gcc/config/aarch64/aarch64-builtins.c 
> > b/gcc/config/aarch64/aarch64-builtins.c
> > index f6b41d9c200..d4414373aa4 100644
> > --- a/gcc/config/aarch64/aarch64-builtins.c
> > +++ b/gcc/config/aarch64/aarch64-builtins.c
> > @@ -29,6 +29,7 @@
> >  #include "rtl.h"
> >  #include "tree.h"
> >  #include "gimple.h"
> > +#include "ssa.h"
> >  #include "memmodel.h"
> >  #include "tm_p.h"
> >  #include "expmed.h"
> > @@ -2333,6 +2334,27 @@ aarch64_general_builtin_rsqrt (unsigned int fn)
> >return NULL_TREE;
> >  }
> >
> > +/* Return true if the lane check can be removed as there is no
> > +   error going to be emitted.  */
> > +static bool
> > +aarch64_fold_builtin_lane_check (tree arg0, tree arg1, tree arg2)
> > +{
> > +  if (TREE_CODE (arg0) != INTEGER_CST)
> > +return false;
> > +  if (TREE_CODE (arg1) != INTEGER_CST)
> > +return false;
> > +  if (TREE_CODE (arg2) != INTEGER_CST)
> > +return false;
> > +
> > +  auto totalsize = wi::to_widest (arg0);
> > +  auto elementsize = wi::to_widest (arg1);
> > +  if (totalsize == 0 || elementsize == 0)
> > +return false;
> > +  auto lane = wi::to_widest (arg2);
> > +  auto high = wi::udiv_trunc (totalsize, elementsize);
> > +  return wi::ltu_p (lane, high);
> > +}
> > +
> >  #undef VAR1
> >  #define VAR1(T, N, MAP, FLAG, A) \
> >case AARCH64_SIMD_BUILTIN_##T##_##N##A:
> > @@ -2353,6 +2375,11 @@ aarch64_general_fold_builtin (unsigned int fcode, 
> > tree type,
> >VAR1 (UNOP, floatv4si, 2, ALL, v4sf)
> >VAR1 (UNOP, floatv2di, 2, ALL, v2df)
> >   return fold_build1 (FLOAT_EXPR, type, args[0]);
> > +  case AARCH64_SIMD_BUILTIN_LANE_CHECK:
> > + if (n_args == 3
>
> Do we need this check?  If it's safe to rely on frontend testing
> for aarch64_general_gimple_fold_builtin then hopefully it should
> be here too.  I think an assert would be better.

I added it just in case, I do find it interesting that it was passed
but never checked.
>
> (FTR, we have extra checking for SVE because the overloaded functions
> don't have definite prototypes.)
>
> > + && aarch64_fold_builtin_lane_check (args[0], args[1], args[2]))
> > +   return fold_convert (void_type_node, integer_zero_node);
>
> Could this just be void_node instead?  VOID_CST is the tree constant
> code for void_type_node.

Oh I had missed there was such a thing, definitely better using that
instead of the above.

>
> It would be good to add the testcase, as a -fdump-tree-optimized test
> that checks for a single instance of { = \*ptr}.

Yes I was thinking about adding one but I will definitely add one now.

Thanks,
Andrew Pinski

>
> Thanks,
> Richard

gcc-10-20210903 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20210903 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20210903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision de2114d2f1792beae55dccb512c4c521b934e72b

You'll find:

 gcc-10-20210903.tar.xz   Complete GCC

  SHA256=bc19b8711cb7759f87a4ceae2d0a19037a7e29ed61392a528a9e13a6984f71aa
  SHA1=85580d14f5bb35881e12d1f9ceb55c01f337c026

Diffs from 10-20210827 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug tree-optimization/102196] -Wmaybe-uninitialized: Maybe generate helpful hints?

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW
 Blocks||24639
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Let me confirm this since it's along the lines of what I've been experimenting
with (i.e., printing notes with the conditionals).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/102198] New: Unused and nonsensical template instantiations used for return type inference end up in the output

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 102198
   Summary: Unused and nonsensical template instantiations used
for return type inference end up in the output
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

Input:

template
int* a() { return x; }

template
auto b() { return a; }

template
auto c() -> int* (*)()
{
static int x1;
return b<>();
}

int main(int argc, char** argv)
{
if constexpr (false)
{
static int x2;
b<>();
}
c();
c();
}

Compile with -O0.

Expected output: Compiles and links successfully.

Actual output, as of 7.2 through 11.2: Assembly output contains four
instantiations of a(), using template arguments c::x1, c::x1,
main::x2, and c::x1 (or whatever _ZZ1cIXT_EEPFPivEvE2x1 is
supposed to be, c++filt doesn't like it). There's no storage assigned for the
latter two, so they instantiations throw linker errors.

/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `_Z1aIXadL_ZZ1cIXT_EEPFPivEvE2x1EEES1_v':
:2: undefined reference to `_ZZ1cIXT_EEPFPivEvE2x1'
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `int* a<&(main::x2)>()':
:2: undefined reference to `main::x2'
collect2: error: ld returned 1 exit status

Actual output, as of current trunk:

: In instantiation of 'auto b() [with int* x = (& x1)]':
:5:6:   required from here
:5:6: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1965
5 | auto b() { return a; }
  |  ^
0x1f31a39 internal_error(char const*, ...)
???:0
0x79e1c7 fancy_abort(char const*, int, char const*)
???:0
0x8fe32b mangle_decl(tree_node*)
???:0
0x148f6b2 decl_assembler_name(tree_node*)
???:0
0x14c15d0 assign_assembler_name_if_needed(tree_node*)
???:0
0xc38855 cgraph_node::analyze()
???:0
0xc3cfdd symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The issues go away if I change main to  if constexpr (true)  or remove the
template from c(), if I put x1 and x2 in global scope, if I append  -> int*
(*)()  to b(), or if I enable -O1 or higher. Only the template variant gives
ICE,  if constexpr (false)  gives the same bad output in trunk as in 11.2
(after removing or neutralizing c()).

I don't know how many different issues this is, but they all look like
different facets of the same root cause (either the extra a() instantiations
should be discarded after determining b's return type, or they shouldn't be
created at all), so I'm filing one bug for them all.

Compiler Explorer: https://godbolt.org/z/89794xb8v

Re: Ping ^ 2: [PATCH] rs6000: Expand fmod and remainder when built with fast-math [PR97142]

[Segher Boessenkool]

Hi!

On Fri, Sep 03, 2021 at 10:31:24AM +0800, Xionghu Luo wrote:
> fmod/fmodf and remainder/remainderf could be expanded instead of library
> call when fast-math build, which is much faster.

Thank you very much for this patch.

Some trivial comments if you haven't commmitted it yet:

> +(define_expand "fmod3"
> +  [(use (match_operand:SFDF 0 "gpc_reg_operand"))
> + (use (match_operand:SFDF 1 "gpc_reg_operand"))
> + (use (match_operand:SFDF 2 "gpc_reg_operand"))]
> +  "TARGET_HARD_FLOAT
> +  && TARGET_FPRND
> +  && flag_unsafe_math_optimizations"

It should have one extra space before each && here:

  "TARGET_HARD_FLOAT
   && TARGET_FPRND
   && flag_unsafe_math_optimizations"

(so that everything inside of the string aligns).

> +(define_expand "remainder3"

(same here).

> +/* { dg-final { scan-assembler-not {\mbl fmod\M} } } */
> +/* { dg-final { scan-assembler-not {\mbl fmodf\M} } } */
> +/* { dg-final { scan-assembler-not {\mbl remainder\M} } } */
> +/* { dg-final { scan-assembler-not {\mbl remainderf\M} } } */

These are negative tests, so won't spuriously fail, but this does not
test for the function prefixes we can have.  See
gcc.target/powerpc/builtins-1.c for example.

Again, thank you, and thanks to everyone else for the patch review
action :-)


Segher

[Bug tree-optimization/102196] -Wmaybe-uninitialized: Maybe generate helpful hints?

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
What does the static analyzer say? It has its own warning for uninitialized
variables that ought to show the paths taken...

[Bug target/102107] protocol register (r12) corrupted before a tail call

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Segher Boessenkool  ---
(Hopefully) fixed on trunk, but it needs backports.

[PATCH] rs6000: Don't use r12 for CR save on ELFv2 (PR102107)

[Segher Boessenkool]

CR is saved and/or restored on some paths where GPR12 is already live
since it has a meaning in the calling convention in the ELFv2 ABI.

It is not completely clear to me that we can always use r11 here, but
it does seem save, there is checking code (to detect conflicts here),
and it is stage 1.  So here goes.


Segher


2021-09-03  Segher Boessenkool 

PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): On ELFv2 use r11
instead of r12 for CR save, in all cases.
---
 gcc/config/rs6000/rs6000-logue.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-logue.c b/gcc/config/rs6000/rs6000-logue.c
index 07337c4836a3..e363d56ecec0 100644
--- a/gcc/config/rs6000/rs6000-logue.c
+++ b/gcc/config/rs6000/rs6000-logue.c
@@ -3293,10 +3293,13 @@ rs6000_emit_prologue (void)
 
   /* If we need to save CR, put it into r12 or r11.  Choose r12 except when
  r12 will be needed by out-of-line gpr save.  */
-  cr_save_regno = ((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
-  && !(strategy & (SAVE_INLINE_GPRS
-   | SAVE_NOINLINE_GPRS_SAVES_LR))
-  ? 11 : 12);
+  if (DEFAULT_ABI == ABI_AIX
+  && !(strategy & (SAVE_INLINE_GPRS | SAVE_NOINLINE_GPRS_SAVES_LR)))
+cr_save_regno = 11;
+  else if (DEFAULT_ABI == ABI_ELFv2)
+cr_save_regno = 11;
+  else
+cr_save_regno = 12;
   if (!WORLD_SAVE_P (info)
   && info->cr_save_p
   && REGNO (frame_reg_rtx) != cr_save_regno
-- 
1.8.3.1

[Bug target/102107] protocol register (r12) corrupted before a tail call

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:2484f7a4b0f52e6ed04754be336f1fa6fde47f6b

commit r12-3353-g2484f7a4b0f52e6ed04754be336f1fa6fde47f6b
Author: Segher Boessenkool 
Date:   Thu Sep 2 16:38:24 2021 +

rs6000: Don't use r12 for CR save on ELFv2 (PR102107)

CR is saved and/or restored on some paths where GPR12 is already live
since it has a meaning in the calling convention in the ELFv2 ABI.

It is not completely clear to me that we can always use r11 here, but
it does seem save, there is checking code (to detect conflicts here),
and it is stage 1.  So here goes.

2021-09-03  Segher Boessenkool 

PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): On ELFv2 use
r11
instead of r12 for CR save, in all cases.

[Bug tree-optimization/102196] -Wmaybe-uninitialized: Maybe generate helpful hints?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
tc-microblaze.c case:

  if (exp.X_op != O_constant)
as_warn (_("Symbol used as immediate for shift instruction"));
  else
{
  output = frag_more (isize);
  immed = exp.X_add_number;
}

  if (immed != (immed % 32))
{
  as_warn (_("Shift value > 32. using "));
  immed = immed % 32;
}


Maybe we could print out the pathes which set it but I don't think that is
useful. Especially in this case it where it is just set a few lines above.



The next one there is the same:
  if (exp.X_op != O_constant) {
as_warn(_("Symbol used as immediate for mbar instruction"));
  } else {
output = frag_more (isize);
immed = exp.X_add_number;
  }
  if (immed != (immed % 32)) {
as_warn(_("Immediate value for mbar > 32. using "));
immed = immed % 32;
  }


config/tc-mcore.c is much more complex, there is a switch table and on some
pathes output variable is not set.

Showing the path in the case of tc-mcore.c is going to be problemantic and
might not actually show the correct thing always.

Note I do think you should file a binutils bug since those obvious bugs there.

[Bug c++/99215] coroutines: debugging with gdb

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Iain Sandoe  ---
also :

https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352947.html
https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352948.html
https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/352949.html

[Bug tree-optimization/102196] -Wmaybe-uninitialized: Maybe generate helpful hints?

[jbglaw--- via Gcc-bugs]

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

--- Comment #2 from Jan-Benedict Glaw  ---
Declaration and possibly uninitialized usage are shown. Ie for said Binutils, I
get these messages:

 microblaze-{elf,linux}

[all 2021-09-03 18:17:30] depbase=`echo config/tc-microblaze.o | sed
's|[^/]*$|.deps/&|;s|\.o$||'`;\
[all 2021-09-03 18:17:30] /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -I. 
-I. -I. -I../bfd -I./config -I./../include -I./.. -I./../bfd
-DLOCALEDIR="\"/tmp/gas-microblaze-elf/share/locale\""  -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
-Wwrite-strings -I./../zlib -g -O2   -MT config/tc-microblaze.o -MD -MP -MF
$depbase.Tpo -c -o config/tc-microblaze.o config/tc-microblaze.c &&\
[all 2021-09-03 18:17:30] mv -f $depbase.Tpo $depbase.Po
[all 2021-09-03 18:17:32] config/tc-microblaze.c: In function 'md_assemble':
[all 2021-09-03 18:17:32] config/tc-microblaze.c:1170:27: error: 'immed' may be
used uninitialized [-Werror=maybe-uninitialized]
[all 2021-09-03 18:17:32]  1170 |   if (immed != (immed % 32))
[all 2021-09-03 18:17:32]   |~~~^
[all 2021-09-03 18:17:32] config/tc-microblaze.c:918:16: note: 'immed' declared
here
[all 2021-09-03 18:17:32]   918 |   unsigned int immed, temp;
[all 2021-09-03 18:17:32]   |^
[all 2021-09-03 18:17:32] config/tc-microblaze.c:1746:27: error: 'immed' may be
used uninitialized [-Werror=maybe-uninitialized]
[all 2021-09-03 18:17:32]  1746 |   if (immed != (immed % 32)) {
[all 2021-09-03 18:17:32]   |~~~^
[all 2021-09-03 18:17:32] config/tc-microblaze.c:918:16: note: 'immed' declared
here
[all 2021-09-03 18:17:32]   918 |   unsigned int immed, temp;
[all 2021-09-03 18:17:32]   |^
[all 2021-09-03 18:17:32] cc1: all warnings being treated as errors
[all 2021-09-03 18:17:32] make[3]: *** [Makefile:1238: config/tc-microblaze.o]
Error 1


 mcore-elf
~~~
[all 2021-09-03 18:17:17] depbase=`echo config/tc-mcore.o | sed
's|[^/]*$|.deps/&|;s|\.o$||'`;\
[all 2021-09-03 18:17:17] /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -I. 
-I. -I. -I../bfd -I./config -I./../include -I./.. -I./../bfd
-DLOCALEDIR="\"/tmp/gas-mcore-elf/share/locale\""  -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -Wwrite-strings
-I./../zlib -g -O2   -MT config/tc-mcore.o -MD -MP -MF $depbase.Tpo -c -o
config/tc-mcore.o config/tc-mcore.c &&\
[all 2021-09-03 18:17:17] mv -f $depbase.Tpo $depbase.Po
[all 2021-09-03 18:17:19] config/tc-mcore.c: In function 'md_assemble':
[all 2021-09-03 18:17:19] config/tc-mcore.c:1599:9: error: 'output' may be used
uninitialized [-Werror=maybe-uninitialized]
[all 2021-09-03 18:17:19]  1599 |   output[0] = INST_BYTE0 (inst);
[all 2021-09-03 18:17:19]   |   ~~^~~
[all 2021-09-03 18:17:19] config/tc-mcore.c:855:10: note: 'output' declared
here
[all 2021-09-03 18:17:19]   855 |   char * output;
[all 2021-09-03 18:17:19]   |  ^~
[all 2021-09-03 18:17:19] config/tc-mcore.c:1599:9: error: 'output' may be used
uninitialized [-Werror=maybe-uninitialized]
[all 2021-09-03 18:17:19]  1599 |   output[0] = INST_BYTE0 (inst);
[all 2021-09-03 18:17:19]   |   ~~^~~
[all 2021-09-03 18:17:19] config/tc-mcore.c:855:10: note: 'output' declared
here
[all 2021-09-03 18:17:19]   855 |   char * output;
[all 2021-09-03 18:17:19]   |  ^~
[all 2021-09-03 18:17:19] config/tc-mcore.c:1599:9: error: 'output' may be used
uninitialized [-Werror=maybe-uninitialized]
[all 2021-09-03 18:17:19]  1599 |   output[0] = INST_BYTE0 (inst);
[all 2021-09-03 18:17:19]   |   ~~^~~
[all 2021-09-03 18:17:19] config/tc-mcore.c:855:10: note: 'output' declared
here
[all 2021-09-03 18:17:19]   855 |   char * output;
[all 2021-09-03 18:17:19]   |  ^~
[all 2021-09-03 18:17:20] cc1: all warnings being treated as errors
[all 2021-09-03 18:17:20] make[3]: *** [Makefile:1238: config/tc-mcore.o] Error
1


Unfortunately, the toolchain testing host isn't yet publically hosted, so it's
not yet IPv4-reachable... Once moved to the DC, I'll announce it.

[Bug tree-optimization/102188] Over widening detection doesn't work when no range information

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit #38

[mailnew4ster at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Paul Jackson  ---
Maybe I'm missing something, but even this dll crashes for me now. So it seems
like it has nothing to do with global variables or static storage. That sucks,
it means that I just can't use C++ in dlls. Or is it? How come nobody noticed
it before?

I hope that I'm missing something here.

```
#include 

void x()
{
std::vector v;
v.push_back(2);
}
```

[Bug target/102197] New: ABI to pass and return 32-bit FP vectors

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 102197
   Summary: ABI to pass and return 32-bit FP vectors
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-cfl-2 pr102143]$ cat v1sf.c
typedef float __v1sf __attribute__ ((__vector_size__ (4)));

struct s1sf
{
  float f;
};

extern __v1sf v1sf;
extern struct s1sf s1sf;

extern void foo1 (__v1sf);
extern void bar1 (struct s1sf);

__v1sf
foo2 (void)
{
  foo1 (v1sf);
  return v1sf;
}

struct s1sf
bar2 (void)
{
  bar1 (s1sf);
  return s1sf;
}
[hjl@gnu-cfl-2 pr102143]$ make v1sf.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -S
v1sf.c
[hjl@gnu-cfl-2 pr102143]$ cat v1sf.s
.file   "v1sf.c"
.text
.p2align 4
.globl  foo2
.type   foo2, @function
foo2:
.LFB0:
.cfi_startproc
pushq   %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
movq%rdi, %r12
subq$32, %rsp
.cfi_def_cfa_offset 48
movlv1sf(%rip), %eax
movl%eax, (%rsp)
callfoo1
movlv1sf(%rip), %eax
movl%eax, (%r12)
addq$32, %rsp
.cfi_def_cfa_offset 16
movq%r12, %rax
popq%r12
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   foo2, .-foo2
.p2align 4
.globl  bar2
.type   bar2, @function
bar2:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movss   s1sf(%rip), %xmm0
callbar1
movss   s1sf(%rip), %xmm0
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   bar2, .-bar2
.ident  "GCC: (GNU) 12.0.0 20210902 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr102143]$ 

Should __v1sf be passed and returned like struct s1sf?

[Bug tree-optimization/102196] -Wmaybe-uninitialized: Maybe generate helpful hints?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-09-03
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
They should show the usage of the variable and where the declaration of the
variable is.
Can you show what output you get from compiling binutils?
Maybe even attach the preprocessed source.

[Bug target/101933] Unloaded dll with global std::mutex causes exe to crash on exit #38

[mailnew4ster at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Paul Jackson  ---
I tried to work around the problem, and it's even worse than I expected. You
can replace dll.cc with the following and observe the same crash.

That means that even if I want to do manual memory management with raw
pointers, I can't. Please, consider fixing at least this.

```
#include 

struct {
std::vector v;
} *test;

void x()
{
if (test) {
test->v.push_back(2);
}
}
```

[Bug driver/102193] DLL linking with a external referenced DLL

[arsoftware25 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ricardo Santos Pereira  ---
thanks

BW

Em sex., 3 de set. de 2021 às 16:02, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> escreveu:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102193
>
> Andrew Pinski  changed:
>
>What|Removed |Added
>
> 
>Last reconfirmed||2021-09-03
>  Ever confirmed|0   |1
>   Component|c   |driver
>  Status|UNCONFIRMED |WAITING
>
> --- Comment #1 from Andrew Pinski  ---
> Can you attach a testcase and exactly what you want to warn about?  Also
> GCC
> does not handle the linker so this might be a binutils issue
> (http://sourceware.org/bugzilla).
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug debug/102195] Missing DW_TAG_typedef when using qualified variable of typedef'd array

[ibhagatgnu at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Indu Bhagat  ---
(In reply to Andrew Pinski from comment #1)
> I think this is a dup of bug 8354.

Possible. It looks like two distinct symptoms, but seem to be originating from
the same underlying issue. I don't have enough expertise here to comment
further.

When I looked around a bit, the difference I noted is that in the function
dwarf2out.c:modified_type_die, the qualified_type returned is NULL for
typedef1.c but non-NULL for typedef3.c. 

dwarf2out.c:modified_type_die () :

  /* See if we already have the appropriately qualified variant of
 this type.  */
  qualified_type = get_qualified_type (type, cv_quals);

Noting that the TREE information is organized differently for array vs not.

[Bug middle-end/102196] New: -Wmaybe-uninitialized: Maybe generate helpful hints?

[jbglaw--- via Gcc-bugs]

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

Bug ID: 102196
   Summary: -Wmaybe-uninitialized: Maybe generate helpful hints?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Hi!

I don't know the code behind -Wmaybe-uninitialized, but maybe it's possible to
show the path GCC considered when emitting this message?

Right now, with Debian's "gcc-snapshot" compiler, I cannot successfully "make
all-gas" for the microblaze-elf and mcore-elf targets (with current binutils at
0b99a66053fa1e93a984f75a7a3d5343c74882fb) due to a maybe-uninitialized warning
in md_assemble() which is kind of unpleasant to find the possible way through
the assignment maze...

My personal impression is that usually, the maybe-uninitialized warnings are
quite helpful, but it's somewhat tedious to track them down. As I'm revamping
my toolchain testing efforts, these show up every now and then.

Thanks,
  Jan-Benedict

[Bug fortran/101349] ICE in gfc_get_descriptor_field, at fortran/trans-array.c:140

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:f826c257b6fb64868fd12a52291d1b6f85e1689a

commit r11-8958-gf826c257b6fb64868fd12a52291d1b6f85e1689a
Author: Harald Anlauf 
Date:   Mon Aug 30 22:41:01 2021 +0200

Fortran - correct check for constraint F2008:C628 / F2018:C932

gcc/fortran/ChangeLog:

PR fortran/101349
* resolve.c (resolve_allocate_expr): An unlimited polymorphic
argument to ALLOCATE must be ALLOCATABLE or a POINTER.  Fix the
corresponding check.

gcc/testsuite/ChangeLog:

PR fortran/101349
* gfortran.dg/unlimited_polymorphic_33.f90: New test.

(cherry picked from commit 9213ff13247739d6d335064a6b568278a872a991)

Re: [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups (PR 74765)

[Thomas Schwinge]

Hi!

Martin, thanks for your review.  Now need someone to formally approve the
third patch.

On 2021-09-01T18:14:46-0600, Martin Sebor  wrote:
> On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>> On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches 
>>  wrote:
>>> On 6/22/21 5:28 PM, David Malcolm wrote:
 On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
> On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
>> The attached patch introduces the suppress_warning(),
>> warning_suppressed(), and copy_no_warning() APIs [etc.]

>> I now had a bit of a deep dive into some aspects of this, in context of
>>  "gcc/sparseset.h:215:20: error: suggest
>> parentheses around assignment used as truth value [-Werror=parentheses]"
>> that I recently filed.  This seems difficult to reproduce, but I'm still
>> able to reliably reproduce it in one specific build
>> configuration/directory/machine/whatever.  Initially, we all quickly
>> assumed that it'd be some GC issue -- but "alas", it's not, at least not
>> directly.  (But I'll certainly assume that some GC aspects are involved
>> which make this issue come and go across different GCC sources revisions,
>> and difficult to reproduce.)

>> First, two pieces of cleanup:

ACKed by Martin, again attached for convenience.


>>> --- /dev/null
>>> +++ b/gcc/diagnostic-spec.h
>>
>>> +typedef location_t key_type_t;
>>> +typedef int_hash  xint_hash_t;

> By the way, it seems we should probably also use a manifest constant
> for Empty (probably UNKNOWN_LOCATION since we're reserving it).

Yes, that will be part of another patch here -- waiting for approval of
"Generalize 'gcc/input.h:struct location_hash'" posted elsewhere.


>> attached "Don't maintain a warning spec for
>> 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION' [PR101574]".  OK to push?
>
> [...].  So I agree that it ought to be fixed.

>> I'm reasonably confident that my changes are doing the right things in
>> general, but please carefully review, especially here:
>>
>>- 'gcc/warning-control.cc:suppress_warning' functions: is it correct to
>>  conditionalize on '!RESERVED_LOCATION_P' the 'suppress_warning_at'
>>  calls and 'supp' update?  Or, should instead 'suppress_warning_at'
>>  handle the case of '!RESERVED_LOCATION_P'?  (How?)
>
> It seems like six of one vs half a dozen of the other.  I'd say go
> with whatever makes more sense to you here :)

OK, was just trying to make sure that I don't fail to see any non-obvious
intentions here.

>>- 'gcc/diagnostic-spec.c:copy_warning' and
>>  'gcc/warning-control.cc:copy_warning': is the rationale correct for
>>  the 'gcc_checking_assert (!from_spec)': "If we cannot set no-warning
>>  dispositions for 'to', ascertain that we don't have any for 'from'.
>>  Otherwise, we'd lose these."?  If the rationale is correct, then
>>  observing that in 'gcc/warning-control.cc:copy_warning' this
>>  currently "triggers during GCC build" is something to be looked into,
>>  later, I suppose, and otherwise, how should I change this code?
>
> copy_warning(location_t, location_t) is called [only] from
> gimple_set_location().  The middle end does clear the location of
> some statements for which it was previously valid (e.g., return
> statements).

What I observed was that the 'assert' never triggered for the
'location_t' variant "called [only] from gimple_set_location" -- but does
trigger for some other variant.  Anyway:

> So I wouldn't expect this assumption to be safe.  If
> that happens, we have no choice but to lose the per-warning detail
> and fall back on the no-warning bit.

ACK.  I'm thus clarifying that as follows:

--- gcc/diagnostic-spec.c
+++ gcc/diagnostic-spec.c
@@ -185,7 +185,5 @@ copy_warning (location_t to, location_t from)
   if (RESERVED_LOCATION_P (to))
-{
-  /* If we cannot set no-warning dispositions for 'to', ascertain that 
we
-don't have any for 'from'.  Otherwise, we'd lose these.  */
-  gcc_checking_assert (!from_spec);
-}
+/* We cannot set no-warning dispositions for 'to', so we have no 
chance but
+   lose those potentially set for 'from'.  */
+;
   else
--- gcc/warning-control.cc
+++ gcc/warning-control.cc
@@ -197,9 +197,5 @@ void copy_warning (ToType to, FromType from)
   if (RESERVED_LOCATION_P (to_loc))
-{
-#if 0 //TODO triggers during GCC build
-  /* If we cannot set no-warning dispositions for 'to', ascertain that 
we
-don't have any for 'from'.  Otherwise, we'd lose these.  */
-  gcc_checking_assert (!from_spec);
-#endif
-}
+/* We cannot set no-warning dispositions for 'to', so we have no 
chance but
+   lose those potentially set for 'from'.  */
+;
   else

> (Either David or a middle end maintainer will need to approve the last
> patch once it's final.)

As far as I'm concerned that would 

[Bug fortran/102113] parsing error in assigned goto

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:95553bfcc3a69afc2a2bc02aeafac6e92d3dea1e

commit r11-8957-g95553bfcc3a69afc2a2bc02aeafac6e92d3dea1e
Author: Harald Anlauf 
Date:   Mon Aug 30 23:07:56 2021 +0200

Fortran - fix whitespace issue during parsing of assigned goto

gcc/fortran/ChangeLog:

PR fortran/102113
* match.c (gfc_match_goto): Allow for whitespace in parsing list
of labels.

gcc/testsuite/ChangeLog:

PR fortran/102113
* gfortran.dg/goto_9.f90: New test.

(cherry picked from commit a7083b83e45852540a4a09ee11b74dc28d777399)

[Bug driver/102189] error: unrecognized command-line option '-fno-[...]'; did you mean '-ftree-[...]'?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed||2021-09-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed

[Bug debug/102195] Missing DW_TAG_typedef when using qualified variable of typedef'd array

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=8354

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 8354.

Re: [r12-3321 Regression] FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) on Linux/x86_64

[H.J. Lu via Gcc-patches]

On Fri, Sep 3, 2021 at 10:25 AM Sandra Loosemore
 wrote:
>
> On 9/2/21 11:37 PM, Sandra Loosemore wrote:
> > On 9/2/21 10:18 PM, sunil.k.pandey wrote:
> >> On Linux/x86_64,
> >>
> >> 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
> >> commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7
> >> Author: Sandra Loosemore 
> >> Date:   Wed Aug 18 07:22:03 2021 -0700
> >>
> >>  libgfortran: Further fixes for GFC/CFI descriptor conversions.
> >>
> >> caused
> >>
> >> FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
> >> FAIL: gfortran.dg/PR100914.f90   -O1  (test for excess errors)
> >> FAIL: gfortran.dg/PR100914.f90   -O2  (test for excess errors)
> >> FAIL: gfortran.dg/PR100914.f90   -O3 -fomit-frame-pointer
> >> -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
> >> excess errors)
> >> FAIL: gfortran.dg/PR100914.f90   -O3 -g  (test for excess errors)
> >> FAIL: gfortran.dg/PR100914.f90   -Os  (test for excess errors)
> >
> > I did not see this failure in my own testing, but I also had this patch
> > for another known bug in my stack:
> >
> > https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html
> >
> > I just pinged that earlier this evening as it has not been reviewed yet.
> >   I'll rebuild/retest without that patch and confirm that's what the
> > problem is.
>
> I'm still not seeing these FAILs in my test results.  Can you provide
> any details about the "excess errors" it is producing?  E.g. is it the
> same missing libquadmath.h error reported here?
>
> https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html
>
> -Sandra

/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/testsuite/gfortran2/../../gfortran
-B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/testsuite/gfortran2/../../
-B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O0
-pedantic-errors
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c
-dumpbase  
-B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libatomic/.libs
-B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs
-lm -o ./PR100914.exe
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c:8:10:
fatal error: quadmath.h: No such file or directory
compilation terminated.
compiler exited with status 1
FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
Excess errors:
/export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c:8:10:
fatal error: quadmath.h: No such file or directory
compilation terminated.

I think some -B/-I is missing.

-- 
H.J.

[Bug debug/102195] New: Missing DW_TAG_typedef when using qualified variable of typedef'd array

[ibhagatgnu at gmail dot com via Gcc-bugs]

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

Bug ID: 102195
   Summary: Missing DW_TAG_typedef when using qualified variable
of typedef'd array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibhagatgnu at gmail dot com
  Target Milestone: ---

$ cat typedef1.c 
typedef int A[2][3];
const A a = {{4, 5, 6}, {7, 8, 9}};
$ gcc -g -c typedef1.c
$ objdump --dwarf=info typedef1.o

 <1><1e>: Abbrev Number: 3 (DW_TAG_array_type)
<1f>   DW_AT_type: <0x40>
<23>   DW_AT_sibling : <0x34>
 <2><27>: Abbrev Number: 1 (DW_TAG_subrange_type)
<28>   DW_AT_type: <0x39>
<2c>   DW_AT_upper_bound : 1
 <2><2d>: Abbrev Number: 1 (DW_TAG_subrange_type)
<2e>   DW_AT_type: <0x39>
<32>   DW_AT_upper_bound : 2
 <2><33>: Abbrev Number: 0
 <1><34>: Abbrev Number: 4 (DW_TAG_const_type)
<35>   DW_AT_type: <0x1e>
 <1><39>: Abbrev Number: 5 (DW_TAG_base_type)
<3a>   DW_AT_byte_size   : 8
<3b>   DW_AT_encoding: 7(unsigned)
<3c>   DW_AT_name: (indirect string, offset: 0x52): long unsigned
int
 <1><40>: Abbrev Number: 6 (DW_TAG_base_type)
<41>   DW_AT_byte_size   : 4
<42>   DW_AT_encoding: 5(signed)
<43>   DW_AT_name: int
 <1><47>: Abbrev Number: 7 (DW_TAG_variable)
<48>   DW_AT_name: a
<4a>   DW_AT_decl_file   : 1
<4b>   DW_AT_decl_line   : 2
<4c>   DW_AT_decl_column : 9
<4d>   DW_AT_type: <0x34>
<51>   DW_AT_external: 1
<51>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><5b>: Abbrev Number: 0

If typedef'd type is a base type / struct, DW_TAG_typedef shows up.

$ cat typedef3.c 
typedef struct foo
{
  int a;
  int b;
} bar;
const bar ba;

$ objdump --dwarf=info typedef3.o
 <1><1e>: Abbrev Number: 3 (DW_TAG_structure_type)
<1f>   DW_AT_name: foo
<23>   DW_AT_byte_size   : 8
<24>   DW_AT_decl_file   : 1
<25>   DW_AT_decl_line   : 1
<26>   DW_AT_decl_column : 16
<27>   DW_AT_sibling : <0x3e>
 <2><2b>: Abbrev Number: 1 (DW_TAG_member)
<2c>   DW_AT_name: a
<2e>   DW_AT_decl_file   : 1
<2e>   DW_AT_decl_line   : 3
<2f>   DW_AT_decl_column : 7
<2f>   DW_AT_type: <0x3e>
<33>   DW_AT_data_member_location: 0
 <2><34>: Abbrev Number: 1 (DW_TAG_member)
<35>   DW_AT_name: b
<37>   DW_AT_decl_file   : 1
<37>   DW_AT_decl_line   : 4
<38>   DW_AT_decl_column : 7
<38>   DW_AT_type: <0x3e>
<3c>   DW_AT_data_member_location: 4
 <2><3d>: Abbrev Number: 0
 <1><3e>: Abbrev Number: 4 (DW_TAG_base_type)
<3f>   DW_AT_byte_size   : 4
<40>   DW_AT_encoding: 5(signed)
<41>   DW_AT_name: int
 <1><45>: Abbrev Number: 5 (DW_TAG_typedef)
<46>   DW_AT_name: bar
<4a>   DW_AT_decl_file   : 1
<4b>   DW_AT_decl_line   : 5
<4c>   DW_AT_decl_column : 3
<4d>   DW_AT_type: <0x1e>
 <1><51>: Abbrev Number: 6 (DW_TAG_const_type)
<52>   DW_AT_type: <0x45>
 <1><56>: Abbrev Number: 7 (DW_TAG_variable)
<57>   DW_AT_name: ba
<5a>   DW_AT_decl_file   : 1
<5b>   DW_AT_decl_line   : 6
<5c>   DW_AT_decl_column : 11
<5d>   DW_AT_type: <0x51>
<61>   DW_AT_external: 1
<61>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><6b>: Abbrev Number: 0

[Bug driver/102193] DLL linking with a external referenced DLL

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-03
 Ever confirmed|0   |1
  Component|c   |driver
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Can you attach a testcase and exactly what you want to warn about?  Also GCC
does not handle the linker so this might be a binutils issue
(http://sourceware.org/bugzilla).

[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #30 from David Binderman  ---
(In reply to Trass3r from comment #27)
> This should really be enabled by -Wall or -Wextra as it generates code that
> may easily crash or corrupt something.

+1.

Clang errors, intel warns and for gcc you have to enable the somewhat
obscure flag -Wconditionally-supported to see anything at all.

gcc looks to be a trailer on this issue. It's not about standards conformance,
its about making it easy for users to find bugs.

Source code I used is:

struct S
{
S();
S( const S &);
~S();

char * p;
};

void f( int, ...);

void g()
{
S s1;

f( 3, s1);
};

$ /home/dcb/llvm/results/bin/clang++   sep3f.cc
sep3f.cc:19:8: error: cannot pass object of non-trivial type 'S' through
variadic function; call will abort at runtime [-Wnon-pod-varargs]
f( 3, s1);
  ^
1 error generated.

$ /home/dcb34/intel/oneapi/compiler/2021.3.0/linux/bin/intel64/icpc  sep3f.cc
sep3f.cc(19): warning #1595: a class type that is not trivially copyable passed
through ellipsis
f( 3, s1);
  ^

$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra  sep3f.cc
$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra
-Wconditionally-supported sep3f.cc
sep3f.cc: In function ‘void g()’:
sep3f.cc:19:10: warning: passing objects of non-trivially-copyable type ‘struct
S’ through ‘...’ is conditionally supported [-Wconditionally-supported]
   19 | f( 3, s1);
  | ~^~~~


I'll add flag -Wconditionally-supported to a build of Fedora and see
what happens.

Re: [committed] analyzer: support "bifurcation"; reimplement realloc [PR99260]

[Gerald Pfeifer]

On Mon, 30 Aug 2021, David Malcolm via Gcc-patches wrote:
> gcc/analyzer/ChangeLog:
>   PR analyzer/99260
>   * analyzer.h (class custom_edge_info): New class, adapted from
>   exploded_edge::custom_info_t.  Make member functions const.
>   Make update_model return bool, converting edge param from
>   reference to a pointer, and adding a ctxt param.
>   (class path_context): New class.
>   * call-info.cc: New file.
>   * call-info.h: New file.
>   * engine.cc: Include "analyzer/call-info.h" and .
>   (impl_region_model_context::impl_region_model_context): Update for
>   new m_path_ctxt field.
>   (impl_region_model_context::bifurcate): New.
>   (impl_region_model_context::terminate_path): New.

I believe it is this change that is causing bootstrap to fail with

  In file included from /scratch/tmp/gerald/GCC-HEAD/gcc/analyzer/engine.cc:69:
  In file included from /usr/include/c++/v1/memory:653:
  /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort' 
in name space 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~
  /usr/include/c++/v1/__config:782:15: note: expanded from macro '_VSTD'
  #define _VSTD std::_LIBCPP_ABI_NAMESPACE
^
  /scratch/tmp/gerald/GCC-HEAD/gcc/system.h:777:13: note: 'fancy_abort' 
declared here
  extern void fancy_abort (const char *, int, const char *)
  ^

This is on FreeBSD 11 with clang version 10.0.1 as system compiler and
libc++, which I assume is what triggers this?

Gerald

[Bug c++/102194] New: Incorrect explicit instantiation of constexpr variable accepted

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102194
   Summary: Incorrect explicit instantiation of constexpr variable
accepted
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This incorrect instantiation is accepted by GCC
```
template constexpr long long fib = fib + fib;
template<> constexpr long long fib<1> = 1;
template<> constexpr long long fib<2> = 1;
template long long fib<70>; // error here, `const` is missing
```

The correct last line must be:
```
template const long long fib<70>;
```

Re: [r12-3321 Regression] FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) on Linux/x86_64

[Sandra Loosemore]

On 9/2/21 11:37 PM, Sandra Loosemore wrote:

On 9/2/21 10:18 PM, sunil.k.pandey wrote:

On Linux/x86_64,

93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7
Author: Sandra Loosemore 
Date:   Wed Aug 18 07:22:03 2021 -0700

 libgfortran: Further fixes for GFC/CFI descriptor conversions.

caused

FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/PR100914.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/PR100914.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/PR100914.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)

FAIL: gfortran.dg/PR100914.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/PR100914.f90   -Os  (test for excess errors)


I did not see this failure in my own testing, but I also had this patch 
for another known bug in my stack:


https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html

I just pinged that earlier this evening as it has not been reviewed yet. 
  I'll rebuild/retest without that patch and confirm that's what the 
problem is.


I'm still not seeing these FAILs in my test results.  Can you provide 
any details about the "excess errors" it is producing?  E.g. is it the 
same missing libquadmath.h error reported here?


https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html

-Sandra

Re: [PATCH v3, Fortran] TS 29113 testsuite

[Sandra Loosemore]

On 9/3/21 3:14 AM, Tobias Burnus wrote:

If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html 
correctly, we should use _Float128 for the following errors


"The _Float128 type is supported on all systems where __float128 is 
supported or where long double has the IEEE binary128 format."


Applies to:


For
typecodes-array-float128.f90
FAIL: gfortran.dg/c-interop/typecodes-array-float128.f90   -O0  (test 
for excess errors)

Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-array-float128-c.c:35:32: 
error: '__float128' undeclared (first use in this function); did you 
mean '_Float128'?

typecodes-sanity.f90
FAIL: gfortran.dg/c-interop/typecodes-sanity.f90   -O0  (test for 
excess errors)

Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-sanity-c.c:41:13: 
error: '__float128' undeclared here (not in a function); did you mean 
'_Float128'?

typecodes-scalar-float128.f90
FAIL: gfortran.dg/c-interop/typecodes-scalar-float128.f90   -O0  (test 
for excess errors)

Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-scalar-float128-c.c:34:32: 
error: '__float128' undeclared (first use in this function); did you 
mean '_Float128'?


Just so I'm clear on this, the situation with ARM/AArch64 is that it 
provides _Float128 but not __float128?


The GNU Fortran manual explicitly defines C_FLOAT128 as corresponding to 
__float128, not _Float128 or some other 128-bit floating-point type.


https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gfortran/ISO_005fC_005fBINDING.html#ISO_005fC_005fBINDING

So the situation with ARM/AArch64 is that it provides _Float128 but not 
__float128?


I guess we could change the documentation and all the references in the 
implementation as well as the test cases to tie this kind to _Float128 
instead.  I think that is backward-compatible with all existing uses?



* * *

PR100914.f90
FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
Excess errors:
/gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: 
No such file or directory


Does ARM/Aarch64 provide _Float128 support without also providing 
libquadmath.h?  I'm trying to understand why it got that particular 
error.  :-S




  * * *

On a normal x86-64 system, I get XPASS for:

gfortran.dg/PR100914.f90

gfortran.dg/c-interop/typecodes-array-float128.f90

The ! { dg-do run { xfail { { x86_64*-*-* i?86*-*-* } && longdouble128 } 
} }

does not help as it just checks whether 'sizeof(long double)==16',
which seemingly passes also on x86-64 with 80bit long double.


I don't understand this, either.  I've been testing on an 
i686-pc-linux-gnu build with both -m32 and -m64.  The tests PASS on -m32 
and XFAIL on -m64.  The XFAIL is there because with -m64, sizeof (long 
double) == 16 and it can't be disambiguated from the true 128-bit 
floating point type __float128 which also has size 16, and the other 
patch I committed makes it choose the standard type over the GNU 
extension type.  With -m32, the 80-bit long double type has size 12 
instead so there is no conflict.


-Sandra

[Bug target/94630] General bug for changes needed to switch the powerpc64le-linux long double default

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:d9f215aa59cca00c862a14d3ee90e0b0ee4ed56f

commit r11-8954-gd9f215aa59cca00c862a14d3ee90e0b0ee4ed56f
Author: Michael Meissner 
Date:   Fri Sep 3 12:59:47 2021 -0400

Fix tests that require IBM 128-bit long double

2021-09-03  Michael Meissner  

gcc/testsuite/
PR target/94630
* gcc.target/powerpc/pr70117.c: Specify that we need the long
double
type to be IBM 128-bit.  Remove the code to use __ibm128.
Backport from master 2021-08-25.
* c-c++-common/dfp/convert-bfp-11.c: Specify that we need the long
double type to be IBM 128-bit.  Run the test at -O2 optimization.
Backport from master 2021-08-25.
* lib/target-supports.exp (add_options_for_long_double_ibm128): New
function.  Backport from master 2021-08-25.
(check_effective_target_long_double_ibm128): New function.
(add_options_for_long_double_ieee128): New function.
(check_effective_target_long_double_ieee128): New function.
(add_options_for_long_double_64bit): New function.
(check_effective_target_long_double_64bit): New function.

[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #5 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #4)
> Fixed on trunk, but I plan to backport it.

You neglected the recursive one.

#include 

std::tuple t;
auto t2 = std::move(t);

https://godbolt.org/z/b4jrs1fYb

[Bug target/102173] [12 Regression] ICEs gcc.target/aarch64/sve/acle/general-c/type_redef_1.c after recent error recovery patch

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Andrew Pinski  ---
Fxied by r12-3349-g6b69bf5729852d0510abbe8e04078ddecef0cf17.  I forgot to put
the PR # in the changelog area.

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Aldy Hernandez via Gcc-patches]

Patches welcome :-).

On Fri, Sep 3, 2021, 18:42 Martin Sebor  wrote:

> On 9/3/21 8:41 AM, Aldy Hernandez via Gcc-patches wrote:
> > [Andrew, do you see any problem with using the minus relational code
> > here?  It seems like everything matches up.]
> >
> > I've seen cases in the upcoming jump threader enhancements where we see
> > a difference of two pointers that are known to be equivalent, and yet we
> > fail to return 0 for the range.  This is because we have no working
> > range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
> > a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
> > adjust_pointer_diff_expr() could get a whack at it here:
> >
> > //def = __builtin_memchr (arg, 0, sz)
> > //n = def - arg
> > //
> > // The range for N can be narrowed to [0, PTRDIFF_MAX - 1].
>
> For the two statements above a tighter bound is possible: [0, sz).
>
> With no range info, sz can be assumed to be in [0, N], where N
> is one less than the smaller of PTRDIFF_MAX and the size of arg.
> (With PTRDIFF_MAX being only hypothetical.  max_object_size()
> should at some return the actual limit for the current target).
>
> The same (or even tighter) range can be derived from calls to
> other functions, including like mempcpy/stpcpy, or strchr, etc.
>
> Martin
>
> >
> > This patch adds the relational magic to range-op, which we can just
> > steal from the minus_expr code.
> >
> > Testing currently in progress.  I will commit pending tests.
> >
> > gcc/ChangeLog:
> >
> >   * range-op.cc (operator_minus::op1_op2_relation_effect): Abstract
> >   out to...
> >   (minus_op1_op2_relation_effect): ...here.
> >   (class operator_pointer_diff): New.
> >   (operator_pointer_diff::op1_op2_relation_effect): Call
> >   minus_op1_op2_relation_effect.
> >   (integral_table::integral_table): Add entry for POINTER_DIFF_EXPR.
> > ---
> >   gcc/range-op.cc | 45 ++---
> >   1 file changed, 38 insertions(+), 7 deletions(-)
> >
> > diff --git a/gcc/range-op.cc b/gcc/range-op.cc
> > index fee0e834c23..5e37133026d 100644
> > --- a/gcc/range-op.cc
> > +++ b/gcc/range-op.cc
> > @@ -1372,13 +1372,14 @@ operator_minus::wi_fold (irange , tree type,
> >   }
> >
> >   // Check to see if the relation REL between OP1 and OP2 has any effect
> on the
> > -// LHS of the expression.  If so, apply it to LHS_RANGE.
> > +// LHS of the expression.  If so, apply it to LHS_RANGE.  This is a
> helper
> > +// function for both MINUS_EXPR and POINTER_DIFF_EXPR.
> >
> > -bool
> > -operator_minus::op1_op2_relation_effect (irange _range, tree type,
> > -   const irange _range
> ATTRIBUTE_UNUSED,
> > -   const irange _range
> ATTRIBUTE_UNUSED,
> > -   relation_kind rel) const
> > +static bool
> > +minus_op1_op2_relation_effect (irange _range, tree type,
> > +const irange _range ATTRIBUTE_UNUSED,
> > +const irange _range ATTRIBUTE_UNUSED,
> > +relation_kind rel)
> >   {
> > if (rel == VREL_NONE)
> >   return false;
> > @@ -1440,6 +1441,16 @@ operator_minus::op1_op2_relation_effect (irange
> _range, tree type,
> > return true;
> >   }
> >
> > +bool
> > +operator_minus::op1_op2_relation_effect (irange _range, tree type,
> > +  const irange _range,
> > +  const irange _range,
> > +  relation_kind rel) const
> > +{
> > +  return minus_op1_op2_relation_effect (lhs_range, type, op1_range,
> op2_range,
> > + rel);
> > +}
> > +
> >   bool
> >   operator_minus::op1_range (irange , tree type,
> >  const irange ,
> > @@ -1459,6 +1470,26 @@ operator_minus::op2_range (irange , tree type,
> >   }
> >
> >
> > +class operator_pointer_diff : public range_operator
> > +{
> > +  virtual bool op1_op2_relation_effect (irange _range,
> > + tree type,
> > + const irange _range,
> > + const irange _range,
> > + relation_kind rel) const;
> > +} op_pointer_diff;
> > +
> > +bool
> > +operator_pointer_diff::op1_op2_relation_effect (irange _range, tree
> type,
> > + const irange _range,
> > + const irange _range,
> > + relation_kind rel) const
> > +{
> > +  return minus_op1_op2_relation_effect (lhs_range, type, op1_range,
> op2_range,
> > + rel);
> > +}
> > +
> > +
> >   class operator_min : public range_operator
> >   {
> >   public:
> > @@ -4018,7 +4049,7 @@ integral_table::integral_table ()
> > set (OBJ_TYPE_REF, op_identity);
> 

[Bug c/102193] New: DLL linking with a external referenced DLL

[arsoftware25 at gmail dot com via Gcc-bugs]

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

Bug ID: 102193
   Summary: DLL linking with a external referenced DLL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsoftware25 at gmail dot com
  Target Milestone: ---

Hi Corina

just figured out that a .def file in a dll may export function from a dll that
is referenced in the compilation stage like this:

gcc file.c external.dll def.def -o out.dll

if in the def.def it has a function that is in the file.c and also available in
external.dll it may generate an invalid out.dll

I don't know but this looks like a problem in gcc that need to be fixed, spend
one hour modifying my function in file.c and it was linking with external.dll

then I commented the function inside file.c and saw the compilation stage
finished without a link error

if it is a GCC feature then a warning about expernal DLL linkage could help a
lot when the function exported is inside an external DLL

hope to have explained it in an easy way

Ricardo

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Martin Sebor via Gcc-patches]

On 9/3/21 8:41 AM, Aldy Hernandez via Gcc-patches wrote:

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//  def = __builtin_memchr (arg, 0, sz)
//  n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].


For the two statements above a tighter bound is possible: [0, sz).

With no range info, sz can be assumed to be in [0, N], where N
is one less than the smaller of PTRDIFF_MAX and the size of arg.
(With PTRDIFF_MAX being only hypothetical.  max_object_size()
should at some return the actual limit for the current target).

The same (or even tighter) range can be derived from calls to
other functions, including like mempcpy/stpcpy, or strchr, etc.

Martin



This patch adds the relational magic to range-op, which we can just
steal from the minus_expr code.

Testing currently in progress.  I will commit pending tests.

gcc/ChangeLog:

* range-op.cc (operator_minus::op1_op2_relation_effect): Abstract
out to...
(minus_op1_op2_relation_effect): ...here.
(class operator_pointer_diff): New.
(operator_pointer_diff::op1_op2_relation_effect): Call
minus_op1_op2_relation_effect.
(integral_table::integral_table): Add entry for POINTER_DIFF_EXPR.
---
  gcc/range-op.cc | 45 ++---
  1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index fee0e834c23..5e37133026d 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1372,13 +1372,14 @@ operator_minus::wi_fold (irange , tree type,
  }
  
  // Check to see if the relation REL between OP1 and OP2 has any effect on the

-// LHS of the expression.  If so, apply it to LHS_RANGE.
+// LHS of the expression.  If so, apply it to LHS_RANGE.  This is a helper
+// function for both MINUS_EXPR and POINTER_DIFF_EXPR.
  
-bool

-operator_minus::op1_op2_relation_effect (irange _range, tree type,
- const irange _range ATTRIBUTE_UNUSED,
- const irange _range ATTRIBUTE_UNUSED,
- relation_kind rel) const
+static bool
+minus_op1_op2_relation_effect (irange _range, tree type,
+  const irange _range ATTRIBUTE_UNUSED,
+  const irange _range ATTRIBUTE_UNUSED,
+  relation_kind rel)
  {
if (rel == VREL_NONE)
  return false;
@@ -1440,6 +1441,16 @@ operator_minus::op1_op2_relation_effect (irange 
_range, tree type,
return true;
  }
  
+bool

+operator_minus::op1_op2_relation_effect (irange _range, tree type,
+const irange _range,
+const irange _range,
+relation_kind rel) const
+{
+  return minus_op1_op2_relation_effect (lhs_range, type, op1_range, op2_range,
+   rel);
+}
+
  bool
  operator_minus::op1_range (irange , tree type,
   const irange ,
@@ -1459,6 +1470,26 @@ operator_minus::op2_range (irange , tree type,
  }
  
  
+class operator_pointer_diff : public range_operator

+{
+  virtual bool op1_op2_relation_effect (irange _range,
+   tree type,
+   const irange _range,
+   const irange _range,
+   relation_kind rel) const;
+} op_pointer_diff;
+
+bool
+operator_pointer_diff::op1_op2_relation_effect (irange _range, tree type,
+   const irange _range,
+   const irange _range,
+   relation_kind rel) const
+{
+  return minus_op1_op2_relation_effect (lhs_range, type, op1_range, op2_range,
+   rel);
+}
+
+
  class operator_min : public range_operator
  {
  public:
@@ -4018,7 +4049,7 @@ integral_table::integral_table ()
set (OBJ_TYPE_REF, op_identity);
set (IMAGPART_EXPR, op_unknown);
set (REALPART_EXPR, op_unknown);
-  set (POINTER_DIFF_EXPR, op_unknown);
+  set (POINTER_DIFF_EXPR, op_pointer_diff);
set (ABS_EXPR, op_abs);
set (ABSU_EXPR, op_absu);
set (NEGATE_EXPR, op_negate);

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Aldy Hernandez via Gcc-patches]

On 9/3/21 5:41 PM, Jakub Jelinek wrote:

On Fri, Sep 03, 2021 at 09:09:59AM -0600, Jeff Law via Gcc-patches wrote:



On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:

On 9/3/21 10:41 AM, Aldy Hernandez wrote:

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//    def = __builtin_memchr (arg, 0, sz)
//    n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].


In theory... but do the non-equality relations make sense?   ie ptr1 <
ptr2   ?   Perhaps there is no harm in those..  Probably undefined
behaviour if they are not related so we can do whatever...

I'm pretty sure they're in the realm of undefined behavior if the pointers
point to different objects.  There was some code that would have cared about
this, but I think it mostly got cleaned up in response to Martin S's
diagnostic work over the last couple years.


Yeah.  Just note, [0, PTRDIFF_MAX - 1] range will be only for builtins
like memchr/strchr/mempcpy etc. that return either the passed argument or that 
pointer
incremented some number of times.  Generally pointer arith can go in both
directions, so POINTER_DIFF_EXPR can be negative too.
If one of the pointers points into some VAR_DECL object, the range could be
narrowed from the size of that object though.


The [0, PTRDIFF_MAX - 1] stuff I spoke of, is the code in 
adjust_pointer_diff_expr().  It is meant to be used when chasing the 
defining statement of a POINTER_DIFF_EXPR is in a specific form. 
Currently it only applies to __builtin_memchr.  I believe the code came 
from vr-values (or tree-vrp) at some point ??.


Do you think the code there should be ehanced to include other built-ins 
other than __builtin_memchr?  Patches welcome :)).


BTW, my proposed patch only deals with relations between the operands. 
It has nothing to do with builtins or other such uses.  For example, if 
both operands to a POINTER_DIFF_EXPR are equal, we can deduce that the 
result will be 0.  I frankly only care about the == and != relationship 
presently, but it was easy enough to hijack the MINUS_EXPR relation code.


Thanks.
Aldy


char a[26];

long
foo (long i, char *q)
{
   char *p = [0] + i;
   return q - p;
}
The minimum result will be if q points to [0] and p to [26], i.e.
-26, maximum the other way, so [-26, 26] range.

Jakub

Re: [Committed] [PATCH 2/4] (v4) On-demand locations within string-literals

[Thomas Schwinge]

Hi!

On 2021-09-02T21:09:54+0200, I wrote:
> On 2021-09-02T15:59:14+0200, I wrote:
>> On 2016-08-05T14:16:58-0400, David Malcolm  wrote:
>>> Committed to trunk as r239175; I'm attaching the final version of the
>>> patch for reference.
>>
>> David, you've added here 'gcc/input.h:struct location_hash' (see quoted
>> below), which will be useful elsewhere, so:
>>
>>> --- a/gcc/input.c
>>> +++ b/gcc/input.c
>>
>>> +/* Internal function.  Canonicalize LOC into a form suitable for
>>> +   use as a key within the database, stripping away macro expansion,
>>> +   ad-hoc information, and range information, using the location of
>>> +   the start of LOC within an ordinary linemap.  */
>>> +
>>> +location_t
>>> +string_concat_db::get_key_loc (location_t loc)
>>> +{
>>> +  loc = linemap_resolve_location (line_table, loc, LRK_SPELLING_LOCATION,
>>> + NULL);
>>> +
>>> +  loc = get_range_from_loc (line_table, loc).m_start;
>>> +
>>> +  return loc;
>>> +}
>>
>> OK to push the attached
>> "Harden 'gcc/input.c:string_concat_db::get_key_loc'"?  (This fell out of
>> my analysis for development work elsewhere.)
>
> My suggested patch was:
>
> --- a/gcc/input.c
> +++ b/gcc/input.c
> @@ -1483,6 +1483,9 @@ string_concat_db::get_key_loc (location_t loc)
>
>loc = get_range_from_loc (line_table, loc).m_start;
>
> +  /* Ascertain that 'loc' is valid as a key in 'm_table'.  */
> +  gcc_checking_assert (!RESERVED_LOCATION_P (loc));
> +
>return loc;
>  }
>
> Uh, I should've looked at the correct test logs...  This change actually
> does regress 'c-c++-common/substring-location-PR-87721.c' and
> 'gcc.dg/plugin/diagnostic-test-string-literals-1.c': for these, we do see
> 'BUILTINS_LOCATION' (via 'string_concat_db::record_string_concatenation').
> Unless someone tell me that's unexpected (I'm completely lost in this
> code...)

I think I convinced myself that the current code doesn't have stable
behavior, so...

> I shall change/generalize my changes to provide both a
> 'location_hash' only using 'UNKNOWN_LOCATION' as a spare value for
> 'Empty' (as currently used here) and another variant additionally using
> 'BUILTINS_LOCATION' as spare value for 'Deleted'.

... I didn't do this, but instead would like to push the attached
"Don't record string concatenation data for 'RESERVED_LOCATION_P'"
(replacing "Harden 'gcc/input.c:string_concat_db::get_key_loc'" as
originally proposed).  OK?


... and then re:

>>> --- a/gcc/input.h
>>> +++ b/gcc/input.h
>>
>>> +struct location_hash : int_hash  { };
>>> +
>>> +class GTY(()) string_concat_db
>>> +{
>>> +[...]
>>> +  hash_map  *m_table;
>>> +};
>>
>> OK to push the attached
>> "Generalize 'gcc/input.h:struct location_hash'"?

Attached again.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 9f1066fcb770397d6e791aa0594f067a755e2ed6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 3 Sep 2021 18:25:10 +0200
Subject: [PATCH] Don't record string concatenation data for
 'RESERVED_LOCATION_P'

'RESERVED_LOCATION_P' means 'UNKNOWN_LOCATION' or 'BUILTINS_LOCATION.
We're using 'UNKNOWN_LOCATION' as a spare value for 'Empty', so should
ascertain that we don't use it as a key additionally.  Similarly for
'BUILTINS_LOCATION' that we'd later like to use as a spare value for
'Deleted'.

As discussed in the source code comment added, for these we didn't have
stable behavior anyway.

Follow-up to r239175 (commit 88faa309e5d6c6171b957daaf2f800920869)
"On-demand locations within string-literals".

	gcc/
	* input.c (string_concat_db::record_string_concatenation)
	(string_concat_db::get_string_concatenation): Skip for
	'RESERVED_LOCATION_P'.
	gcc/testsuite/
	* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Adjust
	expected error diagnostics.
---
 gcc/input.c  | 9 +
 .../gcc.dg/plugin/diagnostic-test-string-literals-1.c| 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 4b809862e02..dd753decfa0 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1437,6 +1437,11 @@ string_concat_db::record_string_concatenation (int num, location_t *locs)
   gcc_assert (locs);
 
   location_t key_loc = get_key_loc (locs[0]);
+  /* We don't record data for 'RESERVED_LOCATION_P (key_loc)' key values:
+ any data now recorded under key 'key_loc' would be overwritten by a
+ subsequent call with the same key 'key_loc'.  */
+  if (RESERVED_LOCATION_P (key_loc))
+return;
 
   string_concat *concat
 = new (ggc_alloc  ()) string_concat (num, locs);
@@ -1460,6 +1465,10 @@ string_concat_db::get_string_concatenation (location_t loc,
   gcc_assert (out_locs);
 
   location_t key_loc = get_key_loc (loc);
+  /* We 

[Bug debug/101947] [12 Regression] Broken LTO bootstrap in get_base_type_offset, at dwarf2out.c:4330

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Eric Botcazou  ---
It's the DW_AT_byte_size expression in:

(gdb) p debug_dwarf_die (die)
DIE 1041: DW_TAG_structure_type (0x739f06e0)
  abbrev id: 51 offset: 1041 mark: 1
  DW_AT_name: "exp_dist__rpc_target"
  DW_AT_byte_size: location descriptor:
(0x739f0dc0) DW_OP_push_object_address 0, 0
(0x739f0e10) DW_OP_deref_type 4, die -> 0 (0x739f0af0)
(0x739f0e60) DW_OP_convert 0, 0
(0x739f0eb0) DW_OP_call4 die -> 0 (0x739f0a50), 0
(0x739f0f50) DW_OP_plus_uconst 7, 0
(0x739f0fa0) DW_OP_const1s 18446744073709551612, 0
(0x739f0960) DW_OP_and 0, 0

whose DW_OP_deref_type 4 operation uses:

DIE0: DW_TAG_base_type (0x739f0af0)
  abbrev id: 21 offset: 0 mark: 1
  DW_AT_byte_size: 4
  DW_AT_encoding: 5
  DW_AT_name: "SIGNED_32"
  DW_AT_artificial: 1

that was not initially referenced anywhere.

Re: [PATCH v3] rs6000: Add load density heuristic

[Bill Schmidt via Gcc-patches]

Hi Kewen,

Sorry that we lost track of this patch!  The heuristic approach looks 
good.  It is limited in scope and won't kick in often, and the case 
you're trying to account for is important.


At the time you submitted this, I think reliable P10 testing wasn't 
possible.  Now that it is, could you please do a quick sniff test to 
make sure there aren't any adjustments that need to be made for P10?  I 
doubt it, but worth checking.


Otherwise I have one comment below...

On 7/28/21 12:22 AM, Kewen.Lin wrote:

Hi,

v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html

This v3 addressed William's review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576154.html

It's mainly to deal with the bwaves_r degradation due to vector
construction fed by strided loads.

As Richi's comments [1], this follows the similar idea to over
price the vector construction fed by VMAT_ELEMENTWISE or
VMAT_STRIDED_SLP.  Instead of adding the extra cost on vector
construction costing immediately, it firstly records how many
loads and vectorized statements in the given loop, later in
rs6000_density_test (called by finish_cost) it computes the
load density ratio against all vectorized stmts, and check
with the corresponding thresholds DENSITY_LOAD_NUM_THRESHOLD
and DENSITY_LOAD_PCT_THRESHOLD, do the actual extra pricing
if both thresholds are exceeded.

Note that this new load density heuristic check is based on
some fields in target cost which are updated as needed when
scanning each add_stmt_cost entry, it's independent of the
current function rs6000_density_test which requires to scan
non_vect stmts.  Since it's checking the load stmts count
vs. all vectorized stmts, it's kind of density, so I put
it in function rs6000_density_test.  With the same reason to
keep it independent, I didn't put it as an else arm of the
current existing density threshold check hunk or before this
hunk.

In the investigation of -1.04% degradation from 526.blender_r
on Power8, I noticed that the extra penalized cost 320 on one
single vector construction with type V16QI is much exaggerated,
which makes the final body cost unreliable, so this patch adds
one maximum bound for the extra penalized cost for each vector
construction statement.

Bootstrapped & regtested *again* on powerpc64le-linux-gnu P9.

Full SPEC2017 performance evaluation on Power8/Power9 with
option combinations (with v2, as v3 is NFC against v2):
   * -O2 -ftree-vectorize {,-fvect-cost-model=very-cheap} {,-ffast-math}
   * {-O3, -Ofast} {,-funroll-loops}

bwaves_r degradations on P8/P9 have been fixed, nothing else
remarkable was observed.

Is it ok for trunk?

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570076.html

BR,
Kewen
-
gcc/ChangeLog:

* config/rs6000/rs6000.c (struct rs6000_cost_data): New members
nstmts, nloads and extra_ctor_cost.
(rs6000_density_test): Add load density related heuristics and the
checks, do extra costing on vector construction statements if need.
(rs6000_init_cost): Init new members.
(rs6000_update_target_cost_per_stmt): New function.
(rs6000_add_stmt_cost): Factor vect_nonmem hunk out to function
rs6000_update_target_cost_per_stmt and call it.



---
gcc/config/rs6000/rs6000.c | 119 ++---
1 file changed, 110 insertions(+), 9 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 279f00cc648..4e9087683dc 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5254,6 +5254,12 @@ typedef struct _rs6000_cost_data
{
  struct loop *loop_info;
  unsigned cost[3];
+  /* Total number of vectorized stmts (loop only).  */
+  unsigned nstmts;
+  /* Total number of loads (loop only).  */
+  unsigned nloads;
+  /* Possible extra penalized cost on vector construction (loop only).  */
+  unsigned extra_ctor_cost;
  /* For each vectorized loop, this var holds TRUE iff a non-memory vector
 instruction is needed by the vectorization.  */
  bool vect_nonmem;
@@ -5315,9 +5321,45 @@ rs6000_density_test (rs6000_cost_data *data)
  if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
 "density %d%%, cost %d exceeds threshold, penalizing "
-"loop body cost by %d%%", density_pct,
+"loop body cost by %d%%\n", density_pct,
 vec_cost + not_vec_cost, DENSITY_PENALTY);
}
+
+  /* Check if we need to penalize the body cost for latency and
+ execution resources bound from strided or elementwise loads
+ into a vector.  */
+  if (data->extra_ctor_cost > 0)
+{
+  /* Threshold for load stmts percentage in all vectorized stmts.  */
+  const int DENSITY_LOAD_PCT_THRESHOLD = 45;
+  /* Threshold for total number of load stmts.  */
+  const int DENSITY_LOAD_NUM_THRESHOLD = 20;
+
+  gcc_assert (data->nloads <= data->nstmts);
+  unsigned int 

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 03, 2021 at 09:09:59AM -0600, Jeff Law via Gcc-patches wrote:
> 
> 
> On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:
> > On 9/3/21 10:41 AM, Aldy Hernandez wrote:
> > > [Andrew, do you see any problem with using the minus relational code
> > > here?  It seems like everything matches up.]
> > > 
> > > I've seen cases in the upcoming jump threader enhancements where we see
> > > a difference of two pointers that are known to be equivalent, and yet we
> > > fail to return 0 for the range.  This is because we have no working
> > > range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
> > > a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
> > > adjust_pointer_diff_expr() could get a whack at it here:
> > > 
> > > //    def = __builtin_memchr (arg, 0, sz)
> > > //    n = def - arg
> > > //
> > > // The range for N can be narrowed to [0, PTRDIFF_MAX - 1].
> > > 
> > In theory... but do the non-equality relations make sense?   ie ptr1 <
> > ptr2   ?   Perhaps there is no harm in those..  Probably undefined
> > behaviour if they are not related so we can do whatever...
> I'm pretty sure they're in the realm of undefined behavior if the pointers
> point to different objects.  There was some code that would have cared about
> this, but I think it mostly got cleaned up in response to Martin S's
> diagnostic work over the last couple years.

Yeah.  Just note, [0, PTRDIFF_MAX - 1] range will be only for builtins
like memchr/strchr/mempcpy etc. that return either the passed argument or that 
pointer
incremented some number of times.  Generally pointer arith can go in both
directions, so POINTER_DIFF_EXPR can be negative too.
If one of the pointers points into some VAR_DECL object, the range could be
narrowed from the size of that object though.
char a[26];

long
foo (long i, char *q)
{
  char *p = [0] + i;
  return q - p;
}
The minimum result will be if q points to [0] and p to [26], i.e.
-26, maximum the other way, so [-26, 26] range.

Jakub

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Aldy Hernandez via Gcc-patches]

On 9/3/21 5:05 PM, Andrew MacLeod wrote:

On 9/3/21 10:41 AM, Aldy Hernandez wrote:

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//    def = __builtin_memchr (arg, 0, sz)
//    n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].

In theory... but do the non-equality relations make sense?   ie ptr1 < 
ptr2   ?   Perhaps there is no harm in those..  Probably undefined 
behaviour if they are not related so we can do whatever...


I originally just copy-pasted the stuff dealing with == and !=, but 
figured why not piggyback onto the existing minus code.


I'm ok with doing whatever for undefined behavior.  At least it's all 
encapsulated in a single place.


Will commit when tests finish.

Thanks.
Aldy

Re: [PATCH] c++: shortcut bad convs during overload resolution [PR101904]

[Patrick Palka via Gcc-patches]

On Thu, 2 Sep 2021, Jason Merrill wrote:

> On 8/31/21 3:15 PM, Patrick Palka wrote:
> > On Mon, 30 Aug 2021, Patrick Palka wrote:
> > 
> > > In the context of overload resolution we have the notion of a "bad"
> > > argument conversion, which is a conversion that "would be a permitted
> > > with a bending of the language standards", and we handle such bad
> > > conversions specially.  In particular, we rank a bad conversion as
> > > better than no conversion but worse than a good conversion, and a bad
> > > conversion doesn't necessarily make a candidate unviable.  With the
> > > flag -fpermissive, we permit the situation where overload resolution
> > > selects a candidate that contains a bad conversion (which we call a
> > > non-strictly viable candidate).  And without the flag we issue a
> > > distinct permerror in this situation instead.
> > > 
> > > One consequence of this defacto behavior is that in order to distinguish
> > > a non-strictly viable candidate from an unviable candidate, if we
> > > encounter a bad argument conversion during overload resolution we must
> > > keep converting subsequent arguments because a subsequent conversion
> > > could render the candidate unviable instead of just non-strictly viable.
> > > But checking subsequent arguments can force template instantiations and
> > > result in otherwise avoidable hard errors.  And in particular, all
> > > 'this' conversions are at worst bad, so this means the
> > > const/ref-qualifiers
> > > of a member function can't be used to prune a candidate quickly, which
> > > is the subject of the mentioned PR.
> > > 
> > > This patch tries to improve the situation without changing the defacto
> > > output of add_candidates.  Specifically, when considering a candidate
> > > during overload resolution this patch makes us shortcut argument
> > > conversion checking upon encountering the first bad conversion
> > > (tentatively marking the candidate as non-strictly viable, though it
> > > could ultimately be unviable) under the assumption that we'll eventually
> > > find a strictly viable candidate anyway (rendering the distinction
> > > between non-strictly viable and unviable moot, since both are worse
> > > than a strictly viable candidate).  If this assumption turns out to be
> > > false, we'll fully reconsider the candidate under the defacto behavior
> > > (without the shortcutting).
> > > 
> > > So in the best case (there's a strictly viable candidate), we avoid
> > > some argument conversions and/or template argument deduction that may
> > > cause a hard error.  In the worst case (there's no such candidate), we
> > > have to redundantly consider some candidates twice.  (In a previous
> > > version of the patch, to avoid this redundant checking I created a new
> > > "deferred" conversion type that represents a conversion that is yet to
> > > be performed, and instead of reconsidering a candidate I just realized
> > > its deferred conversions.  But it doesn't seem this redundancy is a
> > > significant performance issue to justify the added complexity of this
> > > other approach.)
> 
> OK, thanks.

Thanks a lot.  After retesting the patch, I ran into a libstdc++
testsuite failure involving reversed operator candidates that I somehow
missed earlier.  The failure is due to a bug in the last check below

  if (cand->viable == -1
  && shortcut_bad_convs
  && !cand->convs[cand->num_convs - 1]) // BUG
{
  /* This candidate has been tentatively marked non-strictly viable,
 and we didn't compute all argument conversions for it (having
 stopped at the first bad conversion).  Add the function to BAD_FNS
 to fully reconsider later if we don't find any strictly viable
 candidates.  */
  bad_fns = lookup_add (fn, bad_fns);
  *candidates = (*candidates)->next;
}

which assumes a shortcutted candidate must have a missing conversion
at the end of the conversion array (since argument conversions are
processed in left-to-right order).  But for a reversed candidate the
missing conversion would instead be at the front of the array, since we
reversed the order of its conversions in add_candidate.  So I changed
the problematic check to

  !cand->convs[cand->reversed () ? 0 : cand->num_convs - 1])

and committed the patch with this (presumably uncontroversial) change.

> 
> > > Lots of care was taken to preserve the defacto behavior w.r.t.
> > > non-strictly viable candidates, but I wonder how important this behavior
> > > is nowadays?  Can the notion of a non-strictly viable candidate be done
> > > away with, or is it here to stay?
> > 
> > To expand on this, as a concrete alternative to this optimistic shortcutting
> > trick we could maybe recognize non-strictly viable candidates only when
> > -fpermissive (and just mark them as unviable when not -fpermissive).  IIUC
> > this would be a backwards compatible change overall -- only diagnostics
> > would
> > 

[Bug c++/101904] Wrong result of decltype during instantiation of std::result_of

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:47543e5f9d1fc502be79f91c87cbeb6eda17e641

commit r12-3346-g47543e5f9d1fc502be79f91c87cbeb6eda17e641
Author: Patrick Palka 
Date:   Fri Sep 3 11:33:41 2021 -0400

c++: shortcut bad convs during overload resolution [PR101904]

In the context of overload resolution we have the notion of a "bad"
argument conversion, which is a conversion that "would be a permitted
with a bending of the language standards", and we handle such bad
conversions specially.  In particular, we rank a bad conversion as
better than no conversion but worse than a good conversion, and a bad
conversion doesn't necessarily make a candidate unviable.  With the
flag -fpermissive, we permit the situation where overload resolution
selects a candidate that contains a bad conversion (which we call a
non-strictly viable candidate).  And without the flag, the caller
of overload resolution usually issues a distinct permerror in this
situation instead.

One consequence of this defacto behavior is that in order to distinguish
a non-strictly viable candidate from an unviable candidate, if we
encounter a bad argument conversion during overload resolution we must
keep converting subsequent arguments because a subsequent conversion
could render the candidate unviable instead of just non-strictly viable.
But checking subsequent arguments can force template instantiations and
result in otherwise avoidable hard errors.  And in particular, all
'this' conversions are at worst bad, so this means the const/ref-qualifiers
of a member function can't be used to prune a candidate quickly, which
is the subject of the mentioned PR.

This patch tries to improve the situation without changing the defacto
output of add_candidates.  Specifically, when considering a candidate
during overload resolution this patch makes us shortcut argument
conversion checking upon encountering the first bad conversion
(tentatively marking the candidate as non-strictly viable, though it
could ultimately be unviable) under the assumption that we'll eventually
find a strictly viable candidate anyway (which renders moot the
distinction between non-strictly viable and unviable, since both are
worse than a strictly viable candidate).  If this assumption turns out
to be false, we'll fully reconsider the candidate under the defacto
behavior (without the shortcutting) so that all its conversions are
computed.

So in the best case (there's a strictly viable candidate), we avoid
some argument conversions and/or template argument deduction that may
cause a hard error.  In the worst case (there's no such candidate), we
have to redundantly consider some candidates twice.  (In a previous
version of the patch, to avoid this redundant checking I created a new
"deferred" conversion type that represents a conversion that is yet to
be computed, and instead of reconsidering a candidate I just realized
its deferred conversions.  But it doesn't seem this redundancy is a
significant performance issue to justify the added complexity of this
other approach.)

PR c++/101904

gcc/cp/ChangeLog:

* call.c (build_this_conversion): New function, split out from
add_function_candidate.
(add_function_candidate): New parameter shortcut_bad_convs.
Document it.  Use build_this_conversion.  Stop at the first bad
argument conversion when shortcut_bad_convs is true.
(add_template_candidate_real): New parameter shortcut_bad_convs.
Use build_this_conversion to check the 'this' conversion before
attempting deduction.  When the rejection reason code is
rr_bad_arg_conversion, pass -1 instead of 0 as the viable
parameter to add_candidate.  Pass 'convs' to add_candidate.
(add_template_candidate): New parameter shortcut_bad_convs.
(add_template_conv_candidate): Pass false as shortcut_bad_convs
to add_template_candidate_real.
(add_candidates): Prefer to shortcut bad conversions during
overload resolution under the assumption that we'll eventually
see a strictly viable candidate.  If this assumption turns out
to be false, re-process the non-strictly viable candidates
without shortcutting those bad conversions.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv17.C: New test.

Re: [PATCH V3 0/6] Initial support for AVX512FP16

[Iain Sandoe]

> On 3 Sep 2021, at 08:51, Iain Sandoe  wrote:
> 
> 
>> On 2 Sep 2021, at 21:03, Joseph Myers  wrote:
>> 
>> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
>> 
>>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>>> index 2a44ee377ce..a3bb664f5f1 100644
>>> --- a/libgcc/soft-fp/eqdf2.c
>>> +++ b/libgcc/soft-fp/eqdf2.c
>>> @@ -28,6 +28,7 @@
>>>   License along with the GNU C Library; if not, see
>>>   .  */
>>> 
>>> +#define DarwinMode DF
>>> #include "soft-fp.h"
>>> #include "double.h"
>> 
>> All these files are supposed to be taken unmodified from glibc.  They 
>> shouldn't contain any OS-specific code, such as a define of DarwinMode.  
>> sfp-machine.h, however, is libgcc-local, hence putting the definition of 
>> strong_alias there.
> 
> OK, that makes sense.
>> 
>> So you need some other way to extract the argument type of name in order 
>> to use it in a declaration of aliasname.  E.g.
>> 
>> __typeof (_Generic (name,
>>   CMPtype (*) (HFtype, HFtype): (HFtype) 0,
>>   CMPtype (*) (SFtype, SFtype): (SFtype) 0,
>>   CMPtype (*) (DFtype, DFtype): (DFtype) 0,
>>   CMPtype (*) (TFtype, TFtype): (TFtype) 0))
> 
> thanks for the suggestion
> 
>> Now in fact I think the include ordering means none of the *type macros 
>> are defined here.  But if you do e.g.
>> 
>> typedef float alias_SFtype __attribute__ ((mode (SF)));
>> 
>> and similar, you could use alias_SFtype in the above.  And so keep the 
>> changes to the Darwin-specific parts of the libgcc-local sfp-machine.h.
> 
> this is what I’m testing - OK if it bootstraps on x86_64-darwin, linux?

(those bootstraps were sucessful)

given that:

a) this fixes Darwin x86-64 bootstrap which has been broken for more than 24h
b) the patch is now Darwin-local.

I’ve pushed the patch below to fix the bootstrap break - but if there are any 
futher 
recommendations I’m happy to apply a follow-on.  It seems that there will be 
more
changes for the half-float support anyway,

thanks
Iain

> 
> thanks
> Iain
> 
> 
> [PATCH] libgcc, soft-float: Fix strong_alias macro use for Darwin.
> 
> Darwin does not support strong symbol aliases and a work-
> around is provided in sfp-machine.h where a second function
> is created that simply calls the original.  However this
> needs the arguments to the synthesized function to track
> the mode of the original function.
> 
> So the fix here is to match known floating point modes from
> the incoming function and apply the one found to the new
> function args.
> 
> The matching is highly specific to the current set of modes
> and will need adjusting should more cases be added.
> 
> Signed-off-by: Iain Sandoe 
> 
> libgcc/ChangeLog:
> 
>   * config/i386/sfp-machine.h (alias_HFtype, alias_SFtype
>   alias_DFtype, alias_TFtype): New.
>   (ALIAS_SELECTOR): New.
>   (strong_alias): Use __typeof and a _Generic selector to
>   provide the type to the synthesized function.
> ---
> libgcc/config/i386/sfp-machine.h | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/libgcc/config/i386/sfp-machine.h 
> b/libgcc/config/i386/sfp-machine.h
> index f15d29d3755..172ebc70c8d 100644
> --- a/libgcc/config/i386/sfp-machine.h
> +++ b/libgcc/config/i386/sfp-machine.h
> @@ -75,10 +75,24 @@ void __sfp_handle_exceptions (int);
> 
> /* Define ALIASNAME as a strong alias for NAME.  */
> #if defined __MACH__
> -/* Mach-O doesn't support aliasing.  If these functions ever return
> -   anything but CMPtype we need to revisit this... */
> +/* Mach-O doesn't support aliasing, so we build a secondary function for
> +   the alias - we need to do a bit of a dance to find out what the type of
> +   the arguments is and then apply that to the secondary function.
> +   If these functions ever return anything but CMPtype we need to revisit
> +   this... */
> +typedef float alias_HFtype __attribute__ ((mode (HF)));
> +typedef float alias_SFtype __attribute__ ((mode (SF)));
> +typedef float alias_DFtype __attribute__ ((mode (DF)));
> +typedef float alias_TFtype __attribute__ ((mode (TF)));
> +#define ALIAS_SELECTOR \
> +  CMPtype (*) (alias_HFtype, alias_HFtype): (alias_HFtype) 0, \
> +  CMPtype (*) (alias_SFtype, alias_SFtype): (alias_SFtype) 0, \
> +  CMPtype (*) (alias_DFtype, alias_DFtype): (alias_DFtype) 0, \
> +  CMPtype (*) (alias_TFtype, alias_TFtype): (alias_TFtype) 0
> #define strong_alias(name, aliasname) \
> -  CMPtype aliasname (TFtype a, TFtype b) { return name(a, b); }
> +  CMPtype aliasname (__typeof (_Generic (name, ALIAS_SELECTOR)) a, \
> +  __typeof (_Generic (name, ALIAS_SELECTOR)) b) \
> + { return name (a, b); }
> #else
> # define strong_alias(name, aliasname) _strong_alias(name, aliasname)
> # define _strong_alias(name, aliasname) \
> -- 
> 

Re: [PATCH] Do not assume loop header threading in backward threader.

[Aldy Hernandez via Gcc-patches]

On 9/3/21 5:04 PM, Jeff Law wrote:



On 9/3/2021 7:57 AM, Aldy Hernandez wrote:

The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument.  When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE.  This
may not necessarily be true in the future, if the backward threader is
called from another context.  This patch removes the default definition,
in favor of an argument that is exactly the same as the identically
named function in tree-ssa-threadupdate.c.  I think this also makes it
less confusing when looking at both methods across the source base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadbackward.c 
(back_threader::thread_through_all_blocks):

(back_threader_registry::thread_through_all_blocks):
(try_thread_blocks):
(pass_early_thread_jumps::execute):
Presumably this is preparing for addressing some of the issues we 
discussed via email a little while ago -- ie to avoid having the 
backwards threader mucking up loops and allowing the loop optimizer to 
make more decisions about things like peeling because the loop optimizer 
has a cost model for this stuff whereas the jump threaders to not.


Yes.

Currently the forward and the backward threaders have different 
profitability models.  The backward threader has one function to control 
it all, whereas the forward threader has ad-hoc code sprinkled 
throughout.  I would like to combine both models, though I'm not sure 
whether I'll be able to get everything done in this release.


Also, both threaders have different block duplication code.  The forward 
threader's seems more permissive than the other, so this should also be 
combined.  See for instance, EDGE_FSM_THREAD versus EDGE_*BLOCK.


Right now I'm trying to replace the forward threader with an enhanced 
version of the current backward threader, and I'm running into issues 
because the backward threader is handcuffed as to what it can do (see 
profitable_path_p).  It will take some untangling to figure out what to 
allow it to do, without it going ape-shit and threading iterations of 
loops, etc.


Anywhoo...it's a work in progress.  I have upcoming patches to both the 
forward threader clients (to rid them of their dependence on VRP/evrp), 
and to the backward threader to enhance it further so it can get pretty 
much everything the forward threader currently gets.


Gawwwd, this is so convoluted.  I hope most of it made sense.

Aldy

[pushed] c++: Avoid bogus -Wunused with recent change

[Jason Merrill via Gcc-patches]

My change to make limit_bad_template_recursion avoid instantiating members
of erroneous classes produced a bogus "used but not defined" warning for
23_containers/unordered_set/instantiation_neg.cc; it's not defined because
we decided not to instantiate it.  So we need to suppress that warning.

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

gcc/cp/ChangeLog:

* pt.c (limit_bad_template_recursion): Suppress -Wunused for decls
we decide not to instantiate.
---
 gcc/cp/pt.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 72b22d8c487..1b81501386b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10890,15 +10890,27 @@ limit_bad_template_recursion (tree decl)
 return false;
 
   /* Avoid instantiating members of an ill-formed class.  */
-  if (DECL_CLASS_SCOPE_P (decl)
-  && CLASSTYPE_ERRONEOUS (DECL_CONTEXT (decl)))
-return true;
+  bool refuse
+= (DECL_CLASS_SCOPE_P (decl)
+   && CLASSTYPE_ERRONEOUS (DECL_CONTEXT (decl)));
 
-  for (; lev; lev = lev->next)
-if (neglectable_inst_p (lev->maybe_get_node ()))
-  break;
+  if (!refuse)
+{
+  for (; lev; lev = lev->next)
+   if (neglectable_inst_p (lev->maybe_get_node ()))
+ break;
+  refuse = (lev && errs > lev->errors);
+}
 
-  return (lev && errs > lev->errors);
+  if (refuse)
+{
+  /* Don't warn about it not being defined.  */
+  suppress_warning (decl, OPT_Wunused);
+  tree clone;
+  FOR_EACH_CLONE (clone, decl)
+   suppress_warning (clone, OPT_Wunused);
+}
+  return refuse;
 }
 
 static int tinst_depth;

base-commit: 943c65c4494145e993af43c821c8213c6375
-- 
2.27.0

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Jeff Law via Gcc-patches]

On 9/3/2021 9:05 AM, Andrew MacLeod via Gcc-patches wrote:

On 9/3/21 10:41 AM, Aldy Hernandez wrote:

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//    def = __builtin_memchr (arg, 0, sz)
//    n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].

In theory... but do the non-equality relations make sense?   ie ptr1 < 
ptr2   ?   Perhaps there is no harm in those..  Probably undefined 
behaviour if they are not related so we can do whatever...
I'm pretty sure they're in the realm of undefined behavior if the 
pointers point to different objects.  There was some code that would 
have cared about this, but I think it mostly got cleaned up in response 
to Martin S's diagnostic work over the last couple years.


Jeff

Re: [PATCH 2/2] Get rid of all float-int special cases in validate_subreg.

[Andreas Schwab]

On Sep 02 2021, Segher Boessenkool wrote:

> On Tue, Aug 31, 2021 at 07:17:49PM +0800, liuhongt via Gcc-patches wrote:
>>  * emit-rtl.c (validate_subreg): Get rid of all float-int
>>  special cases.
>
> This caused various regressions on powerpc.  Please revert this until
> this can be done safely (the comment this patch deletes says why it can
> not be done yet).

This also breaks ada on riscv64.

s-fatgen.adb: In function 'System.Fat_Flt.Attr_Float.Scaling':
s-fatgen.adb:830:8: error: unable to find a register to spill
s-fatgen.adb:830:8: error: this is the insn:
(insn 215 321 216 26 (set (reg:SF 88 [ xx.26_39 ])
(mult:SF (reg:SF 190)
(subreg:SF (reg:DI 221 [164]) 0))) "s-fatgen.adb":821:25 17 {mulsf3}
 (expr_list:REG_DEAD (reg:DI 221 [164])
(expr_list:REG_DEAD (reg:SF 190)
(nil
during RTL pass: reload

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Andrew MacLeod via Gcc-patches]

On 9/3/21 10:41 AM, Aldy Hernandez wrote:

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//  def = __builtin_memchr (arg, 0, sz)
//  n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].

In theory... but do the non-equality relations make sense?   ie ptr1 < 
ptr2   ?   Perhaps there is no harm in those..  Probably undefined 
behaviour if they are not related so we can do whatever...



Andrew

Re: [PATCH] Do not assume loop header threading in backward threader.

[Jeff Law via Gcc-patches]

On 9/3/2021 7:57 AM, Aldy Hernandez wrote:

The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument.  When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE.  This
may not necessarily be true in the future, if the backward threader is
called from another context.  This patch removes the default definition,
in favor of an argument that is exactly the same as the identically
named function in tree-ssa-threadupdate.c.  I think this also makes it
less confusing when looking at both methods across the source base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadbackward.c (back_threader::thread_through_all_blocks):
(back_threader_registry::thread_through_all_blocks):
(try_thread_blocks):
(pass_early_thread_jumps::execute):
Presumably this is preparing for addressing some of the issues we 
discussed via email a little while ago -- ie to avoid having the 
backwards threader mucking up loops and allowing the loop optimizer to 
make more decisions about things like peeling because the loop optimizer 
has a cost model for this stuff whereas the jump threaders to not.


OK.

jeff

Re: [PATCH] Abstract PHI and forwarder block checks in jump threader.

[Jeff Law via Gcc-patches]

On 9/3/2021 7:56 AM, Aldy Hernandez wrote:

This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p): New.
(potentially_threadable_block): Call forwarder_block_p.
(jump_threader::thread_around_empty_blocks): Call has_phis_p.
(jump_threader::thread_through_normal_block): Call
forwarder_block_p.

OK
jeff

Re: [PATCH] Improve backwards threader debugging dumps.

[Jeff Law via Gcc-patches]

On 9/3/2021 7:56 AM, Aldy Hernandez wrote:

This patch adds debugging helpers to the backwards threader.  I have
also noticed that profitable_path_p() can bail early on paths that
crosses loops and leave the dump of blocks incomplete.  Fixed as
well.

Unfortunately the new methods cannot be marked const, because we call
the solver's dump which is not const.  I believe this was because the
ranger dump calls m_cache.block_range().  This could probably use a
cleanup at a later time.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadbackward.c (back_threader::dump): New.
(back_threader::debug): New.
(back_threader_profitability::profitable_path_p): Dump blocks
even if we are bailing early.

OK
jeff

[Bug tree-optimization/102192] New: Curious '-O2'-only '-Wmaybe-uninitialized' diagnostics for 'libgomp.oacc-fortran/routine-10.f90'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102192
   Summary: Curious '-O2'-only '-Wmaybe-uninitialized' diagnostics
for 'libgomp.oacc-fortran/routine-10.f90'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Blocks: 24639
  Target Milestone: ---

The 'libgomp.oacc-fortran/routine-10.f90' test case as originally added in
commit 12df77ab6df4b91d4770240bcc4ab443e4bb18b9 shows curious
'-Wmaybe-uninitialized' diagnostics.  Now, of course this is
'-Wmaybe-uninitialized', so may easily be dismissed "don't care", but maybe
there's something to be improved here?

For standard host compilation (no '-fopenacc'), but only with '-O2', we get
diagnosed:

libgomp.oacc-fortran/routine-10.f90:28:21: Warning: ‘c’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgomp.oacc-fortran/routine-10.f90:21:50: note: ‘c’ was declared here
libgomp.oacc-fortran/routine-10.f90:46:30: Warning: ‘c’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgomp.oacc-fortran/routine-10.f90:21:50: note: ‘c’ was declared here

Not seeing this with any other '-O[...]' level, and also goes away with '-O2
-fno-inline', for example.  Have not quickly been able to reproduce with '-O3'
plus various '-fno-[...].


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/102191] New: Can't return prvalue with potentially-throwing destructor during constant evaluation

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102191
   Summary: Can't return prvalue with potentially-throwing
destructor during constant evaluation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/8evPWv7cb.
```C++
struct X {
  struct A {
constexpr ~A() noexcept(false) { }
  };

  constexpr A operator()(auto...) { return {}; }
};

void f() { []() consteval { X{}(); }(); }
```
```
: In function 'void f()':
:9:37:   in 'constexpr' expansion of 'f()::().f()::()'
:9:37:   in 'constexpr' expansion of 'X::operator()(auto:1 ...) [with
auto:1 = {}]()'
:9:37: error: modification of '' is not a constant
expression
9 | void f() { []() consteval { X{}(); }(); }
  |~^~
Compiler returned: 1
```

Re: [PATCH] Dump reason why threads are being cancelled and abstract code.

[Jeff Law via Gcc-patches]

On 9/3/2021 7:55 AM, Aldy Hernandez wrote:

We are inconsistent on dumping out reasons why a thread was canceled.
This makes debugging jump threading problems harder because paths can be
canceled with no reason given.  This patch abstracts out the thread
canceling code and adds a reason for every cancellation.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadupdate.c (cancel_thread): New.
(jump_thread_path_registry::thread_block_1): Use cancel_thread.
(jump_thread_path_registry::mark_threaded_blocks): Same.
(jump_thread_path_registry::register_jump_thread): Same.

Probably should have been added long ago.  OK
jeff

[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702

[bergner at gcc dot gnu.org via Gcc-bugs]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Peter Bergner  ---
(In reply to seurer from comment #6)
> The stack limit test case mostly has worked since just after this was opened
> (one short span where it failed again) but I don't know what fixed it.  The
> other test case has worked fine since just after this was opened.  Hopefully
> bootstrap on s390 hasn't been broken since June!

gcc-testresults shows s390 test results, so I'm guessing this isn't broken
anymore.  Let's close this and if it's still a problem, we can reopen it.

Re: Ping ^ 2: [PATCH] rs6000: Expand fmod and remainder when built with fast-math [PR97142]

[David Edelsohn via Gcc-patches]

On Thu, Sep 2, 2021 at 10:31 PM Xionghu Luo  wrote:
>
> Resend the patch that addressed Will's comments.
>
>
> fmod/fmodf and remainder/remainderf could be expanded instead of library
> call when fast-math build, which is much faster.
>
> fmodf:
>  fdivs   f0,f1,f2
>  frizf0,f0
>  fnmsubs f1,f2,f0,f1
>
> remainderf:
>  fdivs   f0,f1,f2
>  frinf0,f0
>  fnmsubs f1,f2,f0,f1
>
> SPEC2017 Ofast P8LE: 511.povray_r +1.14%,  526.blender_r +1.72%
>
> gcc/ChangeLog:
>
> 2021-09-03  Xionghu Luo  
>
> PR target/97142
> * config/rs6000/rs6000.md (fmod3): New define_expand.
> (remainder3): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2021-09-03  Xionghu Luo  
>
> PR target/97142
> * gcc.target/powerpc/pr97142.c: New test.

Okay.

Thanks, David

[Bug fortran/102190] New: Syntax error reported in associate construct

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 102190
   Summary: Syntax error reported in associate construct
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

I think this is related to 102109 and 102112, because minor changes can illicit
the errors reported in those. Given:

module sub_m
type :: sub_t
private
integer :: val
end type

interface sub_t
module procedure constructor
end interface
contains
function constructor(val) result(sub)
integer, intent(in) :: val
type(sub_t) :: sub

sub%val = val
end function
end module
module obj_m
use sub_m, only: sub_t
type :: obj_t
private
type(sub_t) :: sub_obj_
contains
procedure :: sub_obj
end type

interface obj_t
module procedure constructor
end interface
contains
function constructor(sub_obj) result(obj)
type(sub_t), intent(in) :: sub_obj
type(obj_t) :: obj

obj%sub_obj_ = sub_obj
end function

function sub_obj(self)
class(obj_t), intent(in) :: self
type(sub_t) :: sub_obj

sub_obj = self%sub_obj_
end function
end module
program main
use sub_m, only: sub_t
use obj_m, only: obj_t

associate(initial_sub => sub_t(42))
associate(obj => obj_t(initial_sub))
associate(sub_obj => obj%sub_obj())
end associate
end associate
end associate
end program

I get the error:

combined.f90:51:38:

   51 | associate(sub_obj => obj%sub_obj())
  |  1
Error: Expected ‘)’ or ‘,’ at (1)

But if you add implicit none to the program, you get the error reported in
102112, and if you make the components of the types public and/or define the
types in the main program, you get the error reported in 102109.

Re: Ping ^ 2: [PATCH] rs6000: Expand fmod and remainder when built with fast-math [PR97142]

[Bill Schmidt via Gcc-patches]

Hi Xionghu,

This looks okay to me.  Recommend maintainers approve.

Thanks!
Bill

On 9/2/21 9:31 PM, Xionghu Luo wrote:

Resend the patch that addressed Will's comments.


fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.

fmodf:
  fdivs   f0,f1,f2
  frizf0,f0
  fnmsubs f1,f2,f0,f1

remainderf:
  fdivs   f0,f1,f2
  frinf0,f0
  fnmsubs f1,f2,f0,f1

SPEC2017 Ofast P8LE: 511.povray_r +1.14%,  526.blender_r +1.72%

gcc/ChangeLog:

2021-09-03  Xionghu Luo  

PR target/97142
* config/rs6000/rs6000.md (fmod3): New define_expand.
(remainder3): Likewise.

gcc/testsuite/ChangeLog:

2021-09-03  Xionghu Luo  

PR target/97142
* gcc.target/powerpc/pr97142.c: New test.
---
  gcc/config/rs6000/rs6000.md| 36 ++
  gcc/testsuite/gcc.target/powerpc/pr97142.c | 35 +
  2 files changed, 71 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr97142.c

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c8cdc42533c..84820d3b5cb 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -4932,6 +4932,42 @@ (define_insn "fre"
[(set_attr "type" "fp")
 (set_attr "isa" "*,")])
  
+(define_expand "fmod3"

+  [(use (match_operand:SFDF 0 "gpc_reg_operand"))
+   (use (match_operand:SFDF 1 "gpc_reg_operand"))
+   (use (match_operand:SFDF 2 "gpc_reg_operand"))]
+  "TARGET_HARD_FLOAT
+  && TARGET_FPRND
+  && flag_unsafe_math_optimizations"
+{
+  rtx div = gen_reg_rtx (mode);
+  emit_insn (gen_div3 (div, operands[1], operands[2]));
+
+  rtx friz = gen_reg_rtx (mode);
+  emit_insn (gen_btrunc2 (friz, div));
+
+  emit_insn (gen_nfms4 (operands[0], operands[2], friz, operands[1]));
+  DONE;
+ })
+
+(define_expand "remainder3"
+  [(use (match_operand:SFDF 0 "gpc_reg_operand"))
+   (use (match_operand:SFDF 1 "gpc_reg_operand"))
+   (use (match_operand:SFDF 2 "gpc_reg_operand"))]
+  "TARGET_HARD_FLOAT
+  && TARGET_FPRND
+  && flag_unsafe_math_optimizations"
+{
+  rtx div = gen_reg_rtx (mode);
+  emit_insn (gen_div3 (div, operands[1], operands[2]));
+
+  rtx frin = gen_reg_rtx (mode);
+  emit_insn (gen_round2 (frin, div));
+
+  emit_insn (gen_nfms4 (operands[0], operands[2], frin, operands[1]));
+  DONE;
+ })
+
  (define_insn "*rsqrt2"
[(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
(unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" ",wa")]
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97142.c 
b/gcc/testsuite/gcc.target/powerpc/pr97142.c
new file mode 100644
index 000..e5306eb681b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97142.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast" } */
+
+#include 
+
+float test1 (float x, float y)
+{
+  return fmodf (x, y);
+}
+
+double test2 (double x, double y)
+{
+  return fmod (x, y);
+}
+
+float test3 (float x, float y)
+{
+  return remainderf (x, y);
+}
+
+double test4 (double x, double y)
+{
+  return remainder (x, y);
+}
+
+/* { dg-final { scan-assembler-not {\mbl fmod\M} } } */
+/* { dg-final { scan-assembler-not {\mbl fmodf\M} } } */
+/* { dg-final { scan-assembler-not {\mbl remainder\M} } } */
+/* { dg-final { scan-assembler-not {\mbl remainderf\M} } } */
+/* { dg-final { scan-assembler-times {\mfdiv\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mfdivs\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mfnmsub\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mfnmsubs\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mfriz\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mfrin\M} 2 } } */

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

[Qing Zhao via Gcc-patches]

Ping.

Qing

> On Aug 21, 2021, at 3:07 PM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> Hi,
> 
> This is the 8th version of the patch for the new security feature for GCC.
> I have tested it with bootstrap on both x86 and aarch64, regression testing 
> on both x86 and aarch64.
> Also tested it with the kernel testing case provided by Kees.
> Also compile CPU2017 (running is ongoing), without any issue.
> 
> Please take a look at this patch and let me know any issues.
> 
> thanks.
> 
> Qing
> 
> In this version:
> 
> *Fix all issues raised by Richard B on 8/9: (compared with version 7)
> 
>  1. in "handle_uninitialized_attribute", exclude globals with additional 
> checking and warning message. Update corresponding testing cases for this 
> change c-c++-common/auto-init-9/10.c
>  2. add more clarification on the new argument "for_auto_init" for 
> "BUILT_IN_CLEAR_PADDING" in the comments part.
>  3. use auto_var_p to replace "VAR_P && !DECL_EXTERNAL && !TREE_STATIC";
> add a new helper routine "is_var_need_auto_init" to check whether a 
> variable need to be initialized.
>  4. move the "gimple_add_padding_init_for_auto_var" inside the routine 
> "gimplify_init_constructor";
>  5. restrict gimple_add_padding_init_for_auto_var only for INIT_EXPR;
>  6. in "gimplify.c" phase, generate a GENERIC call to DEFERRED_INIT + 
> gimplfiy_assign  instead of a gimple call to fully gimplify the call to the 
> .DEFERRED_INIT to avoid some potential issues.
>  7. in "internal-fn.c" phase, use helper routines "lang_hooks.types, 
> type_for_mode", "can_native_interpret_type_p", "native_interpret_expr" to 
> simplify the implementation for pattern generation.
>  8. move "generating tree node for __BUILTIN_CLEAR_PADDING" in tree.c;
>  9. cleanup tree-cfg.c.
>  10. testing cases updates.
>  for address taken variable -Wuninitialized warnings, add "xfail" for C 
> testing cases; deleting C++ testing cases since "xfail" does not work. 
> (FIXME, add them back if something like "xfail" works for C++.)
> 
> **Known issue:
> 
>  1. -Wuninitialized warnings migh not be issued for address taken auto 
> variables.
> please see https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577431.html
> for details.
> 
> Plan: add a separate patch to improve -Wuninitialized on address taken 
> auto variables.
> 
> **NOTE:
> 
>  1. Changes in tree-sra.c  have been reviewed and approved by Martin Jambor.
>  2. the code changes should be very clean now;
>  3. The testing cases might need more review, I need comments and suggestions 
> on testing cases part. (Not feel very comfortable especially on the testing 
> cases for checking pattern initializations).
> 
> **Please see version 7 at:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576341.html
> 
> **ChangeLog is:
> gcc/ChangeLog:
> 
> 2021-08-21  qing zhao  
> 
>* builtins.c (expand_builtin_memset): Make external visible.
>* builtins.h (expand_builtin_memset): Declare extern.
>* common.opt (ftrivial-auto-var-init=): New option.
>* doc/extend.texi: Document the uninitialized attribute.
>* doc/invoke.texi: Document -ftrivial-auto-var-init.
>* flag-types.h (enum auto_init_type): New enumerated type
>auto_init_type.
>* gimple-fold.c (clear_padding_type): Add one new parameter.
>(clear_padding_union): Likewise.
>(clear_padding_emit_loop): Likewise.
>(clear_type_padding_in_mask): Likewise.
>(gimple_fold_builtin_clear_padding): Handle this new parameter.
>* gimplify.c (gimple_add_init_for_auto_var): New function.
>(gimple_add_padding_init_for_auto_var): New function.
>(is_var_need_auto_init): New function.
>(gimplify_decl_expr): Add initialization to automatic variables per
>users' requests.
>(gimplify_call_expr): Add one new parameter for call to
>__builtin_clear_padding.
>(gimplify_init_constructor): Add padding initialization in the end.
>* internal-fn.c (INIT_PATTERN_VALUE): New macro.
>(expand_DEFERRED_INIT): New function.
>* internal-fn.def (DEFERRED_INIT): New internal function.
>* tree-cfg.c (verify_gimple_call): Verify calls to .DEFERRED_INIT.
>* tree-sra.c (generate_subtree_deferred_init): New function.
>(scan_function): Avoid setting cannot_scalarize_away_bitmap for
>calls to .DEFERRED_INIT.
>(sra_modify_deferred_init): New function.
>(sra_modify_function_body): Handle calls to DEFERRED_INIT specially.
>* tree-ssa-structalias.c (find_func_aliases_for_call): Likewise.
>* tree-ssa-uninit.c (warn_uninit): Handle calls to DEFERRED_INIT
>specially.
>(check_defs): Likewise.
>(warn_uninitialized_vars): Likewise.
>* tree-ssa.c (ssa_undefined_value_p): Likewise.
>* tree.c (build_common_builtin_nodes): Build tree node for
>BUILT_IN_CLEAR_PADDING when needed.
> 
> 

[PATCH] Implement POINTER_DIFF_EXPR entry in range-op.

[Aldy Hernandez via Gcc-patches]

[Andrew, do you see any problem with using the minus relational code
here?  It seems like everything matches up.]

I've seen cases in the upcoming jump threader enhancements where we see
a difference of two pointers that are known to be equivalent, and yet we
fail to return 0 for the range.  This is because we have no working
range-op entry for POINTER_DIFF_EXPR.  The entry we currently have is
a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so
adjust_pointer_diff_expr() could get a whack at it here:

//  def = __builtin_memchr (arg, 0, sz)
//  n = def - arg
//
// The range for N can be narrowed to [0, PTRDIFF_MAX - 1].

This patch adds the relational magic to range-op, which we can just
steal from the minus_expr code.

Testing currently in progress.  I will commit pending tests.

gcc/ChangeLog:

* range-op.cc (operator_minus::op1_op2_relation_effect): Abstract
out to...
(minus_op1_op2_relation_effect): ...here.
(class operator_pointer_diff): New.
(operator_pointer_diff::op1_op2_relation_effect): Call
minus_op1_op2_relation_effect.
(integral_table::integral_table): Add entry for POINTER_DIFF_EXPR.
---
 gcc/range-op.cc | 45 ++---
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index fee0e834c23..5e37133026d 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1372,13 +1372,14 @@ operator_minus::wi_fold (irange , tree type,
 }
 
 // Check to see if the relation REL between OP1 and OP2 has any effect on the
-// LHS of the expression.  If so, apply it to LHS_RANGE.
+// LHS of the expression.  If so, apply it to LHS_RANGE.  This is a helper
+// function for both MINUS_EXPR and POINTER_DIFF_EXPR.
 
-bool
-operator_minus::op1_op2_relation_effect (irange _range, tree type,
- const irange _range ATTRIBUTE_UNUSED,
- const irange _range ATTRIBUTE_UNUSED,
- relation_kind rel) const
+static bool
+minus_op1_op2_relation_effect (irange _range, tree type,
+  const irange _range ATTRIBUTE_UNUSED,
+  const irange _range ATTRIBUTE_UNUSED,
+  relation_kind rel)
 {
   if (rel == VREL_NONE)
 return false;
@@ -1440,6 +1441,16 @@ operator_minus::op1_op2_relation_effect (irange 
_range, tree type,
   return true;
 }
 
+bool
+operator_minus::op1_op2_relation_effect (irange _range, tree type,
+const irange _range,
+const irange _range,
+relation_kind rel) const
+{
+  return minus_op1_op2_relation_effect (lhs_range, type, op1_range, op2_range,
+   rel);
+}
+
 bool
 operator_minus::op1_range (irange , tree type,
   const irange ,
@@ -1459,6 +1470,26 @@ operator_minus::op2_range (irange , tree type,
 }
 
 
+class operator_pointer_diff : public range_operator
+{
+  virtual bool op1_op2_relation_effect (irange _range,
+   tree type,
+   const irange _range,
+   const irange _range,
+   relation_kind rel) const;
+} op_pointer_diff;
+
+bool
+operator_pointer_diff::op1_op2_relation_effect (irange _range, tree type,
+   const irange _range,
+   const irange _range,
+   relation_kind rel) const
+{
+  return minus_op1_op2_relation_effect (lhs_range, type, op1_range, op2_range,
+   rel);
+}
+
+
 class operator_min : public range_operator
 {
 public:
@@ -4018,7 +4049,7 @@ integral_table::integral_table ()
   set (OBJ_TYPE_REF, op_identity);
   set (IMAGPART_EXPR, op_unknown);
   set (REALPART_EXPR, op_unknown);
-  set (POINTER_DIFF_EXPR, op_unknown);
+  set (POINTER_DIFF_EXPR, op_pointer_diff);
   set (ABS_EXPR, op_abs);
   set (ABSU_EXPR, op_absu);
   set (NEGATE_EXPR, op_negate);
-- 
2.31.1

[PATCH] Abstract PHI and forwarder block checks in jump threader.

[Aldy Hernandez via Gcc-patches]

This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p): New.
(potentially_threadable_block): Call forwarder_block_p.
(jump_threader::thread_around_empty_blocks): Call has_phis_p.
(jump_threader::thread_through_normal_block): Call
forwarder_block_p.
---
 gcc/tree-ssa-threadedge.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index e57f6d3e39c..3db54a199fd 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -95,6 +95,21 @@ jump_threader::thread_through_all_blocks (bool 
may_peel_loop_headers)
   return m_registry->thread_through_all_blocks (may_peel_loop_headers);
 }
 
+static inline bool
+has_phis_p (basic_block bb)
+{
+  return !gsi_end_p (gsi_start_phis (bb));
+}
+
+/* Return TRUE for a forwarder block which is defined as having PHIs
+   but no instructions.  */
+
+static bool
+forwarder_block_p (basic_block bb)
+{
+  return gsi_end_p (gsi_start_nondebug_bb (bb)) && has_phis_p (bb);
+}
+
 /* Return TRUE if we may be able to thread an incoming edge into
BB to an outgoing edge from BB.  Return FALSE otherwise.  */
 
@@ -107,9 +122,8 @@ potentially_threadable_block (basic_block bb)
  not optimized away because they forward from outside a loop
  to the loop header.   We want to thread through them as we can
  sometimes thread to the loop exit, which is obviously profitable.
- the interesting case here is when the block has PHIs.  */
-  if (gsi_end_p (gsi_start_nondebug_bb (bb))
-  && !gsi_end_p (gsi_start_phis (bb)))
+ The interesting case here is when the block has PHIs.  */
+  if (forwarder_block_p (bb))
 return true;
 
   /* If BB has a single successor or a single predecessor, then
@@ -854,7 +868,7 @@ jump_threader::thread_around_empty_blocks 
(vec *path,
   /* The key property of these blocks is that they need not be duplicated
  when threading.  Thus they cannot have visible side effects such
  as PHI nodes.  */
-  if (!gsi_end_p (gsi_start_phis (bb)))
+  if (has_phis_p (bb))
 return false;
 
   /* Skip over DEBUG statements at the start of the block.  */
@@ -994,8 +1008,7 @@ jump_threader::thread_through_normal_block 
(vec *path,
 {
   /* First case.  The statement simply doesn't have any instructions, but
 does have PHIs.  */
-  if (gsi_end_p (gsi_start_nondebug_bb (e->dest))
- && !gsi_end_p (gsi_start_phis (e->dest)))
+  if (forwarder_block_p (e->dest))
return 0;
 
   /* Second case.  */
-- 
2.31.1

[Bug driver/102189] New: error: unrecognized command-line option '-fno-[...]'; did you mean '-ftree-[...]'?

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102189
   Summary: error: unrecognized command-line option '-fno-[...]';
did you mean '-ftree-[...]'?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

For example:

xgcc: error: unrecognized command-line option ‘-fno-loop-vectorize’; did
you mean ‘-ftree-loop-vectorize’?
xgcc: error: unrecognized command-line option ‘-fno-slp-vectorize’; did you
mean ‘-ftree-slp-vectorize’?

See how the 'no-' prefix gets lost.  If, for example, '-fno-loop-vectorize' is
specified, it would be more useful to suggest '-fno-tree-loop-vectorize' (again
with '-fno-[...]' prefix) instead of '-ftree-loop-vectorize'.

Maybe we can give the original 'no-' prefix a higher weight or something?

Re: [PATCH 8/8] coroutines: Make the continue handle visible to debug.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:56 AM, Iain Sandoe wrote:


When we have a suspend method that returns a coroutine handle
we transfer (hopefully symmetrically, i.e. with a tailcall) to
that new coroutine instead of returning to our resumer.

This adds the variable to the outer block for the actor function
which means that '_Coro_actor_continue' is visible to debug.

Contributory to PR 99215.


OK.


Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (build_actor_fn): Make _Coro_actor_continue
visible to debug.
---
  gcc/cp/coroutines.cc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 395e5c488e5..b32c5dc5e55 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2148,6 +2148,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
 NULL_TREE);

BIND_EXPR_VARS (actor_bind) = continuation;

+  BLOCK_VARS (top_block) = BIND_EXPR_VARS (actor_bind) ;
  
/* Link in the block associated with the outer scope of the re-written

   function body.  */

Re: [PATCH 7/8] coroutines: Make proxy vars for the function arg copies.

[Iain Sandoe]

> On 3 Sep 2021, at 15:07, Jason Merrill via Gcc-patches 
>  wrote:
> 
> On 9/1/21 6:56 AM, Iain Sandoe wrote:
>> This adds top level proxy variables for the coroutine frame
>> copies of the original function args.  These are then available
>> in the debugger to refer to the frame copies.  We rewrite the
>> function body to use the copies, since the original parms will
>> no longer be in scope when the coroutine is running.
>> Signed-off-by: Iain Sandoe 
>> gcc/cp/ChangeLog:
>>  * coroutines.cc (struct param_info): Add copy_var.
>>  (build_actor_fn): Use simplified param references.
>>  (register_param_uses): Likewise.
>>  (rewrite_param_uses): Likewise.
>>  (analyze_fn_parms): New function.
>>  (coro_rewrite_function_body): Add proxies for the fn
>>  parameters to the outer bind scope of the rewritten code.
>>  (morph_fn_to_coro): Use simplified version of param ref.
>> ---
>>  gcc/cp/coroutines.cc | 247 ---
>>  1 file changed, 117 insertions(+), 130 deletions(-)
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index aacf352f1c9..395e5c488e5 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -1964,6 +1964,7 @@ transform_await_wrapper (tree *stmt, int *do_subtree, 
>> void *d)
>>  struct param_info
>>  {
>>tree field_id; /* The name of the copy in the coroutine frame.  */
>> +  tree copy_var; /* The local var proxy for the frame copy.  */
>>vec *body_uses; /* Worklist of uses, void if there are none.  */
>>tree frame_type;   /* The type used to represent this parm in the frame.  
>> */
>>tree orig_type;/* The original type of the parm (not as passed).  */
>> @@ -2169,36 +2170,6 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>/* Declare the continuation handle.  */
>>add_decl_expr (continuation);
>>  -  /* Re-write param references in the body, no code should be generated
>> - here.  */
>> -  if (DECL_ARGUMENTS (orig))
>> -{
>> -  tree arg;
>> -  for (arg = DECL_ARGUMENTS (orig); arg != NULL; arg = DECL_CHAIN (arg))
>> -{
>> -  bool existed;
>> -  param_info  = param_uses->get_or_insert (arg, );
>> -  if (!parm.body_uses)
>> -continue; /* Wasn't used in the original function body.  */
>> -
>> -  tree fld_ref = lookup_member (coro_frame_type, parm.field_id,
>> -/*protect=*/1, /*want_type=*/0,
>> -tf_warning_or_error);
>> -  tree fld_idx = build3_loc (loc, COMPONENT_REF, parm.frame_type,
>> - actor_frame, fld_ref, NULL_TREE);
>> -
>> -  /* We keep these in the frame as a regular pointer, so convert that
>> -   back to the type expected.  */
>> -  if (parm.pt_ref)
>> -fld_idx = build1_loc (loc, CONVERT_EXPR, TREE_TYPE (arg), fld_idx);
>> -
>> -  int i;
>> -  tree *puse;
>> -  FOR_EACH_VEC_ELT (*parm.body_uses, i, puse)
>> -*puse = fld_idx;
>> -}
>> -}
>> -
>>/* Re-write local vars, similarly.  */
>>local_vars_transform xform_vars_data
>>  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
>> @@ -3772,11 +3743,11 @@ struct param_frame_data
>>bool param_seen;
>>  };
>>  -/* A tree-walk callback that records the use of parameters (to allow for
>> -   optimizations where handling unused parameters may be omitted).  */
>> +/* A tree walk callback that rewrites each parm use to the local variable
>> +   that represents its copy in the frame.  */
>>static tree
>> -register_param_uses (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void *d)
>> +rewrite_param_uses (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void *d)
>>  {
>>param_frame_data *data = (param_frame_data *) d;
>>  @@ -3784,7 +3755,7 @@ register_param_uses (tree *stmt, int *do_subtree 
>> ATTRIBUTE_UNUSED, void *d)
>>if (TREE_CODE (*stmt) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*stmt))
>>  {
>>tree t = DECL_VALUE_EXPR (*stmt);
>> -  return cp_walk_tree (, register_param_uses, d, NULL);
>> +  return cp_walk_tree (, rewrite_param_uses, d, NULL);
>>  }
>>  if (TREE_CODE (*stmt) != PARM_DECL)
>> @@ -3798,16 +3769,87 @@ register_param_uses (tree *stmt, int *do_subtree 
>> ATTRIBUTE_UNUSED, void *d)
>>param_info  = data->param_uses->get_or_insert (*stmt, );
>>gcc_checking_assert (existed);
>>  -  if (!parm.body_uses)
>> +  *stmt = parm.copy_var;
>> +  return NULL_TREE;
>> +}
>> +
>> +/* Build up a set of info that determines how each param copy will be
>> +   handled.  */
>> +
>> +static hash_map *analyze_fn_parms (tree orig)
> 
> Function name should be on a new line.

oops.
> 
>> +{
>> +  if (!DECL_ARGUMENTS (orig))
>> +return NULL;
>> +
>> +  hash_map *param_uses = new hash_map;
>> +
>> +  /* Build a hash map with an entry for each param.
>> + The key is the param tree.
>> + Then we have an 

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

[Iain Sandoe]

> On 3 Sep 2021, at 15:12, Jason Merrill  wrote:
> 
> On 9/3/21 9:56 AM, Iain Sandoe wrote:
>>> On 3 Sep 2021, at 14:52, Jason Merrill  wrote:
>>> 
>>> On 9/1/21 6:55 AM, Iain Sandoe wrote:
 The user might well wish to inspect some of the state that represents
 the implementation of the coroutine machine.
 In particular:
   The promise object.
   The function pointers for the resumer and destroyer.
   The current resume index (suspend point).
   The handle that represent this coroutine 'self handle'.
   Whether the coroutine frame is allocated and needs to be freed.
 These variables are given names that can be 'well-known' and advertised
 in debug documentation - they are placed in the implementation namespace
 and all begin with _Coro_.
>>> 
 Signed-off-by: Iain Sandoe 
 gcc/cp/ChangeLog:
* coroutines.cc (transform_await_expr): Use debug-friendly
names for coroutine implementation.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
(coro_rewrite_function_body): Likewise.
(morph_fn_to_coro): Likewise.
>>> 
>>> Hmm, this patch doesn't seem to match the description and ChangeLog entry 
>>> other than in the names of the functions changed.
>> with 20:20 hindsight I should have squashed the (several) patches related to 
>> the implementation symbols,
>> I’ll redo the description - essentially, this is just making use of the 
>> simplification available because we now have pre-defined values for the 
>> field names.
> 
> I can see how that describes a few lines in this patch, but not for instance 
> the change to transform_await_expr, which seems to have nothing to do with 
> names?

it’s indirect indeed - but the changes we’ve made to the variable handling mean 
that we no longer need to rewrite the
proxy vars into their frame->offset; that is handled by the DECL_VALUE_EXPR (as 
for user’s vars ) - the change to transform_await_expr is removing the now 
defunct substitution (and poorly described, sorry).

> But yes, moving the changed lines that just use the variables from the 
> previous patch into that commit sounds good.  I use rebase -i for that sort 
> of thing all the time.

yeah, me too -  I realised too late that this series could have had more 
squashing - if it would make things easier I could do that for the patches 
related to implemenation variables .. - which would include patch 8 (but not 
patch 7 which is related to parms only)


 ---
  gcc/cp/coroutines.cc | 214 +++
  1 file changed, 94 insertions(+), 120 deletions(-)
 diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
 index 3b46aac4dc5..aacf352f1c9 100644
 --- a/gcc/cp/coroutines.cc
 +++ b/gcc/cp/coroutines.cc
 @@ -1906,7 +1906,6 @@ transform_await_expr (tree await_expr, 
 await_xform_data *xform)
/* So, on entry, we have:
   in : CO_AWAIT_EXPR (a, e_proxy, o, awr_call_vector, mode)
  We no longer need a [it had diagnostic value, maybe?]
 -We need to replace the promise proxy in all elements
  We need to replace the e_proxy in the awr_call.  */
  tree coro_frame_type = TREE_TYPE (xform->actor_frame);
 @@ -1932,16 +1931,6 @@ transform_await_expr (tree await_expr, 
 await_xform_data *xform)
TREE_OPERAND (await_expr, 1) = as;
  }
  -  /* Now do the self_handle.  */
 -  data.from = xform->self_h_proxy;
 -  data.to = xform->real_self_h;
 -  cp_walk_tree (_expr, replace_proxy, , NULL);
 -
 -  /* Now do the promise.  */
 -  data.from = xform->promise_proxy;
 -  data.to = xform->real_promise;
 -  cp_walk_tree (_expr, replace_proxy, , NULL);
 -
return await_expr;
  }
  @@ -2128,10 +2117,9 @@ coro_get_frame_dtor (tree coro_fp, tree orig, tree 
 frame_size,
static void
  build_actor_fn (location_t loc, tree coro_frame_type, tree actor, tree 
 fnbody,
 -  tree orig, hash_map *param_uses,
 -  hash_map *local_var_uses,
 -  vec *param_dtor_list, tree resume_fn_field,
 -  tree resume_idx_field, unsigned body_count, tree frame_size)
 +  tree orig, hash_map *local_var_uses,
 +  vec *param_dtor_list,
 +  tree resume_idx_var, unsigned body_count, tree frame_size)
  {
verify_stmt_tree (fnbody);
/* Some things we inherit from the original function.  */
 @@ -2216,8 +2204,8 @@ build_actor_fn (location_t loc, tree 
 coro_frame_type, tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, 
 NULL);
  -  tree rat_field = lookup_member (coro_frame_type, 
 coro_resume_index_field, 1, 0,
 -tf_warning_or_error);
 +  tree rat_field = lookup_member (coro_frame_type, 
 

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

[Jason Merrill via Gcc-patches]

On 9/3/21 9:56 AM, Iain Sandoe wrote:




On 3 Sep 2021, at 14:52, Jason Merrill  wrote:

On 9/1/21 6:55 AM, Iain Sandoe wrote:

The user might well wish to inspect some of the state that represents
the implementation of the coroutine machine.
In particular:
   The promise object.
   The function pointers for the resumer and destroyer.
   The current resume index (suspend point).
   The handle that represent this coroutine 'self handle'.
   Whether the coroutine frame is allocated and needs to be freed.
These variables are given names that can be 'well-known' and advertised
in debug documentation - they are placed in the implementation namespace
and all begin with _Coro_.



Signed-off-by: Iain Sandoe 
gcc/cp/ChangeLog:
* coroutines.cc (transform_await_expr): Use debug-friendly
names for coroutine implementation.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
(coro_rewrite_function_body): Likewise.
(morph_fn_to_coro): Likewise.


Hmm, this patch doesn't seem to match the description and ChangeLog entry other 
than in the names of the functions changed.


with 20:20 hindsight I should have squashed the (several) patches related to 
the implementation symbols,

I’ll redo the description - essentially, this is just making use of the 
simplification available because we now have pre-defined values for the field 
names.


I can see how that describes a few lines in this patch, but not for 
instance the change to transform_await_expr, which seems to have nothing 
to do with names?


But yes, moving the changed lines that just use the variables from the 
previous patch into that commit sounds good.  I use rebase -i for that 
sort of thing all the time.



---
  gcc/cp/coroutines.cc | 214 +++
  1 file changed, 94 insertions(+), 120 deletions(-)
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 3b46aac4dc5..aacf352f1c9 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1906,7 +1906,6 @@ transform_await_expr (tree await_expr, await_xform_data 
*xform)
/* So, on entry, we have:
   in : CO_AWAIT_EXPR (a, e_proxy, o, awr_call_vector, mode)
  We no longer need a [it had diagnostic value, maybe?]
- We need to replace the promise proxy in all elements
  We need to replace the e_proxy in the awr_call.  */
  tree coro_frame_type = TREE_TYPE (xform->actor_frame);
@@ -1932,16 +1931,6 @@ transform_await_expr (tree await_expr, await_xform_data 
*xform)
TREE_OPERAND (await_expr, 1) = as;
  }
  -  /* Now do the self_handle.  */
-  data.from = xform->self_h_proxy;
-  data.to = xform->real_self_h;
-  cp_walk_tree (_expr, replace_proxy, , NULL);
-
-  /* Now do the promise.  */
-  data.from = xform->promise_proxy;
-  data.to = xform->real_promise;
-  cp_walk_tree (_expr, replace_proxy, , NULL);
-
return await_expr;
  }
  @@ -2128,10 +2117,9 @@ coro_get_frame_dtor (tree coro_fp, tree orig, tree 
frame_size,
static void
  build_actor_fn (location_t loc, tree coro_frame_type, tree actor, tree fnbody,
-   tree orig, hash_map *param_uses,
-   hash_map *local_var_uses,
-   vec *param_dtor_list, tree resume_fn_field,
-   tree resume_idx_field, unsigned body_count, tree frame_size)
+   tree orig, hash_map *local_var_uses,
+   vec *param_dtor_list,
+   tree resume_idx_var, unsigned body_count, tree frame_size)
  {
verify_stmt_tree (fnbody);
/* Some things we inherit from the original function.  */
@@ -2216,8 +2204,8 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
  -  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 
1, 0,
- tf_warning_or_error);
+  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field,
+ 1, 0, tf_warning_or_error);
tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
 rat_field, NULL_TREE);
  @@ -2319,14 +2307,8 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
tree r = build_stmt (loc, LABEL_EXPR, actor_begin_label);
add_stmt (r);
  -  /* actor's version of the promise.  */
-  tree ap_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_promise"), 1, 0,
-tf_warning_or_error);
-  tree ap = build_class_member_access_expr (actor_frame, ap_m, NULL_TREE, 
false,
-   tf_warning_or_error);
-
/* actor's coroutine 'self handle'.  */
-  tree ash_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_self_handle"), 1,
+  tree ash_m = lookup_member (coro_frame_type, coro_self_handle_field, 1,
  0, 

Re: [PATCH 7/8] coroutines: Make proxy vars for the function arg copies.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:56 AM, Iain Sandoe wrote:


This adds top level proxy variables for the coroutine frame
copies of the original function args.  These are then available
in the debugger to refer to the frame copies.  We rewrite the
function body to use the copies, since the original parms will
no longer be in scope when the coroutine is running.

Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (struct param_info): Add copy_var.
(build_actor_fn): Use simplified param references.
(register_param_uses): Likewise.
(rewrite_param_uses): Likewise.
(analyze_fn_parms): New function.
(coro_rewrite_function_body): Add proxies for the fn
parameters to the outer bind scope of the rewritten code.
(morph_fn_to_coro): Use simplified version of param ref.
---
  gcc/cp/coroutines.cc | 247 ---
  1 file changed, 117 insertions(+), 130 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index aacf352f1c9..395e5c488e5 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1964,6 +1964,7 @@ transform_await_wrapper (tree *stmt, int *do_subtree, 
void *d)
  struct param_info
  {
tree field_id; /* The name of the copy in the coroutine frame.  */
+  tree copy_var; /* The local var proxy for the frame copy.  */
vec *body_uses; /* Worklist of uses, void if there are none.  */
tree frame_type;   /* The type used to represent this parm in the frame.  */
tree orig_type;/* The original type of the parm (not as passed).  */
@@ -2169,36 +2170,6 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
/* Declare the continuation handle.  */
add_decl_expr (continuation);
  
-  /* Re-write param references in the body, no code should be generated

- here.  */
-  if (DECL_ARGUMENTS (orig))
-{
-  tree arg;
-  for (arg = DECL_ARGUMENTS (orig); arg != NULL; arg = DECL_CHAIN (arg))
-   {
- bool existed;
- param_info  = param_uses->get_or_insert (arg, );
- if (!parm.body_uses)
-   continue; /* Wasn't used in the original function body.  */
-
- tree fld_ref = lookup_member (coro_frame_type, parm.field_id,
-   /*protect=*/1, /*want_type=*/0,
-   tf_warning_or_error);
- tree fld_idx = build3_loc (loc, COMPONENT_REF, parm.frame_type,
-actor_frame, fld_ref, NULL_TREE);
-
- /* We keep these in the frame as a regular pointer, so convert that
-  back to the type expected.  */
- if (parm.pt_ref)
-   fld_idx = build1_loc (loc, CONVERT_EXPR, TREE_TYPE (arg), fld_idx);
-
- int i;
- tree *puse;
- FOR_EACH_VEC_ELT (*parm.body_uses, i, puse)
-   *puse = fld_idx;
-   }
-}
-
/* Re-write local vars, similarly.  */
local_vars_transform xform_vars_data
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
@@ -3772,11 +3743,11 @@ struct param_frame_data
bool param_seen;
  };
  
-/* A tree-walk callback that records the use of parameters (to allow for

-   optimizations where handling unused parameters may be omitted).  */
+/* A tree walk callback that rewrites each parm use to the local variable
+   that represents its copy in the frame.  */
  
  static tree

-register_param_uses (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void *d)
+rewrite_param_uses (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void *d)
  {
param_frame_data *data = (param_frame_data *) d;
  
@@ -3784,7 +3755,7 @@ register_param_uses (tree *stmt, int *do_subtree ATTRIBUTE_UNUSED, void *d)

if (TREE_CODE (*stmt) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*stmt))
  {
tree t = DECL_VALUE_EXPR (*stmt);
-  return cp_walk_tree (, register_param_uses, d, NULL);
+  return cp_walk_tree (, rewrite_param_uses, d, NULL);
  }
  
if (TREE_CODE (*stmt) != PARM_DECL)

@@ -3798,16 +3769,87 @@ register_param_uses (tree *stmt, int *do_subtree 
ATTRIBUTE_UNUSED, void *d)
param_info  = data->param_uses->get_or_insert (*stmt, );
gcc_checking_assert (existed);
  
-  if (!parm.body_uses)

+  *stmt = parm.copy_var;
+  return NULL_TREE;
+}
+
+/* Build up a set of info that determines how each param copy will be
+   handled.  */
+
+static hash_map *analyze_fn_parms (tree orig)


Function name should be on a new line.


+{
+  if (!DECL_ARGUMENTS (orig))
+return NULL;
+
+  hash_map *param_uses = new hash_map;
+
+  /* Build a hash map with an entry for each param.
+ The key is the param tree.
+ Then we have an entry for the frame field name.
+ Then a cache for the field ref when we come to use it.
+ Then a tree list of the uses.
+ The second two entries start out empty - and only get populated
+ when we see uses.  */
+  bool lambda_p = LAMBDA_FUNCTION_P (orig);
+
+  unsigned no_name_parm = 

[PATCH] Abstract PHI and forwarder block checks in jump threader.

[Aldy Hernandez via Gcc-patches]

This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadedge.c (has_phis_p): New.
(forwarder_block_p): New.
(potentially_threadable_block): Call forwarder_block_p.
(jump_threader::thread_around_empty_blocks): Call has_phis_p.
(jump_threader::thread_through_normal_block): Call
forwarder_block_p.
---
 gcc/tree-ssa-threadedge.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index e57f6d3e39c..3db54a199fd 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -95,6 +95,21 @@ jump_threader::thread_through_all_blocks (bool 
may_peel_loop_headers)
   return m_registry->thread_through_all_blocks (may_peel_loop_headers);
 }
 
+static inline bool
+has_phis_p (basic_block bb)
+{
+  return !gsi_end_p (gsi_start_phis (bb));
+}
+
+/* Return TRUE for a forwarder block which is defined as having PHIs
+   but no instructions.  */
+
+static bool
+forwarder_block_p (basic_block bb)
+{
+  return gsi_end_p (gsi_start_nondebug_bb (bb)) && has_phis_p (bb);
+}
+
 /* Return TRUE if we may be able to thread an incoming edge into
BB to an outgoing edge from BB.  Return FALSE otherwise.  */
 
@@ -107,9 +122,8 @@ potentially_threadable_block (basic_block bb)
  not optimized away because they forward from outside a loop
  to the loop header.   We want to thread through them as we can
  sometimes thread to the loop exit, which is obviously profitable.
- the interesting case here is when the block has PHIs.  */
-  if (gsi_end_p (gsi_start_nondebug_bb (bb))
-  && !gsi_end_p (gsi_start_phis (bb)))
+ The interesting case here is when the block has PHIs.  */
+  if (forwarder_block_p (bb))
 return true;
 
   /* If BB has a single successor or a single predecessor, then
@@ -854,7 +868,7 @@ jump_threader::thread_around_empty_blocks 
(vec *path,
   /* The key property of these blocks is that they need not be duplicated
  when threading.  Thus they cannot have visible side effects such
  as PHI nodes.  */
-  if (!gsi_end_p (gsi_start_phis (bb)))
+  if (has_phis_p (bb))
 return false;
 
   /* Skip over DEBUG statements at the start of the block.  */
@@ -994,8 +1008,7 @@ jump_threader::thread_through_normal_block 
(vec *path,
 {
   /* First case.  The statement simply doesn't have any instructions, but
 does have PHIs.  */
-  if (gsi_end_p (gsi_start_nondebug_bb (e->dest))
- && !gsi_end_p (gsi_start_phis (e->dest)))
+  if (forwarder_block_p (e->dest))
return 0;
 
   /* Second case.  */
-- 
2.31.1

[PATCH] Do not assume loop header threading in backward threader.

[Aldy Hernandez via Gcc-patches]

The registry's thread_through_all_blocks() has a may_peel_loop_headers
argument.  When refactoring the backward threader code, I removed this
argument for the local passthru method because it was always TRUE.  This
may not necessarily be true in the future, if the backward threader is
called from another context.  This patch removes the default definition,
in favor of an argument that is exactly the same as the identically
named function in tree-ssa-threadupdate.c.  I think this also makes it
less confusing when looking at both methods across the source base.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadbackward.c (back_threader::thread_through_all_blocks):
(back_threader_registry::thread_through_all_blocks):
(try_thread_blocks):
(pass_early_thread_jumps::execute):
---
 gcc/tree-ssa-threadbackward.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index b9a0d9a60ad..2fa22f8e328 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -53,7 +53,7 @@ class back_threader_registry
 public:
   back_threader_registry (int max_allowable_paths);
   bool register_path (const vec &, edge taken);
-  bool thread_through_all_blocks ();
+  bool thread_through_all_blocks (bool may_peel_loop_headers);
 private:
   jump_thread_path_registry m_lowlevel_registry;
   const int m_max_allowable_paths;
@@ -80,7 +80,7 @@ public:
   back_threader (bool speed_p);
   ~back_threader ();
   void maybe_thread_block (basic_block bb);
-  bool thread_through_all_blocks ();
+  bool thread_through_all_blocks (bool may_peel_loop_headers);
 private:
   void find_paths (basic_block bb, tree name);
   void maybe_register_path (edge taken_edge);
@@ -497,9 +497,9 @@ back_threader::maybe_thread_block (basic_block bb)
 // Perform the actual jump threading for the all queued paths.
 
 bool
-back_threader::thread_through_all_blocks ()
+back_threader::thread_through_all_blocks (bool may_peel_loop_headers)
 {
-  return m_registry.thread_through_all_blocks ();
+  return m_registry.thread_through_all_blocks (may_peel_loop_headers);
 }
 
 // Dump a sequence of BBs through the CFG.
@@ -553,9 +553,9 @@ back_threader_registry::back_threader_registry (int 
max_allowable_paths)
 }
 
 bool
-back_threader_registry::thread_through_all_blocks ()
+back_threader_registry::thread_through_all_blocks (bool may_peel_loop_headers)
 {
-  return m_lowlevel_registry.thread_through_all_blocks (true);
+  return m_lowlevel_registry.thread_through_all_blocks (may_peel_loop_headers);
 }
 
 /* Examine jump threading path PATH and return TRUE if it is profitable to
@@ -947,7 +947,7 @@ try_thread_blocks (function *fun)
   if (EDGE_COUNT (bb->succs) > 1)
threader.maybe_thread_block (bb);
 }
-  return threader.thread_through_all_blocks ();
+  return threader.thread_through_all_blocks (/*peel_loop_headers=*/true);
 }
 
 unsigned int
@@ -1016,7 +1016,7 @@ pass_early_thread_jumps::execute (function *fun)
   if (EDGE_COUNT (bb->succs) > 1)
threader.maybe_thread_block (bb);
 }
-  threader.thread_through_all_blocks ();
+  threader.thread_through_all_blocks (/*peel_loop_headers=*/true);
 
   loop_optimizer_finalize ();
   return 0;
-- 
2.31.1

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

[Iain Sandoe]

> On 3 Sep 2021, at 14:52, Jason Merrill  wrote:
> 
> On 9/1/21 6:55 AM, Iain Sandoe wrote:
>> The user might well wish to inspect some of the state that represents
>> the implementation of the coroutine machine.
>> In particular:
>>   The promise object.
>>   The function pointers for the resumer and destroyer.
>>   The current resume index (suspend point).
>>   The handle that represent this coroutine 'self handle'.
>>   Whether the coroutine frame is allocated and needs to be freed.
>> These variables are given names that can be 'well-known' and advertised
>> in debug documentation - they are placed in the implementation namespace
>> and all begin with _Coro_.
> 
>> Signed-off-by: Iain Sandoe 
>> gcc/cp/ChangeLog:
>>  * coroutines.cc (transform_await_expr): Use debug-friendly
>>  names for coroutine implementation.
>>  (build_actor_fn): Likewise.
>>  (build_destroy_fn): Likewise.
>>  (coro_rewrite_function_body): Likewise.
>>  (morph_fn_to_coro): Likewise.
> 
> Hmm, this patch doesn't seem to match the description and ChangeLog entry 
> other than in the names of the functions changed.

with 20:20 hindsight I should have squashed the (several) patches related to 
the implementation symbols, 

I’ll redo the description - essentially, this is just making use of the 
simplification available because we now have pre-defined values for the field 
names.

>> ---
>>  gcc/cp/coroutines.cc | 214 +++
>>  1 file changed, 94 insertions(+), 120 deletions(-)
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index 3b46aac4dc5..aacf352f1c9 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -1906,7 +1906,6 @@ transform_await_expr (tree await_expr, 
>> await_xform_data *xform)
>>/* So, on entry, we have:
>>   in : CO_AWAIT_EXPR (a, e_proxy, o, awr_call_vector, mode)
>>We no longer need a [it had diagnostic value, maybe?]
>> -  We need to replace the promise proxy in all elements
>>We need to replace the e_proxy in the awr_call.  */
>>  tree coro_frame_type = TREE_TYPE (xform->actor_frame);
>> @@ -1932,16 +1931,6 @@ transform_await_expr (tree await_expr, 
>> await_xform_data *xform)
>>TREE_OPERAND (await_expr, 1) = as;
>>  }
>>  -  /* Now do the self_handle.  */
>> -  data.from = xform->self_h_proxy;
>> -  data.to = xform->real_self_h;
>> -  cp_walk_tree (_expr, replace_proxy, , NULL);
>> -
>> -  /* Now do the promise.  */
>> -  data.from = xform->promise_proxy;
>> -  data.to = xform->real_promise;
>> -  cp_walk_tree (_expr, replace_proxy, , NULL);
>> -
>>return await_expr;
>>  }
>>  @@ -2128,10 +2117,9 @@ coro_get_frame_dtor (tree coro_fp, tree orig, tree 
>> frame_size,
>>static void
>>  build_actor_fn (location_t loc, tree coro_frame_type, tree actor, tree 
>> fnbody,
>> -tree orig, hash_map *param_uses,
>> -hash_map *local_var_uses,
>> -vec *param_dtor_list, tree resume_fn_field,
>> -tree resume_idx_field, unsigned body_count, tree frame_size)
>> +tree orig, hash_map *local_var_uses,
>> +vec *param_dtor_list,
>> +tree resume_idx_var, unsigned body_count, tree frame_size)
>>  {
>>verify_stmt_tree (fnbody);
>>/* Some things we inherit from the original function.  */
>> @@ -2216,8 +2204,8 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
>>cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
>>  -  tree rat_field = lookup_member (coro_frame_type, 
>> coro_resume_index_field, 1, 0,
>> -  tf_warning_or_error);
>> +  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field,
>> +  1, 0, tf_warning_or_error);
>>tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
>>   rat_field, NULL_TREE);
>>  @@ -2319,14 +2307,8 @@ build_actor_fn (location_t loc, tree 
>> coro_frame_type, tree actor, tree fnbody,
>>tree r = build_stmt (loc, LABEL_EXPR, actor_begin_label);
>>add_stmt (r);
>>  -  /* actor's version of the promise.  */
>> -  tree ap_m = lookup_member (coro_frame_type, get_identifier 
>> ("_Coro_promise"), 1, 0,
>> - tf_warning_or_error);
>> -  tree ap = build_class_member_access_expr (actor_frame, ap_m, NULL_TREE, 
>> false,
>> -tf_warning_or_error);
>> -
>>/* actor's coroutine 'self handle'.  */
>> -  tree ash_m = lookup_member (coro_frame_type, get_identifier 
>> ("_Coro_self_handle"), 1,
>> +  tree ash_m = lookup_member (coro_frame_type, coro_self_handle_field, 1,
>>0, tf_warning_or_error);
>>tree ash = build_class_member_access_expr (actor_frame, ash_m, NULL_TREE,
>>   false, tf_warning_or_error);
>> @@ 

[PATCH] Improve backwards threader debugging dumps.

[Aldy Hernandez via Gcc-patches]

This patch adds debugging helpers to the backwards threader.  I have
also noticed that profitable_path_p() can bail early on paths that
crosses loops and leave the dump of blocks incomplete.  Fixed as
well.

Unfortunately the new methods cannot be marked const, because we call
the solver's dump which is not const.  I believe this was because the
ranger dump calls m_cache.block_range().  This could probably use a
cleanup at a later time.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadbackward.c (back_threader::dump): New.
(back_threader::debug): New.
(back_threader_profitability::profitable_path_p): Dump blocks
even if we are bailing early.
---
 gcc/tree-ssa-threadbackward.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 3aad1493c4d..b9a0d9a60ad 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-range-path.h"
 #include "ssa.h"
 #include "tree-cfgcleanup.h"
+#include "tree-pretty-print.h"
 
 // Path registry for the backwards threader.  After all paths have been
 // registered with register_path(), thread_through_all_blocks() is called
@@ -89,6 +90,8 @@ private:
   edge find_taken_edge (const vec );
   edge find_taken_edge_cond (const vec , gcond *);
   edge find_taken_edge_switch (const vec , gswitch *);
+  virtual void debug ();
+  virtual void dump (FILE *out);
 
   back_threader_registry m_registry;
   back_threader_profitability m_profit;
@@ -519,6 +522,30 @@ debug (const vec  )
   dump_path (stderr, path);
 }
 
+void
+back_threader::dump (FILE *out)
+{
+  m_solver.dump (out);
+  fprintf (out, "\nCandidates for pre-computation:\n");
+  fprintf (out, "===\n");
+
+  bitmap_iterator bi;
+  unsigned i;
+
+  EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi)
+{
+  tree name = ssa_name (i);
+  print_generic_expr (out, name, TDF_NONE);
+  fprintf (out, "\n");
+}
+}
+
+void
+back_threader::debug ()
+{
+  dump (stderr);
+}
+
 back_threader_registry::back_threader_registry (int max_allowable_paths)
   : m_max_allowable_paths (max_allowable_paths)
 {
@@ -607,6 +634,14 @@ back_threader_profitability::profitable_path_p (const 
vec _path,
  if (bb->loop_father != loop)
{
  path_crosses_loops = true;
+
+ // Dump rest of blocks.
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   for (j++; j < m_path.length (); j++)
+ {
+   bb = m_path[j];
+   fprintf (dump_file, " bb:%i", bb->index);
+ }
  break;
}
 
-- 
2.31.1

[PATCH] Dump reason why threads are being cancelled and abstract code.

[Aldy Hernandez via Gcc-patches]

We are inconsistent on dumping out reasons why a thread was canceled.
This makes debugging jump threading problems harder because paths can be
canceled with no reason given.  This patch abstracts out the thread
canceling code and adds a reason for every cancellation.

Tested on x86-64 Linux.

OK?

gcc/ChangeLog:

* tree-ssa-threadupdate.c (cancel_thread): New.
(jump_thread_path_registry::thread_block_1): Use cancel_thread.
(jump_thread_path_registry::mark_threaded_blocks): Same.
(jump_thread_path_registry::register_jump_thread): Same.
---
 gcc/tree-ssa-threadupdate.c | 56 +++--
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 1d32a0230fb..18f16efbb7a 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -245,6 +245,23 @@ debug (const vec *path)
   debug (*path);
 }
 
+/* Release the memory associated with PATH, and if dumping is enabled,
+   dump out the reason why the thread was canceled.  */
+
+static void
+cancel_thread (vec *path, const char *reason = NULL)
+{
+  if (dump_file && (dump_flags & TDF_DETAILS))
+{
+  if (reason)
+   fprintf (dump_file, "%s:\n", reason);
+
+  dump_jump_thread_path (dump_file, *path, false);
+  fprintf (dump_file, "\n");
+}
+  path->release ();
+}
+
 /* Simple hashing function.  For any given incoming edge E, we're going
to be most concerned with the final destination of its jump thread
path.  So hash on the block index of the final edge in the path.  */
@@ -1449,7 +1466,7 @@ jump_thread_path_registry::thread_block_1 (basic_block bb,
  /* Since this case is not handled by our special code
 to thread through a loop header, we must explicitly
 cancel the threading request here.  */
- path->release ();
+ cancel_thread (path, "Threading through unhandled loop header");
  e->aux = NULL;
  continue;
}
@@ -1488,7 +1505,7 @@ jump_thread_path_registry::thread_block_1 (basic_block bb,
 
  if (i != path->length ())
{
- path->release ();
+ cancel_thread (path, "Threading through loop exit");
  e->aux = NULL;
  continue;
}
@@ -1847,7 +1864,7 @@ fail:
 
   if (path)
{
- path->release ();
+ cancel_thread (path, "Failure in thread_through_loop_header");
  e->aux = NULL;
}
 }
@@ -1975,9 +1992,7 @@ jump_thread_path_registry::mark_threaded_blocks (bitmap 
threaded_blocks)
  else
{
  m_paths.unordered_remove (i);
- if (dump_file && (dump_flags & TDF_DETAILS))
-   dump_jump_thread_path (dump_file, *path, false);
- path->release ();
+ cancel_thread (path);
}
}
   else
@@ -2012,9 +2027,7 @@ jump_thread_path_registry::mark_threaded_blocks (bitmap 
threaded_blocks)
{
  e->aux = NULL;
  m_paths.unordered_remove (i);
- if (dump_file && (dump_flags & TDF_DETAILS))
-   dump_jump_thread_path (dump_file, *path, false);
- path->release ();
+ cancel_thread (path);
}
}
   else
@@ -2060,9 +2073,7 @@ jump_thread_path_registry::mark_threaded_blocks (bitmap 
threaded_blocks)
 
if (j != path->length ())
  {
-   if (dump_file && (dump_flags & TDF_DETAILS))
- dump_jump_thread_path (dump_file, *path, false);
-   path->release ();
+   cancel_thread (path);
e->aux = NULL;
  }
else
@@ -2109,7 +2120,7 @@ jump_thread_path_registry::mark_threaded_blocks (bitmap 
threaded_blocks)
 
  if (e2 && !phi_args_equal_on_edges (e2, final_edge))
{
- path->release ();
+ cancel_thread (path);
  e->aux = NULL;
}
}
@@ -2332,9 +2343,7 @@ jump_thread_path_registry::adjust_paths_after_duplication
  if (j == cand_path->length ())
{
remove_candidate_from_list:
- if (dump_file && (dump_flags & TDF_DETAILS))
-   fprintf (dump_file, "adjusted candidate: [EMPTY]\n");
- cand_path->release ();
+ cancel_thread (cand_path, "Adjusted candidate is EMPTY");
  m_paths.unordered_remove (cand_path_num);
  continue;
}
@@ -2595,7 +2604,7 @@ jump_thread_path_registry::thread_through_all_blocks
 
if (j != path->length ())
  {
-   path->release ();
+   cancel_thread (path, "Thread references removed edge");
m_paths.unordered_remove (i);
continue;
   

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:55 AM, Iain Sandoe wrote:


The user might well wish to inspect some of the state that represents
the implementation of the coroutine machine.

In particular:
   The promise object.
   The function pointers for the resumer and destroyer.
   The current resume index (suspend point).
   The handle that represent this coroutine 'self handle'.
   Whether the coroutine frame is allocated and needs to be freed.

These variables are given names that can be 'well-known' and advertised
in debug documentation - they are placed in the implementation namespace
and all begin with _Coro_.



Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (transform_await_expr): Use debug-friendly
names for coroutine implementation.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
(coro_rewrite_function_body): Likewise.
(morph_fn_to_coro): Likewise.


Hmm, this patch doesn't seem to match the description and ChangeLog 
entry other than in the names of the functions changed.



---
  gcc/cp/coroutines.cc | 214 +++
  1 file changed, 94 insertions(+), 120 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 3b46aac4dc5..aacf352f1c9 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1906,7 +1906,6 @@ transform_await_expr (tree await_expr, await_xform_data 
*xform)
/* So, on entry, we have:
   in : CO_AWAIT_EXPR (a, e_proxy, o, awr_call_vector, mode)
  We no longer need a [it had diagnostic value, maybe?]
- We need to replace the promise proxy in all elements
  We need to replace the e_proxy in the awr_call.  */
  
tree coro_frame_type = TREE_TYPE (xform->actor_frame);

@@ -1932,16 +1931,6 @@ transform_await_expr (tree await_expr, await_xform_data 
*xform)
TREE_OPERAND (await_expr, 1) = as;
  }
  
-  /* Now do the self_handle.  */

-  data.from = xform->self_h_proxy;
-  data.to = xform->real_self_h;
-  cp_walk_tree (_expr, replace_proxy, , NULL);
-
-  /* Now do the promise.  */
-  data.from = xform->promise_proxy;
-  data.to = xform->real_promise;
-  cp_walk_tree (_expr, replace_proxy, , NULL);
-
return await_expr;
  }
  
@@ -2128,10 +2117,9 @@ coro_get_frame_dtor (tree coro_fp, tree orig, tree frame_size,
  
  static void

  build_actor_fn (location_t loc, tree coro_frame_type, tree actor, tree fnbody,
-   tree orig, hash_map *param_uses,
-   hash_map *local_var_uses,
-   vec *param_dtor_list, tree resume_fn_field,
-   tree resume_idx_field, unsigned body_count, tree frame_size)
+   tree orig, hash_map *local_var_uses,
+   vec *param_dtor_list,
+   tree resume_idx_var, unsigned body_count, tree frame_size)
  {
verify_stmt_tree (fnbody);
/* Some things we inherit from the original function.  */
@@ -2216,8 +2204,8 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
  
-  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 1, 0,

- tf_warning_or_error);
+  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field,
+ 1, 0, tf_warning_or_error);
tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
 rat_field, NULL_TREE);
  
@@ -2319,14 +2307,8 @@ build_actor_fn (location_t loc, tree coro_frame_type, tree actor, tree fnbody,

tree r = build_stmt (loc, LABEL_EXPR, actor_begin_label);
add_stmt (r);
  
-  /* actor's version of the promise.  */

-  tree ap_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_promise"), 1, 0,
-tf_warning_or_error);
-  tree ap = build_class_member_access_expr (actor_frame, ap_m, NULL_TREE, 
false,
-   tf_warning_or_error);
-
/* actor's coroutine 'self handle'.  */
-  tree ash_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_self_handle"), 1,
+  tree ash_m = lookup_member (coro_frame_type, coro_self_handle_field, 1,
  0, tf_warning_or_error);
tree ash = build_class_member_access_expr (actor_frame, ash_m, NULL_TREE,
 false, tf_warning_or_error);
@@ -2347,36 +2329,13 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
   decide where to put things.  */
  
await_xform_data xform

-= {actor, actor_frame, promise_proxy, ap, self_h_proxy, ash};
+= {actor, actor_frame, NULL_TREE, NULL_TREE, self_h_proxy, ash};
  
/* Transform the await expressions in the function body.  Only do each

   await tree once!  */
hash_set pset;
cp_walk_tree (, transform_await_wrapper, , );
  
-  /* Now replace 

[COMMITTED] Avoid using unavailable objects in jt_state.

[Aldy Hernandez via Gcc-patches]

[Jeff: I'm going to go out on a limb here and commit this under the
obvious rule.  If I am overstepping my obvious powers, please let me
know.]

The jump threading state is about to get more interesting, and it may
get with a ranger or with the const_copies/etc helpers.  This patch
makes sure we have an object before we attempt to call push_marker or
pop_to_marker.

Tested on x86-64 Linux.

gcc/ChangeLog:

* tree-ssa-threadedge.c (jt_state::push): Only call methods for
which objects are available.
(jt_state::pop): Same.
(jt_state::register_equiv): Same.
(jt_state::register_equivs_on_edge): Same.
---
 gcc/tree-ssa-threadedge.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 8a485125ff5..e57f6d3e39c 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -1323,8 +1323,10 @@ jt_state::jt_state (const_and_copies *copies,
 void
 jt_state::push (edge)
 {
-  m_copies->push_marker ();
-  m_exprs->push_marker ();
+  if (m_copies)
+m_copies->push_marker ();
+  if (m_exprs)
+m_exprs->push_marker ();
   if (m_evrp)
 m_evrp->push_marker ();
 }
@@ -1334,8 +1336,10 @@ jt_state::push (edge)
 void
 jt_state::pop ()
 {
-  m_copies->pop_to_marker ();
-  m_exprs->pop_to_marker ();
+  if (m_copies)
+m_copies->pop_to_marker ();
+  if (m_exprs)
+m_exprs->pop_to_marker ();
   if (m_evrp)
 m_evrp->pop_to_marker ();
 }
@@ -1346,7 +1350,8 @@ jt_state::pop ()
 void
 jt_state::register_equiv (tree dst, tree src, bool update_range)
 {
-  m_copies->record_const_or_copy (dst, src);
+  if (m_copies)
+m_copies->record_const_or_copy (dst, src);
 
   /* If requested, update the value range associated with DST, using
  the range from SRC.  */
@@ -1396,7 +1401,8 @@ jt_state::record_ranges_from_stmt (gimple *stmt, bool 
temporary)
 void
 jt_state::register_equivs_on_edge (edge e)
 {
-  record_temporary_equivalences (e, m_copies, m_exprs);
+  if (m_copies && m_exprs)
+record_temporary_equivalences (e, m_copies, m_exprs);
 }
 
 jump_threader_simplifier::jump_threader_simplifier (vr_values *v)
-- 
2.31.1

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

[Jason Merrill via Gcc-patches]

On 9/3/21 9:42 AM, Iain Sandoe wrote:




On 3 Sep 2021, at 14:39, Jason Merrill  wrote:

On 9/1/21 6:54 AM, Iain Sandoe wrote:

This is an efficiency measure and repeats the pattern used for
other identifiers used in the coroutine implementation.
In support of debugging, the user might well need to look at some
of the variables that the implementation manipulates in lowering
the coroutines.  The defines the identifiers for these and populates
them on demand (avoiding repeated identifier calls).
Contributory to debug support (PR 99215)
Signed-off-by: Iain Sandoe 
gcc/cp/ChangeLog:
* coroutines.cc: Add identifiers for implementation
variables that we want to expose to debug.
(coro_init_identifiers): Initialize implementation names.
(coro_promise_type_found_p): Use pre-built identifiers.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
---
  gcc/cp/coroutines.cc | 32 
  1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 081e1a46c63..3b46aac4dc5 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -215,7 +215,17 @@ static GTY(()) tree coro_await_ready_identifier;
  static GTY(()) tree coro_await_suspend_identifier;
  static GTY(()) tree coro_await_resume_identifier;
  -/* Create the identifiers used by the coroutines library interfaces.  */
+/* Accessors for the coroutine frame state used by the implementation.  */
+
+static GTY(()) tree coro_resume_fn_field;
+static GTY(()) tree coro_destroy_fn_field;
+static GTY(()) tree coro_promise_field;
+static GTY(()) tree coro_frame_needs_free_field;
+static GTY(()) tree coro_resume_index_field;
+static GTY(()) tree coro_self_handle_field;


Since these are identifiers, not FIELD_DECLs, calling them *_field seems 
misleading.


I could append _id or _name .. they were just getting long already.
(they are names of fields, so that would not be misleading)


_id works for me, either with or without the _field.

Jason




+/* Create the identifiers used by the coroutines library interfaces and
+   the implementation frame state.  */
static void
  coro_init_identifiers ()
@@ -241,6 +251,14 @@ coro_init_identifiers ()
coro_await_ready_identifier = get_identifier ("await_ready");
coro_await_suspend_identifier = get_identifier ("await_suspend");
coro_await_resume_identifier = get_identifier ("await_resume");
+
+  /* Coroutine state frame field accessors.  */
+  coro_resume_fn_field = get_identifier ("_Coro_resume_fn");
+  coro_destroy_fn_field = get_identifier ("_Coro_destroy_fn");
+  coro_promise_field = get_identifier ("_Coro_promise");
+  coro_frame_needs_free_field = get_identifier ("_Coro_frame_needs_free");
+  coro_resume_index_field = get_identifier ("_Coro_resume_index");
+  coro_self_handle_field = get_identifier ("_Coro_self_handle");
  }
/* Trees we only need to set up once.  */
@@ -513,12 +531,12 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
/* Build a proxy for a handle to "self" as the param to
 await_suspend() calls.  */
coro_info->self_h_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_self_handle"),
+   = build_lang_decl (VAR_DECL, coro_self_handle_field,
   coro_info->handle_type);
  /* Build a proxy for the promise so that we can perform lookups.  */
coro_info->promise_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_promise"),
+   = build_lang_decl (VAR_DECL, coro_promise_field,
   coro_info->promise_type);
  /* Note where we first saw a coroutine keyword.  */
@@ -2198,8 +2216,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
  -  tree resume_idx_name = get_identifier ("_Coro_resume_index");
-  tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
+  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 1, 
0,
  tf_warning_or_error);
tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
 rat_field, NULL_TREE);
@@ -2462,7 +2479,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  /* We will need to know which resume point number should be encoded.  */
tree res_idx_m
-= lookup_member (coro_frame_type, resume_idx_name,
+= lookup_member (coro_frame_type, coro_resume_index_field,
 /*protect=*/1, /*want_type=*/0, tf_warning_or_error);
tree resume_pt_number
  = build_class_member_access_expr (actor_frame, res_idx_m, NULL_TREE, 
false,
@@ -2504,8 +2521,7 @@ build_destroy_fn (location_t loc, tree coro_frame_type, 
tree destroy,
  tree destr_frame = build1 (INDIRECT_REF, 

[COMMITTED] Do not release state location until after path registry.

[Aldy Hernandez via Gcc-patches]

We are popping state and then calling the registry code.  This causes
the registry to have incorrect information.  This isn't visible in
current trunk, but will be an issue when I submit further enhancements
to the threading code.  However, it is a cleanup on its own so I am
pushing it now.

Tested on x86-64 Linux.

Committed as obvious.

gcc/ChangeLog:

* tree-ssa-threadedge.c (jump_threader::thread_across_edge):
Move pop until after a thread is registered.
---
 gcc/tree-ssa-threadedge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 37ee5c11be3..8a485125ff5 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -1155,9 +1155,9 @@ jump_threader::thread_across_edge (edge e)
 {
   propagate_threaded_block_debug_into (path->last ()->e->dest,
   e->dest);
-  m_state->pop ();
   BITMAP_FREE (visited);
   m_registry->register_jump_thread (path);
+  m_state->pop ();
   return;
 }
   else
-- 
2.31.1

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

[Iain Sandoe]

> On 3 Sep 2021, at 14:39, Jason Merrill  wrote:
> 
> On 9/1/21 6:54 AM, Iain Sandoe wrote:
>> This is an efficiency measure and repeats the pattern used for
>> other identifiers used in the coroutine implementation.
>> In support of debugging, the user might well need to look at some
>> of the variables that the implementation manipulates in lowering
>> the coroutines.  The defines the identifiers for these and populates
>> them on demand (avoiding repeated identifier calls).
>> Contributory to debug support (PR 99215)
>> Signed-off-by: Iain Sandoe 
>> gcc/cp/ChangeLog:
>>  * coroutines.cc: Add identifiers for implementation
>>  variables that we want to expose to debug.
>>  (coro_init_identifiers): Initialize implementation names.
>>  (coro_promise_type_found_p): Use pre-built identifiers.
>>  (build_actor_fn): Likewise.
>>  (build_destroy_fn): Likewise.
>> ---
>>  gcc/cp/coroutines.cc | 32 
>>  1 file changed, 24 insertions(+), 8 deletions(-)
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index 081e1a46c63..3b46aac4dc5 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -215,7 +215,17 @@ static GTY(()) tree coro_await_ready_identifier;
>>  static GTY(()) tree coro_await_suspend_identifier;
>>  static GTY(()) tree coro_await_resume_identifier;
>>  -/* Create the identifiers used by the coroutines library interfaces.  */
>> +/* Accessors for the coroutine frame state used by the implementation.  */
>> +
>> +static GTY(()) tree coro_resume_fn_field;
>> +static GTY(()) tree coro_destroy_fn_field;
>> +static GTY(()) tree coro_promise_field;
>> +static GTY(()) tree coro_frame_needs_free_field;
>> +static GTY(()) tree coro_resume_index_field;
>> +static GTY(()) tree coro_self_handle_field;
> 
> Since these are identifiers, not FIELD_DECLs, calling them *_field seems 
> misleading.

I could append _id or _name .. they were just getting long already.
(they are names of fields, so that would not be misleading)

Iain


> 
>> +/* Create the identifiers used by the coroutines library interfaces and
>> +   the implementation frame state.  */
>>static void
>>  coro_init_identifiers ()
>> @@ -241,6 +251,14 @@ coro_init_identifiers ()
>>coro_await_ready_identifier = get_identifier ("await_ready");
>>coro_await_suspend_identifier = get_identifier ("await_suspend");
>>coro_await_resume_identifier = get_identifier ("await_resume");
>> +
>> +  /* Coroutine state frame field accessors.  */
>> +  coro_resume_fn_field = get_identifier ("_Coro_resume_fn");
>> +  coro_destroy_fn_field = get_identifier ("_Coro_destroy_fn");
>> +  coro_promise_field = get_identifier ("_Coro_promise");
>> +  coro_frame_needs_free_field = get_identifier ("_Coro_frame_needs_free");
>> +  coro_resume_index_field = get_identifier ("_Coro_resume_index");
>> +  coro_self_handle_field = get_identifier ("_Coro_self_handle");
>>  }
>>/* Trees we only need to set up once.  */
>> @@ -513,12 +531,12 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
>>/* Build a proxy for a handle to "self" as the param to
>>   await_suspend() calls.  */
>>coro_info->self_h_proxy
>> -= build_lang_decl (VAR_DECL, get_identifier ("_Coro_self_handle"),
>> += build_lang_decl (VAR_DECL, coro_self_handle_field,
>> coro_info->handle_type);
>>  /* Build a proxy for the promise so that we can perform lookups.  */
>>coro_info->promise_proxy
>> -= build_lang_decl (VAR_DECL, get_identifier ("_Coro_promise"),
>> += build_lang_decl (VAR_DECL, coro_promise_field,
>> coro_info->promise_type);
>>  /* Note where we first saw a coroutine keyword.  */
>> @@ -2198,8 +2216,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
>>cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
>>  -  tree resume_idx_name = get_identifier ("_Coro_resume_index");
>> -  tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
>> +  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 
>> 1, 0,
>>tf_warning_or_error);
>>tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
>>   rat_field, NULL_TREE);
>> @@ -2462,7 +2479,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  /* We will need to know which resume point number should be encoded.  */
>>tree res_idx_m
>> -= lookup_member (coro_frame_type, resume_idx_name,
>> += lookup_member (coro_frame_type, coro_resume_index_field,
>>   /*protect=*/1, /*want_type=*/0, tf_warning_or_error);
>>tree resume_pt_number
>>  = build_class_member_access_expr (actor_frame, res_idx_m, NULL_TREE, 
>> false,
>> @@ -2504,8 +2521,7 @@ build_destroy_fn 

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

[Iain Sandoe]

> On 3 Sep 2021, at 14:39, Jason Merrill  wrote:
> 
> On 9/1/21 6:54 AM, Iain Sandoe wrote:
>> This is an efficiency measure and repeats the pattern used for
>> other identifiers used in the coroutine implementation.
>> In support of debugging, the user might well need to look at some
>> of the variables that the implementation manipulates in lowering
>> the coroutines.  The defines the identifiers for these and populates
>> them on demand (avoiding repeated identifier calls).
>> Contributory to debug support (PR 99215)
>> Signed-off-by: Iain Sandoe 
>> gcc/cp/ChangeLog:
>>  * coroutines.cc: Add identifiers for implementation
>>  variables that we want to expose to debug.
>>  (coro_init_identifiers): Initialize implementation names.
>>  (coro_promise_type_found_p): Use pre-built identifiers.
>>  (build_actor_fn): Likewise.
>>  (build_destroy_fn): Likewise.
>> ---
>>  gcc/cp/coroutines.cc | 32 
>>  1 file changed, 24 insertions(+), 8 deletions(-)
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index 081e1a46c63..3b46aac4dc5 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -215,7 +215,17 @@ static GTY(()) tree coro_await_ready_identifier;
>>  static GTY(()) tree coro_await_suspend_identifier;
>>  static GTY(()) tree coro_await_resume_identifier;
>>  -/* Create the identifiers used by the coroutines library interfaces.  */
>> +/* Accessors for the coroutine frame state used by the implementation.  */
>> +
>> +static GTY(()) tree coro_resume_fn_field;
>> +static GTY(()) tree coro_destroy_fn_field;
>> +static GTY(()) tree coro_promise_field;
>> +static GTY(()) tree coro_frame_needs_free_field;
>> +static GTY(()) tree coro_resume_index_field;
>> +static GTY(()) tree coro_self_handle_field;
> 
> Since these are identifiers, not FIELD_DECLs, calling them *_field seems 
> misleading.

> 
>> +/* Create the identifiers used by the coroutines library interfaces and
>> +   the implementation frame state.  */
>>static void
>>  coro_init_identifiers ()
>> @@ -241,6 +251,14 @@ coro_init_identifiers ()
>>coro_await_ready_identifier = get_identifier ("await_ready");
>>coro_await_suspend_identifier = get_identifier ("await_suspend");
>>coro_await_resume_identifier = get_identifier ("await_resume");
>> +
>> +  /* Coroutine state frame field accessors.  */
>> +  coro_resume_fn_field = get_identifier ("_Coro_resume_fn");
>> +  coro_destroy_fn_field = get_identifier ("_Coro_destroy_fn");
>> +  coro_promise_field = get_identifier ("_Coro_promise");
>> +  coro_frame_needs_free_field = get_identifier ("_Coro_frame_needs_free");
>> +  coro_resume_index_field = get_identifier ("_Coro_resume_index");
>> +  coro_self_handle_field = get_identifier ("_Coro_self_handle");
>>  }
>>/* Trees we only need to set up once.  */
>> @@ -513,12 +531,12 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
>>/* Build a proxy for a handle to "self" as the param to
>>   await_suspend() calls.  */
>>coro_info->self_h_proxy
>> -= build_lang_decl (VAR_DECL, get_identifier ("_Coro_self_handle"),
>> += build_lang_decl (VAR_DECL, coro_self_handle_field,
>> coro_info->handle_type);
>>  /* Build a proxy for the promise so that we can perform lookups.  */
>>coro_info->promise_proxy
>> -= build_lang_decl (VAR_DECL, get_identifier ("_Coro_promise"),
>> += build_lang_decl (VAR_DECL, coro_promise_field,
>> coro_info->promise_type);
>>  /* Note where we first saw a coroutine keyword.  */
>> @@ -2198,8 +2216,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
>>cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
>>  -  tree resume_idx_name = get_identifier ("_Coro_resume_index");
>> -  tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
>> +  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 
>> 1, 0,
>>tf_warning_or_error);
>>tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
>>   rat_field, NULL_TREE);
>> @@ -2462,7 +2479,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
>> tree actor, tree fnbody,
>>  /* We will need to know which resume point number should be encoded.  */
>>tree res_idx_m
>> -= lookup_member (coro_frame_type, resume_idx_name,
>> += lookup_member (coro_frame_type, coro_resume_index_field,
>>   /*protect=*/1, /*want_type=*/0, tf_warning_or_error);
>>tree resume_pt_number
>>  = build_class_member_access_expr (actor_frame, res_idx_m, NULL_TREE, 
>> false,
>> @@ -2504,8 +2521,7 @@ build_destroy_fn (location_t loc, tree 
>> coro_frame_type, tree destroy,
>>  tree destr_frame = build1 (INDIRECT_REF, coro_frame_type, destr_fp);
>>  -  tree 

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:54 AM, Iain Sandoe wrote:


This is an efficiency measure and repeats the pattern used for
other identifiers used in the coroutine implementation.

In support of debugging, the user might well need to look at some
of the variables that the implementation manipulates in lowering
the coroutines.  The defines the identifiers for these and populates
them on demand (avoiding repeated identifier calls).

Contributory to debug support (PR 99215)

Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc: Add identifiers for implementation
variables that we want to expose to debug.
(coro_init_identifiers): Initialize implementation names.
(coro_promise_type_found_p): Use pre-built identifiers.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
---
  gcc/cp/coroutines.cc | 32 
  1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 081e1a46c63..3b46aac4dc5 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -215,7 +215,17 @@ static GTY(()) tree coro_await_ready_identifier;
  static GTY(()) tree coro_await_suspend_identifier;
  static GTY(()) tree coro_await_resume_identifier;
  
-/* Create the identifiers used by the coroutines library interfaces.  */

+/* Accessors for the coroutine frame state used by the implementation.  */
+
+static GTY(()) tree coro_resume_fn_field;
+static GTY(()) tree coro_destroy_fn_field;
+static GTY(()) tree coro_promise_field;
+static GTY(()) tree coro_frame_needs_free_field;
+static GTY(()) tree coro_resume_index_field;
+static GTY(()) tree coro_self_handle_field;


Since these are identifiers, not FIELD_DECLs, calling them *_field seems 
misleading.



+/* Create the identifiers used by the coroutines library interfaces and
+   the implementation frame state.  */
  
  static void

  coro_init_identifiers ()
@@ -241,6 +251,14 @@ coro_init_identifiers ()
coro_await_ready_identifier = get_identifier ("await_ready");
coro_await_suspend_identifier = get_identifier ("await_suspend");
coro_await_resume_identifier = get_identifier ("await_resume");
+
+  /* Coroutine state frame field accessors.  */
+  coro_resume_fn_field = get_identifier ("_Coro_resume_fn");
+  coro_destroy_fn_field = get_identifier ("_Coro_destroy_fn");
+  coro_promise_field = get_identifier ("_Coro_promise");
+  coro_frame_needs_free_field = get_identifier ("_Coro_frame_needs_free");
+  coro_resume_index_field = get_identifier ("_Coro_resume_index");
+  coro_self_handle_field = get_identifier ("_Coro_self_handle");
  }
  
  /* Trees we only need to set up once.  */

@@ -513,12 +531,12 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
/* Build a proxy for a handle to "self" as the param to
 await_suspend() calls.  */
coro_info->self_h_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_self_handle"),
+   = build_lang_decl (VAR_DECL, coro_self_handle_field,
   coro_info->handle_type);
  
/* Build a proxy for the promise so that we can perform lookups.  */

coro_info->promise_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_promise"),
+   = build_lang_decl (VAR_DECL, coro_promise_field,
   coro_info->promise_type);
  
/* Note where we first saw a coroutine keyword.  */

@@ -2198,8 +2216,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
  
-  tree resume_idx_name = get_identifier ("_Coro_resume_index");

-  tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
+  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 1, 
0,
  tf_warning_or_error);
tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
 rat_field, NULL_TREE);
@@ -2462,7 +2479,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  
/* We will need to know which resume point number should be encoded.  */

tree res_idx_m
-= lookup_member (coro_frame_type, resume_idx_name,
+= lookup_member (coro_frame_type, coro_resume_index_field,
 /*protect=*/1, /*want_type=*/0, tf_warning_or_error);
tree resume_pt_number
  = build_class_member_access_expr (actor_frame, res_idx_m, NULL_TREE, 
false,
@@ -2504,8 +2521,7 @@ build_destroy_fn (location_t loc, tree coro_frame_type, 
tree destroy,
  
tree destr_frame = build1 (INDIRECT_REF, coro_frame_type, destr_fp);
  
-  tree resume_idx_name = get_identifier ("_Coro_resume_index");

-  tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
+  tree rat_field = lookup_member (coro_frame_type, coro_resume_index_field, 1, 
0,
 

[COMMITTED] Add debug helper for jump thread paths.

[Aldy Hernandez via Gcc-patches]

Committed as obvious.

Tested on x86-64 Linux.

gcc/ChangeLog:

* tree-ssa-threadupdate.c (debug): New.
---
 gcc/tree-ssa-threadupdate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index d08e7d30d8d..1d32a0230fb 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -239,6 +239,12 @@ debug (const vec )
   dump_jump_thread_path (stderr, path, true);
 }
 
+DEBUG_FUNCTION void
+debug (const vec *path)
+{
+  debug (*path);
+}
+
 /* Simple hashing function.  For any given incoming edge E, we're going
to be most concerned with the final destination of its jump thread
path.  So hash on the block index of the final edge in the path.  */
-- 
2.31.1

Re: [PATCH 4/8] coroutines: Make some of the artificial names more debugger-friendly.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:54 AM, Iain Sandoe wrote:


Some of the compiler-generated entries are of interest to a
user debugging - keep variables in the implementation namespace
but avoid using periods as separators (which is not compatible
with visible symbols for some assemblers).

Partial improvement to debugging (PR 99215).


OK.


Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (coro_promise_type_found_p): Rename variable
to make it suitable for debugging.
(build_actor_fn): Likewise.
(build_destroy_fn): Likewise.
(register_local_var_uses): Likewise.
(coro_rewrite_function_body): Likewise.
(morph_fn_to_coro): Likewise.
---
  gcc/cp/coroutines.cc | 59 ++--
  1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index a12714ea67e..081e1a46c63 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -513,12 +513,12 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
/* Build a proxy for a handle to "self" as the param to
 await_suspend() calls.  */
coro_info->self_h_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("self_h.proxy"),
+   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_self_handle"),
   coro_info->handle_type);
  
/* Build a proxy for the promise so that we can perform lookups.  */

coro_info->promise_proxy
-   = build_lang_decl (VAR_DECL, get_identifier ("promise.proxy"),
+   = build_lang_decl (VAR_DECL, get_identifier ("_Coro_promise"),
   coro_info->promise_type);
  
/* Note where we first saw a coroutine keyword.  */

@@ -2198,7 +2198,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
  = {actor, actor_frame, coro_frame_type, loc, local_var_uses};
cp_walk_tree (, transform_local_var_uses, _vars_data, NULL);
  
-  tree resume_idx_name = get_identifier ("__resume_at");

+  tree resume_idx_name = get_identifier ("_Coro_resume_index");
tree rat_field = lookup_member (coro_frame_type, resume_idx_name, 1, 0,
  tf_warning_or_error);
tree rat = build3 (COMPONENT_REF, short_unsigned_type_node, actor_frame,
@@ -2303,13 +2303,13 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
add_stmt (r);
  
/* actor's version of the promise.  */

-  tree ap_m = lookup_member (coro_frame_type, get_identifier ("__p"), 1, 0,
+  tree ap_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_promise"), 1, 0,
 tf_warning_or_error);
tree ap = build_class_member_access_expr (actor_frame, ap_m, NULL_TREE, 
false,
tf_warning_or_error);
  
/* actor's coroutine 'self handle'.  */

-  tree ash_m = lookup_member (coro_frame_type, get_identifier ("__self_h"), 1,
+  tree ash_m = lookup_member (coro_frame_type, get_identifier 
("_Coro_self_handle"), 1,
  0, tf_warning_or_error);
tree ash = build_class_member_access_expr (actor_frame, ash_m, NULL_TREE,
 false, tf_warning_or_error);
@@ -2343,12 +2343,12 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
p_data.to = ap;
cp_walk_tree (, replace_proxy, _data, NULL);
  
-  /* The rewrite of the function adds code to set the __resume field to

+  /* The rewrite of the function adds code to set the resume_fn field to
   nullptr when the coroutine is done and also the index to zero when
   calling an unhandled exception.  These are represented by two proxies
   in the function, so rewrite them to the proper frame access.  */
tree resume_m
-= lookup_member (coro_frame_type, get_identifier ("__resume"),
+= lookup_member (coro_frame_type, get_identifier ("_Coro_resume_fn"),
 /*protect=*/1, /*want_type=*/0, tf_warning_or_error);
tree res_x = build_class_member_access_expr (actor_frame, resume_m, 
NULL_TREE,
   false, tf_warning_or_error);
@@ -2381,7 +2381,7 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
/* Here deallocate the frame (if we allocated it), which we will have at
   present.  */
tree fnf_m
-= lookup_member (coro_frame_type, get_identifier ("__frame_needs_free"), 1,
+= lookup_member (coro_frame_type, get_identifier 
("_Coro_frame_needs_free"), 1,
 0, tf_warning_or_error);
tree fnf2_x = build_class_member_access_expr (actor_frame, fnf_m, NULL_TREE,
false, tf_warning_or_error);
@@ -2504,7 +2504,7 @@ build_destroy_fn (location_t loc, tree coro_frame_type, 
tree destroy,
  
tree destr_frame = build1 (INDIRECT_REF, coro_frame_type, destr_fp);
  
-  tree 

Re: PATCH 3/8] coroutines: Support for debugging implementation state.

[Jason Merrill via Gcc-patches]

On 9/1/21 6:53 AM, Iain Sandoe wrote:


Some of the state that is associated with the implementation
is of interest to a user debugging a coroutine.  In particular
items such as the suspend point, promise object, and current
suspend point.

These variables live in the coroutine frame, but we can inject
proxies for them into the outermost bind expression of the
coroutine.  Such variables are automatically moved into the
coroutine frame (if they need to persist across a suspend
expression).  PLacing the proxies thus allows the user to
inspect them by name in the debugger.

To implement this, we ensure that (at the outermost scope) the
frame entries are not mangled (coroutine frame variables are
usually mangled with scope nesting information so that they do
not clash).  We can safely avoid doing this for the outermost
scope so that we can map frame entries directly to the variables.

This is partial contribution to debug support (PR 99215).


OK.


Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (register_local_var_uses): Do not mangle
frame entries for the outermost scope.  Record the outer
scope as nesting depth 0.
---
  gcc/cp/coroutines.cc | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index b8501032969..a12714ea67e 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3885,8 +3885,6 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  
if (TREE_CODE (*stmt) == BIND_EXPR)

  {
-  lvd->bind_indx++;
-  lvd->nest_depth++;
tree lvar;
for (lvar = BIND_EXPR_VARS (*stmt); lvar != NULL;
   lvar = DECL_CHAIN (lvar))
@@ -3925,11 +3923,17 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
continue;
  
  	  /* Make names depth+index unique, so that we can support nested

-scopes with identically named locals.  */
+scopes with identically named locals and still be able to
+identify them in the coroutine frame.  */
  tree lvname = DECL_NAME (lvar);
  char *buf;
- if (lvname != NULL_TREE)
-   buf = xasprintf ("__%s.%u.%u", IDENTIFIER_POINTER (lvname),
+ /* The outermost bind scope contains the artificial variables that
+we inject to implement the coro state machine.  We want to be able
+to inspect these in debugging.  */
+ if (lvname != NULL_TREE && lvd->nest_depth == 0)
+   buf = xasprintf ("%s", IDENTIFIER_POINTER (lvname));
+ else if (lvname != NULL_TREE)
+   buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
  else
buf = xasprintf ("_D%u.%u.%u", DECL_UID (lvar), lvd->nest_depth,
@@ -3942,6 +3946,8 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  /* We don't walk any of the local var sub-trees, they won't contain
 any bind exprs.  */
}
+  lvd->bind_indx++;
+  lvd->nest_depth++;
cp_walk_tree (_EXPR_BODY (*stmt), register_local_var_uses, d, 
NULL);
*do_subtree = 0; /* We've done this.  */
lvd->nest_depth--;

[COMMITTED] Add function name when dumping ranger contents.

[Aldy Hernandez via Gcc-patches]

These are minor cleanups to the dumping code.

Tested on x86-64 Linux.

gcc/ChangeLog:

* gimple-range-trace.cc (debug_seed_ranger): Remove static.
(dump_ranger): Dump function name.
---
 gcc/gimple-range-trace.cc | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-range-trace.cc b/gcc/gimple-range-trace.cc
index 1feb978e928..449ed8373fd 100644
--- a/gcc/gimple-range-trace.cc
+++ b/gcc/gimple-range-trace.cc
@@ -130,7 +130,7 @@ range_tracer::trailer (unsigned counter, const char 
*caller, bool result,
 
 // Query all statements in the IL to precalculate computable ranges in RANGER.
 
-static DEBUG_FUNCTION void
+DEBUG_FUNCTION void
 debug_seed_ranger (gimple_ranger )
 {
   // Recalculate SCEV to make sure the dump lists everything.
@@ -161,6 +161,11 @@ DEBUG_FUNCTION void
 dump_ranger (FILE *out)
 {
   gimple_ranger ranger;
+
+  fprintf (out, ";; Function ");
+  print_generic_expr (out, current_function_decl);
+  fprintf (out, "\n");
+
   debug_seed_ranger (ranger);
   ranger.dump (out);
 }
-- 
2.31.1

[COMMITTED] Use non-null knowledge in path_range_query.

[Aldy Hernandez via Gcc-patches]

[Jeff, I'm CCing you to keep you in the loop on changes that will impact
jump threading.  Since we're using one engine, any changes to the either
ranger or the path solver, is likely to improve jump threading.]

This patch improves ranges for pointers we are interested in a path, by
using the non-null class from the ranger.  This allows us to thread more
paths with minimal effort.

Tested on x86-64 Linux.

gcc/ChangeLog:

* gimple-range-path.cc (path_range_query::range_defined_in_block):
Adjust for non-null.
(path_range_query::adjust_for_non_null_uses): New.
(path_range_query::precompute_ranges): Call
adjust_for_non_null_uses.
* gimple-range-path.h: Add m_non_null and
adjust_for_non_null_uses.
---
 gcc/gimple-range-path.cc | 33 +
 gcc/gimple-range-path.h  |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index 6d6e5eb6635..db15eb3ff22 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -221,6 +221,9 @@ path_range_query::range_defined_in_block (irange , tree 
name, basic_block bb)
   else if (!fold_range (r, def_stmt, this))
 r.set_varying (TREE_TYPE (name));
 
+  if (bb)
+m_non_null.adjust_range (r, name, bb);
+
   if (DEBUG_SOLVER && (bb || !r.varying_p ()))
 {
   fprintf (dump_file, "range_defined_in_block (BB%d) for ", bb ? bb->index 
: -1);
@@ -302,6 +305,35 @@ path_range_query::precompute_ranges_in_block (basic_block 
bb)
 }
 }
 
+// Adjust all pointer imports in BB with non-null information.
+
+void
+path_range_query::adjust_for_non_null_uses (basic_block bb)
+{
+  int_range_max r;
+  bitmap_iterator bi;
+  unsigned i;
+
+  EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi)
+{
+  tree name = ssa_name (i);
+
+  if (!POINTER_TYPE_P (TREE_TYPE (name)))
+   continue;
+
+  if (get_cache (r, name))
+   {
+ if (r.nonzero_p ())
+   continue;
+   }
+  else
+   r.set_varying (TREE_TYPE (name));
+
+  if (m_non_null.adjust_range (r, name, bb))
+   set_cache (r, name);
+}
+}
+
 // Precompute the ranges for IMPORTS along PATH.
 //
 // IMPORTS are the set of SSA names, any of which could potentially
@@ -332,6 +364,7 @@ path_range_query::precompute_ranges (const vec 
,
   basic_block bb = curr_bb ();
 
   precompute_ranges_in_block (bb);
+  adjust_for_non_null_uses (bb);
 
   if (at_exit ())
break;
diff --git a/gcc/gimple-range-path.h b/gcc/gimple-range-path.h
index 0d2d2e7f75d..51773131040 100644
--- a/gcc/gimple-range-path.h
+++ b/gcc/gimple-range-path.h
@@ -53,6 +53,7 @@ private:
   // Methods to precompute ranges for the given path.
   bool range_defined_in_block (irange &, tree name, basic_block bb);
   void precompute_ranges_in_block (basic_block bb);
+  void adjust_for_non_null_uses (basic_block bb);
   void ssa_range_in_phi (irange , gphi *phi);
 
   // Path navigation.
@@ -80,6 +81,7 @@ private:
 
   const bitmap_head *m_imports;
   gimple_ranger _ranger;
+  non_null_ref m_non_null;
 };
 
 #endif // GCC_TREE_SSA_THREADSOLVER_H
-- 
2.31.1

[committed] libgomp.*/error-1.{c,f90}: Fix dg-output newline pattern

[Tobias Burnus]

Fixes the testcase for \r\n line breaks →
r12-3327-g4ce90454c2c81246be993d997cab12e21bc0be68

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 4ce90454c2c81246be993d997cab12e21bc0be68
Author: Tobias Burnus 
Date:   Fri Sep 3 15:24:41 2021 +0200

libgomp.*/error-1.{c,f90}: Fix dg-output newline pattern

libgomp/ChangeLog:

* testsuite/libgomp.c-c++-common/error-1.c: Use \r\n not \n\r in
dg-output.
* testsuite/libgomp.fortran/error-1.f90: Likewise.

diff --git a/libgomp/testsuite/libgomp.c-c++-common/error-1.c b/libgomp/testsuite/libgomp.c-c++-common/error-1.c
index 04c0519bf63..e7f550ae701 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/error-1.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/error-1.c
@@ -53,7 +53,7 @@ main ()
   return 0;
 }
 
-/* { dg-output "libgomp: error directive encountered(\n|\r|\n\r)(\n|\r|\n\r)" } */
-/* { dg-output "libgomp: error directive encountered: message(\n|\r|\n\r)(\n|\r|\n\r)" } */
-/* { dg-output "libgomp: error directive encountered: hello from a distance(\n|\r|\n\r)(\n|\r|\n\r)" } */
+/* { dg-output "libgomp: error directive encountered(\n|\r|\r\n)(\n|\r|\r\n)" } */
+/* { dg-output "libgomp: error directive encountered: message(\n|\r|\r\n)(\n|\r|\r\n)" } */
+/* { dg-output "libgomp: error directive encountered: hello from a distance(\n|\r|\r\n)(\n|\r|\r\n)" } */
 /* { dg-output "libgomp: fatal error: error directive encountered: my message" } */
diff --git a/libgomp/testsuite/libgomp.fortran/error-1.f90 b/libgomp/testsuite/libgomp.fortran/error-1.f90
index 7c497fd002e..ee3222d8894 100644
--- a/libgomp/testsuite/libgomp.fortran/error-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/error-1.f90
@@ -73,15 +73,15 @@ contains
end subroutine
 end
 
-! { dg-output "(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: Polonius(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: Laertes(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: Paris(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: To thine own self be true(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: message(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: Farewell(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: from a distance(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: Hello World(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: error directive encountered: mes(\n|\r|\n\r)(\n|\r|\n\r)" }
-! { dg-output "libgomp: fatal error: error directive encountered: my message   (\n|\r|\n\r)" }
+! { dg-output "(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: Polonius(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: Laertes(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: Paris(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: To thine own self be true(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: message(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: Farewell(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: from a distance(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: Hello World(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: error directive encountered: mes(\n|\r|\r\n)(\n|\r|\r\n)" }
+! { dg-output "libgomp: fatal error: error directive encountered: my message   (\n|\r|\r\n)" }

[Bug bootstrap/100832] s390x-linux-gnu: wrong number of alternatives in the output template

[jbglaw--- via Gcc-bugs]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jan-Benedict Glaw  ---
Confirmed with current trunk (8d34ffb4e8ed5300d0276b55f573add6db2517e8), this
error does no longer show up.

Thanks!

[COMMITTED] Improve path_range_query dumps.

[Aldy Hernandez via Gcc-patches]

Tested on x86-64 Linux.

gcc/ChangeLog:

* gimple-range-path.cc (path_range_query::dump): Dump path
length.
(path_range_query::precompute_ranges): Dump entire path.
---
 gcc/gimple-range-path.cc | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index 77b823e7bd5..6d6e5eb6635 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -92,7 +92,7 @@ path_range_query::dump (FILE *dump_file)
   bitmap_iterator bi;
   extern void dump_ranger (FILE *, const vec &);
 
-  fprintf (dump_file, "Path is:\n");
+  fprintf (dump_file, "Path is (length=%d):\n", m_path->length ());
   dump_ranger (dump_file, *m_path);
 
   fprintf (dump_file, "Imports:\n");
@@ -315,7 +315,17 @@ path_range_query::precompute_ranges (const 
vec ,
   m_imports = imports;
 
   if (DEBUG_SOLVER)
-fprintf (dump_file, "path_range_query: precompute_ranges\n");
+{
+  fprintf (dump_file, "\npath_range_query: precompute_ranges for path: ");
+  for (unsigned i = path.length (); i > 0; --i)
+   {
+ basic_block bb = path[i - 1];
+ fprintf (dump_file, "BB %d", bb->index);
+ if (i > 1)
+   fprintf (dump_file, ", ");
+   }
+  fprintf (dump_file, "\n");
+}
 
   while (1)
 {
-- 
2.31.1

[COMMITTED] Implement relation_oracle::debug.

[Aldy Hernandez via Gcc-patches]

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-relation.cc (relation_oracle::debug): New.
* value-relation.h (relation_oracle::debug): New.
---
 gcc/value-relation.cc | 6 ++
 gcc/value-relation.h  | 1 +
 2 files changed, 7 insertions(+)

diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 8edd98b612a..ba01d298521 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -1164,3 +1164,9 @@ relation_oracle::dump (FILE *f) const
dump (f, BASIC_BLOCK_FOR_FN (cfun, i));
   }
 }
+
+void
+relation_oracle::debug () const
+{
+  dump (stderr);
+}
diff --git a/gcc/value-relation.h b/gcc/value-relation.h
index e0e2f82c9ae..27158e051bf 100644
--- a/gcc/value-relation.h
+++ b/gcc/value-relation.h
@@ -142,6 +142,7 @@ public:
 
   void dump (FILE *f, basic_block bb) const;
   void dump (FILE *f) const;
+  void debug () const;
 private:
   bitmap m_tmp, m_tmp2;
   bitmap m_relation_set;  // Index by ssa-name. True if a relation exists
-- 
2.31.1