[Bug libstdc++/101571] New: DestroyGuard used by the ranges::uninitialized family should use addressof()

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 101571
   Summary: DestroyGuard used by the ranges::uninitialized family
should use addressof()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

The Standard Library should consistently use addressof() to defend itself
against overloaded operator&().

#include 

struct I {
  using value_type = std::string;
  using difference_type = std::ptrdiff_t;

  I& operator++();
  I operator++(int);
  value_type& operator*() const;
  void operator&() = delete;
  bool operator==(const I&) const;
};

int main() {
  std::ranges::uninitialized_default_construct(I{}, I{});
}

https://godbolt.org/z/5Pb67b9jx

[Bug analyzer/101550] -Wanalyzer-file-leak false positive with an array of pointers, open and fdopen.

[amatej at redhat dot com via Gcc-bugs]

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

--- Comment #2 from amatej at redhat dot com ---
I have: glibc-2.33.9000-43.fc35.x86_64.

Yes that is possible, I have just tried it in a container with:
glibc-2.33-20.fc34.x86_64 and gcc-11.1.1-3.fc34.x86_64 and it doesn't reproduce
there.

Re: [PATCH 05/10] AVX512FP16: Support vector init/broadcast/set/extract for FP16.

[Hongtao Liu via Gcc-patches]

On Wed, Jul 21, 2021 at 3:44 PM liuhongt  wrote:
>
> gcc/ChangeLog:
>
> * config/i386/avx512fp16intrin.h (_mm_set_ph): New intrinsic.
> (_mm256_set_ph): Likewise.
> (_mm512_set_ph): Likewise.
> (_mm_setr_ph): Likewise.
> (_mm256_setr_ph): Likewise.
> (_mm512_setr_ph): Likewise.
> (_mm_set1_ph): Likewise.
> (_mm256_set1_ph): Likewise.
> (_mm512_set1_ph): Likewise.
> (_mm_setzero_ph): Likewise.
> (_mm256_setzero_ph): Likewise.
> (_mm512_setzero_ph): Likewise.
> (_mm_set_sh): Likewise.
> (_mm_load_sh): Likewise.
> (_mm_store_sh): Likewise.
> * config/i386/i386-builtin-types.def (V8HF): New type.
> (DEF_FUNCTION_TYPE (V8HF, V8HI)): New builtin function type
> * config/i386/i386-expand.c (ix86_expand_vector_init_duplicate):
> Support vector HFmodes.
> (ix86_expand_vector_init_one_nonzero): Likewise.
> (ix86_expand_vector_init_one_var): Likewise.
> (ix86_expand_vector_init_interleave): Likewise.
> (ix86_expand_vector_init_general): Likewise.
> (ix86_expand_vector_set): Likewise.
> (ix86_expand_vector_extract): Likewise.
> (ix86_expand_vector_init_concat): Likewise.
> (ix86_expand_sse_movcc): Handle vector HFmodes.
> (ix86_expand_vector_set_var): Ditto.
> * config/i386/i386-modes.def: Add HF vector modes in comment.
> * config/i386/i386.c (classify_argument): Add HF vector modes.
> (ix86_hard_regno_mode_ok): Allow HF vector modes for AVX512FP16.
> (ix86_vector_mode_supported_p): Likewise.
> (ix86_set_reg_reg_cost): Handle vector HFmode.
> (ix86_get_ssemov): Handle vector HFmode.
> (function_arg_advance_64): Pass unamed V16HFmode and V32HFmode
> by stack.
Got some feedback by H.J that 16/32/64-byte vector _Float16 should be
passed by sse registers for 32-bit mode, not stack. will handle it in
function_arg_32  in my next version.
> * config/i386/i386.h (VALID_AVX512FP16_REG_MODE): New.
> (VALID_AVX256_REG_OR_OI_MODE): Rename to ..
> (VALID_AVX256_REG_OR_OI_VHF_MODE): .. this, and add V16HF.
> (VALID_SSE2_REG_VHF_MODE): New.
> (VALID_AVX512VL_128_REG_MODE): Add V8HF and TImode.
> (SSE_REG_MODE_P): Add vector HFmode.
> * config/i386/i386.md (mode): Add HF vector modes.
> (MODE_SIZE): Likewise.
> (ssemodesuffix): Add ph suffix for HF vector modes.
> * config/i386/sse.md (VFH_128): New mode iterator.
> (VMOVE): Adjust for HF vector modes.
> (V): Likewise.
> (V_256_512): Likewise.
> (avx512): Likewise.
> (avx512fmaskmode): Likewise.
> (shuffletype): Likewise.
> (sseinsnmode): Likewise.
> (ssedoublevecmode): Likewise.
> (ssehalfvecmode): Likewise.
> (ssehalfvecmodelower): Likewise.
> (ssePScmode): Likewise.
> (ssescalarmode): Likewise.
> (ssescalarmodelower): Likewise.
> (sseintprefix): Likewise.
> (i128): Likewise.
> (bcstscalarsuff): Likewise.
> (xtg_mode): Likewise.
> (VI12HF_AVX512VL): New mode_iterator.
> (VF_AVX512FP16): Likewise.
> (VIHF): Likewise.
> (VIHF_256): Likewise.
> (VIHF_AVX512BW): Likewise.
> (V16_256): Likewise.
> (V32_512): Likewise.
> (sseintmodesuffix): New mode_attr.
> (sse): Add scalar and vector HFmodes.
> (ssescalarmode): Add vector HFmode mapping.
> (ssescalarmodesuffix): Add sh suffix for HFmode.
> (*_vm3): Use VFH_128.
> (*_vm3): Likewise.
> (*ieee_3): Likewise.
> (_blendm): New define_insn.
> (vec_setv8hf): New define_expand.
> (vec_set_0): New define_insn for HF vector set.
> (*avx512fp16_movsh): Likewise.
> (avx512fp16_movsh): Likewise.
> (vec_extract_lo_v32hi): Rename to ...
> (vec_extract_lo_): ... this, and adjust to allow HF
> vector modes.
> (vec_extract_hi_v32hi): Likewise.
> (vec_extract_hi_): Likewise.
> (vec_extract_lo_v16hi): Likewise.
> (vec_extract_lo_): Likewise.
> (vec_extract_hi_v16hi): Likewise.
> (vec_extract_hi_): Likewise.
> (vec_set_hi_v16hi): Likewise.
> (vec_set_hi_): Likewise.
> (vec_set_lo_v16hi): Likewise.
> (vec_set_lo_: Likewise.
> (*vec_extract_0): New define_insn_and_split for HF
> vector extract.
> (*vec_extracthf): New define_insn.
> (VEC_EXTRACT_MODE): Add HF vector modes.
> (PINSR_MODE): Add V8HF.
> (sse2p4_1): Likewise.
> (pinsr_evex_isa): Likewise.
> (_pinsr): Adjust to support
> insert for V8HFmode.
> (pbroadcast_evex_isa): Add HF vector modes.
> (AVX2_VEC_DUP_MODE): Likewise.
> (VEC_INIT_MODE): Likewise.
>

Re: [PATCH 02/10] [i386] Enable _Float16 type for TARGET_SSE2 and above.

[Hongtao Liu via Gcc-patches]

On Wed, Jul 21, 2021 at 6:35 PM Uros Bizjak  wrote:
>
> On Wed, Jul 21, 2021 at 9:43 AM liuhongt  wrote:
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386-modes.def (FLOAT_MODE): Define ieee HFmode.
> > * config/i386/i386.c (enum x86_64_reg_class): Add
> > X86_64_SSEHF_CLASS.
> > (merge_classes): Handle X86_64_SSEHF_CLASS.
> > (examine_argument): Ditto.
> > (construct_container): Ditto.
> > (classify_argument): Ditto, and set HFmode/HCmode to
> > X86_64_SSEHF_CLASS.
> > (function_value_32): Return _FLoat16/Complex Float16 by
> > %xmm0/%xmm1.
I forget to update changelog entry here, Complex _Float16 will be
returned by 1 sse register, will be updated in my next version.
> > (function_value_64): Return _Float16/Complex Float16 by SSE
> > register.
> > (ix86_print_operand): Handle CONST_DOUBLE HFmode.
> > (ix86_secondary_reload): Require gpr as intermediate register
> > to store _Float16 from sse register when sse4 is not
> > available.
> > (ix86_hard_regno_mode_ok): Put HFmode in sse register and gpr.
> > (ix86_libgcc_floating_mode_supported_p): Enable _FLoat16 under
> > sse2.
> > (ix86_scalar_mode_supported_p): Ditto.
> > (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Defined.
> > (ix86_get_excess_precision): Return
> > FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 under sse2.
> > * config/i386/i386.h (VALID_SSE2_REG_MODE): Add HFmode.
> > * config/i386/i386.md (*pushhf_rex64): New define_insn.
> > (*pushhf): Ditto.
> > (*movhf_internal): Ditto.
> > * doc/extend.texi (Half-Precision Floating Point): Documemt
> > _Float16 for x86.
> >
> > gcc/lto/ChangeLog:
> >
> > * lto-lang.c (lto_type_for_mode): Return float16_type_node
> > when mode == TYPE_MODE (float16_type_node).
> >
> > gcc/testsuite/ChangeLog
> >
> > * gcc.target/i386/sse2-float16-1.c: New test.
> > * gcc.target/i386/sse2-float16-2.c: Ditto.
> > * gcc.target/i386/sse2-float16-3.c: Ditto.
>
> OK for the x86 part with some small changes inline.
>
> Thanks,
> Uros.
>
> > ---
> >  gcc/config/i386/i386-modes.def|   1 +
> >  gcc/config/i386/i386.c|  99 ++-
> >  gcc/config/i386/i386.h|   2 +-
> >  gcc/config/i386/i386.md   | 118 +-
> >  gcc/doc/extend.texi   |  16 +++
> >  gcc/lto/lto-lang.c|   3 +
> >  .../gcc.target/i386/sse2-float16-1.c  |   8 ++
> >  .../gcc.target/i386/sse2-float16-2.c  |  16 +++
> >  .../gcc.target/i386/sse2-float16-3.c  |  12 ++
> >  9 files changed, 265 insertions(+), 10 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-float16-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-float16-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-float16-3.c
> >
> > diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
> > index 4e7014be034..9232f59a925 100644
> > --- a/gcc/config/i386/i386-modes.def
> > +++ b/gcc/config/i386/i386-modes.def
> > @@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
> >
> >  FRACTIONAL_FLOAT_MODE (XF, 80, 12, ieee_extended_intel_96_format);
> >  FLOAT_MODE (TF, 16, ieee_quad_format);
> > +FLOAT_MODE (HF, 2, ieee_half_format);
> >
> >  /* In ILP32 mode, XFmode has size 12 and alignment 4.
> > In LP64 mode, XFmode has size and alignment 16.  */
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index ff96134fb37..02628d838fc 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -387,6 +387,7 @@ enum x86_64_reg_class
> >  X86_64_INTEGER_CLASS,
> >  X86_64_INTEGERSI_CLASS,
> >  X86_64_SSE_CLASS,
> > +X86_64_SSEHF_CLASS,
> >  X86_64_SSESF_CLASS,
> >  X86_64_SSEDF_CLASS,
> >  X86_64_SSEUP_CLASS,
> > @@ -2023,8 +2024,10 @@ merge_classes (enum x86_64_reg_class class1, enum 
> > x86_64_reg_class class2)
> >  return X86_64_MEMORY_CLASS;
> >
> >/* Rule #4: If one of the classes is INTEGER, the result is INTEGER.  */
> > -  if ((class1 == X86_64_INTEGERSI_CLASS && class2 == X86_64_SSESF_CLASS)
> > -  || (class2 == X86_64_INTEGERSI_CLASS && class1 == 
> > X86_64_SSESF_CLASS))
> > +  if ((class1 == X86_64_INTEGERSI_CLASS
> > +   && (class2 == X86_64_SSESF_CLASS || class2 == X86_64_SSEHF_CLASS))
> > +  || (class2 == X86_64_INTEGERSI_CLASS
> > + && (class1 == X86_64_SSESF_CLASS || class1 == 
> > X86_64_SSEHF_CLASS)))
> >  return X86_64_INTEGERSI_CLASS;
> >if (class1 == X86_64_INTEGER_CLASS || class1 == X86_64_INTEGERSI_CLASS
> >|| class2 == X86_64_INTEGER_CLASS || class2 == 
> > X86_64_INTEGERSI_CLASS)
> > @@ -2178,6 +2181,8 @@ classify_argument (machine_mode mode, const_tree type,
> > 

Re: [PATCH] [i386] Remove pass_cpb which is related to enable avx512 embedded broadcast from constant pool.

[Hongtao Liu via Gcc-patches]

On Wed, Jul 14, 2021 at 8:38 PM H.J. Lu  wrote:
>
> On Tue, Jul 13, 2021 at 9:35 PM Hongtao Liu  wrote:
> >
> > On Wed, Jul 14, 2021 at 10:34 AM liuhongt  wrote:
> > >
> > > By optimizing vector movement to broadcast in ix86_expand_vector_move
> > > during pass_expand, pass_reload/LRA can automatically generate an avx512
> > > embedded broadcast, pass_cpb is not needed.
> > >
> > > Considering that in the absence of avx512f, broadcast from memory is
> > > still slightly faster than loading the entire memory, so always enable
> > > broadcast.
> > >
> > > benchmark:
> > > https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/vaddps/broadcast
> > >
> > > The performance diff
> > >
> > > strategy: cycles
> > > memory  : 1046611188
> > > memory  : 1255420817
> > > memory  : 1044720793
> > > memory  : 1253414145
> > > average : 1097868397
> > >
> > > broadcast   : 1044430688
> > > broadcast   : 1044477630
> > > broadcast   : 1253554603
> > > broadcast   : 1044561934
> > > average : 1096756213
> > >
> > > But however broadcast has larger size.
> > >
> > > the size diff
> > >
> > > size broadcast.o
> > >textdata bss dec hex filename
> > > 137   0   0 137  89 broadcast.o
> > >
> > > size memory.o
> > >textdata bss dec hex filename
> > > 115   0   0 115  73 memory.o
> > >
> > > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/i386/i386-expand.c
> > > (ix86_broadcast_from_integer_constant): Rename to ..
> > > (ix86_broadcast_from_constant): .. this, and extend it to
> > > handle float mode.
> > > (ix86_expand_vector_move): Extend to float mode.
> > > * config/i386/i386-features.c
> > > (replace_constant_pool_with_broadcast): Remove.
> > > (remove_partial_avx_dependency_gate): Ditto.
> > > (constant_pool_broadcast): Ditto.
> > > (class pass_constant_pool_broadcast): Ditto.
> > > (make_pass_constant_pool_broadcast): Ditto.
> > > (remove_partial_avx_dependency): Adjust gate.
> > > * config/i386/i386-passes.def: Remove 
> > > pass_constant_pool_broadcast.
> > > * config/i386/i386-protos.h
> > > (make_pass_constant_pool_broadcast): Remove.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.target/i386/fuse-caller-save-xmm.c: Adjust testcase.
> > > ---
> > >  gcc/config/i386/i386-expand.c |  29 +++-
> > >  gcc/config/i386/i386-features.c   | 157 +-
> > >  gcc/config/i386/i386-passes.def   |   1 -
> > >  gcc/config/i386/i386-protos.h |   1 -
> > >  .../gcc.target/i386/fuse-caller-save-xmm.c|   2 +-
> > >  5 files changed, 26 insertions(+), 164 deletions(-)
> > >
> > > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> > > index 69ea79e6123..ba870145acd 100644
> > > --- a/gcc/config/i386/i386-expand.c
> > > +++ b/gcc/config/i386/i386-expand.c
> > > @@ -453,8 +453,10 @@ ix86_expand_move (machine_mode mode, rtx operands[])
> > >emit_insn (gen_rtx_SET (op0, op1));
> > >  }
> > >
> > > +/* OP is a memref of CONST_VECTOR, return scalar constant mem
> > > +   if CONST_VECTOR is a vec_duplicate, else return NULL.  */
> > >  static rtx
> > > -ix86_broadcast_from_integer_constant (machine_mode mode, rtx op)
> > > +ix86_broadcast_from_constant (machine_mode mode, rtx op)
> > >  {
> > >int nunits = GET_MODE_NUNITS (mode);
> > >if (nunits < 2)
> > > @@ -462,7 +464,8 @@ ix86_broadcast_from_integer_constant (machine_mode 
> > > mode, rtx op)
> > >
> > >/* Don't use integer vector broadcast if we can't move from GPR to SSE
> > >   register directly.  */
> > > -  if (!TARGET_INTER_UNIT_MOVES_TO_VEC)
> > > +  if (!TARGET_INTER_UNIT_MOVES_TO_VEC
> > > +  && INTEGRAL_MODE_P (mode))
> > >  return nullptr;
> > >
> > >/* Convert CONST_VECTOR to a non-standard SSE constant integer
> > > @@ -470,12 +473,17 @@ ix86_broadcast_from_integer_constant (machine_mode 
> > > mode, rtx op)
> > >if (!(TARGET_AVX2
> > > || (TARGET_AVX
> > > && (GET_MODE_INNER (mode) == SImode
> > > -   || GET_MODE_INNER (mode) == DImode)))
> > > +   || GET_MODE_INNER (mode) == DImode))
> > > +   || FLOAT_MODE_P (mode))
> > >|| standard_sse_constant_p (op, mode))
> > >  return nullptr;
> > >
> > > -  /* Don't broadcast from a 64-bit integer constant in 32-bit mode.  */
> > > -  if (GET_MODE_INNER (mode) == DImode && !TARGET_64BIT)
> > > +  /* Don't broadcast from a 64-bit integer constant in 32-bit mode.
> > > + We can still put 64-bit integer constant in memory when
> > > + avx512 embed broadcast is available.  */
> > > +  if (GET_MODE_INNER (mode) == DImode && !TARGET_64BIT
> > > +  && (!TARGET_AVX512F
> > > + || (GET_MODE_SIZE (mode) < 64 && !TARGET_AVX512VL)))
> > > 

Re: [POWER10] __morestack calls from pcrel code

[Alan Modra via Gcc-patches]

On Wed, Jul 21, 2021 at 08:59:04AM -0400, David Edelsohn wrote:
> On Wed, Jul 21, 2021 at 4:29 AM Alan Modra  wrote:
> >
> > On Wed, Jul 14, 2021 at 08:24:16PM -0400, David Edelsohn wrote:
> > > > > > * config/rs6000/morestack.S (R2_SAVE): Define.
> > > > > > (__morestack): Save and restore r2.  Set up r2 for called
> > > > > > functions.
> > >
> > > This patch is okay.
> >
> > Thanks David, the patch is needed on gcc-11 and gcc-10 too.
> > OK for the branches too?
> 
> Backports are fine, but I believe that Richi is planning to cut GCC 11
> RC today, so you really should check with him about a backport at the
> last minute.

Hi Richard,
Is this patch OK at this late stage for the gcc-11 branch?
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573978.html

The impacts of the bug are segfaults and other undesirable behaviour
with Go (or more generally -fsplit-stack) on power10 when libgcc is
not power10 pcrel.  A non-pcrel libgcc is very likely how distros
will ship gcc.

-- 
Alan Modra
Australia Development Lab, IBM

[Bug target/101504] [12 Regression] ICE: in lra_assign, at lra-assigns.c:1649 with -O2 -march=broadwell

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

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-22
 Status|UNCONFIRMED |NEW

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Alan Modra  ---
Preserving certain -m gas options goes back to this patch:
https://sourceware.org/pipermail/binutils/2008-January/054935.html

Given the number of ppc micros around with differing functional units, it is
quite reasonable that we have assembly options to say "this base cpu" plus
"this extra functionality".  Whether you think it was wise to allow those
"extra functionality" options to be specified before the "base cpu" option is
another matter, but it has been that way for a long time.  I'm not inclined to
change that since it would very likely break some projects, and I happen to
think that it is entirely reasonable to expect that "-maltivec -mppc64" for
example is the same as "-mppc64 -maltivec".

In any case sticky options are a side issue here.  The real issue is that
emitted .machine is wrong.  Note that I'm not vetoing assembler changes.  It
might be a good idea to reset all sticky options on processing any .machine
directive for example, and I'm happy with the idea of -mno-vsx etc. options for
the assembler.

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law via Gcc]

On 7/21/2021 6:31 PM, Michael Eager wrote:



On 7/21/21 5:22 PM, Joel Sherrill wrote:



On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:


    On 7/21/21 2:28 PM, Joel Sherrill wrote:
 > Hi
 >
 > We are in the process of porting RTEMS to the Microblaze and 
gcc does

 > not have __ELF__ as a predefine. In looking around at where to
    add it,
 > it looks like there are multiple ways to do it. We see 
variations on

 > the following patterns:
 >
 > + dbxelf.h
 > + OS specific header in config/
 > + Arch/OS specific header
 >
 > Integrating dbxelf.h into the microblaze seems risky for one 
simple

 > builtin_define(). Adding it to config/microblaze/rtems.h won't
    address
 > the microblaze-elf target.
 >
 > A suggestion on where to add the builtin_predefine is 
appreciated.


    There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are 
130 references to that file there. That seems to be where most 
architectures get it.


AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.
Avoiding dbxelf would be advisable.  We're really only supporting stabs 
for for aix anymore.  We need to start excising dbxelf from all the 
places it's being used.


jeff

[Bug analyzer/101570] New: [12 Regression] ICE in maybe_reconstruct_from_def_stmt, at analyzer/analyzer.cc:133

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 101570
   Summary: [12 Regression] ICE in
maybe_reconstruct_from_def_stmt, at
analyzer/analyzer.cc:133
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-12.0.0-alpha20210718 snapshot (g:6ae8aac19cdbdbd96d90f86e4d8505fe121bdf06)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/torture/pr70370.c, w/ -fanalyzer:

void
test2 (_Complex double f)
{
  __asm__ ("" : "=r" (__real f));
}

% gcc-12.0.0 -fanalyzer -c erc6pp1g.c
during IPA pass: analyzer
erc6pp1g.c: In function 'test2':
erc6pp1g.c:4:3: internal compiler error: in maybe_reconstruct_from_def_stmt, at
analyzer/analyzer.cc:133
4 |   __asm__ ("" : "=r" (__real f));
  |   ^~~
0x7ff6f0 maybe_reconstruct_from_def_stmt
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:133
0x7ff6f0 fixup_tree_for_diagnostic_1
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:180
0x1a32b3a fixup_tree_for_diagnostic_1
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/hash-table.h:687
0x1a32b3a ana::fixup_tree_for_diagnostic(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:201
0x120761f ana::region_model::check_for_poison(ana::svalue const*, tree_node*,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:839
0x120ba80 ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:1842
0x120ba80 ana::region_model::get_gassign_result(gassign const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:765
0x120c62c ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:869
0x11e998d ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:1223
0x11ebf22 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:3098
0x11eca8a ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:2684
0x115 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:4972
0x11efd80 ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:5043
0x11e0e48 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer-pass.cc:87

[Bug gcov-profile/101569] New: [GCOV] Wrong coverage caused by callee format.

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101569
   Summary: [GCOV] Wrong coverage caused by callee format.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 


$ cat test.c
#include
#include
typedef unsigned char u8;
typedef unsigned long long u64;

static inline __attribute__((always_inline)) u64 __swab64p(const u64 *p) {
  return (__builtin_constant_p((u64)(*p))? 
   (u64)(((u64)(*p) & (u64)0x00ffULL) << 56)
   :__builtin_bswap64(*p));
}

static inline u64 wwn_to_u64(void *wwn) { return __swab64p(wwn); }

static inline u64 wwn_to_u64_copy(void *wwn) { 
return __swab64p(wwn); 
}

void __attribute__((noinline, noclone)) broken(u64 *shost) {
  u8 node_name[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
  *shost = wwn_to_u64(node_name);
  *shost = wwn_to_u64_copy(node_name);
}

int main(int argc, char *argv[]) {
  u64 v;

  broken();

  if (v != (u64)-1)
__builtin_abort();

  return 0;
}

$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:92.86% of 14
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:typedef unsigned char u8;
-:4:typedef unsigned long long u64;
-:5:
-:6:static inline __attribute__((always_inline)) u64
__swab64p(const u64 *p) {
-:7:  return (__builtin_constant_p((u64)(*p))? 
-:8:   (u64)(((u64)(*p) &
(u64)0x00ffULL) << 56)
2:9:   :__builtin_bswap64(*p));
-:   10:}
-:   11:
2:   12:static inline u64 wwn_to_u64(void *wwn) { return
__swab64p(wwn); }
-:   13:
1:   14:static inline u64 wwn_to_u64_copy(void *wwn) { 
1:   15:return __swab64p(wwn); 
-:   16:}
-:   17:
1:   18:void __attribute__((noinline, noclone)) broken(u64 *shost) {
1:   19:  u8 node_name[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF};
1:   20:  *shost = wwn_to_u64(node_name);
1:   21:  *shost = wwn_to_u64_copy(node_name);
1:   22:}
-:   23:
1:   24:int main(int argc, char *argv[]) {
-:   25:  u64 v;
-:   26:
1:   27:  broken();
-:   28:
1:   29:  if (v != (u64)-1)
#:   30:__builtin_abort();
-:   31:
1:   32:  return 0;
-:   33:}

Line 14 and 15 were executed once. However, when they are in one line, the
coverage becomes 2.

Re: [PATCH 1/2] RISC-V: Add arch flags for T-HEAD.

[Jojo R via Gcc-patches]

— Jojo
在 2021年7月22日 +0800 AM4:53，Jim Wilson ，写道：
> On Tue, Jul 13, 2021 at 11:06 AM Palmer Dabbelt  wrote:
> > Is there are documentation as to what this "theadc" extension is?
>
> The best doc I know of is    https://github.com/isrc-cas/c910-llvmThe README 
> is in Chinese, but google translate does a decent job on it.  If you want 
> more details, you have to read the llvm sources to see exactly what each 
> instruction does.  They have mentioned that they are working on English 
> language docs, but I don't know when they will be available.
> There are quite a few T-Head specific instructions here.  This patch is only 
> adding support for a few of them, probably as a trial to see how it goes 
> before they try to add the rest.
Hi,

Please let me feed more details for this patch,

There are about ~100+ instructions in our ISA spec,
and we put the RFC[1] to ask guide how to commit vendor extension ISAs,
we want to commit one type instruction every time, it’s helpful for 
reviewing.

Some Chinese T-HEAD ISA Specs have been on the our web page [2] already,
and we are converting these docs to english version to help your 
reading :)
it will be out in the next week, including binutils.

Thanks for your suggestion of the patch

[1] https://github.com/riscv/riscv-gcc/issues/278
[2] https://www.t-head.cn/technology
> Jim
>

RE: [PATCH] Support logic shift left/right for avx512 mask type.

[Liu, Hongtao via Gcc-patches]

>-Original Message-
>From: Uros Bizjak 
>Sent: Wednesday, July 21, 2021 4:23 PM
>To: Hongtao Liu 
>Cc: Liu, Hongtao ; gcc-patches@gcc.gnu.org; H. J. Lu
>; Richard Biener 
>Subject: Re: [PATCH] Support logic shift left/right for avx512 mask type.
>
>On Wed, Jul 21, 2021 at 5:05 AM Hongtao Liu  wrote:
>>
>> On Tue, Jul 20, 2021 at 9:41 PM Uros Bizjak  wrote:
>> >
>> > On Tue, Jul 20, 2021 at 2:33 PM liuhongt  wrote:
>> > >
>> > > Hi:
>> > >   As mention in
>> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575420.html
>> > >
>> > > cut start-
>> > > > note for the lowpart we can just view-convert away the excess
>> > > > bits, fully re-using the mask.  We generate surprisingly "good" code:
>> > > >
>> > > > kmovb   %k1, %edi
>> > > > shrb$4, %dil
>> > > > kmovb   %edi, %k2
>> > > >
>> > > > besides the lack of using kshiftrb.  I guess we're just lacking
>> > > > a mask register alternative for
>> > > Yes, we can do it similar as kor/kand/kxor.
>> > > ---cut end
>> > >
>> > >   Bootstrap and regtested on x86_64-linux-gnu{-m32,}.
>> > >   Ok for trunk?
>> > >
>> > > gcc/ChangeLog:
>> > >
>> > > * config/i386/constraints.md (Wb): New constraint.
>> > > (Ww): Ditto.
>> > > * config/i386/i386.md (*ashlhi3_1): Extend to avx512 mask
>> > > shift.
>> > > (*ashlqi3_1): Ditto.
>> > > (*3_1): Ditto.
>> > > (*3_1): Ditto.
>> > > * config/i386/sse.md (k): New define_split after
>> > > it to convert generic shift pattern to mask shift ones.
>> > >
>> > > gcc/testsuite/ChangeLog:
>> > >
>> > > * gcc.target/i386/mask-shift.c: New test.
>
>
>+(define_insn "*lshr3_1"
>+  [(set (match_operand:SWI12 0 "nonimmediate_operand" "=m, ?k")
>+(lshiftrt:SWI12
>+  (match_operand:SWI12 1 "nonimmediate_operand" "0, k")
>+  (match_operand:QI 2 "nonmemory_operand" "c, ")))
>+   (clobber (reg:CC FLAGS_REG))]
>+  "ix86_binary_operator_ok (LSHIFTRT, mode, operands)"
>
>Also split this one to QImode and HImode to avoid conditions in isa attribute.
>
>OK with this change.
>

Thanks for the review, here's the patch I'm check in.

>Thanks,
>Uros.


V3-0001-Support-logic-shift-left-right-for-avx512-mask-type.patch
Description: V3-0001-Support-logic-shift-left-right-for-avx512-mask-type.patch

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 5:22 PM, Joel Sherrill wrote:



On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:


On 7/21/21 2:28 PM, Joel Sherrill wrote:
 > Hi
 >
 > We are in the process of porting RTEMS to the Microblaze and gcc does
 > not have __ELF__ as a predefine. In looking around at where to
add it,
 > it looks like there are multiple ways to do it. We see variations on
 > the following patterns:
 >
 > + dbxelf.h
 > + OS specific header in config/
 > + Arch/OS specific header
 >
 > Integrating dbxelf.h into the microblaze seems risky for one simple
 > builtin_define(). Adding it to config/microblaze/rtems.h won't
address
 > the microblaze-elf target.
 >
 > A suggestion on where to add the builtin_predefine is appreciated.

There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are 130 
references to that file there. That seems to be where most architectures 
get it.


AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.





Why don't you put this in rtems.h?


That's ok for a hack but we haven't had to do that on the other ports so 
it seems wrong.


Yep.



I didn't mention but without this defined the cdefs.h file in newlib 
produces incorrect macro definitions for at the weak_reference macro.



Alternately, you might put it in microblaze-s.c, wrapped with
#ifdef OBJECT_FORMAT_ELF/#endif.


Ok. This should fix it for microblaze-elf also.


ARM does something which looks screwy to me.  Instead of defining
__ELF__, they pass -D__ELF__ on the CPP command line.



Thanks.

--joel


-- 
Michael Eager




--
Michael Eager

Re: Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

On Wed, Jul 21, 2021, 7:12 PM Michael Eager  wrote:

> On 7/21/21 2:28 PM, Joel Sherrill wrote:
> > Hi
> >
> > We are in the process of porting RTEMS to the Microblaze and gcc does
> > not have __ELF__ as a predefine. In looking around at where to add it,
> > it looks like there are multiple ways to do it. We see variations on
> > the following patterns:
> >
> > + dbxelf.h
> > + OS specific header in config/
> > + Arch/OS specific header
> >
> > Integrating dbxelf.h into the microblaze seems risky for one simple
> > builtin_define(). Adding it to config/microblaze/rtems.h won't address
> > the microblaze-elf target.
> >
> > A suggestion on where to add the builtin_predefine is appreciated.
>
> There are very few defines for __ELF__ in the GCC target files.
>

Many  targets include dbxelf.h from the config.gcc script. There are 130
references to that file there. That seems to be where most architectures
get it.



> Why don't you put this in rtems.h?
>

That's ok for a hack but we haven't had to do that on the other ports so it
seems wrong.

I didn't mention but without this defined the cdefs.h file in newlib
produces incorrect macro definitions for at the weak_reference macro.


> Alternately, you might put it in microblaze-s.c, wrapped with
> #ifdef OBJECT_FORMAT_ELF/#endif.
>

Ok. This should fix it for microblaze-elf also.

Thanks.

--joel

>
> --
> Michael Eager
>

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 2:28 PM, Joel Sherrill wrote:

Hi

We are in the process of porting RTEMS to the Microblaze and gcc does
not have __ELF__ as a predefine. In looking around at where to add it,
it looks like there are multiple ways to do it. We see variations on
the following patterns:

+ dbxelf.h
+ OS specific header in config/
+ Arch/OS specific header

Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.

A suggestion on where to add the builtin_predefine is appreciated.


There are very few defines for __ELF__ in the GCC target files.

Why don't you put this in rtems.h?

Alternately, you might put it in microblaze-s.c, wrapped with
#ifdef OBJECT_FORMAT_ELF/#endif.

--
Michael Eager

[PATCH] RISC-V: Enable overlap-by-pieces via tune param

[Christoph Muellner via Gcc-patches]

This patch adds the field overlap_op_by_pieces to the struct
riscv_tune_param, which allows to enable the overlap_op_by_pieces
feature of the by-pieces infrastructure.

gcc/ChangeLog:

* config/riscv/riscv.c (struct riscv_tune_param): New field.
(riscv_overlap_op_by_pieces): New function.
(TARGET_OVERLAP_OP_BY_PIECES_P): Connect to
riscv_overlap_op_by_pieces.

Signed-off-by: Christoph Muellner 
---
 gcc/config/riscv/riscv.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 576960bb37c..824e930ef05 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -220,6 +220,7 @@ struct riscv_tune_param
   unsigned short branch_cost;
   unsigned short memory_cost;
   bool slow_unaligned_access;
+  bool overlap_op_by_pieces;
 };
 
 /* Information about one micro-arch we know about.  */
@@ -285,6 +286,7 @@ static const struct riscv_tune_param rocket_tune_info = {
   3,   /* branch_cost */
   5,   /* memory_cost */
   true,/* 
slow_unaligned_access */
+  false,   /* overlap_op_by_pieces */
 };
 
 /* Costs to use when optimizing for Sifive 7 Series.  */
@@ -298,6 +300,7 @@ static const struct riscv_tune_param sifive_7_tune_info = {
   4,   /* branch_cost */
   3,   /* memory_cost */
   true,/* 
slow_unaligned_access */
+  false,   /* overlap_op_by_pieces */
 };
 
 /* Costs to use when optimizing for T-HEAD c906.  */
@@ -311,6 +314,7 @@ static const struct riscv_tune_param thead_c906_tune_info = 
{
   3,/* branch_cost */
   5,/* memory_cost */
   false,/* slow_unaligned_access */
+  false,   /* overlap_op_by_pieces */
 };
 
 /* Costs to use when optimizing for size.  */
@@ -324,6 +328,7 @@ static const struct riscv_tune_param 
optimize_size_tune_info = {
   1,   /* branch_cost */
   2,   /* memory_cost */
   false,   /* slow_unaligned_access */
+  false,   /* overlap_op_by_pieces */
 };
 
 static tree riscv_handle_fndecl_attribute (tree *, tree, tree, int, bool *);
@@ -5201,6 +5206,12 @@ riscv_slow_unaligned_access (machine_mode, unsigned int)
   return riscv_slow_unaligned_access_p;
 }
 
+static bool
+riscv_overlap_op_by_pieces (void)
+{
+  return tune_param->overlap_op_by_pieces;
+}
+
 /* Implement TARGET_CAN_CHANGE_MODE_CLASS.  */
 
 static bool
@@ -5525,6 +5536,9 @@ riscv_asan_shadow_offset (void)
 #undef TARGET_SLOW_UNALIGNED_ACCESS
 #define TARGET_SLOW_UNALIGNED_ACCESS riscv_slow_unaligned_access
 
+#undef TARGET_OVERLAP_OP_BY_PIECES_P
+#define TARGET_OVERLAP_OP_BY_PIECES_P riscv_overlap_op_by_pieces
+
 #undef TARGET_SECONDARY_MEMORY_NEEDED
 #define TARGET_SECONDARY_MEMORY_NEEDED riscv_secondary_memory_needed
 
-- 
2.31.1

[Bug analyzer/101547] [12 Regression] ICE: Segmentation fault (in c_tree_printer)

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from David Malcolm  ---
Thanks for filing this; confirmed.

Should be fixed by the above patch.

[committed] analyzer: bulletproof -Wanalyzer-file-leak [PR101547]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-2460-g893b12cc12877aca1c9df6272123b26eddf12722.

gcc/analyzer/ChangeLog:
PR analyzer/101547
* sm-file.cc (file_leak::emit): Handle m_arg being NULL.
(file_leak::describe_final_event): Handle ev.m_expr being NULL.

gcc/testsuite/ChangeLog:
PR analyzer/101547
* gcc.dg/analyzer/pr101547.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/sm-file.cc  | 27 ++--
 gcc/testsuite/gcc.dg/analyzer/pr101547.c | 11 ++
 2 files changed, 32 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr101547.c

diff --git a/gcc/analyzer/sm-file.cc b/gcc/analyzer/sm-file.cc
index b40a9a1edb9..6a17019448e 100644
--- a/gcc/analyzer/sm-file.cc
+++ b/gcc/analyzer/sm-file.cc
@@ -193,9 +193,13 @@ public:
 /* CWE-775: "Missing Release of File Descriptor or Handle after
Effective Lifetime". */
 m.add_cwe (775);
-return warning_meta (rich_loc, m, OPT_Wanalyzer_file_leak,
-"leak of FILE %qE",
-m_arg);
+if (m_arg)
+  return warning_meta (rich_loc, m, OPT_Wanalyzer_file_leak,
+  "leak of FILE %qE",
+  m_arg);
+else
+  return warning_meta (rich_loc, m, OPT_Wanalyzer_file_leak,
+  "leak of FILE");
   }
 
   label_text describe_state_change (const evdesc::state_change )
@@ -212,10 +216,21 @@ public:
   label_text describe_final_event (const evdesc::final_event ) FINAL 
OVERRIDE
   {
 if (m_fopen_event.known_p ())
-  return ev.formatted_print ("%qE leaks here; was opened at %@",
-ev.m_expr, _fopen_event);
+  {
+   if (ev.m_expr)
+ return ev.formatted_print ("%qE leaks here; was opened at %@",
+ev.m_expr, _fopen_event);
+   else
+ return ev.formatted_print ("leaks here; was opened at %@",
+_fopen_event);
+  }
 else
-  return ev.formatted_print ("%qE leaks here", ev.m_expr);
+  {
+   if (ev.m_expr)
+ return ev.formatted_print ("%qE leaks here", ev.m_expr);
+   else
+ return ev.formatted_print ("leaks here");
+  }
   }
 
 private:
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr101547.c 
b/gcc/testsuite/gcc.dg/analyzer/pr101547.c
new file mode 100644
index 000..8791cffa2b6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr101547.c
@@ -0,0 +1,11 @@
+char *
+fopen (const char *restrict, const char *restrict);
+
+void
+k2 (void)
+{
+  char *setfiles[1];
+  int i;
+
+  setfiles[i] = fopen ("", ""); /* { dg-warning "use of uninitialized value 
'i'" } */
+} /* { dg-warning "leak of FILE" } */
-- 
2.26.3

[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above patch.

[committed] analyzer: fix ICE in binding_cluster::purge_state_involving [PR101522]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-2459-g87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa.

gcc/analyzer/ChangeLog:
PR analyzer/101522
* store.cc (binding_cluster::purge_state_involving): Don't change
m_map whilst iterating through it.

gcc/testsuite/ChangeLog:
PR analyzer/101522
* g++.dg/analyzer/pr101522.C: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/store.cc| 14 +++
 gcc/testsuite/g++.dg/analyzer/pr101522.C | 31 
 2 files changed, 40 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/analyzer/pr101522.C

diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index 0042a207ba6..8ee414da5c8 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1323,6 +1323,7 @@ binding_cluster::purge_state_involving (const svalue 
*sval,
region_model_manager *sval_mgr)
 {
   auto_vec to_remove;
+  auto_vec > to_make_unknown;
   for (auto iter : m_map)
 {
   const binding_key *iter_key = iter.first;
@@ -1335,17 +1336,20 @@ binding_cluster::purge_state_involving (const svalue 
*sval,
}
   const svalue *iter_sval = iter.second;
   if (iter_sval->involves_p (sval))
-   {
- const svalue *new_sval
-   = sval_mgr->get_or_create_unknown_svalue (iter_sval->get_type ());
- m_map.put (iter_key, new_sval);
-   }
+   to_make_unknown.safe_push (std::make_pair(iter_key,
+ iter_sval->get_type ()));
 }
   for (auto iter : to_remove)
 {
   m_map.remove (iter);
   m_touched = true;
 }
+  for (auto iter : to_make_unknown)
+{
+  const svalue *new_sval
+   = sval_mgr->get_or_create_unknown_svalue (iter.second);
+  m_map.put (iter.first, new_sval);
+}
 }
 
 /* Get any SVAL bound to REG within this cluster via kind KIND,
diff --git a/gcc/testsuite/g++.dg/analyzer/pr101522.C 
b/gcc/testsuite/g++.dg/analyzer/pr101522.C
new file mode 100644
index 000..634a2ac30cd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/analyzer/pr101522.C
@@ -0,0 +1,31 @@
+// { dg-do compile { target c++11 } }
+
+double
+sqrt ();
+
+namespace std {
+  class gamma_distribution {
+  public:
+gamma_distribution () : _M_param () {}
+
+  private:
+struct param_type {
+  param_type () : _M_beta () { _M_a2 = 1 / ::sqrt (); }
+  double _M_beta, _M_a2;
+};
+param_type _M_param;
+int _M_saved_available, _M_saved = 0, _M_param0 = 0;
+  };
+
+  struct fisher_f_distribution {
+gamma_distribution _M_gd_x, _M_gd_y;
+  };
+}
+
+int
+main ()
+{
+  std::fisher_f_distribution d;
+
+  return 0;
+}
-- 
2.26.3

[Bug analyzer/101547] [12 Regression] ICE: Segmentation fault (in c_tree_printer)

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:893b12cc12877aca1c9df6272123b26eddf12722

commit r12-2460-g893b12cc12877aca1c9df6272123b26eddf12722
Author: David Malcolm 
Date:   Wed Jul 21 19:19:31 2021 -0400

analyzer: bulletproof -Wanalyzer-file-leak [PR101547]

gcc/analyzer/ChangeLog:
PR analyzer/101547
* sm-file.cc (file_leak::emit): Handle m_arg being NULL.
(file_leak::describe_final_event): Handle ev.m_expr being NULL.

gcc/testsuite/ChangeLog:
PR analyzer/101547
* gcc.dg/analyzer/pr101547.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa

commit r12-2459-g87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa
Author: David Malcolm 
Date:   Wed Jul 21 19:16:08 2021 -0400

analyzer: fix ICE in binding_cluster::purge_state_involving [PR101522]

gcc/analyzer/ChangeLog:
PR analyzer/101522
* store.cc (binding_cluster::purge_state_involving): Don't change
m_map whilst iterating through it.

gcc/testsuite/ChangeLog:
PR analyzer/101522
* g++.dg/analyzer/pr101522.C: New test.

Signed-off-by: David Malcolm 

Re: Using unsafe blocks in let expressions

[Mark Wielaard]

On Wed, Jul 21, 2021 at 11:09:38PM +0200, Mark Wielaard wrote:
> +  Location locus;
> +  if (!pratt_parse)
> +{
> +  Location locus = lexer.peek_token ()->get_locus ();

Oops, shadowed locus.  Fixed patch attached, and also at
https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=let-unsafe


>From a7329b7fc0190920a9cf8bec77e34f2866b8af94 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Wed, 21 Jul 2021 22:41:04 +0200
Subject: [PATCH] unsafe blocks can be used in expressions

To use an unsafe block expression handle it in null_denotation for the
pratt parser. Adjust parse_unsafe_block_expr to take a pratt_parse
bool that defaults to false.
---
 gcc/rust/parse/rust-parse-impl.h | 15 ---
 gcc/rust/parse/rust-parse.h  |  5 +++--
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/rust/parse/rust-parse-impl.h b/gcc/rust/parse/rust-parse-impl.h
index eedc76db43e..bdf1e09a029 100644
--- a/gcc/rust/parse/rust-parse-impl.h
+++ b/gcc/rust/parse/rust-parse-impl.h
@@ -8704,10 +8704,17 @@ Parser::parse_async_block_expr (AST::AttrVec outer_attrs)
 // Parses an unsafe block expression.
 template 
 std::unique_ptr
-Parser::parse_unsafe_block_expr (AST::AttrVec outer_attrs)
+Parser::parse_unsafe_block_expr (AST::AttrVec outer_attrs,
+		 bool pratt_parse)
 {
-  Location locus = lexer.peek_token ()->get_locus ();
-  skip_token (UNSAFE);
+  Location locus;
+  if (!pratt_parse)
+{
+  locus = lexer.peek_token ()->get_locus ();
+  skip_token (UNSAFE);
+}
+  else
+locus = lexer.peek_token ()->get_locus () - 1;
 
   // parse block expression (required)
   std::unique_ptr block_expr = parse_block_expr ();
@@ -12823,6 +12830,8 @@ Parser::null_denotation (const_TokenPtr tok,
 case LEFT_SQUARE:
   // array definition expr (not indexing)
   return parse_array_expr (std::move (outer_attrs), true);
+case UNSAFE:
+  return parse_unsafe_block_expr (std::move (outer_attrs), true);
 default:
   if (!restrictions.expr_can_be_null)
 	add_error (Error (tok->get_locus (),
diff --git a/gcc/rust/parse/rust-parse.h b/gcc/rust/parse/rust-parse.h
index 1cd85eae8c2..1c7bd781b3f 100644
--- a/gcc/rust/parse/rust-parse.h
+++ b/gcc/rust/parse/rust-parse.h
@@ -504,8 +504,6 @@ private:
   AST::LoopLabel parse_loop_label ();
   std::unique_ptr
   parse_async_block_expr (AST::AttrVec outer_attrs = AST::AttrVec ());
-  std::unique_ptr
-  parse_unsafe_block_expr (AST::AttrVec outer_attrs = AST::AttrVec ());
   std::unique_ptr parse_grouped_expr (AST::AttrVec outer_attrs
 			= AST::AttrVec ());
   std::unique_ptr parse_closure_expr (AST::AttrVec outer_attrs
@@ -522,6 +520,9 @@ private:
   std::unique_ptr
   parse_continue_expr (AST::AttrVec outer_attrs = AST::AttrVec (),
 		   bool pratt_parse = false);
+  std::unique_ptr
+  parse_unsafe_block_expr (AST::AttrVec outer_attrs = AST::AttrVec (),
+			   bool pratt_parse = false);
   std::unique_ptr parse_array_expr (AST::AttrVec outer_attrs
 		= AST::AttrVec (),
 		bool pratt_parse = false);
-- 
2.32.0

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH, rs6000] fix failure test cases caused by disabling mode promotion for pseudos [PR100952]

[Segher Boessenkool]

Hi!

On Tue, Jul 06, 2021 at 11:11:05AM +0800, HAO CHEN GUI wrote:
>    The patch changed matching conditions in pr81384.c and pr56605.c. 
> The original conditions failed to match due to mode promotion disabled.

>   PR target/100952
>   * gcc/testsuite/gcc.target/powerpc/pr56605.c: Change matching
>   conditions.
>   * gcc/testsuite/gcc.target/powerpc/pr81348.c: Likewise.
> 

> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c 
> b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> index 29efd815adc..2b7ddbd7410 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> @@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
>  ia[i] = (int) sb[i];
>  }
>  
> -/* { dg-final { scan-rtl-dump-times "\\\(compare:CC 
> \\\((?:and|zero_extend):DI \\\(reg:\[SD\]I" 1 "combine" } } */
> +/* { dg-final { scan-rtl-dump-times "\\\(compare:CC 
> \\\((?:and|zero_extend):SI \\\(subreg:SI \\\(reg:\[SD\]I" 1 "combine" } } */

So, this testcase only runs on 64-bit machines (even only on lp64
configurations).  But do we now always get a subreg?  And, can that
change again some time in the future?

Writing it as
/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):SI 
\(subreg:SI \(reg:[SD]I} 1 "combine" } } */
is easier to read btw.

If you get a subreg:SI of a reg:SI here, something is wrong.  And you
cannot have a zero_extend:SI of anything :SI either.

So what the original matched were
  (compare:CC (and:DI (reg:DI
and
  (compare:CC (zero_extend:DI (reg:SI
and now you want to allow a subreg:SI in that last one as well (and you
do not really care what it is a subreg of, you don't check what offset
anyway), so maybe just
/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI 
\((?:sub)?reg:[SD]I} 1 "combine" } } */
will do what you want?

> --- a/gcc/testsuite/gcc.target/powerpc/pr81348.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr81348.c
> @@ -19,5 +19,5 @@ void d(void)
>  ***c = e;
>  }
>  
> -/* { dg-final { scan-assembler {\mlxsihzx\M}  } } */
> -/* { dg-final { scan-assembler {\mvextsh2d\M} } } */
> +/* { dg-final { scan-assembler {\mlha\M}  } } */
> +/* { dg-final { scan-assembler {\mmtvsrwa\M} } } */

(This test should not test for powerpc64*-*-* but powerpc*-*-* btw,
and that means it can just be left out, so just
/* { dg-do compile { target lp64 } } */
and nothing more).

Okay for trunk with those changes (the RE and lp64).  Thanks!
(Test if it works of course; I did not :-) )


Segher

Re: [PATCH, rs6000] fix execution failure of parity_1.f90 on P10 [PR100952]

[Segher Boessenkool]

Sorry for the delay!

On Tue, Jul 13, 2021 at 09:38:33AM +0800, HAO CHEN GUI wrote:
>   PR target/100952
>   * config/rs6000/rs6000.md (cstore4): Fix wrong fall through.

> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 3f59b544f6a..d7c13d4e79d 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -11623,7 +11623,10 @@ (define_expand "cstore4"
>  {
>/* Everything is best done with setbc[r] if available.  */
>if (TARGET_POWER10 && TARGET_ISEL)
> -rs6000_emit_int_cmove (operands[0], operands[1], const1_rtx, const0_rtx);
> +{
> +  rs6000_emit_int_cmove (operands[0], operands[1], const1_rtx, 
> const0_rtx);
> +  DONE;
> +}
>  
>/* Expanding EQ and NE directly to some machine instructions does not help
>   but does hurt combine.  So don't.  */

Perfect.  Okay for trunk and backports (but do not touch GCC 11 right
now without RM approval, see
).  Thanks!


Segher

OpenACC 'nohost' clause

[Thomas Schwinge]

Hi!

On 2018-10-02T07:11:43-0700, Cesar Philippidis  wrote:
> Attached is a patch that introduces support for the acc routine nohost
> clause. Basically, if an acc routine function is marked as nohost, then
> the compiler does not generate code for the host.

This is in particular useful in combination with the OpenACC 'bind'
clause and 'device_type' clause, which we don't have yet, so:

> It's kind of strange
> to test for. Basically, we had to use acc_on_device at -O2 so that the
> host references to the dead function get optimized away.

Additionally I figured out something using weak symbols.

> I believe that the nohost clause was added for acc routines to allow
> offloaded acc code to call vendor libraries, such as cuBLAS, which are
> only available for specific accelerators. I haven't seen it used much in
> practice though.

ACK.

> Is this OK for trunk?

After fixing the crucial issue to discard 'nohost' functions only for the
host but not also for all offload targets ;-) and considerably
improving/fixing the Fortran front end changes and boosting C/C++/Fortran
test coverage generally, I've now pushed "OpenACC 'nohost' clause" to
master branch in commit a61f6afbee370785cf091fe46e2e022748528307, see
attached.


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 a61f6afbee370785cf091fe46e2e022748528307 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 21 Jul 2021 18:30:00 +0200
Subject: [PATCH] OpenACC 'nohost' clause

Do not "compile a version of this procedure for the host".

	gcc/
	* tree-core.h (omp_clause_code): Add 'OMP_CLAUSE_NOHOST'.
	* tree.c (omp_clause_num_ops, omp_clause_code_name, walk_tree_1):
	Handle it.
	* tree-pretty-print.c (dump_omp_clause): Likewise.
	* omp-general.c (oacc_verify_routine_clauses): Likewise.
	* gimplify.c (gimplify_scan_omp_clauses)
	(gimplify_adjust_omp_clauses): Likewise.
	* tree-nested.c (convert_nonlocal_omp_clauses)
	(convert_local_omp_clauses): Likewise.
	* omp-low.c (scan_sharing_clauses): Likewise.
	* omp-offload.c (execute_oacc_device_lower): Update.
	gcc/c-family/
	* c-pragma.h (pragma_omp_clause): Add 'PRAGMA_OACC_CLAUSE_NOHOST'.
	gcc/c/
	* c-parser.c (c_parser_omp_clause_name): Handle 'nohost'.
	(c_parser_oacc_all_clauses): Handle 'PRAGMA_OACC_CLAUSE_NOHOST'.
	(OACC_ROUTINE_CLAUSE_MASK): Add 'PRAGMA_OACC_CLAUSE_NOHOST'.
	* c-typeck.c (c_finish_omp_clauses): Handle 'OMP_CLAUSE_NOHOST'.
	gcc/cp/
	* parser.c (cp_parser_omp_clause_name): Handle 'nohost'.
	(cp_parser_oacc_all_clauses): Handle 'PRAGMA_OACC_CLAUSE_NOHOST'.
	(OACC_ROUTINE_CLAUSE_MASK): Add 'PRAGMA_OACC_CLAUSE_NOHOST'.
	* pt.c (tsubst_omp_clauses): Handle 'OMP_CLAUSE_NOHOST'.
	* semantics.c (finish_omp_clauses): Likewise.
	gcc/fortran/
	* dump-parse-tree.c (show_attr): Update.
	* gfortran.h (symbol_attribute): Add 'oacc_routine_nohost' member.
	(gfc_omp_clauses): Add 'nohost' member.
	* module.c (ab_attribute): Add 'AB_OACC_ROUTINE_NOHOST'.
	(attr_bits, mio_symbol_attribute): Update.
	* openmp.c (omp_mask2): Add 'OMP_CLAUSE_NOHOST'.
	(gfc_match_omp_clauses): Handle 'OMP_CLAUSE_NOHOST'.
	(OACC_ROUTINE_CLAUSES): Add 'OMP_CLAUSE_NOHOST'.
	(gfc_match_oacc_routine): Update.
	* trans-decl.c (add_attributes_to_decl): Update.
	* trans-openmp.c (gfc_trans_omp_clauses): Likewise.
	gcc/testsuite/
	* c-c++-common/goacc/classify-routine-nohost.c: New file.
	* c-c++-common/goacc/classify-routine.c: Update.
	* c-c++-common/goacc/routine-2.c: Likewise.
	* c-c++-common/goacc/routine-nohost-1.c: New file.
	* c-c++-common/goacc/routine-nohost-2.c: Likewise.
	* g++.dg/goacc/template.C: Update.
	* gfortran.dg/goacc/classify-routine-nohost.f95: New file.
	* gfortran.dg/goacc/classify-routine.f95: Update.
	* gfortran.dg/goacc/pure-elemental-procedures-2.f90: Likewise.
	* gfortran.dg/goacc/routine-6.f90: Likewise.
	* gfortran.dg/goacc/routine-intrinsic-2.f: Likewise.
	* gfortran.dg/goacc/routine-module-1.f90: Likewise.
	* gfortran.dg/goacc/routine-module-2.f90: Likewise.
	* gfortran.dg/goacc/routine-module-3.f90: Likewise.
	* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.
	* gfortran.dg/goacc/routine-multiple-directives-1.f90: Likewise.
	* gfortran.dg/goacc/routine-multiple-directives-2.f90: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/routine-nohost-1.c: New
	file.
	* testsuite/libgomp.oacc-c-c++-common/routine-nohost-2.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/routine-nohost-2_2.c:
	Likewise.
	* testsuite/libgomp.oacc-fortran/routine-nohost-1.f90: Likewise.

Co-Authored-By: Joseph Myers 
Co-Authored-By: Cesar Philippidis 
---
 gcc/c-family/c-pragma.h   |   1 +
 gcc/c/c-parser.c  |  10 +-
 gcc/c/c-typeck.c  |   1 +
 gcc/cp/parser.c   |  11 +-
 

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

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

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index d148de3e3b5..d7668f6a928 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -2350,6 +2350,34 @@ match_forall_iterator (gfc_forall_iterator **result)
>gfc_forall_iterator *iter;
>locus where;
>match m;
> +  gfc_typespec ts;
> +  bool seen_ts;
> +
> +  /* In Fortran 2018, one can do "forall (integer :: i = 1:20)".

s/2018/2008

> + Try to match an optional "type-spec ::"  */
> +  seen_ts = false;
> +  gfc_clear_ts ();
> +  m = gfc_match_type_spec ();
> +  if (m == MATCH_YES)
> +{
> +  seen_ts = (gfc_match (" ::") == MATCH_YES);
> +
> +  if (seen_ts)
> + {
> +   if (!gfc_notify_std (GFC_STD_F2018, "FORALL includes a "

s/2018/2008

> +"type specification at %C"))
> + return MATCH_ERROR;
> +
> +   if (ts.type != BT_INTEGER)
> + {
> +   gfc_error ("Type-spec at %L shall be INTEGER",
> +  _current_locus);
> +   return MATCH_ERROR;
> + }
> + }
> +}
> +  else if (m == MATCH_ERROR)
> +return m;
>  
>where = gfc_current_locus;
>iter = XCNEW (gfc_forall_iterator);
> @@ -2358,6 +2386,9 @@ match_forall_iterator (gfc_forall_iterator **result)
>if (m != MATCH_YES)
>  goto cleanup;
>  
> +  if (seen_ts)
> +iter->var->ts = ts;
> +
>if (gfc_match_char ('=') != MATCH_YES
>|| iter->var->expr_type != EXPR_VARIABLE)
>  {

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

[Thomas Schwinge]

Hi!

Half a decade later...  ;-)

On 2015-11-05T18:10:49-0800, Cesar Philippidis  wrote:
> I've applied this patch to trunk.
> [...]

> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/goacc/template.C
> @@ -0,0 +1,141 @@
> +[...]
> +#pragma acc atomic capture
> +c = b++;
> +
> +#pragma atomic update
> +c++;
> +
> +#pragma acc atomic read
> +b = a;
> +
> +#pragma acc atomic write
> +b = a;
> +[...]

Pushed "[OpenACC] Fix '#pragma atomic update' typo in
'g++.dg/goacc/template.C'" to master branch in commit
6099b9cc8ce70d2ec7f2fc9f71da95fbb66d335f, see attached.


(Did I suggest to enable '-Wunknown-pragmas' for '-fopenacc'/'-fopenmp*',
or if that's not permissible, then at least do it in the relevant
testsuite '*.exp' files?)


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 6099b9cc8ce70d2ec7f2fc9f71da95fbb66d335f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 21 Jul 2021 08:20:18 +0200
Subject: [PATCH] [OpenACC] Fix '#pragma atomic update' typo in
 'g++.dg/goacc/template.C'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[...]/g++.dg/goacc/template.C:58: warning: ignoring ‘#pragma atomic update’ [-Wunknown-pragmas]
   58 | #pragma atomic update
  |

Small fix-up for r229832 (commit 7a5e4956cc026cba54159d5c764486ac4151db85)
"[openacc] tile, independent, default, private and firstprivate support in
c/++".

	gcc/testsuite/
	* g++.dg/goacc/template.C: Fix '#pragma atomic update' typo.
---
 gcc/testsuite/g++.dg/goacc/template.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/goacc/template.C b/gcc/testsuite/g++.dg/goacc/template.C
index 8bcd2a1ce43..51a3f54e43f 100644
--- a/gcc/testsuite/g++.dg/goacc/template.C
+++ b/gcc/testsuite/g++.dg/goacc/template.C
@@ -55,7 +55,7 @@ oacc_parallel_copy (T a)
 #pragma acc atomic capture
   c = b++;
 
-#pragma atomic update
+#pragma acc atomic update
   c++;
 
 #pragma acc atomic read
-- 
2.30.2

[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
The original test case also appears to now work.

[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #2)
> Simplification :
> 
> 
> $ cat z1.f90
> program p
>type t
>   integer :: n = 1
>   integer, allocatable :: u(:)
>   real :: v(3, 3)
>end type
>type(t) :: z
>real :: x(3) = [1.0, 2.0, 3.0]
>allocate (z%u(3))
>z%u = [3, 1, 2]
>forall (j = 1:3)
>   z%v(j, z%n) = x(z%u(j))
>end forall
> end
> 
> 

This seems to work now.

[Bug other/101568] [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug other/101568] New: [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338

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

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

Bug ID: 101568
   Summary: [12 regression] g++.dg/ipa/pr82352.C fails after
r12-2338
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f0500db3692276f60e0562c17c87a0cb03e34398, r12-2338
make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/ipa/pr82352.C"
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++2a (test for excess errors)
# of unexpected failures4

Same failure for all 4:

FAIL: g++.dg/ipa/pr82352.C  -std=gnu++17 (test for excess errors)
Excess errors:
cc1plus: warning: writing 16 bytes into a region of size 0
[-Wstringop-overflow=]

Note: This still occurs with r12-2456.

[committed] analyzer: fix issues with phi handling

[David Malcolm via Gcc-patches]

The analyzer's state purging code was overzealously purging state
for ssa names that might be used within phi nodes, leading to
false positives from -Wanalyzer-use-of-uninitialized-value.

This patch updates phi handling in the analyzer to fix these issues.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as e0a7a6752dad7848eb4b29b826a551c0992256ec.

gcc/analyzer/ChangeLog:
* region-model.cc (region_model::handle_phi): Add "old_state"
param and use it.
(region_model::update_for_phis): Update so that all of the phi
stmts are effectively handled simultaneously, rather than in
order.
* region-model.h (region_model::handle_phi): Add "old_state"
param.
* state-purge.cc (self_referential_phi_p): Replace with...
(name_used_by_phis_p): ...this new function.
(state_purge_per_ssa_name::process_point): Update to use the
above, so that all phi stmts at a basic block are effectively
considered simultaneously, and only consider the phi arguments for
the pertinent in-edge.
* supergraph.cc (cfg_superedge::get_phi_arg_idx): New.
(cfg_superedge::get_phi_arg): Use the above.
* supergraph.h (cfg_superedge::get_phi_arg_idx): New decl.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/explode-2.c: Remove xfail.
* gcc.dg/analyzer/explode-2a.c: Remove expected leak warning on
while stmt.
* gcc.dg/analyzer/phi-2.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model.cc   | 18 +++---
 gcc/analyzer/region-model.h|  1 +
 gcc/analyzer/state-purge.cc| 42 --
 gcc/analyzer/supergraph.cc | 11 +-
 gcc/analyzer/supergraph.h  |  1 +
 gcc/testsuite/gcc.dg/analyzer/explode-2.c  |  2 +-
 gcc/testsuite/gcc.dg/analyzer/explode-2a.c |  2 +-
 gcc/testsuite/gcc.dg/analyzer/phi-2.c  | 27 ++
 8 files changed, 78 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/phi-2.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 6d02c60449c..c029759cb9b 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1553,11 +1553,14 @@ region_model::on_longjmp (const gcall *longjmp_call, 
const gcall *setjmp_call,
 
 /* Update this region_model for a phi stmt of the form
  LHS = PHI <...RHS...>.
-   where RHS is for the appropriate edge.  */
+   where RHS is for the appropriate edge.
+   Get state from OLD_STATE so that all of the phi stmts for a basic block
+   are effectively handled simultaneously.  */
 
 void
 region_model::handle_phi (const gphi *phi,
  tree lhs, tree rhs,
+ const region_model _state,
  region_model_context *ctxt)
 {
   /* For now, don't bother tracking the .MEM SSA names.  */
@@ -1566,9 +1569,10 @@ region_model::handle_phi (const gphi *phi,
   if (VAR_DECL_IS_VIRTUAL_OPERAND (var))
return;
 
-  const svalue *rhs_sval = get_rvalue (rhs, ctxt);
+  const svalue *src_sval = old_state.get_rvalue (rhs, ctxt);
+  const region *dst_reg = old_state.get_lvalue (lhs, ctxt);
 
-  set_value (get_lvalue (lhs, ctxt), rhs_sval, ctxt);
+  set_value (dst_reg, src_sval, ctxt);
 
   if (ctxt)
 ctxt->on_phi (phi, rhs);
@@ -3036,6 +3040,10 @@ region_model::update_for_phis (const supernode *snode,
 {
   gcc_assert (last_cfg_superedge);
 
+  /* Copy this state and pass it to handle_phi so that all of the phi stmts
+ are effectively handled simultaneously.  */
+  const region_model old_state (*this);
+
   for (gphi_iterator gpi = const_cast(snode)->start_phis ();
!gsi_end_p (gpi); gsi_next ())
 {
@@ -3044,8 +3052,8 @@ region_model::update_for_phis (const supernode *snode,
   tree src = last_cfg_superedge->get_phi_arg (phi);
   tree lhs = gimple_phi_result (phi);
 
-  /* Update next_state based on phi.  */
-  handle_phi (phi, lhs, src, ctxt);
+  /* Update next_state based on phi and old_state.  */
+  handle_phi (phi, lhs, src, old_state, ctxt);
 }
 }
 
diff --git a/gcc/analyzer/region-model.h b/gcc/analyzer/region-model.h
index 734ec601237..cc39929db26 100644
--- a/gcc/analyzer/region-model.h
+++ b/gcc/analyzer/region-model.h
@@ -582,6 +582,7 @@ class region_model
region_model_context *ctxt);
 
   void handle_phi (const gphi *phi, tree lhs, tree rhs,
+  const region_model _state,
   region_model_context *ctxt);
 
   bool maybe_update_for_edge (const superedge ,
diff --git a/gcc/analyzer/state-purge.cc b/gcc/analyzer/state-purge.cc
index 3c3b77500a6..bfa48a9ef3f 100644
--- a/gcc/analyzer/state-purge.cc
+++ b/gcc/analyzer/state-purge.cc
@@ -288,17 +288,23 @@ state_purge_per_ssa_name::add_to_worklist (const 
function_point ,
 }
 }
 
-/* Does this phi depend on itself?
-   e.g. 

[committed] analyzer: fixes to -fdump-analyzer-state-purge for phi nodes

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 6bbad96cd44774bc199b256dbf4260b25b87c7db.

gcc/analyzer/ChangeLog:
* state-purge.cc (state_purge_annotator::add_node_annotations):
Rather than erroneously always using the NULL in-edge, determine
each relevant in-edge, and print the appropriate data for each
in-edge.  Use print_needed to print the data as comma-separated
lists of SSA names.
(print_vec_of_names): Add "within_table" param and use it.
(state_purge_annotator::add_stmt_annotations): Factor out
collation and printing code into...
(state_purge_annotator::print_needed): ...this new function.
* state-purge.h (state_purge_annotator::print_needed): New decl.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/state-purge.cc | 66 ++---
 gcc/analyzer/state-purge.h  |  4 +++
 2 files changed, 43 insertions(+), 27 deletions(-)

diff --git a/gcc/analyzer/state-purge.cc b/gcc/analyzer/state-purge.cc
index e82ea87e735..3c3b77500a6 100644
--- a/gcc/analyzer/state-purge.cc
+++ b/gcc/analyzer/state-purge.cc
@@ -477,23 +477,20 @@ state_purge_annotator::add_node_annotations (graphviz_out 
*gv,
  "lightblue");
pp_write_text_to_stream (pp);
 
-   // FIXME: passing in a NULL in-edge means we get no hits
-   function_point before_supernode
- (function_point::before_supernode (, NULL));
-
-   for (state_purge_map::iterator iter = m_map->begin ();
-   iter != m_map->end ();
-   ++iter)
+   /* Different in-edges mean different names need purging.
+  Determine which points to dump.  */
+   auto_vec points;
+   if (n.entry_p ())
+ points.safe_push (function_point::before_supernode (, NULL));
+   else
+ for (auto inedge : n.m_preds)
+   points.safe_push (function_point::before_supernode (, inedge));
+
+   for (auto & point : points)
  {
-   tree name = (*iter).first;
-   state_purge_per_ssa_name *per_name_data = (*iter).second;
-   if (per_name_data->get_function () == n.m_fun)
-{
-  if (per_name_data->needed_at_point_p (before_supernode))
-pp_printf (pp, "%qE needed here", name);
-  else
-pp_printf (pp, "%qE not needed here", name);
-}
+   point.print (pp, format (true));
+   pp_newline (pp);
+   print_needed (gv, point, false);
pp_newline (pp);
  }
 
@@ -502,19 +499,20 @@ state_purge_annotator::add_node_annotations (graphviz_out 
*gv,
return false;
 }
 
-/* Print V to GV as a comma-separated list in braces within a ,
-   titling it with TITLE.
+/* Print V to GV as a comma-separated list in braces, titling it with TITLE.
+   If WITHIN_TABLE is true, print it within a 
 
-   Subroutine of state_purge_annotator::add_stmt_annotations.  */
+   Subroutine of state_purge_annotator::print_needed.  */
 
 static void
 print_vec_of_names (graphviz_out *gv, const char *title,
-   const auto_vec )
+   const auto_vec , bool within_table)
 {
   pretty_printer *pp = gv->get_pp ();
   tree name;
   unsigned i;
-  gv->begin_trtd ();
+  if (within_table)
+gv->begin_trtd ();
   pp_printf (pp, "%s: {", title);
   FOR_EACH_VEC_ELT (v, i, name)
 {
@@ -523,8 +521,11 @@ print_vec_of_names (graphviz_out *gv, const char *title,
   pp_printf (pp, "%qE", name);
 }
   pp_printf (pp, "}");
-  pp_write_text_as_html_like_dot_to_stream (pp);
-  gv->end_tdtr ();
+  if (within_table)
+{
+  pp_write_text_as_html_like_dot_to_stream (pp);
+  gv->end_tdtr ();
+}
   pp_newline (pp);
 }
 
@@ -556,6 +557,17 @@ state_purge_annotator::add_stmt_annotations (graphviz_out 
*gv,
   function_point before_stmt
 (function_point::before_stmt (supernode, stmt_idx));
 
+  print_needed (gv, before_stmt, true);
+}
+
+/* Get the ssa names needed and not-needed at POINT, and print them to GV.
+   If WITHIN_TABLE is true, print them within  elements.  */
+
+void
+state_purge_annotator::print_needed (graphviz_out *gv,
+const function_point ,
+bool within_table) const
+{
   auto_vec needed;
   auto_vec not_needed;
   for (state_purge_map::iterator iter = m_map->begin ();
@@ -564,17 +576,17 @@ state_purge_annotator::add_stmt_annotations (graphviz_out 
*gv,
 {
   tree name = (*iter).first;
   state_purge_per_ssa_name *per_name_data = (*iter).second;
-  if (per_name_data->get_function () == supernode->m_fun)
+  if (per_name_data->get_function () == point.get_function ())
{
- if (per_name_data->needed_at_point_p (before_stmt))
+ if (per_name_data->needed_at_point_p (point))
needed.safe_push (name);
  else
not_needed.safe_push (name);
}
 }
 
-  print_vec_of_names (gv, "needed here", needed);
-  print_vec_of_names (gv, "not needed here", not_needed);
+  print_vec_of_names (gv, 

Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

Hi

We are in the process of porting RTEMS to the Microblaze and gcc does
not have __ELF__ as a predefine. In looking around at where to add it,
it looks like there are multiple ways to do it. We see variations on
the following patterns:

+ dbxelf.h
+ OS specific header in config/
+ Arch/OS specific header

Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.

A suggestion on where to add the builtin_predefine is appreciated.

Thanks

--joel

[committed] analyzer: show BB index in BEFORE_SUPERNODE's in-edge

[David Malcolm via Gcc-patches]

This is useful for debugging how the analyzer handles phi nodes.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 81703584769707c34533e78c7a2bc229b0e14b2d.

gcc/analyzer/ChangeLog:
* program-point.cc (function_point::print): Show src BB index at
BEFORE_SUPERNODE.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/program-point.cc | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/analyzer/program-point.cc b/gcc/analyzer/program-point.cc
index d8cfc61975e..d73b6211141 100644
--- a/gcc/analyzer/program-point.cc
+++ b/gcc/analyzer/program-point.cc
@@ -119,8 +119,15 @@ function_point::print (pretty_printer *pp, const format 
) const
 case PK_BEFORE_SUPERNODE:
   {
if (m_from_edge)
- pp_printf (pp, "before SN: %i (from SN: %i)",
-m_supernode->m_index, m_from_edge->m_src->m_index);
+ {
+   if (basic_block bb = m_from_edge->m_src->m_bb)
+ pp_printf (pp, "before SN: %i (from SN: %i (bb: %i))",
+m_supernode->m_index, m_from_edge->m_src->m_index,
+bb->index);
+   else
+ pp_printf (pp, "before SN: %i (from SN: %i)",
+m_supernode->m_index, m_from_edge->m_src->m_index);
+ }
else
  pp_printf (pp, "before SN: %i (NULL from-edge)",
 m_supernode->m_index);
-- 
2.26.3

[committed] analyzer: tweak dumping of min_expr/max_expr

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as dcdf6bb24e5f113f2bb9298588105a071bddf50f.

gcc/analyzer/ChangeLog:
* svalue.cc (infix_p): New.
(binop_svalue::dump_to_pp): Use it to print MIN_EXPR and MAX_EXPR
in prefix form, rather than infix.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/svalue.cc | 39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/gcc/analyzer/svalue.cc b/gcc/analyzer/svalue.cc
index 094c7256818..a1e6f50b7d7 100644
--- a/gcc/analyzer/svalue.cc
+++ b/gcc/analyzer/svalue.cc
@@ -1053,6 +1053,21 @@ unaryop_svalue::maybe_fold_bits_within (tree type,
 
 /* class binop_svalue : public svalue.  */
 
+/* Return whether OP be printed as an infix operator.  */
+
+static bool
+infix_p (enum tree_code op)
+{
+  switch (op)
+{
+default:
+  return true;
+case MAX_EXPR:
+case MIN_EXPR:
+  return false;
+}
+}
+
 /* Implementation of svalue::dump_to_pp vfunc for binop_svalue.  */
 
 void
@@ -1060,11 +1075,25 @@ binop_svalue::dump_to_pp (pretty_printer *pp, bool 
simple) const
 {
   if (simple)
 {
-  pp_character (pp, '(');
-  m_arg0->dump_to_pp (pp, simple);
-  pp_string (pp, op_symbol_code (m_op));
-  m_arg1->dump_to_pp (pp, simple);
-  pp_character (pp, ')');
+  if (infix_p (m_op))
+   {
+ /* Print "(A OP B)".  */
+ pp_character (pp, '(');
+ m_arg0->dump_to_pp (pp, simple);
+ pp_string (pp, op_symbol_code (m_op));
+ m_arg1->dump_to_pp (pp, simple);
+ pp_character (pp, ')');
+   }
+  else
+   {
+ /* Print "OP(A, B)".  */
+ pp_string (pp, op_symbol_code (m_op));
+ pp_character (pp, '(');
+ m_arg0->dump_to_pp (pp, simple);
+ pp_string (pp, ", ");
+ m_arg1->dump_to_pp (pp, simple);
+ pp_character (pp, ')');
+   }
 }
   else
 {
-- 
2.26.3

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

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

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Franz Sirl from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > I don't think it is a good idea to add workaround upon workaround to avoid
> > some of the not-so-useful behaviours of -many.  Instead, we should just
> > not use -many?
> 
> As I understand it -many is just one variation of the general problem with
> the sticky flags. If we remove -many from the assembler, there are still
> other sticky flags like -mvsx. Turning of any sticky flag is currently not
> supported by the assembler AFAICS. So for example it's impossible to switch
> from a VSX supporting assembler mode to an assembler mode without VSX via
> the .machine pseudo-op. Or did I misread the the assembler source?

So "sticky" is some internal GAS concept?  This isn't documented in the
manuals.  This means that its behaviour can likely be changed without too
much trouble; that would be quite preferable, it's not such a hot idea to
have to change what GCC does to something ever more complex, if we could
just change GAS instead.

Maybe the assembler can adopt -mno-vsx etc., with the same semantics as
that has in GCC?

[Bug c++/101567] New: Gcc incorrectly allows co_await operator inside catch-block

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 101567
   Summary: Gcc incorrectly allows co_await operator inside
catch-block
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

According to the standard "An await-expression shall appear only in a
potentially-evaluated expression within the compound-statement of a
function-body outside of a handler."
https://timsong-cpp.github.io/cppwp/n4861/expr.await#2

But GCC currently allows co_await operator inside catch-block, which lead to
very weird results:
https://gcc.godbolt.org/z/4deoG7Pnh

Using unsafe blocks in let expressions

[Mark Wielaard]

Hi,

I wanted to use an unsafe block in a let expression, which wasn't
accepted. The attached patch implements this.

I did want to add a testcase, but I couldn't come up with a test that
is correct and passes the type checker. The following works, but is
not correctly typed:

pub fn main ()
{
  let mut num = 2;
  // let r1 =  as *const i32;
  // let r1: *const i32 = 
  let r1 = 
  let r2 = unsafe { *r1 } + unsafe { *r1 };
  let r3 = num;
  num = 4;
  let r4 = num + unsafe { *r1 } * r3;
  let _eightteen = r2 + r3 + r4;
}

In this case r1 is a reference, not a raw pointer, so the code
shouldn't work, but it does. It does correctly add up to 18.

The two ways to make this code type correct don't work. The first
gives:

let_unsafe.rs:4:12: fatal error: Failed to lower expr: [ as *const i32]
4 |   let r1 =  as *const i32;
  |^

The second gives:

let_unsafe.rs:7:21: error: expected reference type got * const i32
7 |   let r2 = unsafe { *r1 } + unsafe { *r1 };
  | ^
let_unsafe.rs:7:21: error: failed to type resolve expression
let_unsafe.rs:7:38: error: expected reference type got * const i32
7 |   let r2 = unsafe { *r1 } + unsafe { *r1 };
  |  ^
let_unsafe.rs:7:38: error: failed to type resolve expression
let_unsafe.rs:7:18: error: cannot apply this operator to types  
and 
7 |   let r2 = unsafe { *r1 } + unsafe { *r1 };
  |  ^~  

Note that the error marker is wrong on the last line. I think that is
because of the way the pratt parser eats the token and then the code
does a locus - 1. Which ends up at the wrong place. I think instead of
a boolean we should pass the current token to get the correct
location.

Cheers,

Mark>From 3e9c4eff383cd1a23a148f5a7d556345b7972e26 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Wed, 21 Jul 2021 22:41:04 +0200
Subject: [PATCH] unsafe blocks can be used in expressions

To use an unsafe block expression handle it in null_denotation for the
pratt parser. Adjust parse_unsafe_block_expr to take a pratt_parse
bool that defaults to false.
---
 gcc/rust/parse/rust-parse-impl.h | 15 ---
 gcc/rust/parse/rust-parse.h  |  5 +++--
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/rust/parse/rust-parse-impl.h b/gcc/rust/parse/rust-parse-impl.h
index eedc76db43e..f75dd206963 100644
--- a/gcc/rust/parse/rust-parse-impl.h
+++ b/gcc/rust/parse/rust-parse-impl.h
@@ -8704,10 +8704,17 @@ Parser::parse_async_block_expr (AST::AttrVec outer_attrs)
 // Parses an unsafe block expression.
 template 
 std::unique_ptr
-Parser::parse_unsafe_block_expr (AST::AttrVec outer_attrs)
+Parser::parse_unsafe_block_expr (AST::AttrVec outer_attrs,
+		 bool pratt_parse)
 {
-  Location locus = lexer.peek_token ()->get_locus ();
-  skip_token (UNSAFE);
+  Location locus;
+  if (!pratt_parse)
+{
+  Location locus = lexer.peek_token ()->get_locus ();
+  skip_token (UNSAFE);
+}
+  else
+locus = lexer.peek_token ()->get_locus () - 1;
 
   // parse block expression (required)
   std::unique_ptr block_expr = parse_block_expr ();
@@ -12823,6 +12830,8 @@ Parser::null_denotation (const_TokenPtr tok,
 case LEFT_SQUARE:
   // array definition expr (not indexing)
   return parse_array_expr (std::move (outer_attrs), true);
+case UNSAFE:
+  return parse_unsafe_block_expr (std::move (outer_attrs), true);
 default:
   if (!restrictions.expr_can_be_null)
 	add_error (Error (tok->get_locus (),
diff --git a/gcc/rust/parse/rust-parse.h b/gcc/rust/parse/rust-parse.h
index 1cd85eae8c2..1c7bd781b3f 100644
--- a/gcc/rust/parse/rust-parse.h
+++ b/gcc/rust/parse/rust-parse.h
@@ -504,8 +504,6 @@ private:
   AST::LoopLabel parse_loop_label ();
   std::unique_ptr
   parse_async_block_expr (AST::AttrVec outer_attrs = AST::AttrVec ());
-  std::unique_ptr
-  parse_unsafe_block_expr (AST::AttrVec outer_attrs = AST::AttrVec ());
   std::unique_ptr parse_grouped_expr (AST::AttrVec outer_attrs
 			= AST::AttrVec ());
   std::unique_ptr parse_closure_expr (AST::AttrVec outer_attrs
@@ -522,6 +520,9 @@ private:
   std::unique_ptr
   parse_continue_expr (AST::AttrVec outer_attrs = AST::AttrVec (),
 		   bool pratt_parse = false);
+  std::unique_ptr
+  parse_unsafe_block_expr (AST::AttrVec outer_attrs = AST::AttrVec (),
+			   bool pratt_parse = false);
   std::unique_ptr parse_array_expr (AST::AttrVec outer_attrs
 		= AST::AttrVec (),
 		bool pratt_parse = false);
-- 
2.32.0

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug libstdc++/100682] Outdated manual about the debug mode using

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug analyzer/101550] -Wanalyzer-file-leak false positive with an array of pointers, open and fdopen.

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

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

What version of glibc are you using?

This looks similar to PR 101081 in that I think it's dependent on the exact
uses of __attribute__((malloc)) within stdio.h.

Clarification on CTF/BTF workings with LTO

[Indu Bhagat via Gcc-patches]

Hello,

Wanted to follow up on the CTF/BTF debug info + LTO workings.

To summarize, the current status/workflow on trunk is:

- The CTF container is written out in the ctfout.c or btfout.c via the 
ctf_debug_finalize () API.
- At this time, the ctf_debug_finalize () itself is called once in 
dwarf2out_early_finish ().

- Until this time, the requirements of CTF and BTF are simple.
   - The generated .ctf/.BTF sections needs no demarcation of 
"early"/"late" debug. All of it can be generated "early".
   - The generated .ctf/.BTF information does not need to be different 
for the final assembly and the fat LTO IR.

   - The BPF CO-RE is not yet implemented on trunk.

Writing out the CTF/BTF at dwarf2out_early_finish seems to work - there 
will always be a .ctf/.BTF section whether it's fat or slim LTO objects 
(because the emission is still in dwarf2out_early_finish on the trunk). 
And we have functionality to copy over the .ctf/.BTF debug sections in 
handle_lto_debug_sections (). However, reading through some of the past 
emails on the CTF/BTF patch series, it seems that you have been pointing 
to the CTF/BTF debug info generation being broken when used with LTO. If 
true, I am most certainly missing some key point here.


So, before we move to the next steps of supporting additional 
requirements of BPF CO-RE etc., I would like to make sure that my 
current understanding is OK and that the current state of CTF/BTF on 
trunk is functional -with LTO-. I have tested some bits (with and 
without fat objects on x86_64) and have not run into issues.


Can you please confirm what you see amiss in the current workings of 
CTF/BTF with LTO on trunk ?


Thanks
Indu

Re: [PATCH 1/2] RISC-V: Add arch flags for T-HEAD.

[Jim Wilson]

On Tue, Jul 13, 2021 at 11:06 AM Palmer Dabbelt  wrote:

> Is there are documentation as to what this "theadc" extension is?
>

The best doc I know of is
https://github.com/isrc-cas/c910-llvm
The README is in Chinese, but google translate does a decent job on it.  If
you want more details, you have to read the llvm sources to see exactly
what each instruction does.  They have mentioned that they are working on
English language docs, but I don't know when they will be available.

There are quite a few T-Head specific instructions here.  This patch is
only adding support for a few of them, probably as a trial to see how it
goes before they try to add the rest.

Jim

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Jul 21, 2021 at 08:37:02PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056264.html
> 

OK.  Just a generic patch to avoid a null pointer dereference.

[committed] fix a couple of typos in a comment

[Martin Sebor via Gcc-patches]

My eye was drawn to the typos below so I fixed them.

Martin

diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 742a95a549e..cbd51ac4d7c 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -3745,7 +3745,7 @@ walk_non_aliased_vuses (ao_ref *ref, tree vuse, 
bool tbaa_p,

 }


-/* Based on the memory reference REF call WALKER for each vdef which
+/* Based on the memory reference REF call WALKER for each vdef whose
defining statement may clobber REF, starting with VDEF.  If REF
is NULL_TREE, each defining statement is visited.

@@ -3755,8 +3755,8 @@ walk_non_aliased_vuses (ao_ref *ref, tree vuse, 
bool tbaa_p,

If function entry is reached, FUNCTION_ENTRY_REACHED is set to true.
The pointer may be NULL and then we do not track this information.

-   At PHI nodes walk_aliased_vdefs forks into one walk for reach
-   PHI argument (but only one walk continues on merge points), the
+   At PHI nodes walk_aliased_vdefs forks into one walk for each
+   PHI argument (but only one walk continues at merge points), the
return value is true if any of the walks was successful.

The function returns the number of statements walked or -1 if

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056264.html

[PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[Harald Anlauf via Gcc-patches]

I have the impression that Gerhard is a hydra: one PR down, he submits
two new ones... :-(
Anyway, here's a straightforward fix for a NULL pointer dereference for
an invalid argument to STAT.  For an alternative patch by Steve see PR.

Regtested on x86_64-pc-linux-gnu.  OK for mainline / 11-branch when it
reopens?

Thanks,
Harald


Fortran: ICE in resolve_allocate_deallocate for invalid STAT argument

gcc/fortran/ChangeLog:

PR fortran/101564
* resolve.c (resolve_allocate_deallocate): Avoid NULL pointer
dereference and shortcut for bad STAT argument to (DE)ALLOCATE.

gcc/testsuite/ChangeLog:

PR fortran/101564
* gfortran.dg/pr101564.f90: New test.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 45c3ad387ac..51d312116eb 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8165,6 +8165,9 @@ resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 	gfc_error ("Stat-variable at %L must be a scalar INTEGER "
 		   "variable", >where);

+  if (stat->expr_type == EXPR_CONSTANT || stat->symtree == NULL)
+	goto done_stat;
+
   for (p = code->ext.alloc.list; p; p = p->next)
 	if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
 	  {
@@ -8192,6 +8195,8 @@ resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 	  }
 }

+done_stat:
+
   /* Check the errmsg variable.  */
   if (errmsg)
 {
diff --git a/gcc/testsuite/gfortran.dg/pr101564.f90 b/gcc/testsuite/gfortran.dg/pr101564.f90
new file mode 100644
index 000..1e7c9911ce6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr101564.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/101564 - ICE in resolve_allocate_deallocate
+
+program p
+  integer, allocatable :: x(:)
+  integer  :: stat
+  allocate (x(2), stat=stat)
+  deallocate (x,  stat=stat%kind) ! { dg-error "(STAT variable)" }
+end

[Bug fortran/101536] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056263.html

[PATCH] PR fortran/101536 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324

[Harald Anlauf via Gcc-patches]

Another one of Gerhard's infamous testcases.  We did not properly detect
and reject array elements of type CLASS as argument to an intrinsic when
it should be an array.

Regtested on x86_64-pc-linux-gnu.  OK for mainline / 11-branch when it
reopens?

Thanks,
Harald


Fortran: extend check for array arguments and reject CLASS array elements.

gcc/fortran/ChangeLog:

PR fortran/101536
* check.c (array_check): Array elements of CLASS type are not
arrays.

gcc/testsuite/ChangeLog:

PR fortran/101536
* gfortran.dg/pr101536.f90: New test.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 27bf3a7eafe..6d2d9fe4007 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -735,6 +735,10 @@ array_check (gfc_expr *e, int n)
 	&& CLASS_DATA (e)->attr.dimension
 	&& CLASS_DATA (e)->as->rank)
 {
+  if (e->ref && e->ref->type == REF_ARRAY
+	  && e->ref->u.ar.type == AR_ELEMENT)
+	goto error;
+
   gfc_add_class_array_ref (e);
   return true;
 }
@@ -742,6 +746,7 @@ array_check (gfc_expr *e, int n)
   if (e->rank != 0 && e->ts.type != BT_PROCEDURE)
 return true;

+error:
   gfc_error ("%qs argument of %qs intrinsic at %L must be an array",
 	 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
 	 >where);
diff --git a/gcc/testsuite/gfortran.dg/pr101536.f90 b/gcc/testsuite/gfortran.dg/pr101536.f90
new file mode 100644
index 000..14cb4100bd6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr101536.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/101536 - ICE in gfc_conv_expr_descriptor
+
+program p
+  type t
+  end type
+contains
+  integer function f(x)
+class(t), allocatable :: x(:)
+f = size (x(1)) ! { dg-error "must be an array" }
+  end
+end

[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

Confirmed; I'm working on a fix.

[Bug target/95483] [i386] Missing SIMD functions

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 88035 has been marked as a duplicate of this bug. ***

[Bug target/88035] missing _mm512_reduce_round_pd() et al

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #4 from H.J. Lu  ---
Dup.

*** This bug has been marked as a duplicate of bug 95483 ***

Re: [PATCH v3] Add QI vector mode support to by-pieces for memset

[H.J. Lu via Gcc-patches]

On Wed, Jul 21, 2021 at 12:42 PM Richard Sandiford
 wrote:
>
> Richard Sandiford  writes:
> > "H.J. Lu via Gcc-patches"  writes:
> >> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
> >>  wrote:
> >>>
> >>> "H.J. Lu"  writes:
> >>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> >>> > index 39ab139b7e1..1972301ce3c 100644
> >>> > --- a/gcc/builtins.c
> >>> > +++ b/gcc/builtins.c
> >>> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
> >>> > machine_mode target_mode)
> >>> >
> >>> >  static rtx
> >>> >  builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> >>> > -  scalar_int_mode mode)
> >>> > +  fixed_size_mode mode)
> >>> >  {
> >>> >/* The REPresentation pointed to by DATA need not be a nul-terminated
> >>> >   string but the caller guarantees it's large enough for MODE.  */
> >>> >const char *rep = (const char *) data;
> >>> >
> >>> > -  return c_readstr (rep + offset, mode, /*nul_terminated=*/false);
> >>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> >>> > + the memset expander.  */
> >>>
> >>> Sorry to nitpick, but I guess this might get out out-of-date.  Maybe:
> >>>
> >>>   /* The by-pieces infrastructure does not try to pick a vector mode
> >>>  for memcpy expansion.  */
> >>
> >> Fixed.
> >>
> >>> > +  return c_readstr (rep + offset, as_a  (mode),
> >>> > + /*nul_terminated=*/false);
> >>> >  }
> >>> >
> >>> >  /* LEN specify length of the block of memcpy/memset operation.
> >>> > @@ -6478,14 +6481,16 @@ expand_builtin_stpncpy (tree exp, rtx)
> >>> >
> >>> >  rtx
> >>> >  builtin_strncpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> >>> > -   scalar_int_mode mode)
> >>> > +   fixed_size_mode mode)
> >>> >  {
> >>> >const char *str = (const char *) data;
> >>> >
> >>> >if ((unsigned HOST_WIDE_INT) offset > strlen (str))
> >>> >  return const0_rtx;
> >>> >
> >>> > -  return c_readstr (str + offset, mode);
> >>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> >>> > + the memset expander.  */
> >>>
> >>> Similarly here for strncpy expansion.
> >>
> >> Fixed.
> >>
> >>> > +  return c_readstr (str + offset, as_a  (mode));
> >>> >  }
> >>> >
> >>> >  /* Helper to check the sizes of sequences and the destination of calls
> >>> > @@ -6686,30 +6691,117 @@ expand_builtin_strncpy (tree exp, rtx target)
> >>> >return NULL_RTX;
> >>> >  }
> >>> >
> >>> > -/* Callback routine for store_by_pieces.  Read GET_MODE_BITSIZE (MODE)
> >>> > -   bytes from constant string DATA + OFFSET and return it as target
> >>> > -   constant.  If PREV isn't nullptr, it has the RTL info from the
> >>> > +/* Return the RTL of a register in MODE generated from PREV in the
> >>> > previous iteration.  */
> >>> >
> >>> > -rtx
> >>> > -builtin_memset_read_str (void *data, void *prevp,
> >>> > -  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
> >>> > -  scalar_int_mode mode)
> >>> > +static rtx
> >>> > +gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
> >>> >  {
> >>> > -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
> >>> > +  rtx target = nullptr;
> >>> >if (prev != nullptr && prev->data != nullptr)
> >>> >  {
> >>> >/* Use the previous data in the same mode.  */
> >>> >if (prev->mode == mode)
> >>> >   return prev->data;
> >>> > +
> >>> > +  fixed_size_mode prev_mode = prev->mode;
> >>> > +
> >>> > +  /* Don't use the previous data to write QImode if it is in a
> >>> > +  vector mode.  */
> >>> > +  if (VECTOR_MODE_P (prev_mode) && mode == QImode)
> >>> > + return target;
> >>> > +
> >>> > +  rtx prev_rtx = prev->data;
> >>> > +
> >>> > +  if (REG_P (prev_rtx)
> >>> > +   && HARD_REGISTER_P (prev_rtx)
> >>> > +   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> >>> > + {
> >>> > +   /* If we can't put a hard register in MODE, first generate a
> >>> > +  subreg of word mode if the previous mode is wider than word
> >>> > +  mode and word mode is wider than MODE.  */
> >>> > +   if (UNITS_PER_WORD < GET_MODE_SIZE (prev_mode)
> >>> > +   && UNITS_PER_WORD > GET_MODE_SIZE (mode))
> >>> > + {
> >>> > +   prev_rtx = lowpart_subreg (word_mode, prev_rtx,
> >>> > +  prev_mode);
> >>> > +   if (prev_rtx != nullptr)
> >>> > + prev_mode = word_mode;
> >>> > + }
> >>> > +   else
> >>> > + prev_rtx = nullptr;
> >>>
> >>> I don't understand this.  Why not just do the:
> >>>
> >>>   if (REG_P (prev_rtx)
> >>>   && HARD_REGISTER_P (prev_rtx)
> >>>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> >>> prev_rtx = copy_to_reg (prev_rtx);
> >>>
> >>> that I suggested in the previous review?
> >>
> >> But 

[PATCH v4] Add QI vector mode support to by-pieces for memset

[H.J. Lu via Gcc-patches]

1. Replace scalar_int_mode with fixed_size_mode in the by-pieces
infrastructure to allow non-integer mode.
2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size
to return QI vector mode for memset.
3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the
smallest integer or QI vector mode.
4. Remove clear_by_pieces_1 and use builtin_memset_read_str in
clear_by_pieces to support vector mode broadcast.
5. Add lowpart_subreg_regno, a wrapper around simplify_subreg_regno that
uses subreg_lowpart_offset (mode, prev_mode) as the offset.
6. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard
scratch register to avoid stack realignment when expanding memset.

gcc/

PR middle-end/90773
* builtins.c (builtin_memcpy_read_str): Change the mode argument
from scalar_int_mode to fixed_size_mode.
(builtin_strncpy_read_str): Likewise.
(gen_memset_value_from_prev): New function.
(gen_memset_broadcast): Likewise.
(builtin_memset_read_str): Change the mode argument from
scalar_int_mode to fixed_size_mode.  Use gen_memset_value_from_prev
and gen_memset_broadcast.
(builtin_memset_gen_str): Likewise.
(try_store_by_multiple_pieces): Use by_pieces_constfn to declare
constfun.
* builtins.h (builtin_strncpy_read_str): Replace scalar_int_mode
with fixed_size_mode.
(builtin_memset_read_str): Likewise.
* expr.c (widest_int_mode_for_size): Renamed to ...
(widest_fixed_size_mode_for_size): Add a bool argument to
indicate if QI vector mode can be used.
(by_pieces_ninsns): Call widest_fixed_size_mode_for_size
instead of widest_int_mode_for_size.
(pieces_addr::adjust): Change the mode argument from
scalar_int_mode to fixed_size_mode.
(op_by_pieces_d): Make m_len read-only.  Add a bool member,
m_qi_vector_mode, to indicate that QI vector mode can be used.
(op_by_pieces_d::op_by_pieces_d): Add a bool argument to
initialize m_qi_vector_mode.  Call widest_fixed_size_mode_for_size
instead of widest_int_mode_for_size.
(op_by_pieces_d::get_usable_mode): Change the mode argument from
scalar_int_mode to fixed_size_mode.  Call
widest_fixed_size_mode_for_size instead of
widest_int_mode_for_size.
(op_by_pieces_d::smallest_fixed_size_mode_for_size): New member
function to return the smallest integer or QI vector mode.
(op_by_pieces_d::run): Call widest_fixed_size_mode_for_size
instead of widest_int_mode_for_size.  Call
smallest_fixed_size_mode_for_size instead of
smallest_int_mode_for_size.
(store_by_pieces_d::store_by_pieces_d): Add a bool argument to
indicate that QI vector mode can be used and pass it to
op_by_pieces_d::op_by_pieces_d.
(can_store_by_pieces): Call widest_fixed_size_mode_for_size
instead of widest_int_mode_for_size.
(store_by_pieces): Pass memsetp to
store_by_pieces_d::store_by_pieces_d.
(clear_by_pieces_1): Removed.
(clear_by_pieces): Replace clear_by_pieces_1 with
builtin_memset_read_str and pass true to store_by_pieces_d to
support vector mode broadcast.
(string_cst_read_str): Change the mode argument from
scalar_int_mode to fixed_size_mode.
* expr.h (by_pieces_constfn): Change scalar_int_mode to
fixed_size_mode.
(by_pieces_prev): Likewise.
* rtl.h (lowpart_subreg_regno): New.
* rtlanal.c (lowpart_subreg_regno): New.  A wrapper around
simplify_subreg_regno.
* target.def (gen_memset_scratch_rtx): New hook.
* doc/tm.texi.in: Add TARGET_GEN_MEMSET_SCRATCH_RTX.
* doc/tm.texi: Regenerated.

gcc/testsuite/

* gcc.target/i386/pr100865-3.c: Expect vmovdqu8 instead of
vmovdqu.
* gcc.target/i386/pr100865-4b.c: Likewise.
---
 gcc/builtins.c  | 180 
 gcc/builtins.h  |   4 +-
 gcc/doc/tm.texi |   7 +
 gcc/doc/tm.texi.in  |   2 +
 gcc/expr.c  | 168 --
 gcc/expr.h  |   4 +-
 gcc/rtl.h   |   2 +
 gcc/rtlanal.c   |  11 ++
 gcc/target.def  |   9 +
 gcc/testsuite/gcc.target/i386/pr100865-3.c  |   2 +-
 gcc/testsuite/gcc.target/i386/pr100865-4b.c |   2 +-
 11 files changed, 303 insertions(+), 88 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 170d776c410..26360b0b11b 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
machine_mode target_mode)
 
 static rtx
 builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
- 

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Dale Weiler from comment #5)
> This is curious, omitting `decltype(auto)` for get, as in just `auto` seems
> to work around the issue as well.
> 
> template
> constexpr auto get(T tuple) { return *tuple(Get{}); }
> 
> I'm a bit out of my element here, in that I don't understand the semantic
> differences between the two and if that behavior is correct.

auto makes it return by value, decltype(auto) returns exactly the type of the
return statement (so if it's a reference, so is the return type).

Re: [PATCH v3] Add QI vector mode support to by-pieces for memset

[Richard Sandiford via Gcc-patches]

Richard Sandiford  writes:
> "H.J. Lu via Gcc-patches"  writes:
>> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
>>  wrote:
>>>
>>> "H.J. Lu"  writes:
>>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> > index 39ab139b7e1..1972301ce3c 100644
>>> > --- a/gcc/builtins.c
>>> > +++ b/gcc/builtins.c
>>> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
>>> > machine_mode target_mode)
>>> >
>>> >  static rtx
>>> >  builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
>>> > -  scalar_int_mode mode)
>>> > +  fixed_size_mode mode)
>>> >  {
>>> >/* The REPresentation pointed to by DATA need not be a nul-terminated
>>> >   string but the caller guarantees it's large enough for MODE.  */
>>> >const char *rep = (const char *) data;
>>> >
>>> > -  return c_readstr (rep + offset, mode, /*nul_terminated=*/false);
>>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
>>> > + the memset expander.  */
>>>
>>> Sorry to nitpick, but I guess this might get out out-of-date.  Maybe:
>>>
>>>   /* The by-pieces infrastructure does not try to pick a vector mode
>>>  for memcpy expansion.  */
>>
>> Fixed.
>>
>>> > +  return c_readstr (rep + offset, as_a  (mode),
>>> > + /*nul_terminated=*/false);
>>> >  }
>>> >
>>> >  /* LEN specify length of the block of memcpy/memset operation.
>>> > @@ -6478,14 +6481,16 @@ expand_builtin_stpncpy (tree exp, rtx)
>>> >
>>> >  rtx
>>> >  builtin_strncpy_read_str (void *data, void *, HOST_WIDE_INT offset,
>>> > -   scalar_int_mode mode)
>>> > +   fixed_size_mode mode)
>>> >  {
>>> >const char *str = (const char *) data;
>>> >
>>> >if ((unsigned HOST_WIDE_INT) offset > strlen (str))
>>> >  return const0_rtx;
>>> >
>>> > -  return c_readstr (str + offset, mode);
>>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
>>> > + the memset expander.  */
>>>
>>> Similarly here for strncpy expansion.
>>
>> Fixed.
>>
>>> > +  return c_readstr (str + offset, as_a  (mode));
>>> >  }
>>> >
>>> >  /* Helper to check the sizes of sequences and the destination of calls
>>> > @@ -6686,30 +6691,117 @@ expand_builtin_strncpy (tree exp, rtx target)
>>> >return NULL_RTX;
>>> >  }
>>> >
>>> > -/* Callback routine for store_by_pieces.  Read GET_MODE_BITSIZE (MODE)
>>> > -   bytes from constant string DATA + OFFSET and return it as target
>>> > -   constant.  If PREV isn't nullptr, it has the RTL info from the
>>> > +/* Return the RTL of a register in MODE generated from PREV in the
>>> > previous iteration.  */
>>> >
>>> > -rtx
>>> > -builtin_memset_read_str (void *data, void *prevp,
>>> > -  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
>>> > -  scalar_int_mode mode)
>>> > +static rtx
>>> > +gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
>>> >  {
>>> > -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
>>> > +  rtx target = nullptr;
>>> >if (prev != nullptr && prev->data != nullptr)
>>> >  {
>>> >/* Use the previous data in the same mode.  */
>>> >if (prev->mode == mode)
>>> >   return prev->data;
>>> > +
>>> > +  fixed_size_mode prev_mode = prev->mode;
>>> > +
>>> > +  /* Don't use the previous data to write QImode if it is in a
>>> > +  vector mode.  */
>>> > +  if (VECTOR_MODE_P (prev_mode) && mode == QImode)
>>> > + return target;
>>> > +
>>> > +  rtx prev_rtx = prev->data;
>>> > +
>>> > +  if (REG_P (prev_rtx)
>>> > +   && HARD_REGISTER_P (prev_rtx)
>>> > +   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
>>> > + {
>>> > +   /* If we can't put a hard register in MODE, first generate a
>>> > +  subreg of word mode if the previous mode is wider than word
>>> > +  mode and word mode is wider than MODE.  */
>>> > +   if (UNITS_PER_WORD < GET_MODE_SIZE (prev_mode)
>>> > +   && UNITS_PER_WORD > GET_MODE_SIZE (mode))
>>> > + {
>>> > +   prev_rtx = lowpart_subreg (word_mode, prev_rtx,
>>> > +  prev_mode);
>>> > +   if (prev_rtx != nullptr)
>>> > + prev_mode = word_mode;
>>> > + }
>>> > +   else
>>> > + prev_rtx = nullptr;
>>>
>>> I don't understand this.  Why not just do the:
>>>
>>>   if (REG_P (prev_rtx)
>>>   && HARD_REGISTER_P (prev_rtx)
>>>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
>>> prev_rtx = copy_to_reg (prev_rtx);
>>>
>>> that I suggested in the previous review?
>>
>> But for
>> ---
>> extern void *ops;
>>
>> void
>> foo (int c)
>> {
>>   __builtin_memset (ops, c, 18);
>> }
>> ---
>> I got
>>
>> vpbroadcastb %edi, %xmm31
>> vmovdqa64 %xmm31, -24(%rsp)
>> movq ops(%rip), %rax
>> movzwl -24(%rsp), %edx
>> vmovdqu8 %xmm31, (%rax)
>> movw %dx, 16(%rax)
>> ret
>>
>> I want to 

Re: [PATCH v3] Add QI vector mode support to by-pieces for memset

[H.J. Lu via Gcc-patches]

On Wed, Jul 21, 2021 at 12:20 PM Richard Sandiford
 wrote:
>
> "H.J. Lu via Gcc-patches"  writes:
> > On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
> >  wrote:
> >>
> >> "H.J. Lu"  writes:
> >> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> >> > index 39ab139b7e1..1972301ce3c 100644
> >> > --- a/gcc/builtins.c
> >> > +++ b/gcc/builtins.c
> >> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
> >> > machine_mode target_mode)
> >> >
> >> >  static rtx
> >> >  builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> >> > -  scalar_int_mode mode)
> >> > +  fixed_size_mode mode)
> >> >  {
> >> >/* The REPresentation pointed to by DATA need not be a nul-terminated
> >> >   string but the caller guarantees it's large enough for MODE.  */
> >> >const char *rep = (const char *) data;
> >> >
> >> > -  return c_readstr (rep + offset, mode, /*nul_terminated=*/false);
> >> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> >> > + the memset expander.  */
> >>
> >> Sorry to nitpick, but I guess this might get out out-of-date.  Maybe:
> >>
> >>   /* The by-pieces infrastructure does not try to pick a vector mode
> >>  for memcpy expansion.  */
> >
> > Fixed.
> >
> >> > +  return c_readstr (rep + offset, as_a  (mode),
> >> > + /*nul_terminated=*/false);
> >> >  }
> >> >
> >> >  /* LEN specify length of the block of memcpy/memset operation.
> >> > @@ -6478,14 +6481,16 @@ expand_builtin_stpncpy (tree exp, rtx)
> >> >
> >> >  rtx
> >> >  builtin_strncpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> >> > -   scalar_int_mode mode)
> >> > +   fixed_size_mode mode)
> >> >  {
> >> >const char *str = (const char *) data;
> >> >
> >> >if ((unsigned HOST_WIDE_INT) offset > strlen (str))
> >> >  return const0_rtx;
> >> >
> >> > -  return c_readstr (str + offset, mode);
> >> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> >> > + the memset expander.  */
> >>
> >> Similarly here for strncpy expansion.
> >
> > Fixed.
> >
> >> > +  return c_readstr (str + offset, as_a  (mode));
> >> >  }
> >> >
> >> >  /* Helper to check the sizes of sequences and the destination of calls
> >> > @@ -6686,30 +6691,117 @@ expand_builtin_strncpy (tree exp, rtx target)
> >> >return NULL_RTX;
> >> >  }
> >> >
> >> > -/* Callback routine for store_by_pieces.  Read GET_MODE_BITSIZE (MODE)
> >> > -   bytes from constant string DATA + OFFSET and return it as target
> >> > -   constant.  If PREV isn't nullptr, it has the RTL info from the
> >> > +/* Return the RTL of a register in MODE generated from PREV in the
> >> > previous iteration.  */
> >> >
> >> > -rtx
> >> > -builtin_memset_read_str (void *data, void *prevp,
> >> > -  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
> >> > -  scalar_int_mode mode)
> >> > +static rtx
> >> > +gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
> >> >  {
> >> > -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
> >> > +  rtx target = nullptr;
> >> >if (prev != nullptr && prev->data != nullptr)
> >> >  {
> >> >/* Use the previous data in the same mode.  */
> >> >if (prev->mode == mode)
> >> >   return prev->data;
> >> > +
> >> > +  fixed_size_mode prev_mode = prev->mode;
> >> > +
> >> > +  /* Don't use the previous data to write QImode if it is in a
> >> > +  vector mode.  */
> >> > +  if (VECTOR_MODE_P (prev_mode) && mode == QImode)
> >> > + return target;
> >> > +
> >> > +  rtx prev_rtx = prev->data;
> >> > +
> >> > +  if (REG_P (prev_rtx)
> >> > +   && HARD_REGISTER_P (prev_rtx)
> >> > +   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> >> > + {
> >> > +   /* If we can't put a hard register in MODE, first generate a
> >> > +  subreg of word mode if the previous mode is wider than word
> >> > +  mode and word mode is wider than MODE.  */
> >> > +   if (UNITS_PER_WORD < GET_MODE_SIZE (prev_mode)
> >> > +   && UNITS_PER_WORD > GET_MODE_SIZE (mode))
> >> > + {
> >> > +   prev_rtx = lowpart_subreg (word_mode, prev_rtx,
> >> > +  prev_mode);
> >> > +   if (prev_rtx != nullptr)
> >> > + prev_mode = word_mode;
> >> > + }
> >> > +   else
> >> > + prev_rtx = nullptr;
> >>
> >> I don't understand this.  Why not just do the:
> >>
> >>   if (REG_P (prev_rtx)
> >>   && HARD_REGISTER_P (prev_rtx)
> >>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> >> prev_rtx = copy_to_reg (prev_rtx);
> >>
> >> that I suggested in the previous review?
> >
> > But for
> > ---
> > extern void *ops;
> >
> > void
> > foo (int c)
> > {
> >   __builtin_memset (ops, c, 18);
> > }
> > ---
> > I got
> >
> > vpbroadcastb 

[Bug tree-optimization/101534] ICE in create_tailcall_accumulator, at tree-tailcall.c:1083

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2021-July/57 |il/gcc-patches/2021-July/57
   |5692.html   |5771.html

--- Comment #6 from Andrew Pinski  ---
Updated patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575771.html

[PATCH] Fix PR 10153: tail recusion for vector types.

[apinski--- via Gcc-patches]

From: Andrew Pinski 

The problem here is we try to an initialized value
from a scalar constant. For vectors we need to do
a vect_dup instead.  This fixes that issue by using
build_{one,zero}_cst instead of integer_{one,zero}_node
when calling create_tailcall_accumulator.

Changes from v1:
* v2: Use build_{one,zero}_cst and get the correct type before.

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

gcc/ChangeLog:

PR tree-optimize/10153
* tree-tailcall.c (create_tailcall_accumulator):
Don't call fold_convert as the type should be correct already.
(tree_optimize_tail_calls_1): Use build_{one,zero}_cst instead
of integer_{one,zero}_node for the call of create_tailcall_accumulator.

gcc/testsuite/ChangeLog:

PR tree-optimize/10153
* gcc.c-torture/compile/pr10153-1.c: New test.
* gcc.c-torture/compile/pr10153-2.c: New test.
---
 gcc/testsuite/gcc.c-torture/compile/pr10153-1.c |  7 +++
 gcc/testsuite/gcc.c-torture/compile/pr10153-2.c |  9 +
 gcc/tree-tailcall.c | 10 ++
 3 files changed, 22 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr10153-1.c
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr10153-2.c

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr10153-1.c 
b/gcc/testsuite/gcc.c-torture/compile/pr10153-1.c
new file mode 100644
index 000..3f2040f32a1
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr10153-1.c
@@ -0,0 +1,7 @@
+typedef int V __attribute__ ((vector_size (2 * sizeof (int;
+V
+foo (void)
+{
+  V v = { };
+  return v - foo();
+}
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr10153-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr10153-2.c
new file mode 100644
index 000..1af4c8e2a36
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr10153-2.c
@@ -0,0 +1,9 @@
+typedef int V __attribute__ ((vector_size (2 * sizeof (int;
+V
+foo (int t)
+{
+  if (t < 10)
+return (V){1, 1};
+  V v = { };
+  return v - foo(t - 1);
+}
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index a4d31c90c49..f2833d25ce8 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -1079,8 +1079,7 @@ create_tailcall_accumulator (const char *label, 
basic_block bb, tree init)
   gphi *phi;
 
   phi = create_phi_node (tmp, bb);
-  /* RET_TYPE can be a float when -ffast-maths is enabled.  */
-  add_phi_arg (phi, fold_convert (ret_type, init), single_pred_edge (bb),
+  add_phi_arg (phi, init, single_pred_edge (bb),
   UNKNOWN_LOCATION);
   return PHI_RESULT (phi);
 }
@@ -1157,14 +1156,17 @@ tree_optimize_tail_calls_1 (bool opt_tailcalls)
  }
  phis_constructed = true;
}
+  tree ret_type = TREE_TYPE (DECL_RESULT (current_function_decl));
+  if (POINTER_TYPE_P (ret_type))
+   ret_type = sizetype;
 
   if (act->add && !a_acc)
a_acc = create_tailcall_accumulator ("add_acc", first,
-integer_zero_node);
+build_zero_cst (ret_type));
 
   if (act->mult && !m_acc)
m_acc = create_tailcall_accumulator ("mult_acc", first,
-integer_one_node);
+build_one_cst (ret_type));
 }
 
   if (a_acc || m_acc)
-- 
2.27.0

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Dale Weiler  ---
Yeah the code example is invalid, there is a reference to a temporary,
decltype(auto) on *ptr produces reference type, somehow I thought it produced
the value type, sorry for the confusion.

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

Dale Weiler  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Dale Weiler  ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2) 
> > > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > > question now becomes why does -fsanitize=undefined find nothing, and is 
> > > the
> > > return type, i.e `declval(get(t))` different in gcc compared to the 
> > > other
> > > compiles. I would expect similar issues in the other compilers if this is
> > > returning a reference to the temporary given by the argument list of `get`
> > 
> > So -fsanitize=undefined adds some extra code which just happens to cause GCC
> > not to optimize as much.
> > 
> > Try -fsanitize=address instead which enables
> > -fsanitize-address-use-after-scope which should detect the problem but I see
> > it does not 
> 
> I'm unsure why this would be a temporary, given:
> 
> auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(); };
> 
> This should capture all `ts...` by copy, the `f()` should reference
> the captures of `this` inside the lambda (of the compiler generated
> structure.)
> 
> When `get` is called, the values from the lambda are returned by
> dereferencing since the function is called with pointers (synthesized with
> `` in the lambda). I verified this by printing
> `typeid(decltype(get(t))).name()` passed to `__cxa_demangle`. There isn't
> any reference types, just to be sure that's not some runtime quirk, the
> compile-time result of `std::is_same_v)>` is true.
> 
> Where is the temporary happening?

This is curious, omitting `decltype(auto)` for get, as in just `auto` seems to
work around the issue as well.

template
constexpr auto get(T tuple) { return *tuple(Get{}); }

I'm a bit out of my element here, in that I don't understand the semantic
differences between the two and if that behavior is correct.

Re: [PATCH v3] Add QI vector mode support to by-pieces for memset

[Richard Sandiford via Gcc-patches]

"H.J. Lu via Gcc-patches"  writes:
> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
>  wrote:
>>
>> "H.J. Lu"  writes:
>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
>> > index 39ab139b7e1..1972301ce3c 100644
>> > --- a/gcc/builtins.c
>> > +++ b/gcc/builtins.c
>> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
>> > machine_mode target_mode)
>> >
>> >  static rtx
>> >  builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
>> > -  scalar_int_mode mode)
>> > +  fixed_size_mode mode)
>> >  {
>> >/* The REPresentation pointed to by DATA need not be a nul-terminated
>> >   string but the caller guarantees it's large enough for MODE.  */
>> >const char *rep = (const char *) data;
>> >
>> > -  return c_readstr (rep + offset, mode, /*nul_terminated=*/false);
>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
>> > + the memset expander.  */
>>
>> Sorry to nitpick, but I guess this might get out out-of-date.  Maybe:
>>
>>   /* The by-pieces infrastructure does not try to pick a vector mode
>>  for memcpy expansion.  */
>
> Fixed.
>
>> > +  return c_readstr (rep + offset, as_a  (mode),
>> > + /*nul_terminated=*/false);
>> >  }
>> >
>> >  /* LEN specify length of the block of memcpy/memset operation.
>> > @@ -6478,14 +6481,16 @@ expand_builtin_stpncpy (tree exp, rtx)
>> >
>> >  rtx
>> >  builtin_strncpy_read_str (void *data, void *, HOST_WIDE_INT offset,
>> > -   scalar_int_mode mode)
>> > +   fixed_size_mode mode)
>> >  {
>> >const char *str = (const char *) data;
>> >
>> >if ((unsigned HOST_WIDE_INT) offset > strlen (str))
>> >  return const0_rtx;
>> >
>> > -  return c_readstr (str + offset, mode);
>> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
>> > + the memset expander.  */
>>
>> Similarly here for strncpy expansion.
>
> Fixed.
>
>> > +  return c_readstr (str + offset, as_a  (mode));
>> >  }
>> >
>> >  /* Helper to check the sizes of sequences and the destination of calls
>> > @@ -6686,30 +6691,117 @@ expand_builtin_strncpy (tree exp, rtx target)
>> >return NULL_RTX;
>> >  }
>> >
>> > -/* Callback routine for store_by_pieces.  Read GET_MODE_BITSIZE (MODE)
>> > -   bytes from constant string DATA + OFFSET and return it as target
>> > -   constant.  If PREV isn't nullptr, it has the RTL info from the
>> > +/* Return the RTL of a register in MODE generated from PREV in the
>> > previous iteration.  */
>> >
>> > -rtx
>> > -builtin_memset_read_str (void *data, void *prevp,
>> > -  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
>> > -  scalar_int_mode mode)
>> > +static rtx
>> > +gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
>> >  {
>> > -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
>> > +  rtx target = nullptr;
>> >if (prev != nullptr && prev->data != nullptr)
>> >  {
>> >/* Use the previous data in the same mode.  */
>> >if (prev->mode == mode)
>> >   return prev->data;
>> > +
>> > +  fixed_size_mode prev_mode = prev->mode;
>> > +
>> > +  /* Don't use the previous data to write QImode if it is in a
>> > +  vector mode.  */
>> > +  if (VECTOR_MODE_P (prev_mode) && mode == QImode)
>> > + return target;
>> > +
>> > +  rtx prev_rtx = prev->data;
>> > +
>> > +  if (REG_P (prev_rtx)
>> > +   && HARD_REGISTER_P (prev_rtx)
>> > +   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
>> > + {
>> > +   /* If we can't put a hard register in MODE, first generate a
>> > +  subreg of word mode if the previous mode is wider than word
>> > +  mode and word mode is wider than MODE.  */
>> > +   if (UNITS_PER_WORD < GET_MODE_SIZE (prev_mode)
>> > +   && UNITS_PER_WORD > GET_MODE_SIZE (mode))
>> > + {
>> > +   prev_rtx = lowpart_subreg (word_mode, prev_rtx,
>> > +  prev_mode);
>> > +   if (prev_rtx != nullptr)
>> > + prev_mode = word_mode;
>> > + }
>> > +   else
>> > + prev_rtx = nullptr;
>>
>> I don't understand this.  Why not just do the:
>>
>>   if (REG_P (prev_rtx)
>>   && HARD_REGISTER_P (prev_rtx)
>>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
>> prev_rtx = copy_to_reg (prev_rtx);
>>
>> that I suggested in the previous review?
>
> But for
> ---
> extern void *ops;
>
> void
> foo (int c)
> {
>   __builtin_memset (ops, c, 18);
> }
> ---
> I got
>
> vpbroadcastb %edi, %xmm31
> vmovdqa64 %xmm31, -24(%rsp)
> movq ops(%rip), %rax
> movzwl -24(%rsp), %edx
> vmovdqu8 %xmm31, (%rax)
> movw %dx, 16(%rax)
> ret
>
> I want to avoid store and load.  I am testing
>
>   if (REG_P (prev_rtx)
>   && HARD_REGISTER_P (prev_rtx)
>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, 

Re: [PATCH v3] Add QI vector mode support to by-pieces for memset

[H.J. Lu via Gcc-patches]

On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
 wrote:
>
> "H.J. Lu"  writes:
> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> > index 39ab139b7e1..1972301ce3c 100644
> > --- a/gcc/builtins.c
> > +++ b/gcc/builtins.c
> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target, 
> > machine_mode target_mode)
> >
> >  static rtx
> >  builtin_memcpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> > -  scalar_int_mode mode)
> > +  fixed_size_mode mode)
> >  {
> >/* The REPresentation pointed to by DATA need not be a nul-terminated
> >   string but the caller guarantees it's large enough for MODE.  */
> >const char *rep = (const char *) data;
> >
> > -  return c_readstr (rep + offset, mode, /*nul_terminated=*/false);
> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> > + the memset expander.  */
>
> Sorry to nitpick, but I guess this might get out out-of-date.  Maybe:
>
>   /* The by-pieces infrastructure does not try to pick a vector mode
>  for memcpy expansion.  */

Fixed.

> > +  return c_readstr (rep + offset, as_a  (mode),
> > + /*nul_terminated=*/false);
> >  }
> >
> >  /* LEN specify length of the block of memcpy/memset operation.
> > @@ -6478,14 +6481,16 @@ expand_builtin_stpncpy (tree exp, rtx)
> >
> >  rtx
> >  builtin_strncpy_read_str (void *data, void *, HOST_WIDE_INT offset,
> > -   scalar_int_mode mode)
> > +   fixed_size_mode mode)
> >  {
> >const char *str = (const char *) data;
> >
> >if ((unsigned HOST_WIDE_INT) offset > strlen (str))
> >  return const0_rtx;
> >
> > -  return c_readstr (str + offset, mode);
> > +  /* NB: Vector mode in the by-pieces infrastructure is only used by
> > + the memset expander.  */
>
> Similarly here for strncpy expansion.

Fixed.

> > +  return c_readstr (str + offset, as_a  (mode));
> >  }
> >
> >  /* Helper to check the sizes of sequences and the destination of calls
> > @@ -6686,30 +6691,117 @@ expand_builtin_strncpy (tree exp, rtx target)
> >return NULL_RTX;
> >  }
> >
> > -/* Callback routine for store_by_pieces.  Read GET_MODE_BITSIZE (MODE)
> > -   bytes from constant string DATA + OFFSET and return it as target
> > -   constant.  If PREV isn't nullptr, it has the RTL info from the
> > +/* Return the RTL of a register in MODE generated from PREV in the
> > previous iteration.  */
> >
> > -rtx
> > -builtin_memset_read_str (void *data, void *prevp,
> > -  HOST_WIDE_INT offset ATTRIBUTE_UNUSED,
> > -  scalar_int_mode mode)
> > +static rtx
> > +gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
> >  {
> > -  by_pieces_prev *prev = (by_pieces_prev *) prevp;
> > +  rtx target = nullptr;
> >if (prev != nullptr && prev->data != nullptr)
> >  {
> >/* Use the previous data in the same mode.  */
> >if (prev->mode == mode)
> >   return prev->data;
> > +
> > +  fixed_size_mode prev_mode = prev->mode;
> > +
> > +  /* Don't use the previous data to write QImode if it is in a
> > +  vector mode.  */
> > +  if (VECTOR_MODE_P (prev_mode) && mode == QImode)
> > + return target;
> > +
> > +  rtx prev_rtx = prev->data;
> > +
> > +  if (REG_P (prev_rtx)
> > +   && HARD_REGISTER_P (prev_rtx)
> > +   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> > + {
> > +   /* If we can't put a hard register in MODE, first generate a
> > +  subreg of word mode if the previous mode is wider than word
> > +  mode and word mode is wider than MODE.  */
> > +   if (UNITS_PER_WORD < GET_MODE_SIZE (prev_mode)
> > +   && UNITS_PER_WORD > GET_MODE_SIZE (mode))
> > + {
> > +   prev_rtx = lowpart_subreg (word_mode, prev_rtx,
> > +  prev_mode);
> > +   if (prev_rtx != nullptr)
> > + prev_mode = word_mode;
> > + }
> > +   else
> > + prev_rtx = nullptr;
>
> I don't understand this.  Why not just do the:
>
>   if (REG_P (prev_rtx)
>   && HARD_REGISTER_P (prev_rtx)
>   && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
> prev_rtx = copy_to_reg (prev_rtx);
>
> that I suggested in the previous review?

But for
---
extern void *ops;

void
foo (int c)
{
  __builtin_memset (ops, c, 18);
}
---
I got

vpbroadcastb %edi, %xmm31
vmovdqa64 %xmm31, -24(%rsp)
movq ops(%rip), %rax
movzwl -24(%rsp), %edx
vmovdqu8 %xmm31, (%rax)
movw %dx, 16(%rax)
ret

I want to avoid store and load.  I am testing

  if (REG_P (prev_rtx)
  && HARD_REGISTER_P (prev_rtx)
  && lowpart_subreg_regno (REGNO (prev_rtx), prev_mode, mode) < 0)
{
  /* Find the smallest subreg mode in the same mode class which
 is not narrower than MODE and narrower than PREV_MODE.  */
  machine_mode m;
  

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> The %kind was introduced probably in r9, so likely not a real regression.
> 
> I am testing the following patch:
> 
> diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
> index 45c3ad387ac..51d312116eb 100644
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -8165,6 +8165,9 @@ resolve_allocate_deallocate (gfc_code *code, const
> char *fcn)
> gfc_error ("Stat-variable at %L must be a scalar INTEGER "
>"variable", >where);
>  
> +  if (stat->expr_type == EXPR_CONSTANT || stat->symtree == NULL)
> +   goto done_stat;
> +
>for (p = code->ext.alloc.list; p; p = p->next)
> if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
>   {
> @@ -8192,6 +8195,8 @@ resolve_allocate_deallocate (gfc_code *code, const
> char *fcn)
>   }
>  }
>  
> +done_stat:
> +
>/* Check the errmsg variable.  */
>if (errmsg)
>  {

The patch I posted is simpler, but yours will also do the trick.

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The %kind was introduced probably in r9, so likely not a real regression.

I am testing the following patch:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 45c3ad387ac..51d312116eb 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8165,6 +8165,9 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
gfc_error ("Stat-variable at %L must be a scalar INTEGER "
   "variable", >where);

+  if (stat->expr_type == EXPR_CONSTANT || stat->symtree == NULL)
+   goto done_stat;
+
   for (p = code->ext.alloc.list; p; p = p->next)
if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
  {
@@ -8192,6 +8195,8 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
  }
 }

+done_stat:
+
   /* Check the errmsg variable.  */
   if (errmsg)
 {

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 45c3ad387ac..ce22d8644ea 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8166,7 +8167,8 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
   "variable", >where);

   for (p = code->ext.alloc.list; p; p = p->next)
-   if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
+   if (stat->symtree
+   && stat->symtree->n.sym->name == p->expr->symtree->n.sym->name)
  {
gfc_ref *ref1, *ref2;
bool found = true;

Re: [PATCH 23/55] rs6000: Incorporate new builtins code into the build machinery

[Segher Boessenkool]

On Thu, Jun 17, 2021 at 10:19:07AM -0500, Bill Schmidt wrote:
> 2021-06-07  Bill Schmidt  
> 
> gcc/
>   * config.gcc (extra_objs): Include rs6000-builtins.o and
>   rs6000-c.o.

The rs6000-c.o part needs an explanation, and probably should be a
separate (bugfix) patch (and it needs backports?)

The changelog entry should read
* config.gcc (powerpc*-*-*): Include [...] in extra_objs.
or similar.

>   * config/rs6000/t-rs6000 (rs6000-gen-builtins.o): New target.
>   (rbtree.o): Likewise.
>   (rs6000-gen-builtins): Likewise.
>   (rs6000-builtins.c): Likewise.
>   (rs6000-builtins.h): Likewise.
>   (rs6000.o): Add dependency.
>   (EXTRA_HEADERS): Add rs6000-vecdefines.h.
>   (rs6000-vecdefines.h): New target.
>   (rs6000-builtins.o): Likewise.
>   (rs6000-call.o): Add rs6000-builtins.h as a dependency.
>   (rs6000-c.o): Likewise.

> +rs6000-gen-builtins.o: $(srcdir)/config/rs6000/rs6000-gen-builtins.c
> + $(COMPILE) $(CXXFLAGS) $<
> + $(POSTCOMPILE)
> +
> +rbtree.o: $(srcdir)/config/rs6000/rbtree.c
> + $(COMPILE) $<
> + $(POSTCOMPILE)

Why does one need CXXFLAGS and the other does not?

> +# TODO: Whenever GNU make 4.3 is the minimum required, we should use
> +# grouped targets on this:

That may be quite a while still.  GNU make is the foundation of
everything, so we cannot require very new versions of it ever.

In the meantime, you can make all these targets depend on an
intermediate target (that you mark with .INTERMEDIATE), and have that
intermediate target have the dependencies.  This is from version 3.74.3
and we require 3.80 already, so this is fine.

> +EXTRA_HEADERS += rs6000-vecdefines.h
> +rs6000-vecdefines.h : rs6000-builtins.c

No space before the colon please.


Segher

[Bug libstdc++/40380] class documentation should mention include file to use

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

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

--- Comment #6 from Jonathan Wakely  ---
My doxygen patch was merged, so we can start to use SHOW_HEADERFILE and
@headerfile to do this.

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Dale Weiler  ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2) 
> > > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > > question now becomes why does -fsanitize=undefined find nothing, and is 
> > > the
> > > return type, i.e `declval(get(t))` different in gcc compared to the 
> > > other
> > > compiles. I would expect similar issues in the other compilers if this is
> > > returning a reference to the temporary given by the argument list of `get`
> > 
> > So -fsanitize=undefined adds some extra code which just happens to cause GCC
> > not to optimize as much.
> > 
> > Try -fsanitize=address instead which enables
> > -fsanitize-address-use-after-scope which should detect the problem but I see
> > it does not 
> 
> I'm unsure why this would be a temporary, given:
> 
> auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(); };
> 
> This should capture all `ts...` by copy, the `f()` should reference
> the captures of `this` inside the lambda (of the compiler generated
> structure.)
> 
> When `get` is called, the values from the lambda are returned by
> dereferencing since the function is called with pointers (synthesized with
> `` in the lambda). I verified this by printing
> `typeid(decltype(get(t))).name()` passed to `__cxa_demangle`. There isn't
> any reference types, just to be sure that's not some runtime quirk, the
> compile-time result of `std::is_same_v)>` is true.
> 
> Where is the temporary happening?

This is curious, omitting `decltype(auto)` for get, as in just `auto` seems to
work around the issue as well.

template
constexpr auto get(T tuple) { return *tuple(Get{}); }

I'm a bit out of my element here, in that I don't understand the semantic
differences between the two and if that behavior is correct.

[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780

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

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

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|11.2|11.3

[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780

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

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

Bill Schmidt  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |NEW

--- Comment #3 from Bill Schmidt  ---
Fixed on trunk, awaiting backports.  (Confirmed, BTW.)

[PATCH, committed] rs6000: Add int128 target check to pr101129.c (PR101531)

[Bill Schmidt via Gcc-patches]

Hi,

PR101531 observes that gcc.target/powerpc/pr191129.c fails on 32-bit 
targets.  I overlooked that the OP's test case has an __int128 
dependency.  This patch fixes the obvious oversight. Committed as 
obvious.  I plan to backport to 11, 10, and 9 once the 11.2 release is 
complete.


Thanks!
Bill


rs6000: Add int128 target check to pr101129.c (PR101531)

2021-07-21  Bill Schmidt  

gcc/testsuite/
PR target/101531
* gcc.target/powerpc/pr101129.c: Adjust.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr101129.c 
b/gcc/testsuite/gcc.target/powerpc/pr101129.c
index 1abc12480e4..6b8e5a9b597 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr101129.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr101129.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target p8vector_hw } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=power8 -O " } */
 
 /* PR101129: The swaps pass was turning a mult-lopart into a mult-hipart.

[Bug target/88035] missing _mm512_reduce_round_pd() et al

[skpgkp2 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sunil Pandey  ---
I added _mm512_reduce_round_pd() and bunch of other missing intrinsic last
year.


commit 93103603fd66a9fcf3ea2d8b52657e4b2496f544
Author: Sunil K Pandey 
Date:   Wed Oct 14 11:36:39 2020 -0700

x86: Add missing intrinsics [PR95483]

Tested on x86-64.

gcc/ChangeLog:


$ git grep mm512_reduce_round_pd
gcc/ChangeLog-2020: (_mm512_reduce_round_pd): Ditto.
gcc/config/i386/avx512dqintrin.h:_mm512_reduce_round_pd (__m512d __A, int __B,
const int __R)
gcc/config/i386/avx512dqintrin.h:#define _mm512_reduce_round_pd(A, B, R)   
 \
gcc/testsuite/gcc.target/i386/avx512dq-vreducepd-3.c:  xx1 =
_mm512_reduce_round_pd(xx1, IMM, _MM_FROUND_NO_EXC);

$ git grep mm_*reduce_round
gcc/ChangeLog-2020: * config/i386/avx512dqintrin.h (_mm_reduce_round_sd):
New intrinsics.
gcc/ChangeLog-2020: (_mm_reduce_round_ss): Ditto.
gcc/config/i386/avx512dqintrin.h:_mm_reduce_round_sd (__m128d __A, __m128d __B,
int __C, const int __R)
gcc/config/i386/avx512dqintrin.h:_mm_reduce_round_ss (__m128 __A, __m128 __B,
int __C, const int __R)
gcc/config/i386/avx512dqintrin.h:#define _mm_reduce_round_sd(A, B, C, R)   
   \
gcc/config/i386/avx512dqintrin.h:#define _mm_reduce_round_ss(A, B, C, R)   
   \
gcc/testsuite/gcc.target/i386/avx512dq-vreducesd-1.c:  xx1 =
_mm_reduce_round_sd (xx1, xx2, IMM, _MM_FROUND_NO_EXC);
gcc/testsuite/gcc.target/i386/avx512dq-vreducesd-2.c:  res4.x =
_mm_reduce_round_sd (s1.x, s2.x, IMM,_MM_FROUND_TO_NEAREST_INT
gcc/testsuite/gcc.target/i386/avx512dq-vreducess-1.c:  xx1 =
_mm_reduce_round_ss (xx1, xx2, IMM, _MM_FROUND_NO_EXC);
gcc/testsuite/gcc.target/i386/avx512dq-vreducess-2.c:  res4.x =
_mm_reduce_round_ss (s1.x, s2.x, IMM, _MM_FROUND_TO_NEAREST_INT

[Bug fortran/101565] ICE in gfc_simplify_image_index, at fortran/simplify.c:8234

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 27bf3a7eafe..e0162f16348 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -5970,6 +5970,13 @@ gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub)
   return false;
 }

+  if (sub->ts.type != BT_INTEGER)
+{
+  gfc_error ("Type of %s argument of IMAGE_INDEX at %L shall be INTEGER",
+gfc_current_intrinsic_arg[1]->name, >where);
+  return false;
+}
+
   if (gfc_array_size (sub, ))
 {
   int corank = gfc_get_corank (coarray);

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Dale Weiler  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Dale Weiler from comment #2) 
> > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > question now becomes why does -fsanitize=undefined find nothing, and is the
> > return type, i.e `declval(get(t))` different in gcc compared to the other
> > compiles. I would expect similar issues in the other compilers if this is
> > returning a reference to the temporary given by the argument list of `get`
> 
> So -fsanitize=undefined adds some extra code which just happens to cause GCC
> not to optimize as much.
> 
> Try -fsanitize=address instead which enables
> -fsanitize-address-use-after-scope which should detect the problem but I see
> it does not 

I'm unsure why this would be a temporary, given:

auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(); };

This should capture all `ts...` by copy, the `f()` should reference the
captures of `this` inside the lambda (of the compiler generated structure.)

When `get` is called, the values from the lambda are returned by dereferencing
since the function is called with pointers (synthesized with `` in the
lambda). I verified this by printing `typeid(decltype(get(t))).name()`
passed to `__cxa_demangle`. There isn't any reference types, just to be sure
that's not some runtime quirk, the compile-time result of `std::is_same_v)>` is true.

Where is the temporary happening?

[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by William Schmidt :

https://gcc.gnu.org/g:133aa7e54f77fdc15c311ecb52decfb3f52e179c

commit r12-2451-g133aa7e54f77fdc15c311ecb52decfb3f52e179c
Author: Bill Schmidt 
Date:   Wed Jul 21 09:23:45 2021 -0500

rs6000: Add int128 target check to pr101129.c (PR101531)

2021-07-21  Bill Schmidt  

gcc/testsuite/
PR target/101531
* gcc.target/powerpc/pr101129.c: Adjust.

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Dale Weiler from comment #2) 
> Ah, passing `T&` here instead of T does appear to avoid the issue, the
> question now becomes why does -fsanitize=undefined find nothing, and is the
> return type, i.e `declval(get(t))` different in gcc compared to the other
> compiles. I would expect similar issues in the other compilers if this is
> returning a reference to the temporary given by the argument list of `get`

So -fsanitize=undefined adds some extra code which just happens to cause GCC
not to optimize as much.

Try -fsanitize=address instead which enables -fsanitize-address-use-after-scope
which should detect the problen but I see it does not 

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Dale Weiler  ---
(In reply to Andrew Pinski from comment #1)
>   f.0_1 = f_8(D);
>   tuple = t;
>   _11 = __ts#2;
>   tuple ={v} {CLOBBER};
> 
> 
> template
> constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }
> 
> 
> I think the above function (get) is broken and is returning a reference to
> the argument and that would be invalid.

Ah, passing `T&` here instead of T does appear to avoid the issue, the question
now becomes why does -fsanitize=undefined find nothing, and is the return type,
i.e `declval(get(t))` different in gcc compared to the other compiles. I
would expect similar issues in the other compilers if this is returning a
reference to the temporary given by the argument list of `get`

[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call

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

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

--- Comment #1 from Andrew Pinski  ---
  f.0_1 = f_8(D);
  tuple = t;
  _11 = __ts#2;
  tuple ={v} {CLOBBER};


template
constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }


I think the above function (get) is broken and is returning a reference to the
argument and that would be invalid.

[Bug tree-optimization/101494] [11 Regression] -Wmaybe-uninitialized false alarm with memrchr of size 0

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|-Wmaybe-uninitialized false |[11 Regression]
   |alarm with memrchr of size  |-Wmaybe-uninitialized false
   |0   |alarm with memrchr of size
   ||0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||11.1.0

--- Comment #3 from Martin Sebor  ---
It is a regression but only because GCC 10 doesn't check accesses to allocated
storage to see if it's initialized.

[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

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

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

--- Comment #2 from Andrew Pinski  ---
669 /* Insert WIDTH bits from Y into X starting at START.  */
670 wide_int
671 wi::insert (const wide_int , const wide_int , unsigned int start,
672 unsigned int width)
673 {
674   wide_int result;
675   wide_int mask;
676   wide_int tmp;
(gdb) p precision
$11 = 8
(gdb) p width
$12 = 16

[Bug c++/101566] New: gcc miscompiles lambda used as tuple-like object applied to function for call

[weilercdale at gmail dot com via Gcc-bugs]

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

Bug ID: 101566
   Summary: gcc miscompiles lambda used as tuple-like object
applied to function for call
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weilercdale at gmail dot com
  Target Milestone: ---

Created attachment 51191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51191=edit
minimized test case

The following code uses a compiler generated structure via a lambda and `[=]`
capture-list to create a "tuple"-like object, `get` is implemented in terms
of the gcc provided intrinsic `__integer_pack(N)` to emulate
`std::index_sequence` for peeling off the value from the "tuple"-like object.
`apply` calls any callable by applying `get<>` to each value in the
"tuple"-like object. `PackCount` exposes the parameter pack count of the
"tuple"-like object created with `make`, A `decltype` of the lambda is used to
create a new struct `Lambda` that inherits both, making
`PackCount::ELEMENTS` available as a compile-time constant to each
created "tuple"-like object. A `Tuple` type is provided by taking the
`decltype` of `make` synthesizing values for the call with `declval`. The code
compiles in gcc, msvc, and clang but only works in the latter two compilers,
gcc appears to miscompile the code under -O3. When compiling in gcc with
-fsanitize=undefined, the code isn't miscompiled, and it runs fine. Under other
optimization levels the code isn't miscompiled either. This appears to affect
multiple versions of gcc including 10.1, 10.2, 10.3, 11.1.0, 11.1.1, and
current trunk as can be verified on compiler explorer here
https://godbolt.org/z/3sYnrj6nW

[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

2837  wide_int o = wi::insert (rtx_mode_t (outer, temp_mode),
2838   rtx_mode_t (inner, dest_mode),
2839   offset, width);
2840
2841  combine_merges++;
2842  subst_insn = i3;
2843  subst_low_luid = DF_INSN_LUID (i2);
(gdb) p outer
$1 = (rtx) 0x76b32490
(gdb) p debug_rtx(outer)
(const_int 0 [0])
$2 = void
(gdb) p debug_rtx(inner)
(const_int 256 [0x100])
$3 = void
(gdb) p offset
$4 = 0
(gdb) p mode
No symbol "mode" in current context.
(gdb) p width
$5 = 16
(gdb) p temp_mode
$6 = QImode
(gdb) p dest_mode
$7 = HImode

[Bug tree-optimization/101494] -Wmaybe-uninitialized false alarm with memrchr of size 0

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-21
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  I think this exposes two underlying bugs: one that the
initialization isn't detected and another that the second argument to attribute
access isn't respected.  A slightly enhanced test case:

$ cat b.c && gcc -O2 -S -Wall b.c
__attribute__ ((access (read_only, 1, 2))) void f (const void*, int);

void g (void)
{
  char *p = __builtin_alloca (1);
  *p = 0;
  f (p, 0);// bogus -Wmaybe-uninitialized
}

void h (void)
{
  char *p = __builtin_malloc (1);
  f (p, 0);// bogus -Wmaybe-uninitialized
}

b.c: In function ‘g’:
b.c:7:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
7 |   f (p, 0);// bogus -Wmaybe-uninitialized
  |   ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
  | ^
b.c: In function ‘h’:
b.c:13:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
   13 |   f (p, 0);// bogus -Wmaybe-uninitialized
  |   ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
  | ^

Re: [PATCH, Fortran] [PR libfortran/101317] Bind(c): Improve error checking in CFI_* functions

[Sandra Loosemore]

On 7/21/21 11:26 AM, Tobias Burnus wrote:

On 17.07.21 02:49, Sandra Loosemore wrote:

This patch is for PR101317, one of the bugs uncovered by the TS29113 
testsuite.  Here I'd observed that CFI_establish, etc was not 
diagnosing some invalid-argument situations documented in the 
standard, although it was properly catching others.  After fixing 
those I discovered a couple small mistakes in the test cases and fixed 
those too.


Some first comments – I think I have to read though the file 
ISO_Fortran_binding.c itself and not only your patch.



--- a/libgfortran/runtime/ISO_Fortran_binding.c
+++ b/libgfortran/runtime/ISO_Fortran_binding.c
@@ -232,7 +232,16 @@ CFI_allocate (CFI_cdesc_t *dv, const CFI_index_t 
lower_bounds[],

    /* If the type is a Fortran character type, the descriptor's element
   length is replaced by the elem_len argument. */
    if (dv->type == CFI_type_char || dv->type == CFI_type_ucs4_char)
-    dv->elem_len = elem_len;
+    {
+  if (unlikely (compile_options.bounds_check) && elem_len == 0)
+    {
+  fprintf ("CFI_allocate: The supplied elem_len must be "
+   "greater than zero (elem_len = %d).\n",
+   (int) elem_len);


I think there is no need to use '(elem_len = %d)' given that it is 
always zero as stated in the error message itself.


Yeah, I could fix this.  I'd initially forgotten that elem_len was an 
unsigned type and was trying to test it by passing a negative value.  :-P




(Appears twice)

However, the check itself is also wrong – cf. below.


Hmmm.  CFI_establish explicitly says that the elem_len has to be greater 
than zero.  It seems somewhat confusing that it's inconsistent with the 
other functions that take an elem_len argument.



Talking about CFI_allocatable, there is also another bug in that function,
untouched by your patch:

  /* If the type is a character, the descriptor's element length is 
replaced

  by the elem_len argument. */
   if (dv->type == CFI_type_char || dv->type == CFI_type_ucs4_char ||
   dv->type == CFI_type_signed_char)
     dv->elem_len = elem_len;

The bug is that CFI_type_signed_char is not a character type.


Ha!  I noticed the same thing and already posted a separate patch for 
that.  :-P


https://gcc.gnu.org/pipermail/fortran/2021-July/056243.html


+  else if (unlikely (compile_options.bounds_check)
+   && type < 0)

Pointless line break.

+  fprintf (stderr, "CFI_establish: Extents must be nonnegative "
+   "(extents[%d] = %d).\n", i, (int)extents[i]);
+  return CFI_INVALID_EXTENT;
+    }


How about PRIiPTR + ptrdiff_t instead of %d + (int) cast? At least as 
positive value, extent may exceed INT_MAX.


Hmmm, there are similar problems in existing code in other functions in 
this file (e.g., CFI_section).



+  if (source->attribute == CFI_attribute_other
+  && source->rank > 0
+  && source->dim[source->rank - 1].extent == -1)
+    {
+  fprintf (stderr, "CFI_setpointer: The source is a "
+   "nonallocatable nonpointer object that is an "
+   "assumed-size array.\n");


I think you could just check for assumed rank – without 
CFI_attribute_other in the 'if' and 'nonallocatable nonpointer' in the 
error message. Only nonallocatable nonpointer variables can be of 
assumed size (in Fortran); I think that makes the message simpler 
(focusing on the issue) and if the C user passes an allocatable/pointer, 
which is assumed rank, it is also a bug.


The wording of the message reflects the language of the standard:
"source shall be a null pointer or the address of a C descriptor for an 
allocated allocatable object, a data pointer object, or a nonallocatable 
nonpointer data object that is not an assumed-size array.


-Sandra

Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.

[Hafiz Abid Qadeer]

On 19/07/2021 17:41, Richard Biener wrote:
> On July 19, 2021 6:13:40 PM GMT+02:00, Hafiz Abid Qadeer 
>  wrote:
>> On 19/07/2021 11:45, Richard Biener wrote:
>>> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
>>>  wrote:

 On 15/07/2021 13:09, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
>  wrote:
>>
>> On 15/07/2021 11:33, Thomas Schwinge wrote:
>>>
 Note that the "parent" should be abstract but I don't think
>> dwarf has a
 way to express a fully abstract parent of a concrete instance
>> child - or
 at least how GCC expresses this causes consumers to
>> "misinterpret"
 that.  I wonder if adding a DW_AT_declaration to the late DWARF
 emitted "parent" would fix things as well here?
>>>
>>> (I suppose not, Abid?)
>>>
>>
>> Yes, adding DW_AT_declaration does not fix the problem.
>
> Does emitting
>
> DW_TAG_compile_unit
>   DW_AT_name("")
>
>   DW_TAG_subprogram // notional parent function (foo) with no code
>> range
> DW_AT_declaration 1
> a:DW_TAG_subprogram // offload function foo._omp_fn.0
>   DW_AT_declaration 1
>
>   DW_TAG_subprogram // offload function
>   DW_AT_abstract_origin a
> ...
>
> do the trick?  The following would do this, flattening function
>> definitions
> for the concrete copies:
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 82783c4968b..a9c8bc43e88 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -6076,6 +6076,11 @@ maybe_create_die_with_external_ref (tree
>> decl)
>/* Peel types in the context stack.  */
>while (ctx && TYPE_P (ctx))
>  ctx = TYPE_CONTEXT (ctx);
> +  /* For functions peel the context up to namespace/TU scope.  The
>> abstract
> + copies reveal the true nesting.  */
> +  if (TREE_CODE (decl) == FUNCTION_DECL)
> +while (ctx && TREE_CODE (ctx) == FUNCTION_DECL)
> +  ctx = DECL_CONTEXT (ctx);
>/* Likewise namespaces in case we do not want to emit DIEs for
>> them.  */
>if (debug_info_level <= DINFO_LEVEL_TERSE)
>  while (ctx && TREE_CODE (ctx) == NAMESPACE_DECL)
> @@ -6099,8 +6104,7 @@ maybe_create_die_with_external_ref (tree
>> decl)
> /* Leave function local entities parent determination to
>> when
>we process scope vars.  */
> ;
> -  else
> -   parent = lookup_decl_die (ctx);
> +  parent = lookup_decl_die (ctx);
>  }
>else
>  /* In some cases the FEs fail to set DECL_CONTEXT properly.
>

 Thanks. This solves the problem. Only the first hunk was required.
>> Second hunk
 actually causes an ICE when TREE_CODE (ctx) == BLOCK.
 OK to commit the attached patch?
>>>
>>> I think we need to merge the TYPE_P peeling and FUNCTION_DECL peeling
>> into
>>> one loop since I suppose we can have a nested function in class
>> scope.
>>> So sth like
>>>
>>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>>> index 82783c4968b..61228410b51 100644
>>> --- a/gcc/dwarf2out.c
>>> +++ b/gcc/dwarf2out.c
>>> @@ -6073,8 +6073,12 @@ maybe_create_die_with_external_ref (tree decl)
>>>  }
>>>else
>>>  ctx = DECL_CONTEXT (decl);
>>> -  /* Peel types in the context stack.  */
>>> -  while (ctx && TYPE_P (ctx))
>>> +  /* Peel types in the context stack.  For functions peel the
>> context up
>>> + to namespace/TU scope.  The abstract copies reveal the true
>> nesting.  */
>>> +  while (ctx
>>> +&& (TYPE_P (ctx)
>>> +|| (TREE_CODE (decl) == FUNCTION_DECL
>>> +&& TREE_CODE (ctx) == FUNCTION_DECL)))
>>>  ctx = TYPE_CONTEXT (ctx);
>>>/* Likewise namespaces in case we do not want to emit DIEs for
>> them.  */
>>>if (debug_info_level <= DINFO_LEVEL_TERSE)
>>>
>> This causes an ICE,
>> internal compiler error: tree check: expected class 'type', have
>> 'declaration' (function_decl)
>>
>> Did you intend something like this:
>>
>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>> index 561f8b23517..c61f0041fba 100644
>> --- a/gcc/dwarf2out.c
>> +++ b/gcc/dwarf2out.c
>> @@ -6121,3 +6121,8 @@ maybe_create_die_with_external_ref (tree decl)
>> -  /* Peel types in the context stack.  */
>> -  while (ctx && TYPE_P (ctx))
>> -ctx = TYPE_CONTEXT (ctx);
>> +  /* Peel types in the context stack.  For functions peel the context
>> up
>> + to namespace/TU scope.  The abstract copies reveal the true
>> nesting.  */
>> +  while (ctx
>> +   && (TYPE_P (ctx)
>> +   || (TREE_CODE (decl) == FUNCTION_DECL
>> +   && TREE_CODE (ctx) == FUNCTION_DECL)))
>> +ctx = TYPE_P (ctx) ? TYPE_CONTEXT (ctx) : DECL_CONTEXT (ctx);
>> +
> 
> Yes, of course. 
> 
>>
>>> if that works it's OK.  Can you run it on the gdb testsuite with
>> -flto added
>>> as well please (you need to do before/after comparison since 

[Bug fortran/101565] New: ICE in gfc_simplify_image_index, at fortran/simplify.c:8234

[gscfq--- via Gcc-bugs]

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

Bug ID: 101565
   Summary: ICE in gfc_simplify_image_index, at
fortran/simplify.c:8234
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Non-integer array SUB affects versions down to at least r5 :
(z4 with a misleading error)


$ cat z1.f90
program p
   integer :: x[*]
   print *, image_index(x, [1.0])
end


$ cat z2.f90
program p
   integer :: x[*]
   print *, image_index(x, [.true.])
end


$ cat z3.f90
program p
   type t
  integer :: a
   end type
   integer :: x[*]
   print *, image_index(x, [t(1)])
end


$ cat z4.f90
program p
   integer :: x[*]
   print *, image_index(x, ['1'])
end


$ gfortran-12-20210718 -c z4.f90 -fcoarray=lib
z4.f90:3:24:

3 |print *, image_index(x, ['1'])
  |1
Error: Out of bounds in IMAGE_INDEX at (1) for dimension 1, SUB has 0 and
COARRAY lower bound is 1)


$ gfortran-12-20210718 -c z1.f90 -fcoarray=lib
f951: internal compiler error: Segmentation fault
0xe3985f crash_signal
../../gcc/toplev.c:328
0x7d59d2 gfc_simplify_image_index(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:8234
0x753f73 do_simplify
../../gcc/fortran/intrinsic.c:4664
0x75e99a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:5050
0x7af8b9 resolve_unknown_f
../../gcc/fortran/resolve.c:2926
0x7af8b9 resolve_function
../../gcc/fortran/resolve.c:3270
0x7af8b9 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7104
0x7b5cf4 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7071
0x7b5cf4 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11832
0x7b463f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10851
0x7b4a08 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11822
0x7b7317 resolve_codes
../../gcc/fortran/resolve.c:17427
0x7b73de gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17462
0x79f924 resolve_all_program_units
../../gcc/fortran/parse.c:6403
0x79f924 gfc_parse_file()
../../gcc/fortran/parse.c:6655
0x7ecf1f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/101564] New: ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[gscfq--- via Gcc-bugs]

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

Bug ID: 101564
   Summary: ICE in resolve_allocate_deallocate, at
fortran/resolve.c:8169
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Since r9, backtrace when configured with --enable-checking=yes :


$ cat z1.f90
program p
   integer, allocatable :: x(:)
   integer :: stat
   allocate (x(2), stat=stat)
   deallocate (x, stat=stat%kind)
end


$ cat z2.f90
program p
   integer, allocatable :: x[:]
   integer :: stat
   allocate (x[*], stat=stat)
   deallocate (x, stat=stat%kind)
end


$ gfortran-12-20210718 -c z1.f90
z1.f90:5:32:

5 |deallocate (x, stat=stat%kind)
  |1
Error: Non-variable expression in variable definition context (STAT variable)
at (1)
f951: internal compiler error: Segmentation fault
0xe3985f crash_signal
../../gcc/toplev.c:328
0x7b3170 resolve_allocate_deallocate
../../gcc/fortran/resolve.c:8169
0x7b67b2 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:12118
0x7b7317 resolve_codes
../../gcc/fortran/resolve.c:17427
0x7b73de gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17462
0x79f924 resolve_all_program_units
../../gcc/fortran/parse.c:6403
0x79f924 gfc_parse_file()
../../gcc/fortran/parse.c:6655
0x7ecf1f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug c++/101563] New: ICE in lookup_template_class_1, at cp/pt.c:10184

[gscfq--- via Gcc-bugs]

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

Bug ID: 101563
   Summary: ICE in lookup_template_class_1, at cp/pt.c:10184
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(in addition to g++.dg/template/mem-spec1.C)


$ cat z1.cc
namespace N {
  template struct A
  {
template struct B {};
A() { B b; }
  };
  template<> template
  struct A::B
  {
~B() {}
  };
  A x;
  A::B y;
}


$ g++-12-20210718 -c z1.cc
z1.cc: In instantiation of 'N::A<  >::A() [with
 = int]':
z1.cc:12:10:   required from here
z1.cc:5:18: internal compiler error: in lookup_template_class_1, at
cp/pt.c:10184
5 | A() { B b; }
  |  ^
0x98a861 lookup_template_class_1
../../gcc/cp/pt.c:10184
0x98a861 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10230
0x98b14d tsubst_aggr_type
../../gcc/cp/pt.c:13577
0x9753d7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15450
0x98cb91 tsubst_decl
../../gcc/cp/pt.c:14747
0x9755bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15369
0x998171 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18236
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x993b75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18120
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x979d49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18106
0x979d49 instantiate_body
../../gcc/cp/pt.c:25869
0x97b477 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26162
0x9bd42b instantiate_pending_templates(int)
../../gcc/cp/pt.c:26241
0x82cac1 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4991

[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
  Component|c   |rtl-optimization

[Bug c/101562] New: [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682

[gscfq--- via Gcc-bugs]

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

Bug ID: 101562
   Summary: [9/10/11/12 Regression] ICE in insert, at
wide-int.cc:682
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7, at -O2+ :

(gcc here configured with --enable-checking=yes)
(helpful warning with -O2 -Wall, but not with -O1 -Wall)
(-> array subscript is above array bounds)


$ cat z1.c
struct S { char c; };
void g (struct S a, struct S b);
void f ()
{
  struct S x[1];
  x[0].c = 0;
  x[1].c = 1;
  g (x[0], x[1]);
  return;
}


$ gcc-6 -c z1.c -O2
$ gcc-12-20210718 -c z1.c -O1
$
$ gcc-12-20210718 -c z1.c -O2
during RTL pass: combine
z1.c: In function 'f':
z1.c:10:1: internal compiler error: in insert, at wide-int.cc:682
   10 | }
  | ^
0x11ad9c1 wi::insert(generic_wide_int const&,
generic_wide_int const&, unsigned int, unsigned int)
../../gcc/wide-int.cc:682
0x17f6c2e try_combine
../../gcc/combine.c:2839
0x17f9860 combine_instructions
../../gcc/combine.c:1269
0x17f9860 rest_of_handle_combine
../../gcc/combine.c:14873
0x17f9860 execute
../../gcc/combine.c:14918

Re: [PATCH 22/55] rs6000: Write static initializations for overload tables

[Segher Boessenkool]

On Thu, Jun 17, 2021 at 10:19:06AM -0500, Bill Schmidt wrote:
> 2021-06-07  Bill Schmidt  
> 
> gcc/
>   * config/rs6000/rs6000-gen-builtins.c (write_ovld_static_init): New
>   function.
>   (write_init_file): Call write_ovld_static_init.

Okay for trunk.  Thanks!


Segher

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #275 from dave.anglin at bell dot net ---
On 2021-07-21 12:55 p.m., me at larbob dot org wrote:
> Here's `disas $pc-256,$pc+256`'s output.
Maybe r47 contains garbage.

Re: [PATCH, Fortran] [PR libfortran/101317] Bind(c): Improve error checking in CFI_* functions

[Tobias Burnus]

On 17.07.21 02:49, Sandra Loosemore wrote:


This patch is for PR101317, one of the bugs uncovered by the TS29113
testsuite.  Here I'd observed that CFI_establish, etc was not
diagnosing some invalid-argument situations documented in the
standard, although it was properly catching others.  After fixing
those I discovered a couple small mistakes in the test cases and fixed
those too.


Some first comments – I think I have to read though the file
ISO_Fortran_binding.c itself and not only your patch.


--- a/libgfortran/runtime/ISO_Fortran_binding.c
+++ b/libgfortran/runtime/ISO_Fortran_binding.c
@@ -232,7 +232,16 @@ CFI_allocate (CFI_cdesc_t *dv, const CFI_index_t 
lower_bounds[],
/* If the type is a Fortran character type, the descriptor's element
   length is replaced by the elem_len argument. */
if (dv->type == CFI_type_char || dv->type == CFI_type_ucs4_char)
-dv->elem_len = elem_len;
+{
+  if (unlikely (compile_options.bounds_check) && elem_len == 0)
+ {
+   fprintf ("CFI_allocate: The supplied elem_len must be "
+"greater than zero (elem_len = %d).\n",
+(int) elem_len);


I think there is no need to use '(elem_len = %d)' given that it is always zero 
as stated in the error message itself.

(Appears twice)

However, the check itself is also wrong – cf. below.

 * * *

Talking about CFI_allocatable, there is also another bug in that function,
untouched by your patch:

 /* If the type is a character, the descriptor's element length is replaced
 by the elem_len argument. */
  if (dv->type == CFI_type_char || dv->type == CFI_type_ucs4_char ||
  dv->type == CFI_type_signed_char)
dv->elem_len = elem_len;

The bug is that CFI_type_signed_char is not a character type.


+  else if (unlikely (compile_options.bounds_check)
+&& type < 0)

Pointless line break.

+   fprintf (stderr, "CFI_establish: Extents must be nonnegative "
+"(extents[%d] = %d).\n", i, (int)extents[i]);
+   return CFI_INVALID_EXTENT;
+ }


How about PRIiPTR + ptrdiff_t instead of %d + (int) cast? At least as
positive value, extent may exceed INT_MAX.

(Twice)


if (result->type == CFI_type_char || result->type == CFI_type_ucs4_char)
-result->elem_len = elem_len;
+{
+  if (unlikely (compile_options.bounds_check) && elem_len == 0)
+ {
+   fprintf ("CFI_select_part: The supplied elem_len must be "
+"greater than zero (elem_len = %d).\n",
+(int) elem_len);


What's wrong with  ["", ""]? Or with:
  character(len=:), allocatable :: str2(:)
  str2 = [str1(5:4)]
both are len(...) == 0 arrays with 1 or 2 elements.


+   if (source->attribute == CFI_attribute_other
+   && source->rank > 0
+   && source->dim[source->rank - 1].extent == -1)
+ {
+   fprintf (stderr, "CFI_setpointer: The source is a "
+"nonallocatable nonpointer object that is an "
+"assumed-size array.\n");


I think you could just check for assumed rank – without
CFI_attribute_other in the 'if' and 'nonallocatable nonpointer' in the
error message. Only nonallocatable nonpointer variables can be of
assumed size (in Fortran); I think that makes the message simpler
(focusing on the issue) and if the C user passes an allocatable/pointer,
which is assumed rank, it is also a bug.

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

[Bug target/101561] -msse4 -mno-crc32 doesn't disable CRC32 intrinsics

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

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

H.J. Lu  changed:

   What|Removed |Added

  Known to work||12.0
   Last reconfirmed||2021-07-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
This is fixed in GCC 12 by r12-12 and r12-2440.

[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 12.  GCC 11 failed to disable CRC32 with -mno-crc32 (PR 101561).

Re: [PATCH 21/55] rs6000: Write static initializations for built-in table

[Segher Boessenkool]

Hi!

On Thu, Jun 17, 2021 at 10:19:05AM -0500, Bill Schmidt wrote:
> 2021-06-07  Bill Schmidt  
> 
> gcc/
>   * config/rs6000/rs6000-gen-builtins.c (write_bif_static_init): New
>   function.
>   (write_init_file): Call write_bif_static_init.

> +  for (int j = 0; j < 3; j++)
> + res[j] = (bifp->proto.restr_opnd[j] == 0 ? "RES_NONE"
> +   : (bifp->proto.restr[j] == RES_BITS ? "RES_BITS"
> +  : (bifp->proto.restr[j] == RES_RANGE ? "RES_RANGE"
> + : (bifp->proto.restr[j] == RES_VALUES ? "RES_VALUES"
> +: (bifp->proto.restr[j] == RES_VAR_RANGE
> +   ? "RES_VAR_RANGE" : "ERROR");

The unnecessary parens make this harder to read.

Having ? on the same line as the condition but : on another is not
normal style.

Some "if"s would be more readable anyway?


Okay for trunk.  Thanks!


Segher

[Bug target/101561] New: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics

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

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

Bug ID: 101561
   Summary: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-2 tmp]$ cat x.c
#include 

unsigned int
test_mm_crc32_u8(unsigned int CRC, unsigned char V)
{
  return _mm_crc32_u8(CRC, V);
}   
[hjl@gnu-cfl-2 tmp]$ gcc -S -O2 -msse4 -mno-crc32 x.c
[hjl@gnu-cfl-2 tmp]$