[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to SRINATH PARVATHANENI from comment #4)
> With the above patch I'm getting ICE as below while building arm-none-eabi
> target:
> 
> checking for scalbnl... during RTL pass: expand
> 
> generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc: In constructor
> 'std::locale::_Impl::_Impl(std::size_t)':
> 
> generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc:471:3: internal
> compiler error: tree check: expected bit_field_ref or mem_ref, have ssa_name
> in expand_assignment, at expr.c:5203
>   471 |   locale::_Impl::
>   |   ^~

Hmm, it looks like I cannot reproduce this,
which version did you use for that ?
what is in line 5203 of expr.c ?

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 27 Oct 2020, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
> 
> --- Comment #2 from Martin Li?ka  ---
> (In reply to Richard Biener from comment #1)
> > So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a
> > vector(16)  HImode result.  We fall into
> > 
> >   gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (cmp_op_mode))
> >   && known_eq (GET_MODE_NUNITS (mode),
> >GET_MODE_NUNITS (cmp_op_mode)));
> > 
> > then but this is clearly a case where we _have_ to use the vec_cmp_expr
> > (because of the scalar mode).  So either simply remove the
> > used_vec_cond_exprs check or amend it with the negative of the above assert.
> 
> No, used_vec_cond_exprs == 2, but we fail here:
> 
>166if (used_vec_cond_exprs >= 2
>167&& (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type))
>168!= CODE_FOR_nothing)
>169&& expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs),
> tcode))
> 
> where:
> 
> #0  get_vcond_mask_icode (vmode=E_HImode, mmode=E_V16SImode) at
> /home/marxin/Programming/gcc/gcc/optabs-query.h:131
> 
> returns false.

Hmm, but get_vcond_mask_icode expects the vector mode first and the
mask mode second.  But it would be odd if that's the mistake...
(but the patterns agree as well).

Now, the code seems to be a bit confused.  We're looking at


 op0 = op0a tcode op0b;
 lhs = op0 ? op1 : op2;

and I assume the check tries to verify we can expand both the
compare-to-mask and the vcond_mask.  Then we need to query

  tree op0_type = TREE_TYPE (op0);
  tree op0a_type = TREE_TYPE (op0a);
  if (used_vec_cond_exprs >= 2
  && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
  != CODE_FOR_nothing)
  && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{

no?  That would match

  if (TREE_CODE_CLASS (tcode) != tcc_comparison)
{
  gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0)));
  if (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
  != CODE_FOR_nothing)

Doing that shifts the ICE elsewhere though:

during GIMPLE pass: isel
x.c: In function 'calc_rows':
x.c:22:1: internal compiler error: in gimple_expand_vec_cond_expr, at 
gimple-isel.cc:204
   22 | calc_rows() {
  | ^
0x17c3bd8 gimple_expand_vec_cond_expr
/home/rguenther/src/gcc2/gcc/gimple-isel.cc:202

Now we face the situation where lhs == HImode but op0a is V16SImode
so a VEC_COND_EXPR combining masks based on a compare.  That's
a situation we didn't run into before the VEC_COND_EXPR splitting.

Which means we're missing a fallback like

  if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
  expand the comparison to a mask
  turn the VEC_COND_EXPR into a mask operation,
maskr = cmpmask ? maska : maskb;
  becomes
maskr = (maska & cmpmask) | (maskb & ~cmpmask);
}

the alternative is to add vcond_mask patterns for mask value modes
(I think vternlog can do this in one operation, there may also be
a mask operation for this).  But that would be an enhancement
and not require any new fallback code.

But first double-check the first point I made above.

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

--- Comment #1 from Richard Biener  ---
I think the main confusion is as to how we represent IPA clones in debug,
namely making them have an abstract origin to the cloned function even though
their signatures do not match.  In reality we're creating a new function
[entry] with a different signature.  I think a better representation for
a function clone would be

 <1>: Abbrev Number: 10 (DW_TAG_subprogram)
  DW_AT_artificial : 1


 <2>  DW_TAG_inlined_subroutine 

plus the parameter mapping.  Thus represent a clone as what it really is,
a new function calling the old one with appropriate parameters.

This doesn't work for the function splitting tail though (IIRC we had another
PR about that).

The question is whether we need to have any debug for the formal parameters
of clones or if it is enough to appropriately specify the
DW_TAG_inlined_subroutine (that's where users would expect breakpoints as
well).

So in the end I don't believe the current situation is "fixable" since we
cannot distinguish clones from abstract vs. concrete instances in the
DWARF itself.  And the abstract origin we have on the tree level is just
misleading.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > --- a/gcc/emit-rtl.c
> > +++ b/gcc/emit-rtl.c
> > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
> > objectp,
> > {
> >   gcc_assert (handled_component_p (t)
> >   || TREE_CODE (t) == MEM_REF
> > - || TREE_CODE (t) == TARGET_MEM_REF);
> > + || TREE_CODE (t) == TARGET_MEM_REF
> > + || TREE_CODE (t) == SSA_NAME);
> 
> Can you track down this?  It's a red herring to have a MEM_EXPR
> that just is a SSA_NAME.
> 

This happens here:

  if (MEM_P (to_rtx))
{
  /* If the field is at offset zero, we could have been given the
 DECL_RTX of the parent struct.  Don't munge it.  */
  to_rtx = shallow_copy_rtx (to_rtx);
  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
  if (volatilep)
MEM_VOLATILE_P (to_rtx) = 1;
}

since the patch allows the SSA_NAME to reach this block.


> > --- a/gcc/expr.c
> > +++ b/gcc/expr.c
> > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > nontemporal)
> >|| (TREE_CODE (to) == MEM_REF
> >   && (REF_REVERSE_STORAGE_ORDER (to)
> >   || mem_ref_refers_to_non_mem_p (to)))
> > +  || (TREE_CODE (to) == SSA_NAME
> > + && mode != BLKmode
> > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> 
> But an SSA name is a register, esp. one with non-BLKmode.  And if
> expanded to a stack location that stack location should better
> be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> 

Hmm, to avoid the ICE the SSA_NAME would need a naturally
aligned type, maybe replace it somehow in make_ssa_name_fn ...

But isn't it possible that expand_expr_real_1
returns the original unaligned decl here?

case GIMPLE_SINGLE_RHS:
  {
r = expand_expr_real (gimple_assign_rhs1 (g), target,
  tmode, modifier, alt_rtl,
  inner_reference_p);
break;
  }
default:
  gcc_unreachable ();
}
  set_curr_insn_location (saved_loc);
  if (REG_P (r) && !REG_EXPR (r))
set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
  return r;

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

--- Comment #2 from Richard Biener  ---
Implementation-wise we'd have to put a wrapping inline BLOCK in function clones
plus the appropriate inlined PARM_DECLs / debug stmts to initialize the
call parameters.  And then simply forgo with setting DECL_ABSTRACT_ORIGIN
and make the clone DECL_ARTIFICIAL.

[Bug tree-optimization/97603] Failure to optimize out compare into reuse of subtraction result

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
Well, I don't actually know enough to be able to determine which would be
optimal. Transformation to the example from the third comment would be
suboptimal on some targets (say, I don't think AVR would like this for 64-bit
numbers), while doing this as an x86 specific transformation would be missing
on an optimization opportunity on plenty of other targets.

[Bug testsuite/97611] New: FAIL: gfortran.dg/vect/pr83232.f90 with AVX, suitable target selector missing

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

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

Bug ID: 97611
   Summary: FAIL: gfortran.dg/vect/pr83232.f90 with AVX, suitable
target selector missing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We're splitting

  Einc(1) = DTnext * Dxx ! (1)
  Einc(2) = DTnext * Dyy
  Einc(3) = DTnext * Dzz
  Einc(4) = DTnext * Dxy
  Einc(5) = DTnext * Dxz
  Einc(6) = DTnext * Dyz

into 32B and 16B pieces which confuses the dump scan counting.
vect_sizes_32B_16B is

return [expr { [available_vector_sizes] == [list 256 128] }]

but x86_64 always has 64 as well so the exact match doesn't work.
For this case we'd need vect_size_32B_prefered && vect_size_16B_supported or
so.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> 
> --- Comment #6 from Bernd Edlinger  ---
> (In reply to rguent...@suse.de from comment #3)
> > On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > > --- a/gcc/emit-rtl.c
> > > +++ b/gcc/emit-rtl.c
> > > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, 
> > > int
> > > objectp,
> > > {
> > >   gcc_assert (handled_component_p (t)
> > >   || TREE_CODE (t) == MEM_REF
> > > - || TREE_CODE (t) == TARGET_MEM_REF);
> > > + || TREE_CODE (t) == TARGET_MEM_REF
> > > + || TREE_CODE (t) == SSA_NAME);
> > 
> > Can you track down this?  It's a red herring to have a MEM_EXPR
> > that just is a SSA_NAME.
> > 
> 
> This happens here:
> 
>   if (MEM_P (to_rtx))
> {
>   /* If the field is at offset zero, we could have been given the
>  DECL_RTX of the parent struct.  Don't munge it.  */
>   to_rtx = shallow_copy_rtx (to_rtx);
>   set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
>   if (volatilep)
> MEM_VOLATILE_P (to_rtx) = 1;
> }
> 
> since the patch allows the SSA_NAME to reach this block.
> 
> 
> > > --- a/gcc/expr.c
> > > +++ b/gcc/expr.c
> > > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > > nontemporal)
> > >|| (TREE_CODE (to) == MEM_REF
> > >   && (REF_REVERSE_STORAGE_ORDER (to)
> > >   || mem_ref_refers_to_non_mem_p (to)))
> > > +  || (TREE_CODE (to) == SSA_NAME
> > > + && mode != BLKmode
> > > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> > 
> > But an SSA name is a register, esp. one with non-BLKmode.  And if
> > expanded to a stack location that stack location should better
> > be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> > 
> 
> Hmm, to avoid the ICE the SSA_NAME would need a naturally
> aligned type, maybe replace it somehow in make_ssa_name_fn ...

Ah, OK - only now looked at the testcase ;)  Yes, I think for
registers we should ignore decl/type alignment and _always_
use the natural (mode) alignment.  That is,

static unsigned int
align_local_variable (tree decl, bool really_expand)
{
  unsigned int align;

  if (TREE_CODE (decl) == SSA_NAME)
align = TYPE_ALIGN (TREE_TYPE (decl));

should probably use GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (decl)))
unless it is a BLKmode var.  There's a duplicate code in
expand_one_stack_var_1, not sure why it special-cases SSA_NAMEs there.

Also, when an SSA name gets a stack location, we should instead use
the underlying decl for the MEM_EXPR, not the SSA name.

> But isn't it possible that expand_expr_real_1
> returns the original unaligned decl here?
> 
> case GIMPLE_SINGLE_RHS:
>   {
> r = expand_expr_real (gimple_assign_rhs1 (g), target,
>   tmode, modifier, alt_rtl,
>   inner_reference_p);
> break;
>   }
> default:
>   gcc_unreachable ();
> }
>   set_curr_insn_location (saved_loc);
>   if (REG_P (r) && !REG_EXPR (r))
> set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
>   return r;
> 
>

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

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

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

--- Comment #8 from SRINATH PARVATHANENI  ---
(In reply to Bernd Edlinger from comment #5)
> (In reply to SRINATH PARVATHANENI from comment #4)
> > With the above patch I'm getting ICE as below while building arm-none-eabi
> > target:
> > 
> > checking for scalbnl... during RTL pass: expand
> > 
> > generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc: In constructor
> > 'std::locale::_Impl::_Impl(std::size_t)':
> > 
> > generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc:471:3: internal
> > compiler error: tree check: expected bit_field_ref or mem_ref, have ssa_name
> > in expand_assignment, at expr.c:5203
> >   471 |   locale::_Impl::
> >   |   ^~
> 
> Hmm, it looks like I cannot reproduce this,
> which version did you use for that ?
> what is in line 5203 of expr.c ?

Sorry for confusing you by mentioned ICE, that was because of merge conflict. I
have resolved the conflict and applied the patch correctly. The build is
successful and I have tested the test reported in this Bugzilla and it is
fixed.

Thanks.

[Bug c++/97569] Declaring a struct in a field declaration of another struct. gcc and clang difference.

[anders.granlund.0 at gmail dot com via Gcc-bugs]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #4 from Anders Granlund  ---
Thanks for the explanation. I will close this bug report and report to bug to
clang instead.

[Bug fortran/97612] New: Structure constructor of type with nested allocatable array components fails to compile

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 97612
   Summary: Structure constructor of type with nested allocatable
array components fails to compile
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The program below does not compile with error message:

constructor_allocatable.F90:4:9:

4 | type :: s
  | 1
Error: The rank of the element in the structure constructor at (1) does not
match that of the component (0/1)

It is essential that x is an array, and that component u of type s has the
allocatable attribute as well. However, component u does not need to be an
array to trigger the error.


program constructor_allocatable
implicit none

type :: s
   integer, dimension(:), allocatable :: u
end type s

type :: t
   type(s), dimension(:), allocatable :: x
end type t

type(t) :: a = t()

end program constructor_allocatable

[Bug libstdc++/97613] New: chrono::year_month_weekday cast to sys_days : return bad value if index() == 0

[faithandbrave at gmail dot com via Gcc-bugs]

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

Bug ID: 97613
   Summary: chrono::year_month_weekday cast to sys_days : return
bad value if index() == 0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: faithandbrave at gmail dot com
  Target Milestone: ---

#include 
#include 

namespace chrono = std::chrono;
using namespace std::chrono_literals;

int main()
{
  // 1
  chrono::sys_days date1 = 2020y/3/chrono::Sunday[1];
  assert(chrono::year_month_day{date1} == 2020y/3/1);

  // 2
  chrono::sys_days date2 = 2020y/3/chrono::Sunday[2];
  assert(chrono::year_month_day{date2} == 2020y/3/8);

  // 3
  chrono::sys_days date3 = 2020y/3/chrono::Sunday[0];
  assert(chrono::year_month_day{date3} == 2020y/2/23);
}

Assertion failed the program's No.3 patten.
GCC 11 (trunk) returns `30297y/March/14d`. Clang (libc++) is OK.

See the specification:

> 27.8.16.2 [time.cal.ymwd.members]
> If index() is 0 the returned sys_days represents the date 7 days prior to the 
> first weekday() of year()/month().

[Bug libstdc++/97613] chrono::year_month_weekday cast to sys_days : return bad value if index() == 0

[faithandbrave at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Akira Takahashi  ---
- #include 
+ #include 

#include 
#include 

namespace chrono = std::chrono;
using namespace std::chrono_literals;

int main()
{
  chrono::sys_days date1 = 2020y/3/chrono::Sunday[1];
  assert(chrono::year_month_day{date1} == 2020y/3/1);

  chrono::sys_days date2 = 2020y/3/chrono::Sunday[2];
  assert(chrono::year_month_day{date2} == 2020y/3/8);

  chrono::sys_days date3 = 2020y/3/chrono::Sunday[0];
  assert(chrono::year_month_day{date3} == 2020y/2/23);
}

[Bug tree-optimization/97595] [11 Regression] bogus -Wstringop-overflow due to DECL_SIZE_UNIT underreporting field size

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords||wrong-debug

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mark at gcc dot gnu.org,
   ||palves at redhat dot com

--- Comment #3 from Jakub Jelinek  ---
So, let's first discuss how we want to represent these in DWARF, I've added
further folks on CC, thoughts on that?

If the function is the same rather than some clone with possibly changed
calling convention, does your reading of DWARF suggest that each
DW_TAG_subprogram should have its own DW_TAG_unspecified_parameters child, or
e.g. DW_AT_calling_convention attribute, or is that something that can be
inherited through DW_AT_abstract_origin and only overridden if different from
the abstract origin?

Then there is the question what to do with function clones, which, while can
have different arguments and calling convention, but otherwise they still
represent the whole function.

And finally, the question of just outlined regions of functions, whether it is
the outlined part of partial inlining, OpenMP/OpenACC etc. outlined regions
etc.
At least for this third set I think we really want some attribute that says
they are partial (e.g. implementations should expect their start to be the
start of the function) and with DW_AT_abstract_origin pointing to something
more useful (e.g. the DW_TAG_lexical_block they are representing?).

As for the implementation of this patch if DW_TAG_unspecified_parameters and/or
DW_AT_calling_convention aren't inherited through DW_AT_abstract_origin by
consumers, I think rather than what I'm doing in the above patch for LTO we
could immediately after old_die = lookup_die (decl); remember for in_lto_p if
old_die->die_child was NULL, that would stand for a freshly created DIE and
then could be used as if (subr_die != old_die || old_die_was_empty) to decide
whether to add DW_TAG_unspecified_parameters or not.

[Bug rtl-optimization/97603] Failure to optimize out compare into reuse of subtraction result

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization
   Last reconfirmed||2020-10-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Richard Biener  ---
I guess it could be formulated as code-hoisting opportunity when we make
a - b (or b - a) anticipated on the edges from the a != b compare.  What's
then missing is transforming

  int tem = a - b;
  if (a != b)
 ...

into

  tem = a - b;
  if (tem != 0)

but IIRC we essentially do the reverse transform via match.pd.  Here
the main issue is that the GIMPLE IL doesn't reflect what targets
usually do, that is, flags registers are not modeled and instead we
branch on the actual compare rather than its outcome and a subtract
doesn't set flags.

Eventually this is sth for RTL if-conversion though where those details
are exposed.

[Bug lto/96680] [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r11-4468-gf165ef89c08ddabb19583e45e8a6819f810d95ab
Author: Jakub Jelinek 
Date:   Wed Oct 28 10:28:18 2020 +0100

lto: LTO cgraph support for late declare variant resolution [PR96680]

> I've tried to add the saving/restoring next to ipa refs saving/restoring,
as
> the declare variant alt stuff is kind of extension of those,
unfortunately
> following doesn't compile, because I need to also write or read a tree
there
> (ctx is a portion of DECL_ATTRIBUTES of the base function), but the ipa
refs
> write/read back functions don't have arguments that can be used for that.

This patch adds the streaming out and in of those omp_declare_variant_alt
hash table on the side data for the declare_variant_alt cgraph_nodes and
treats for LTO purposes the declare_variant_alt nodes (which have no body)
as if they contained a body that calls all the possible variants.
After IPA all the calls to these magic declare_variant_alt calls are
replaced with call to one of the variant depending on which one has the
highest score in the context.

2020-10-28  Jakub Jelinek  

PR lto/96680
gcc/
* lto-streamer.h (omp_lto_output_declare_variant_alt,
omp_lto_input_declare_variant_alt): Declare variant.
* symtab.c (symtab_node::get_partitioning_class): Return
SYMBOL_DUPLICATE for declare_variant_alt nodes.
* passes.c (ipa_write_summaries): Add declare_variant_alt to
partition.
* lto-cgraph.c (output_refs): Call
omp_lto_output_declare_variant_alt
on declare_variant_alt nodes.
(input_refs): Call omp_lto_input_declare_variant_alt on
declare_variant_alt nodes.
* lto-streamer-out.c (output_function): Don't call
collect_block_tree_leafs if DECL_INITIAL is error_mark_node.
(lto_output): Call output_function even for declare_variant_alt
nodes.
* omp-general.c (omp_lto_output_declare_variant_alt,
omp_lto_input_declare_variant_alt): New functions.
gcc/lto/
* lto-common.c (lto_fixup_prevailing_decls): Don't use
LTO_NO_PREVAIL on TREE_LIST's TREE_PURPOSE.
* lto-partition.c (lto_balanced_map): Treat declare_variant_alt
nodes like definitions.
libgomp/
* testsuite/libgomp.c/declare-variant-1.c: New test.

[Bug testsuite/81690] libgomp.c/{target-32,thread-limit-2}.c fail for nvptx: missing usleep

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3f39b64e57ab8e8f69a017e4bd20aa6dd2aec492

commit r11-4469-g3f39b64e57ab8e8f69a017e4bd20aa6dd2aec492
Author: Jakub Jelinek 
Date:   Wed Oct 28 10:30:41 2020 +0100

xfail and improve some failing libgomp tests [PR81690]

With the patch I've posted today to fix up declare variant LTO handling,
Tobias reported the patch still doesn't work, and there are two
reasons for that.
One is that when the base function is marked implicitly as declare target,
we don't mark also implicitly the variants.  I'll need to ask on omp-lang
about details for that, but generally the compiler should do it some way.
The other one is that the way base_delay is written, it will always
call the usleep function, which is undesirable for nvptx.  While the
compiler will replace all direct calls to base_delay to nvptx_delay,
the base_delay definition which calls usleep stays.

2020-10-28  Jakub Jelinek  
Tom de Vries  

PR testsuite/81690
* testsuite/libgomp.c/usleep.h: New file.
* testsuite/libgomp.c/target-32.c: Include usleep.h.
(main): Use tgt_usleep instead of usleep.
* testsuite/libgomp.c/thread-limit-2.c: Include usleep.h.
(main): Use tgt_usleep instead of usleep.

[Bug tree-optimization/97081] [8/9/10 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-8948-gca84557f3024c75ede850007099ec9b2c19e9f8a
Author: Richard Biener 
Date:   Fri Sep 18 13:36:24 2020 +0200

tree-optimization/97081 - fix wrong-code with vectorized shift

This corrects the mask for creation of x << s | x >> (-x & mask)
from a rotate x <

PR tree-optimization/97081
* tree-vect-patterns.c (vect_recog_rotate_pattern): Use the
precision of the shifted operand to determine the mask.

* gcc.dg/vect/pr97081.c: New testcase.

(cherry picked from commit 9c9b88fdcff3520b2c4fb520c5d3b422eaa9a72f)

[Bug tree-optimization/97081] [8/9/10 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-8949-ga78cd759754c92cecbf235ac9b447dcdff6c6e2f
Author: Jakub Jelinek 
Date:   Fri Sep 18 15:05:53 2020 +0200

testsuite: add another test for the rotate vectorization miscompilation

This time with short and char where the used mask used to be larger
than it should have been.

2020-09-18  Jakub Jelinek  

PR tree-optimization/97081
* gcc.dg/vect/pr97081-2.c: New test.

(cherry picked from commit 3d3fe967b0961cb59f5df03ae2a55d83dc4bbd34)

[Bug tree-optimization/97605] unused conditionally freed allocation not eliminated

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  This is partial dead code elimination which we do not perform.
You can think of partial dead code elimination as sinking & duplicating code
to N places where dataflow determines that in M < N places the sunk code
is dead (it's usually done for stores, but calls work as well of course).
For malloc/free pairs it actually requires eliding the whole pair while
classically for stores only the sunk store is.  Thus

int g;
void f (int i)
{
  g = 1;
  if (i)
g = 2;
}

becomes

int g;
void f (int i)
{
  if (i)
g = 2;
  else
g = 1;
}

in your case you'd sink the malloc and elide the malloc/free pair.
It might be tempting to implement this in two-steps and only do the
sinking, relying on followup DCE/DSE but that will likely run into
cases where we just ended up duplicating code.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #11 from Richard Biener  ---
*** Bug 97606 has been marked as a duplicate of this bug. ***

[Bug target/97606] internal compiler error: in extract_constrain_insn, at recog.c:2196

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Richard Biener  ---
dup then

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

[Bug rtl-optimization/97607] Spurious sign extension

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||x86_64-linux
   Last reconfirmed||2020-10-28
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
This is the TARGET_PROMOTE_PROTOTYPES target hook at play, directing the FEs to
emit the sign-extension and RTL expansion failing to elide it.  Note the
x86 ABI does _not_ specify the incoming argument is sign-extended so it only
works for functions where all calls are generated by GCC.

IMHO TARGET_PROMOTE_PROTOTYPES should go away.

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   Priority|P3  |P1
   Target Milestone|--- |11.0

[Bug analyzer/97614] New: MinGW-w64 pointer to long conversion loses precision error

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 97614
   Summary: MinGW-w64 pointer to long conversion loses precision
error
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

When compiling GCC 11-20201025 with MinGW-w64 I got the following error:
../../gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc/analyzer/store.h:272:41: error: cast from 'const ana::region*' to
'long int' loses precision [-fpermissive]
  272 | return (binding_key::impl_hash () ^ (long)m_region);
  | ^~

This is typically caused by the false assumption that pointer and long have the
same size, which is not true on Windows/MinGW.

Usually the solution is to cast to something like intptr_t instead of long.

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

--- Comment #4 from Jakub Jelinek  ---
Another version of the patch:
--- gcc/dwarf2out.c.jj  2020-10-27 18:38:00.001979404 +0100
+++ gcc/dwarf2out.c 2020-10-28 10:52:29.618796758 +0100
@@ -22756,6 +22756,7 @@ gen_subprogram_die (tree decl, dw_die_re
   tree origin = decl_ultimate_origin (decl);
   dw_die_ref subr_die;
   dw_die_ref old_die = lookup_decl_die (decl);
+  bool old_die_had_no_children = false;

   /* This function gets called multiple times for different stages of
  the debug process.  For example, for func() in this code:
@@ -22846,6 +22847,9 @@ gen_subprogram_die (tree decl, dw_die_re
   if (old_die && declaration)
 return;

+  if (in_lto_p && old_die && old_die->die_child == NULL)
+old_die_had_no_children = true;
+
   /* Now that the C++ front end lazily declares artificial member fns, we
  might need to retrofit the declaration into its class.  */
   if (!declaration && !origin && !old_die
@@ -23365,6 +23369,10 @@ gen_subprogram_die (tree decl, dw_die_re
  else if (DECL_INITIAL (decl) == NULL_TREE)
gen_unspecified_parameters_die (decl, subr_die);
}
+  else if ((subr_die != old_die || old_die_had_no_children)
+  && prototype_p (TREE_TYPE (decl))
+  && stdarg_p (TREE_TYPE (decl)))
+   gen_unspecified_parameters_die (decl, subr_die);
 }

   if (subr_die != old_die)

[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Adding Alex for debug-stmt / inline-entry etc. issues.

Note that clones are materialized only during LTRANS where for example we
have no way of generating "nice" DWARF for a clone of a C++ class method.
What we _can_ do is create DWARF for an aritificial wrapper function
whose body contains an inline copy of said C++ class method (plus required
argument marshalling).

User (dwarf consumer) expectation is another issue, breakpoints on a
function should work and also break on clones.

User expectation for OMP outlines is less clear to me.

For split functions we shouldn't get two breakpoints (inlined header
plus tail) but only break on the header.  Ideally the frame of the
tail wouldn't even be visible...  Note that we do not necessarily
outline full scopes in the splitting case, so even abstract origins
to scopes might not be a good match there.  Maybe don't try to represent
the call to the tail as call but handle it as a jump like hot/cold
parts of a function (though technically there is a frame).

[Bug tree-optimization/97615] New: [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

Bug ID: 97615
   Summary: [11 Regression] -O3 on -Wsequence-point-unclean code
ICEs: during GIMPLE pass: slp: internal compiler
error: in vectorizable_live_operation, at
tree-vect-loop.c:8497
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

The ICE initially observed on dolphin-emu code base. cvise reduced it down to
the following example:

  $ cat bug.cpp
  // g++-11.0.0 -O3 -std=c++17 -c bug.cpp -o bug.o -Wall
  short *a;
  void b(int c, int d) {
*a++ = *a++ = c;
*a++ = d;
  }
  int e, f;
  void g() {
b(e + f - 2, e + f - 1);
b(e + f - 1, 0);
  }

gcc crashes as:

$ LANG=C g++-11.0.0 -O3 -c bug.cpp -o bug.o -Wall
bug.cpp: In function 'void b(int, int)':
bug.cpp:4:5: warning: operation on 'a' may be undefined [-Wsequence-point]
4 |   *a++ = *a++ = c;
  |~^~
during GIMPLE pass: slp
bug.cpp: In function 'void g()':
bug.cpp:8:6: internal compiler error: in vectorizable_live_operation, at
tree-vect-loop.c:8497
8 | void g() {
  |  ^
0x60f1cb vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-loop.c:8497
0xe82bd7 can_vectorize_live_stmts
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-stmts.c:10529
0xea4f58 vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-stmts.c:10913
0xed1611 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:5360
0xedd1cf vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:5495
0xedd8fc vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:5624
0xeded4b vect_slp_region
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:4232
0xeded4b vect_slp_bbs
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:4350
0xedfb3c vect_slp_function(function*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vect-slp.c:4418
0xee1923 execute
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/tree-vectorizer.c:1437

[Bug tree-optimization/97615] [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Same testcase rewritten to be -Wsequence-point clean:
short *a;
int e, f;

void
foo (int c, int d)
{
  short *a1, *a2, *a3;
  a1 = a;
  a = a1 + 1;
  *a1 = c;
  a2 = a;
  a = a2 + 1;
  *a2 = *a1;
  a3 = a;
  a = a3 + 1;
  *a3 = d;
}

void
bar ()
{
  foo (e + f - 2, e + f - 1);
  foo (e + f - 1, 0);
}

[Bug tree-optimization/97616] New: [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428

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

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

Bug ID: 97616
   Summary: [11 regression] bb-slp-58.c and bb-slp-59.c fail on
arm after r11-4428
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r11-4428 (g:4a369d199bf2f34e037030b18d0da923e8a24997) I have noticed
regressions on arm:

FAIL: gcc.dg/vect/bb-slp-58.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-58.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1 "transform load" 2
FAIL: gcc.dg/vect/bb-slp-58.c scan-tree-dump-times slp1 "optimized: basic
block" 1
FAIL: gcc.dg/vect/bb-slp-58.c scan-tree-dump-times slp1 "transform load" 2
FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects  scan-tree-dump-times
loopdone "VEC_PERM_EXPR" 1
FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1 "transform load" 2
FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times loopdone "VEC_PERM_EXPR" 1
FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times slp1 "optimized: basic
block" 1
FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times slp1 "transform load" 2


The expected patterns are found 0 times.

[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428

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

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

Christophe Lyon  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/97615] [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

--- Comment #2 from Jakub Jelinek  ---
And slightly simplified; still ICEs with -O3:

short *a;
int e, f;

void
foo (int c, int d)
{
  short *a1, *a2, *a3;
  a1 = a++;
  *a1 = c;
  a2 = a++;
  *a2 = *a1;
  a3 = a++;
  *a3 = d;
}

void
bar (void)
{
  foo (e + f - 2, e + f - 1);
  foo (e + f - 1, 0);
}

[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428

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

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

--- Comment #1 from Christophe Lyon  ---
Actually these are not regressions, but new failures since the tests were just
added.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:31643fa3e994749bd2da7b35846f1958f8823b8d

commit r11-4472-g31643fa3e994749bd2da7b35846f1958f8823b8d
Author: Alexandre Oliva 
Date:   Wed Oct 28 07:54:33 2020 -0300

[PR97504] riscv needs wraplf for aux_long_long_float too

riscv is another platform on which GNAT maps Long_Long_Float to double
rather than long double, so we have to explicitly avoid the long
double intrinsics.


for  gcc/ada/ChangeLog

PR ada/97504
* Makefile.rtl (LIBGNAT_TARGET_PAIRS> : Use wraplf
version of Aux_Long_Long_Float.

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-28
 CC||amacleod at redhat dot com

--- Comment #1 from Aldy Hernandez  ---
confirmed

[Bug middle-end/97617] New: missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 97617
   Summary: missing aggressive loop optimization warning in C++
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49458&action=edit
testcase

Following testcase produces a compile warning in C, but not C++.

 error: iteration 16 invokes undefined behavior
[-Werror=aggressive-loop-optimizations]

The warning *is* shown when the printf call is removed. (C++)
When compiled as C the warning is always shown.

GCC 10.2, x86_64-linux-gnu

[Bug rtl-optimization/97497] gcse wrong code generation with partial register clobbers

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-28
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Thanks for the s390 fix.  On second thoughts, I guess it would
be easier to keep this bug open for the general problem, since
it has all the info.

Hope to get to this early in stage 3.

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The warning is documented to be done only for loops that don't have multiple
exits (because otherwise it would have too many false positives; when the loop
isn't guaranteed to loop 16 times, there might not be an UB).
As printf is a possible cancellation point, it isn't marked throw() in the C
headers, so if you compile with C++ and don't turn off exceptions, the result
is expected - there are EH edges out of the printf call that might terminate
the loop.

[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org,
   ||rth at gcc dot gnu.org

--- Comment #8 from Maxim Kuvyrkov  ---
Hi Richard,

Interested in checking out this bug?  The original testcase is from QEMU
source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972789 .

[Bug tree-optimization/97615] [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Priority|P3  |P1
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Mine.

[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-28
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine.  Forgot vect_double effective target.

[Bug libstdc++/95609] span could have better layout

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:0f7cd5e5735e5536bf7bc8ca2b998f7ce8b4ddee

commit r11-4475-g0f7cd5e5735e5536bf7bc8ca2b998f7ce8b4ddee
Author: Jonathan Wakely 
Date:   Wed Oct 28 12:07:40 2020 +

libstdc++: Make std::span layout-compatible with struct iovec [PR 95609]

This change reorders the data members of std::span so that span is
layout-compatible with common implementations of struct iovec. This will
allow span to be used directly in places that use a struct iovec
to do scatter-gather I/O.

It's important to note that POSIX doesn't specify the order of members
in iovec. Also the equivalent type on Windows has members in the other
order, and uses type ULONG (which is always 32-bit whereas size_t is
64-bit for Win64). So this change will only help for certain targets and
an indirection between std::span and I/O system calls will still be
needed for the general case.

libstdc++-v3/ChangeLog:

PR libstdc++/95609
* include/std/span (span): Reorder data members to match common
implementations of struct iovec.
* testsuite/23_containers/span/layout_compat.cc: New test.

[Bug libstdc++/95609] span could have better layout

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for GCC 11, not appropriate to backport.

[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:72a87d82e0d0741d75c72c8f3d2fc070e3a02b5f

commit r11-4476-g72a87d82e0d0741d75c72c8f3d2fc070e3a02b5f
Author: Jonathan Wakely 
Date:   Wed Oct 28 12:35:44 2020 +

libstdc++: Fix name clash with _Cosh in QNX headers [PR 95592]

This replaces unqualified names like _Cosh with struct std::_Cosh to
ensure there is no ambiguity with other entities with the same name.

libstdc++-v3/ChangeLog:

PR libstdc++/95592
* include/bits/valarray_after.h (_DEFINE_EXPR_UNARY_OPERATOR)
(_DEFINE_EXPR_BINARY_OPERATOR, _DEFINE_EXPR_BINARY_FUNCTION):
Use elaborated-type-specifier and qualified-id to avoid
ambiguities with QNX system headers.
* testsuite/26_numerics/valarray/95592.cc: New test.

[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed in GCC 11. Probably OK to backport, but I'll wait a bit.

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-28

[Bug c++/95557] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is int instead of size_t

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-28

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Jan Smets  ---
Is it maybe a possibility to report the (possible) false positives with
something like -Waggressive-loop-optimizations=2 ? 

Would that only require a skip of single_exit() in
do_warn_aggressive_loop_optimizations, or is there more to it? 
Thanks

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #3 from Jan Smets  ---
Sorry, I was too quickly in my wording to "skip single_exit()", of course that
edge is still required.

[Bug libstdc++/89610] Move-assigning a pmr container sometimes copies the elements instead of moving them

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Fixed in GCC 10

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

[Bug libstdc++/92124] std::vector copy-assigning when it should move-assign.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 89610 has been marked as a duplicate of this bug. ***

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:0bc199fc5d4eef5a20ced20df892e5e3b8821b60

commit r11-4479-g0bc199fc5d4eef5a20ced20df892e5e3b8821b60
Author: Jonathan Wakely 
Date:   Wed Oct 28 13:19:21 2020 +

libstdc++: Override BUFSIZ for Windows targets [PR 94268]

This replaces uses of BUFSIZ with a new _GLIBCXX_BUFSIZ macro that can
be overridden in target-specific config headers.

That allows the mingw and mingw-w64 targets to override it, because
BUFSIZ is apparently defined to 512, resulting in poor performance. The
MSVCRT stdio apparently uses 4096, so we use that too.

libstdc++-v3/ChangeLog:

PR libstdc++/94268
* config/os/mingw32-w64/os_defines.h (_GLIBCXX_BUFSIZ):
Define.
* config/os/mingw32/os_defines.h (_GLIBCXX_BUFSIZ):
Define.
* include/bits/fstream.tcc: Use _GLIBCXX_BUFSIZ instead
of BUFSIZ.
* include/ext/stdio_filebuf.h: Likewise.
* include/std/fstream (_GLIBCXX_BUFSIZ): Define.

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.0

--- Comment #12 from Jonathan Wakely  ---
Changed to 4096 for mingw and mingw-w64 in GCC 11.

[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |`__deref` in|`__deref` in 
   |in debug mode clashes with  |in debug mode clashes with
   |internal macro in Windows   |internal macro in Windows
   |system header   |system header
  Known to fail|11.0|

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk with g:2137aa92412da363d52ef699987441be28b239d0 which for some
reason didn't get added here.

[Bug tree-optimization/97596] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535 r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
This should be fixed with:

commit 279a9ce9d545f65a0bb1bc4564abafabfc25f82d
Author: Jakub Jelinek 
Date:   Wed Oct 28 10:24:20 2020 +0100

wide-int: Fix up set_bit_large

> >> wide_int new_lb = wi::set_bit (r.lower_bound (0), 127)
> >>
> >> and creates the value:
> >>
> >> p new_lb
> >> { = {val = {-65535, -1, 0}, len = 2, precision =
128},
> >> static is_sign_extended = true}
> >
> > This is non-canonical and so invalid, if the low HWI has the MSB set
> > and the high HWI is -1, it should have been just
> > val = {-65535}, len = 1, precision = 128}
> >
> > I guess the bug is that wi::set_bit_large doesn't call canonize.
>
> Yeah, looks like a micro-optimisation gone wrong.

2020-10-28  Jakub Jelinek  

* wide-int.cc (wi::set_bit_large): Call canonize unless setting
msb bit and clearing bits above it.

[Bug libstdc++/97613] chrono::year_month_weekday cast to sys_days : return bad value if index() == 0

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2020-10-28

--- Comment #2 from Patrick Palka  ---
Confirmed.

[Bug c/97618] New: undefined reference to LC11 building for target MinGW-w64 32-bit

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 97618
   Summary: undefined reference to LC11 building for target
MinGW-w64 32-bit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

When building GCC11 with MinGW-w64 32-bit it fails in the Fortran language with
undefined references to LC symbols.

Continuing to build without Fortran works.

However when using the resulting compuler the same error reappears when
building other libraries like libffi and boost.

The output of boost is this:
gcc.link.dll.mingw
build_win\boost\bin.v2\libs\log\build\gcc-11.0.0\release\visibility-hidden\libboost_log-x32.dll.a
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x3b9):
undefined reference to `LC10'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x3c9):
undefined reference to `LC11'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0xce6):
undefined reference to `LC10'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0xcee):
undefined reference to `LC11'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x19c6):
undefined reference to `LC10'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x19ce):
undefined reference to `LC11'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x2740):
undefined reference to `LC10'
d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x2750):
undefined reference to `LC11'
collect2.exe: error: ld returned 1 exit status

With libffi I noticed that when I replace -O3 with -O2 in each Makefile it does
actually build.

So it appears the issue is triggered by -O3 optimizations for MinGW Windows
32-bit builds.

[Bug c++/96331] Class template argument deduction (CTAD) with Concepts

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Pilar Latiesa  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #4 from Pilar Latiesa  ---
Another testcase, taken from
https://stackoverflow.com/questions/64567607/why-is-there-an-error-no-matching-function-for-call-to-aa-auto

template 
struct A {};

template 
struct B {};

template 
struct is_B {};

template 
struct is_B> {}; // error

template 
using B_t = B; // error

[Bug libstdc++/65114] char_traits::copy violates memcpy constraints, own postcondition

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #3 from Jonathan Wakely  ---
This is https://wg21.link/lwg3085

[Bug libstdc++/60630] FAIL: 21_strings/basic_string/literals/types.cc (test for excess errors)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-28
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Is this still an issue?

I have no idea how those test can fail like that.

[Bug tree-optimization/97615] [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-4482-gb626b00823af9ca9ab619fe13d1e8703a3101dab
Author: Richard Biener 
Date:   Wed Oct 28 13:21:53 2020 +0100

tree-optimization/97615 - avoid creating externals from patterns

The previous change missed to check for patterns again, the following
corrects that.

2020-10-28  Richard Biener  

PR tree-optimization/97615
* tree-vect-slp.c (vect_build_slp_tree_2): Do not build
an external from pattern defs.

* gcc.dg/vect/bb-slp-pr97615.c: New testcase.

[Bug tree-optimization/97615] [11 Regression] -O3 on -Wsequence-point-unclean code ICEs: during GIMPLE pass: slp: internal compiler error: in vectorizable_live_operation, at tree-vect-loop.c:8497

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Should be fixed.

[Bug libstdc++/95609] span could have better layout

[s_gccbugzilla at nedprod dot com via Gcc-bugs]

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

--- Comment #6 from Niall Douglas  ---
Cool, thanks. I believe that all three major STLs now implement struct iovec
compatibility with span. That's a nice win.

[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #1 from Brecht Sanders  
---
I see a similar issue when building mpfr with the resulting compiler, but here
the error is:

build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:616:
undefined reference to `LC4'

and replacing -O3 with -O2 or -Os didn't work.

[Bug libstdc++/60630] FAIL: 21_strings/basic_string/literals/types.cc (test for excess errors)

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

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

--- Comment #2 from dave.anglin at bell dot net ---
My hpux11.00 machine died some years ago.

On hpux11.11, the  only non prettyprinter fail is:
FAIL: 26_numerics/complex/proj.cc execution test

The prettyprinter tests all fail due to a perl issue.

So, it's likely not an issue anymore.

Dave

[Bug c/45821] Missed -Wreturn-local-addr when local variable address comes from within a statement expression

[philiprbrenan at gmail dot com via Gcc-bugs]

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

Philip R Brenan  changed:

   What|Removed |Added

 CC||philiprbrenan at gmail dot com

--- Comment #7 from Philip R Brenan  ---
A more compact example:

#include 
int * aaa() {return ({int a = 2;&a;});} // no warning unless -O2
int * bbb() { int b = 3; return &b;}//warning

int main(void)
 {int *a = aaa(), *b = bbb();
  fprintf(stderr, " %d\n", *a);
  fprintf(stderr, " %d\n", *b);
  return 0;
 }
//  3
// Segmentation fault (core dumped)

Please provide the warning for line 2 (aaa) regardless of the level of
optimization?

[Bug libstdc++/65113] string::copy violates traits requirements

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
Since C++17 the effects of basic_string::copy are stated in terms of
traits_type::copy, and the precondition is inherited due to the use of
"Effects: Equivalent to ..." wording.

So at least since C++17, if passing the arguments to traits_type::copy is
invalid, then the call to basic_string::copy is invalid.

This was changed by LWG 2777 https://wg21.link/lwg2777

Since that's a library defect, I'm going to consider it correct for us to do it
before C++17 too.

[Bug c++/68003] Variable declared in condition in for loop is destroyed too soon

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #1 from Arthur O'Dwyer  ---
Confirmed. https://godbolt.org/z/MfbrcG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769 is a duplicate.

[Bug c++/68003] Variable declared in condition in for loop is destroyed too soon

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
PR86769 has a nicer test, so closing this one.  Thanks for finding the dup.

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

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot 
eelis
   ||.net

--- Comment #2 from Marek Polacek  ---
*** Bug 68003 has been marked as a duplicate of this bug. ***

[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
My changes for P1120R0 will partially handle this, I think.  (I haven't posted
it yet.)

[Bug c++/95132] Concept checked after auto return type deduction

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

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

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

https://gcc.gnu.org/g:9ccc3495766116ea4ae8e4cd8129beca60e30445

commit r11-4488-g9ccc3495766116ea4ae8e4cd8129beca60e30445
Author: Patrick Palka 
Date:   Wed Oct 28 11:47:26 2020 -0400

c++: Check constraints before instantiation from mark_used [PR95132]

This makes mark_used check constraints of a function _before_ calling
maybe_instantiate_decl, so that we don't try instantiating a function
(as part of return type deduction) with unsatisfied constraints.

gcc/cp/ChangeLog:

PR c++/95132
* decl2.c (mark_used): Move up the constraints_satisfied_p check
so that we check constraints before calling maybe_instantiate_decl.

gcc/testsuite/ChangeLog:

PR c++/95132
* g++.dg/cpp2a/concepts-fn7.C: New test.

[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Brecht Sanders  
---
To build mpfr wich fails with:
build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:1523:
undefined reference to `LC4'
I figured out that the symbol LC4 is defined in libgcc.a, so I was able to
build mpfr by running:
make LIBS="-Wl,--as-needed -lgmp -lgcc"

It appears that in this case the GCC 11 linker doesn't automatically link with
libgcc.

[Bug c++/86769] g++ destroys condition variable in for statement too early

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #3 from Arthur O'Dwyer  ---
Confirmed. https://godbolt.org/z/MfbrcG

[Bug analyzer/96713] [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

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

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

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

https://gcc.gnu.org/g:8572edc828f6d1e7c8243f901fe7c96f62a11a8e

commit r11-4490-g8572edc828f6d1e7c8243f901fe7c96f62a11a8e
Author: Patrick Palka 
Date:   Wed Oct 28 12:28:08 2020 -0400

libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

The conversion function year_month_weekday::operator sys_days computes
the offset in days from the first weekday of the month with:

 days{(index()-1)*7}
  ^  type 'unsigned'

We want the above to yield -7d when index() is 0u, but our 'days' alias
is based on long instead of int, so the conversion from unsigned to the
underlying type of 'days' instead yields a large positive value.

This patch fixes this by casting the result of index() to int so that
the initializer is sign-extended in the conversion to long.

The added testcase also verifies we do the right thing when index() == 5.

libstdc++-v3/ChangeLog:

PR libstdc++/96713
* include/std/chrono (year_month_weekday::operator sys_days):
Cast the result of index() to int so that the initializer for
days{} is sign-extended when it's converted to the underlying
type.
* testsuite/std/time/year_month_weekday/3.cc: New test.

[Bug analyzer/96713] [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Whoops, meant to write PR97613...

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

--- Comment #2 from Aldy Hernandez  ---
tl;dr: substitute_and_fold_engine::replace_uses_in() creates invalid gimple, so
when its loop goes on to request a range (value_of_expr), the ranger may see
invalid IL and die an ungraceful death.

The long story:

We are calling substitute_and_fold_engine::replace_uses_in() on the following
statement:

   :
  SR.2_9 = &__to_destroy._M_head;
  SR.1_10 = SR.2_9;
  __pos$_M_node_6 = SR.1_10;
  _11 = __pos$_M_node_6;
  _11->_M_next = __keep_12(D);  <-- HERE HERE

For _11, the call to value_of_expr() in replace_uses_in() returns:

  &__to_destroy._M_head;

which is propagated with propagate_value() and creates invalid gimple in the
process:

  __to_destroy._M_head._M_next = __keep_12(D);

The next time in the loop in replace_uses_in, we ask for
value_of_expr(__keep_12(D)), which dies deep in the call chain, because the IL
borked.

[Bug libstdc++/97613] chrono::year_month_weekday cast to sys_days : return bad value if index() == 0

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

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

--- Comment #3 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:8572edc828f6d1e7c8243f901fe7c96f62a11a8e

commit r11-4490-g8572edc828f6d1e7c8243f901fe7c96f62a11a8e
Author: Patrick Palka 
Date:   Wed Oct 28 12:28:08 2020 -0400

libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

The conversion function year_month_weekday::operator sys_days computes
the offset in days from the first weekday of the month with:

 days{(index()-1)*7}
  ^  type 'unsigned'

We want the above to yield -7d when index() is 0u, but our 'days' alias
is based on long instead of int, so the conversion from unsigned to the
underlying type of 'days' instead yields a large positive value.

This patch fixes this by casting the result of index() to int so that
the initializer is sign-extended in the conversion to long.

The added testcase also verifies we do the right thing when index() == 5.

libstdc++-v3/ChangeLog:

PR libstdc++/96713
* include/std/chrono (year_month_weekday::operator sys_days):
Cast the result of index() to int so that the initializer for
days{} is sign-extended when it's converted to the underlying
type.
* testsuite/std/time/year_month_weekday/3.cc: New test.

[Bug libstdc++/97613] chrono::year_month_weekday cast to sys_days : return bad value if index() == 0

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #4 from Patrick Palka  ---
This should be fixed now, thanks for the report!

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

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

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

--- Comment #3 from Aldy Hernandez  ---
And the reason this was working before is two-fold.

First, value_of_expr() in legacy evrp won't look at broken gimple, so the
request for __keep_12(D) in the following statement actually succeeds:

  __to_destroy._M_head._M_next = __keep_12(D);

Well... returns NULL.

Second, after replace_uses_in() succeeds, the gimple folder fixes the crappy IL
by transforming:

  __to_destroy._M_head._M_next = __keep_12(D);

into:

  MEM[(struct _Fwd_list_node_base *)&__to_destroy]._M_next = __keep_12(D);


So basically this worked before because even though
substitute_and_fold_engine::replace_uses_in() created invalid gimple, it
depended on the gimple folder to clean-up the nonsense after the fact.  How
stupid is that? :)

[Bug other/96217] undefined reference to `_Unwind_Resume'

[legarrec.vincent at gmail dot com via Gcc-bugs]

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

--- Comment #8 from LE GARREC Vincent  ---
Thanks, you're right. I was able to build with

CFLAGS="-march=native -ggdb2 -g2 -pipe -fno-omit-frame-pointer -O0"
CXXFLAGS="-march=native -ggdb2 -g2 -pipe -fno-omit-frame-pointer -O0"

but with adding :
export CFLAGS_FOR_TARGET="-O2 -g"
export CXXFLAGS_FOR_TARGET="-O2 -g"

[Bug libstdc++/97600] [ranges] satisfaction value of range affected by prior use of basic_istream_view::begin()

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2020-10-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c/97619] New: error: true/false edge after a non-GIMPLE_COND in bb

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97619
   Summary: error: true/false edge after a non-GIMPLE_COND in bb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 49459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49459&action=edit
C source code

For the attached C source code with recent gcc trunk and compiler
flag -O3, does this:

/home/dcb/gcc/results.20201027/bin/gcc
/home/dcb/gcc/results.20201028/bin/gcc
resample.c: In function ‘merge_linear_argb_ref’:
resample.c:163:1: error: true/false edge after a non-GIMPLE_COND in bb 4
resample.c:163:1: error: true/false edge after a non-GIMPLE_COND in bb 4
during GIMPLE pass: slp
resample.c:163:1: internal compiler error: verify_flow_info failed
0xa0a2c0 verify_flow_info()
../../trunk.git/gcc/cfghooks.c:269
0xe1b583 execute_function_todo
../../trunk.git/gcc/passes.c:2004

The bug first appears sometime between 20201027 and 20201028.

I won't be able to reduce the code until tomorrow.

[Bug c/97619] error: true/false edge after a non-GIMPLE_COND in bb

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced code is:

char a;
char *b;
int c;
void f(void) 
{
char *d = f;
int e;
for(;e;e++)
{
d[4*e] = a*(256-c) + b[4*e]*c >> 8;
d[4*e+1] = a*(256-c) + b[4*e+1]*c >> 8;
d[4*e+2] = a*(256-c) + b[4*e+2]*c >> 8;
d[4*e+3] = a*(256-c) + b[4*e+3]*c >> 8;
}
}

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #9 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #7)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> > 
> > --- Comment #6 from Bernd Edlinger  ---
> > (In reply to rguent...@suse.de from comment #3)
> > > On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > > > --- a/gcc/emit-rtl.c
> > > > +++ b/gcc/emit-rtl.c
> > > > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, 
> > > > int
> > > > objectp,
> > > > {
> > > >   gcc_assert (handled_component_p (t)
> > > >   || TREE_CODE (t) == MEM_REF
> > > > - || TREE_CODE (t) == TARGET_MEM_REF);
> > > > + || TREE_CODE (t) == TARGET_MEM_REF
> > > > + || TREE_CODE (t) == SSA_NAME);
> > > 
> > > Can you track down this?  It's a red herring to have a MEM_EXPR
> > > that just is a SSA_NAME.
> > > 
> > 
> > This happens here:
> > 
> >   if (MEM_P (to_rtx))
> > {
> >   /* If the field is at offset zero, we could have been given 
> > the
> >  DECL_RTX of the parent struct.  Don't munge it.  */
> >   to_rtx = shallow_copy_rtx (to_rtx);
> >   set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
> >   if (volatilep)
> > MEM_VOLATILE_P (to_rtx) = 1;
> > }
> > 
> > since the patch allows the SSA_NAME to reach this block.
> > 
> > 
> > > > --- a/gcc/expr.c
> > > > +++ b/gcc/expr.c
> > > > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > > > nontemporal)
> > > >|| (TREE_CODE (to) == MEM_REF
> > > >   && (REF_REVERSE_STORAGE_ORDER (to)
> > > >   || mem_ref_refers_to_non_mem_p (to)))
> > > > +  || (TREE_CODE (to) == SSA_NAME
> > > > + && mode != BLKmode
> > > > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> > > 
> > > But an SSA name is a register, esp. one with non-BLKmode.  And if
> > > expanded to a stack location that stack location should better
> > > be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> > > 
> > 
> > Hmm, to avoid the ICE the SSA_NAME would need a naturally
> > aligned type, maybe replace it somehow in make_ssa_name_fn ...
> 
> Ah, OK - only now looked at the testcase ;)  Yes, I think for
> registers we should ignore decl/type alignment and _always_
> use the natural (mode) alignment.  That is,
> 
> static unsigned int
> align_local_variable (tree decl, bool really_expand)
> {
>   unsigned int align;
> 
>   if (TREE_CODE (decl) == SSA_NAME)
> align = TYPE_ALIGN (TREE_TYPE (decl));
> 
> should probably use GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (decl)))
> unless it is a BLKmode var.  There's a duplicate code in
> expand_one_stack_var_1, not sure why it special-cases SSA_NAMEs there.
> 

Ah, yes, using a similar strategy as we did in r274986
where we aligned param_decls, I would say this
completely untested patch goes in the same direction:

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index f3f17d3..030d0cb 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -366,7 +366,18 @@ align_local_variable (tree decl, bool really_expand)
   unsigned int align;

   if (TREE_CODE (decl) == SSA_NAME)
-align = TYPE_ALIGN (TREE_TYPE (decl));
+{
+  tree type = TREE_TYPE (decl);
+  machine_mode mode = TYPE_MODE (type);
+
+  align = TYPE_ALIGN (type);
+  if (mode != BLKmode
+ && align < GET_MODE_ALIGNMENT (mode)
+ && ((optab_handler (movmisalign_optab, mode)
+  != CODE_FOR_nothing)
+ || targetm.slow_unaligned_access (mode, align)))
+   align = GET_MODE_ALIGNMENT (mode);
+}
   else
 {
   align = LOCAL_DECL_ALIGNMENT (decl);
@@ -1022,6 +1033,17 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned
base_align,
 }

   set_rtl (decl, x);
+
+  if (TREE_CODE (decl) == SSA_NAME
+  && GET_MODE (x) != BLKmode
+  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x))
+  && ((optab_handler (movmisalign_optab, GET_MODE (x))
+  != CODE_FOR_nothing)
+ || targetm.slow_unaligned_access (GET_MODE (x), MEM_ALIGN (x
+{
+  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <= base_align);
+  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
+}
 }

 class stack_vars_data
@@ -1327,13 +1349,11 @@ expand_one_stack_var_1 (tree var)
 {
   tree type = TREE_TYPE (var);
   size = tree_to_poly_uint64 (TYPE_SIZE_UNIT (type));
-  byte_align = TYPE_ALIGN_UNIT (type);
 }
   else
-{
-  size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
-  byte_align = align_local_variable (var, true);
-}
+size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
+
+  byte_align = align_local_variable (var, true);

   /* We handle highly aligned variabl

[Bug analyzer/97620] New: -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97620
   Summary: -fexec-charset=IBM16804 triggers ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

gcc -o stdio stdio.c -s -O2 -fexec-charset=IBM16804
during GIMPLE pass: strlen
stdio.c: In function 'main':
stdio.c:7: internal compiler error: converting to execution character set:
Invalid or incomplete multibyte or wide character
0x8f21da c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
../../gcc/gcc/c-family/c-common.c:6366
0x192798d cpp_diagnostic_at
../../gcc/libcpp/errors.c:42
0x192798d cpp_diagnostic
../../gcc/libcpp/errors.c:75
0x1927a79 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
../../gcc/libcpp/errors.c:89
0x1921214 cpp_host_to_exec_charset(cpp_reader*, unsigned int)
../../gcc/libcpp/charset.c:798
0x8f22e3 c_common_to_target_charset(long)
../../gcc/gcc/c-family/c-common.c:6384
0x178f119 init_target_to_host_charmap
../../gcc/gcc/gimple-ssa-sprintf.c:199
0x178f119 handle_printf_call(gimple_stmt_iterator*, range_query*)
../../gcc/gcc/gimple-ssa-sprintf.c:4301
0xfdabfb strlen_check_and_optimize_call
../../gcc/gcc/tree-ssa-strlen.c:5473
0xfdabfb check_and_optimize_stmt
../../gcc/gcc/tree-ssa-strlen.c:5641
0xfdabfb strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-strlen.c:5874
0x1737467 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:309
0xfcfd91 printf_strlen_execute
../../gcc/gcc/tree-ssa-strlen.c:5940
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/97621] New: [11 regression] bogus message in gcc.dg/analyzer/malloc-vs-local-1b.c after r11-4434

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

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

Bug ID: 97621
   Summary: [11 regression] bogus message in
gcc.dg/analyzer/malloc-vs-local-1b.c after r11-4434
   Product: gcc
   Version: 11.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:b0702ac5588333e27d7ec43d21d704521f7a05c6, r11-4434
make -k check-gcc
RUNTESTFLAGS=analyzer.exp=gcc.dg/analyzer/malloc-vs-local-1b.c
FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 170)
# of expected passes22
# of unexpected failures1

commit b0702ac5588333e27d7ec43d21d704521f7a05c6
Author: David Malcolm 
Date:   Tue Oct 27 09:51:19 2020 -0400

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c
-fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -fanalyzer-call-summaries -S -o malloc-vs-local-1b.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:
In function 'test_initial_flag':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:170:5:
warning: 'free' of 'ptr' which points to memory not on the heap [CWE-590]
[-Wanalyzer-free-of-non-heap]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:158:6:
note: (1) following 'false' branch (when 'on_heap == 0')...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:161:9:
note: (2) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:161:9:
note: (3) pointer is from here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:169:6:
note: (4) following 'true' branch (when 'n > 10')...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:170:5:
note: (5) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:170:5:
note: (6) call to 'free' here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:
At top level:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:47:3:
warning: 2 processed enodes: [EN: 69-70]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:51:3:
warning: 2 processed enodes: [EN: 75-76]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:72:3:
warning: 2 processed enodes: [EN: 105-106]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:101:3:
warning: 2 processed enodes: [EN: 125-126]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:105:3:
warning: 2 processed enodes: [EN: 131-132]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:126:3:
warning: 2 processed enodes: [EN: 161-162]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:130:3:
warning: 2 processed enodes: [EN: 167-168]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:156:3:
warning: 1 processed enode: [EN: 196]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:163:3:
warning: 2 processed enodes: [EN: 207-208]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:167:3:
warning: 2 processed enodes: [EN: 213-214]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/malloc-vs-local-1b.c:76:3:
warning: 2 processed enodes: [EN: 263, EN: 275]
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 16)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 47)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 51)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 54)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 56)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 72)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 76)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 79)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 81)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 101)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 105)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 108)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, line 110)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 126)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for warnings, line 130)
PASS: gcc.dg/analyzer/malloc-vs-local-1b.c  (test for bogus messages, 

[Bug analyzer/97620] -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
Program:

#include

int main()
{
printf("Hello World %d\n",6);
}

[Bug target/97457] [10/11 Regression] SVE: wrong code since r10-4752-g2d56600c

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:54ef7701a9dec8c923a12d1983f8a051ba88a7b9

commit r11-4495-g54ef7701a9dec8c923a12d1983f8a051ba88a7b9
Author: Richard Sandiford 
Date:   Wed Oct 28 19:05:49 2020 +

value-range: Give up on POLY_INT_CST ranges [PR97457]

This PR shows another problem with calculating value ranges for
POLY_INT_CSTs.  We have:

  ivtmp_76 = ASSERT_EXPR  POLY_INT_CST [9,
4294967294]>

where the VQ coefficient is unsigned but is effectively acting
as a negative number.  We wrongly give the POLY_INT_CST the range:

  [9, INT_MAX]

and things go downhill from there: later iterations of the unrolled
epilogue are wrongly removed as dead.

I guess this is the final nail in the coffin for doing VRP on
POLY_INT_CSTs.  For other similarly exotic testcases we could have
overflow for any coefficient, not just those that could be treated
as contextually negative.

Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
couldn't handle warn_strict_overflow properly.  At this stage we're
just recording a range that might or might not lead to strict-overflow
assumptions later.

It still feels like we should be able to do something here, but for
now removing the code seems safest.  It's also telling that there
are no testsuite failures on SVE from doing this.

gcc/
PR tree-optimization/97457
* value-range.cc (irange::set): Don't decay POLY_INT_CST ranges
to integer ranges.

gcc/testsuite/
PR tree-optimization/97457
* gcc.dg/vect/pr97457.c: New test.

[Bug tree-optimization/82700] ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||euloanty at live dot com

--- Comment #4 from Martin Sebor  ---
*** Bug 97620 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/97620] -fexec-charset=IBM16804 triggers ICE

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 CC||msebor at gcc dot gnu.org
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
  Component|analyzer|tree-optimization

--- Comment #2 from Martin Sebor  ---
This is almost certainly caused by an incomplete charset, same as in pr82700.

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

[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
This worked OK because the code does:

  /* Replace real uses in the statement.  */
  did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);

  gimple_stmt_iterator prev_gsi = i;
  gsi_prev (&prev_gsi);

  /* If we made a replacement, fold the statement.  */
  if (did_replace)
{
  fold_stmt (&i, follow_single_use_edges);
  stmt = gsi_stmt (i);
  gimple_set_modified (stmt, true);
}

basically replace uses, and then folded the statement to make it right.

Enter the hybrid folder... and if you look closely at 
substitute_and_fold_engine::replace_uses_in (), you will see:

  FOR_EACH_SSA_USE_OPERAND (use, stmt, iter, SSA_OP_USE)
{
  tree tuse = USE_FROM_PTR (use);
  tree val = value_of_expr (tuse, stmt);

<...>


The statement giving us grief is:
_11->_M_next = __keep_12(D);
where EVRP has decided that _11 can be replaced by  &__to_destroy._M_head

replace_uses_in () loops thru the SSA_NAMEs in the stmt.
THe first one is _11, which it proceeds to replace with &__to_destroy._M_head,
producing our problematic

  __to_destroy._M_head._M_next = __keep_12(D);

but before returning and calling fold_stmt to fix it up, it looks at the next
ssa_name, __keep_12 and calls 
   tree val = value_of_expr (tuse, stmt);
which causes a ranger lookup for __keep_12 on this stmt.

Normally, that wouldn't be a big deal either because we don't need to look at
this statement, but because its a pointer, it triggers a call to the rangers
non-null pointer tracking code.

__keep_12 has never been "checked" before, so the non-null pointer code goes
and quickly visits each use to globally mark which blocks trigger a non-null
deference for future use...   and voila...
it visits this malformed statement and dies.

Now. what to do about it.  I don't think replace_uses is doing anything wrong.
This is purely the fault of non-null deref tracking, which I plan to revamp
before the next stage 1...

Let me think...

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:3dcd47389b16f48dcf5512b9ebba15af5c0be948

commit r11-4496-g3dcd47389b16f48dcf5512b9ebba15af5c0be948
Author: Tamar Christina 
Date:   Wed Oct 28 19:13:27 2020 +

AArch64: Skip test for pr97535 on ILP32 since it can't express the range.

I am excluding the test from ILP32 since the goal of the test is to test
truncations of large numbers above INT_MAX.

gcc/testsuite/ChangeLog:

PR target/97535
* gcc.target/aarch64/pr97535.c: Exclude ILP32.

[Bug tree-optimization/97620] -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Martin Sebor from comment #2)
> This is almost certainly caused by an incomplete charset, same as in pr82700.
> 
> *** This bug has been marked as a duplicate of bug 82700 ***

Then provide a better error message. Use -fexec-charset=IBM-12712 instead for
example.

Is that possible to detect fexec-charset from macros?

[Bug c++/86773] GCC accepts junk before fold expressions

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:43cb72263fb3b7b97a74fb38d71364a1d5cf0448

commit r11-4498-g43cb72263fb3b7b97a74fb38d71364a1d5cf0448
Author: Marek Polacek 
Date:   Mon Oct 26 15:04:58 2020 -0400

c++: GCC accepts junk before fold-expression [PR86773]

Here we accept a bogus expression before a left fold:

Recall that a fold expression looks like:

 fold-expression:
( cast-expression fold-operator ... )
( ... fold-operator cast-expression )
( cast-expression fold-operator ... fold-operator cast-expression )

but here we have

( cast-expression ... fold-operator cast-expression )

The best fix seems to just return error_mark_node when we know this code
is invalid, and let the subsequent code report that a ) was expected.

gcc/cp/ChangeLog:

PR c++/86773
* parser.c (cp_parser_fold_expression): Return error_mark_node
if a left fold is preceded by an expression.

gcc/testsuite/ChangeLog:

PR c++/86773
* g++.dg/cpp1z/fold12.C: New test.

[Bug c++/86773] GCC accepts junk before fold expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:323dd4255203479d8c456b85513db4f8e0041d04

commit r11-4499-g323dd4255203479d8c456b85513db4f8e0041d04
Author: Marek Polacek 
Date:   Mon Oct 19 18:13:42 2020 -0400

c++: Member template function lookup failure [PR94799]

My earlier patch for this PR, r11-86, broke pybind11.  That patch
changed cp_parser_class_name to also consider the object expression
scope (parser->context->object_type) to fix parsing of

  p->template A::foo(); // consider p's scope too

Here we reject

  b.operator typename B::type();

because 'typename_p' in cp_parser_class_name uses 'scope', which means
that 'typename_p' will be true for the example above.  Then we create
a TYPENAME_TYPE via make_typename_type, which fails when tsubsting it;
the code basically created 'typename B::B' and then we complain that there
is no member named 'B' in 'A'.  So, when deciding if we should
create a TYPENAME_TYPE, don't consider the object_type scope, like we
did pre-r11-86.

gcc/cp/ChangeLog:

PR c++/94799
* parser.c (cp_parser_class_name): Use parser->scope when
setting typename_p.

gcc/testsuite/ChangeLog:

PR c++/94799
* g++.dg/template/lookup16.C: New test.