[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Dimitry Andric from comment #5)
> Hmm, it appears that this diff "fixes" it:
> 
> diff --git a/gcc/config/i386/i386-features.c
> b/gcc/config/i386/i386-features.c
> index 9505b4a1330..091a59f3cb9 100644
> --- a/gcc/config/i386/i386-features.c
> +++ b/gcc/config/i386/i386-features.c
> @@ -1166,7 +1166,11 @@ general_scalar_chain::convert_registers ()
>bitmap_iterator bi;
>unsigned id;
>EXECUTE_IF_SET_IN_BITMAP (defs_conv, 0, id, bi)
> -defs_map.put (regno_reg_rtx[id], gen_reg_rtx (smode));
> +{
> +  rtx key = regno_reg_rtx[id];
> +  rtx val = gen_reg_rtx (smode);
> +  defs_map.put (key, val);
> +}
>EXECUTE_IF_SET_IN_BITMAP (insns_conv, 0, id, bi)
>  for (df_ref ref = DF_INSN_UID_DEFS (id); ref; ref = DF_REF_NEXT_LOC
> (ref))
>if (bitmap_bit_p (defs_conv, DF_REF_REGNO (ref)))
> 
> but obviously that can't be right, unless gen_reg_rtx() is doing something
> horrible to regno_reg_rtx[].  I only see it adding another element at the
> end, though.
> 
> I think this might indeed be some clang code generation bug, as the assembly
> looks a little different with the above patch applied.
> 
> Digging further...

Ok, just a quick note, it can make a different if defs_map.put takes a constant
reference for its arguments.  As gen_reg_rtx can free the old regno_reg_rtx.

Basically the old code is equivalant to:

 +{
 +  const rtx  = regno_reg_rtx[id];
 +  const rtx  = gen_reg_rtx (smode);
 +  defs_map.put (key, val);
 +}

so taking the reference of a pointer which can be free is a big no-no.

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Somewhat reduced:

typedef struct rtx_def *rtx;
enum machine_mode {
  E_VOIDmode,
  E_BLKmode,
  E_CCmode,
  E_CCFPmode,
  E_CCFPEmode,
  E_CC_SWPmode,
  E_CC_NZCmode,
  E_CC_NZmode,
  E_CC_Zmode,
  E_CC_Cmode,
  E_CC_ADCmode,
  E_CC_Vmode,
  E_BImode,
  E_QImode,
  E_HImode,
  E_SImode,
  E_DImode,
  E_TImode,
  E_OImode,
  E_CImode,
  E_XImode,
  E_QQmode,
  E_HQmode,
  E_SQmode,
  E_DQmode,
  E_TQmode,
  E_UQQmode,
  E_UHQmode,
  E_USQmode,
  E_UDQmode,
  E_UTQmode,
  E_HAmode,
  E_SAmode,
  E_DAmode,
  E_TAmode,
  E_UHAmode,
  E_USAmode,
  E_UDAmode,
  E_UTAmode,
  E_HFmode,
  E_SFmode,
  E_DFmode,
  E_TFmode,
  E_SDmode,
  E_DDmode,
  E_TDmode,
  E_CQImode,
  E_CHImode,
  E_CSImode,
  E_CDImode,
  E_CTImode,
  E_COImode,
  E_CCImode,
  E_CXImode,
  E_HCmode,
  E_SCmode,
  E_DCmode,
  E_TCmode,
  E_V8QImode,
  E_V4HImode,
  E_V2SImode,
  E_V16QImode,
  E_V8HImode,
  E_V4SImode,
  E_V2DImode,
  E_VNx2TImode,
  E_VNx3TImode,
  E_VNx4TImode,
  E_VNx2OImode,
  E_V2HFmode,
  E_V4HFmode,
  E_V2SFmode,
  E_V2DFmode,
  NUM_MACHINE_MODES
};
template  struct A { int coeffs[N]; };
template  class C : public A {
public:
  template  C(const C0 &);
};
machine_mode mode_size_inline_mode, emit_store_flag_1_target_mode;
A<2> mode_size[1];
struct B {
  enum from_int {};
};
extern const char mode_class[NUM_MACHINE_MODES];
template  T as_a(machine_mode);
class scalar_int_mode {
public:
  scalar_int_mode() {}
  scalar_int_mode(B::from_int p1) : m_mode(machine_mode(p1)) {}
  operator machine_mode() { return m_mode; }
  machine_mode m_mode;
} mode_to_bytes_mode;
scalar_int_mode word_mode;
template  bool is_int_mode(machine_mode p1, T p2) {
  if (mode_class[p1]) {
*p2 = B::from_int(p1);
return true;
  }
  return false;
}
enum insn_code {};
enum rtx_code { GE, LE, LT };
struct rtx_def {
  rtx_code code;
  machine_mode mode;
};
rtx const_int_rtx_63, const_int_rtx_64, emit_store_flag_1_subtarget,
emit_store_flag_1_tem, emit_store_flag_1_op00, emit_store_flag_1_op01,
emit_store_flag_1_op0h, emit_store_flag_1_target, emit_store_flag_1_op0,
emit_store_flag_1_op1;
enum tree_code { RSHIFT_EXPR };
enum optab_tag { and_optab, ior_optab, one_cmpl_optab };
enum optab_methods { OPTAB_DIRECT };
insn_code emit_store_flag_1_icode;
rtx_code emit_store_flag_1_code;
int emit_store_flag_1_unsignedp, emit_store_flag_1_normalizep;
short emit_store_flag_1___trans_tmp_24, emit_store_flag_1___trans_tmp_23;
bool iterate_p();
inline __attribute__((__always_inline__)) C<2> mode_size_inline() {
  A<2> mode_size;
  switch (mode_size_inline_mode) {
  case E_VOIDmode:
return 0;
  case E_BLKmode:
return 0;
  case E_CCmode:
return 4;
  case E_CCFPmode:
return 4;
  case E_CCFPEmode:
return 4;
  case E_CC_SWPmode:
return 4;
  case E_CC_NZCmode:
return 4;
  case E_CC_NZmode:
return 4;
  case E_CC_Zmode:
return 4;
  case E_CC_Cmode:
return 4;
  case E_CC_ADCmode:
return 4;
  case E_CC_Vmode:
return 4;
  case E_BImode:
return 1;
  case E_QImode:
return 1;
  case E_HImode:
return 2;
  case E_SImode:
return 4;
  case E_DImode:
return 8;
  case E_TImode:
return 6;
  case E_OImode:
return 2;
  case E_CImode:
return 8;
  case E_XImode:
return 4;
  case E_QQmode:
return 1;
  case E_HQmode:
return 2;
  case E_SQmode:
return 4;
  case E_DQmode:
return 8;
  case E_TQmode:
return 6;
  case E_UQQmode:
return 1;
  case E_UHQmode:
return 2;
  case E_USQmode:
return 4;
  case E_UDQmode:
return 8;
  case E_UTQmode:
return 6;
  case E_HAmode:
return 2;
  case E_SAmode:
return 4;
  case E_DAmode:
return 8;
  case E_TAmode:
return 6;
  case E_UHAmode:
return 2;
  case E_USAmode:
return 4;
  case E_UDAmode:
return 8;
  case E_UTAmode:
return 6;
  case E_HFmode:
return 2;
  case E_SFmode:
return 4;
  case E_DFmode:
return 8;
  case E_TFmode:
return 6;
  case E_SDmode:
return 4;
  case E_DDmode:
return 8;
  case E_TDmode:
return 6;
  case E_CQImode:
return 2;
  case E_CHImode:
return 4;
  case E_CSImode:
return 8;
  case E_CDImode:
return 6;
  case E_CTImode:
return 2;
  case E_COImode:
return 4;
  case E_CCImode:
return 6;
  case E_CXImode:
return 8;
  case E_HCmode:
return 4;
  case E_SCmode:
return 8;
  case E_DCmode:
return 6;
  case E_TCmode:
return 2;
  case E_V8QImode:
return 8;
  case E_V4HImode:
return 8;
  case E_V2SImode:
return 8;
  case E_V16QImode:
return 6;
  case E_V8HImode:
return 6;
  case E_V4SImode:
return 6;
  case E_V2DImode:
return 6;
  case E_VNx2TImode:
return 2;
  case E_VNx3TImode:
return 8;
  case E_VNx4TImode:
return 4;
  case E_VNx2OImode:
return 4;
  case E_V2HFmode:
return 4;
  case E_V4HFmode:
return 8;
  case E_V2SFmode:
return 8;
  case E_V2DFmode:

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 275969)
+++ gcc/fortran/primary.c   (working copy)
@@ -2331,6 +2331,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 

   if (tmp && tmp->type == REF_INQUIRY)
{
+ if (!primary->where.lb || !primary->where.nextc)
+   primary->where = gfc_current_locus;
  gfc_simplify_expr (primary, 0);

  if (primary->expr_type == EXPR_CONSTANT)

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[hjl.tools at gmail dot com]

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

--- Comment #56 from H.J. Lu  ---
(In reply to Thomas Koenig from comment #55)
> (In reply to H.J. Lu from comment #45)
> > Created attachment 45510 [details]
> > An updated patch
> 
> HJ, do you plan on committing these?

We are collecting performance data before I submit it.

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 275969)
+++ gcc/fortran/decl.c  (working copy)
@@ -8468,6 +8468,15 @@ attr_decl1 (void)
   goto cleanup;
 }

+  /* Check F2018:C822.  */
+  if (sym->attr.dimension && sym->attr.codimension
+  && sym->as && sym->as->rank + sym->as->corank > 15)
+{
+  gfc_error ("rank + corank of %qs exceeds 15 at %C", sym->name);
+  m = MATCH_ERROR;
+  goto cleanup;
+}
+
   if (sym->attr.cray_pointee && sym->as != NULL)
 {
   /* Fix the array spec.  */
Index: gcc/testsuite/gfortran.dg/pr91802.f90
===
--- gcc/testsuite/gfortran.dg/pr91802.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr91802.f90   (working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+! Code contributed by Gerhard Steinmetz
+! PR fortran/91802
+module m
+   real :: x
+   dimension ::   x(1,2,1,2,1,2,1,2)
+   codimension :: x[1,2,1,2,1,2,1,*] ! { dg-error "exceeds 15" }
+end

[Bug middle-end/91631] buffer overflow into an array member of a declared object not detected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Partially fixed in r275981.  The test case triggers the six warnings below (the
output with -D_FORTIFY_SOURCE=2 is similar).  What's not "fixed" is that the
warning for buffer overflow is supposed to be -Wstringop-overflow (and with
_FORTIFY_SOURCE the overflow should cause an abort).  But that's a separate
problem.

pr91631.c: In function ‘efa’:
pr91631.c:11:3: warning: ‘strcpy’ offset 3 from the object at ‘es’ is out of
the bounds of referenced subobject ‘a’ with type ‘char[3]’ at offset 0
[-Warray-bounds]
   11 |   strcpy (es[0].a, a);   // missing warning
  |   ^~~
pr91631.c:3:17: note: subobject ‘a’ declared here
3 | struct S { char a[3], b[5], c[]; };
  | ^
pr91631.c: In function ‘efb’:
pr91631.c:17:3: warning: ‘strcpy’ offset 8 from the object at ‘es’ is out of
the bounds of referenced subobject ‘b’ with type ‘char[5]’ at offset 3
[-Warray-bounds]
   17 |   strcpy (es[0].b, a);   // missing warning
  |   ^~~
pr91631.c:3:23: note: subobject ‘b’ declared here
3 | struct S { char a[3], b[5], c[]; };
  |   ^
pr91631.c: In function ‘efc’:
pr91631.c:23:3: warning: ‘strcpy’ offset [8, 11] from the object at ‘es’ is out
of the bounds of referenced subobject ‘c’ with type ‘char[]’ at offset 8
[-Warray-bounds]
   23 |   strcpy (es[0].c, a);   // missing warning
  |   ^~~
pr91631.c:3:29: note: subobject ‘c’ declared here
3 | struct S { char a[3], b[5], c[]; };
  | ^
pr91631.c: In function ‘ifa’:
pr91631.c:29:3: warning: ‘strcpy’ offset 3 from the object at ‘is’ is out of
the bounds of referenced subobject ‘a’ with type ‘char[3]’ at offset 0
[-Warray-bounds]
   29 |   strcpy (is[0].a, a);   // warning (good)
  |   ^~~
pr91631.c:3:17: note: subobject ‘a’ declared here
3 | struct S { char a[3], b[5], c[]; };
  | ^
pr91631.c: In function ‘ifb’:
pr91631.c:35:3: warning: ‘strcpy’ offset 8 from the object at ‘is’ is out of
the bounds of referenced subobject ‘b’ with type ‘char[5]’ at offset 3
[-Warray-bounds]
   35 |   strcpy (is[0].b, a);   // warning (good)
  |   ^~~
pr91631.c:3:23: note: subobject ‘b’ declared here
3 | struct S { char a[3], b[5], c[]; };
  |   ^
pr91631.c: In function ‘ifc’:
pr91631.c:41:3: warning: ‘strcpy’ offset [8, 11] from the object at ‘is’ is out
of the bounds of referenced subobject ‘c’ with type ‘char[]’ at offset 8
[-Warray-bounds]
   41 |   strcpy (is[0].c, a);   // missing warning
  |   ^~~
pr91631.c:3:29: note: subobject ‘c’ declared here
3 | struct S { char a[3], b[5], c[]; };
  | ^

[Bug middle-end/91631] buffer overflow into an array member of a declared object not detected

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Sep 19 22:15:34 2019
New Revision: 275981

URL: https://gcc.gnu.org/viewcvs?rev=275981=gcc=rev
Log:
PR middle-end/91631 - buffer overflow into an array member of a declared object
not detected

gcc/ChangeLog:

PR middle-end/91631
* builtins.c (component_size): Correct trailing array computation,
rename to component_ref_size and move...
(compute_objsize): Adjust.
* gimple-ssa-warn-restrict.c (builtin_memref::refsize): New member.
(builtin_access::strict): Do not consider mememmove.
(builtin_access::write_off): New function.
(builtin_memref::builtin_memref): Initialize refsize.
(builtin_memref::set_base_and_offset): Adjust refoff and compute
refsize.
(builtin_memref::offset_out_of_bounds): Use ooboff input values.
Handle refsize.
(builtin_access::builtin_access): Intialize dstoff to destination
refeence offset here instead of in maybe_diag_overlap.  Adjust
referencess even to unrelated objects.  Adjust sizrange of bounded
string functions to reflect bound.  For strcat, adjust destination
sizrange by that of source.
(builtin_access::strcat_overlap):  Adjust offsets and sizes
to reflect the increase in destination sizrange above.
(builtin_access::overlap): Do not set dstoff here but instead
in builtin_access::builtin_access.
(check_bounds_or_overlap): Use builtin_access::write_off.
(maybe_diag_access_bounds): Add argument.  Add informational notes.
(dump_builtin_memref, dump_builtin_access): New functions.
* tree.c (component_ref_size): ...to here.
* tree.h (component_ref_size): Declare.
* tree-ssa-strlen (handle_builtin_strcat): Include the terminating
nul in the size of the source string.

gcc/testsuite/ChangeLog:

PR middle-end/91631
* /c-c++-common/Warray-bounds-3.c: Correct expected offsets.
* /c-c++-common/Warray-bounds-4.c: Same.
* gcc.dg/Warray-bounds-39.c: Remove xfails.
* gcc.dg/Warray-bounds-45.c: New test.
* gcc.dg/Warray-bounds-46.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-45.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-3.c
trunk/gcc/testsuite/c-c++-common/Warray-bounds-4.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-39.c
trunk/gcc/tree-ssa-strlen.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c/67224] UTF-8 support for identifier names in GCC

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #33 from Eric Gallager  ---
This is a big enough feature that it should probably get an entry in
gcc-10/changes.html

[Bug libstdc++/91829] New: compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[forkenmasterforce at keemail dot me]

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

Bug ID: 91829
   Summary: compatibility.cc: syntax error lea (%pc,
_GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: forkenmasterforce at keemail dot me
  Target Milestone: ---

Instruction ignored causing the error seems to be emitted at m68k.md:7370

return "lea (%%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %0";

[Bug fortran/91801] ICE in gfc_simplify_reshape, at fortran/simplify.c:6733

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Should be easy to fix.

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[tkoenig at gcc dot gnu.org]

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

--- Comment #55 from Thomas Koenig  ---
(In reply to H.J. Lu from comment #45)
> Created attachment 45510 [details]
> An updated patch

HJ, do you plan on committing these?

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Created attachment 46902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46902=edit
expmed.ii.xz

Compiling this with "-Wmaybe-uninitialized -O2" gave the warning (on x86_64
too).

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[sje at gcc dot gnu.org]

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

--- Comment #4 from Steve Ellcey  ---
The original bootstrap failure is on aarch64.

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Note that I reverted the patch, but still need a reproducer.

[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
My view is as stated in 
 and 
:

* Update the minimum to at least 3.0, possibly later if there are 
relevant features in later versions it would be convenient to use 
unconditionally.

* Clean up the uses of obsolescent MPFR interfaces such as those I listed 
in .  Many of 
those are just renamings, but it's still better for GCC to use the main 
interfaces people will know about from reading the MPFR manual rather than 
ones that, if documented at all, are documented as deprecated names.

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|build, diagnostic   |
 Blocks|24639   |

--- Comment #2 from Jason Merrill  ---
Do you have a reproducer?  It doesn't need to be reduced.  What platform are
you building on?


Referenced Bugs:

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

[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to David Malcolm from comment #0)
> Along with other dependencies, trunk's gcc/docs/install.texi has:
>   @item MPFR Library version 2.4.2 (or later)
> 
> I'm attempting to build trunk against that minimal version, mpfr-2.4.2, and
> the build of fortran fails with:
> 
> ../../../src/gcc/fortran/check.c: In function ‘void bin2real(gfc_expr*,
> int)’:
> ../../../src/gcc/fortran/check.c:257:7: error: ‘mpfr_set_z_2exp’ was not
> declared in this scope; did you mean ‘mpfr_get_d_2exp’?
>   257 |   mpfr_set_z_2exp (x->value.real, em, ie - t, GFC_RND_MODE);
>   |   ^~~
>   |   mpfr_get_d_2exp
> 
> This call to mpfr_set_z_2exp seems to have been added in
> 3d5ce34eb455518344e99966e87e7c44ed64d9da aka r274096 (for PR fortran/88227).
> 
> According to:
>   https://gmplib.org/list-archives/gmp-discuss/2010-June/004197.html
> mpfr_set_z_2exp was added in GNU MPFR 3.0.0:
>   "New function mpfr_set_z_2exp (companion to mpfr_get_z_2exp, which
>was renamed from mpfr_get_z_exp in previous versions)."
> 
> Should the minimum required version of mpfr be updated, or this check.c be
> rewritten?  (or am I misreading things)

2.4.2 was released 10 years ago and 3.0.0 was released 9 years ago.
I think updating the minimum requirement to at least 3.0.0 would be
fine.  In fact, it might be prudent to bump to 3.1.6, released on
2017-09-07, which appears to be the last release in the 3.x series.

[Bug c/67224] UTF-8 support for identifier names in GCC

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #32 from Joseph S. Myers  ---
Implemented for GCC 10.

[Bug c/67224] UTF-8 support for identifier names in GCC

[jsm28 at gcc dot gnu.org]

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

--- Comment #31 from Joseph S. Myers  ---
Author: jsm28
Date: Thu Sep 19 19:56:11 2019
New Revision: 275979

URL: https://gcc.gnu.org/viewcvs?rev=275979=gcc=rev
Log:
Support extended characters in C/C++ identifiers (PR c/67224)

libcpp/ChangeLog
2019-09-19  Lewis Hyatt  

PR c/67224
* charset.c (_cpp_valid_utf8): New function to help lex UTF-8 tokens.
* internal.h (_cpp_valid_utf8): Declare.
* lex.c (forms_identifier_p): Use it to recognize UTF-8 identifiers.
(_cpp_lex_direct): Handle UTF-8 in identifiers and CPP_OTHER tokens.
Do all work in "default" case to avoid slowing down typical code paths.
Also handle $ and UCN in the default case for consistency.

gcc/Changelog
2019-09-19  Lewis Hyatt  

PR c/67224
* doc/cpp.texi: Document support for extended characters in
identifiers.
* doc/cppopts.texi: Likewise.

gcc/testsuite/ChangeLog
2019-09-19  Lewis Hyatt  

PR c/67224
* c-c++-common/cpp/ucnid-2011-1-utf8.c: New test.
* g++.dg/cpp/ucnid-1-utf8.C: New test.
* g++.dg/cpp/ucnid-2-utf8.C: New test.
* g++.dg/cpp/ucnid-3-utf8.C: New test.
* g++.dg/cpp/ucnid-4-utf8.C: New test.
* g++.dg/other/ucnid-1-utf8.C: New test.
* gcc.dg/cpp/ucnid-1-utf8.c: New test.
* gcc.dg/cpp/ucnid-10-utf8.c: New test.
* gcc.dg/cpp/ucnid-11-utf8.c: New test.
* gcc.dg/cpp/ucnid-12-utf8.c: New test.
* gcc.dg/cpp/ucnid-13-utf8.c: New test.
* gcc.dg/cpp/ucnid-14-utf8.c: New test.
* gcc.dg/cpp/ucnid-15-utf8.c: New test.
* gcc.dg/cpp/ucnid-2-utf8.c: New test.
* gcc.dg/cpp/ucnid-3-utf8.c: New test.
* gcc.dg/cpp/ucnid-4-utf8.c: New test.
* gcc.dg/cpp/ucnid-6-utf8.c: New test.
* gcc.dg/cpp/ucnid-7-utf8.c: New test.
* gcc.dg/cpp/ucnid-9-utf8.c: New test.
* gcc.dg/ucnid-1-utf8.c: New test.
* gcc.dg/ucnid-10-utf8.c: New test.
* gcc.dg/ucnid-11-utf8.c: New test.
* gcc.dg/ucnid-12-utf8.c: New test.
* gcc.dg/ucnid-13-utf8.c: New test.
* gcc.dg/ucnid-14-utf8.c: New test.
* gcc.dg/ucnid-15-utf8.c: New test.
* gcc.dg/ucnid-16-utf8.c: New test.
* gcc.dg/ucnid-2-utf8.c: New test.
* gcc.dg/ucnid-3-utf8.c: New test.
* gcc.dg/ucnid-4-utf8.c: New test.
* gcc.dg/ucnid-5-utf8.c: New test.
* gcc.dg/ucnid-6-utf8.c: New test.
* gcc.dg/ucnid-7-utf8.c: New test.
* gcc.dg/ucnid-8-utf8.c: New test.
* gcc.dg/ucnid-9-utf8.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/cpp/ucnid-2011-1-utf8.c
trunk/gcc/testsuite/g++.dg/cpp/ucnid-1-utf8.C
trunk/gcc/testsuite/g++.dg/cpp/ucnid-2-utf8.C
trunk/gcc/testsuite/g++.dg/cpp/ucnid-3-utf8.C
trunk/gcc/testsuite/g++.dg/cpp/ucnid-4-utf8.C
trunk/gcc/testsuite/g++.dg/other/ucnid-1-utf8.C
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-1-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-10-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-11-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-12-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-13-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-14-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-15-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-2-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-3-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-4-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-6-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-7-utf8.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-9-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-1-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-10-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-11-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-12-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-13-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-14-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-15-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-16-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-2-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-3-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-4-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-5-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-6-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-7-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-8-utf8.c
trunk/gcc/testsuite/gcc.dg/ucnid-9-utf8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/cpp.texi
trunk/gcc/doc/cppopts.texi
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c
trunk/libcpp/internal.h
trunk/libcpp/lex.c

[Bug target/91823] [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
The test case works with that change.  I will run a comparison full test too to
check if everything else is still OK.

[Bug fortran/91828] New: gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 91828
   Summary: gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR
3.0.0, unavailable in mpfr-2.4.2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Along with other dependencies, trunk's gcc/docs/install.texi has:
  @item MPFR Library version 2.4.2 (or later)

I'm attempting to build trunk against that minimal version, mpfr-2.4.2, and the
build of fortran fails with:

../../../src/gcc/fortran/check.c: In function ‘void bin2real(gfc_expr*, int)’:
../../../src/gcc/fortran/check.c:257:7: error: ‘mpfr_set_z_2exp’ was not
declared in this scope; did you mean ‘mpfr_get_d_2exp’?
  257 |   mpfr_set_z_2exp (x->value.real, em, ie - t, GFC_RND_MODE);
  |   ^~~
  |   mpfr_get_d_2exp

This call to mpfr_set_z_2exp seems to have been added in
3d5ce34eb455518344e99966e87e7c44ed64d9da aka r274096 (for PR fortran/88227).

According to:
  https://gmplib.org/list-archives/gmp-discuss/2010-June/004197.html
mpfr_set_z_2exp was added in GNU MPFR 3.0.0:
  "New function mpfr_set_z_2exp (companion to mpfr_get_z_2exp, which
   was renamed from mpfr_get_z_exp in previous versions)."

Should the minimum required version of mpfr be updated, or this check.c be
rewritten?  (or am I misreading things)

[Bug c/91815] questionable error on type definition at file scope

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
Either gcc.dg or gcc.c-torture/compile would be fine for this test.

[Bug rtl-optimization/91823] [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Created attachment 46901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46901=edit
Candidate patch

Seems like a latent problem with non-canonical rtl.
Could you try the attached?

[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv

[dimitry at andric dot com]

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

--- Comment #5 from Dimitry Andric  ---
Hmm, it appears that this diff "fixes" it:

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 9505b4a1330..091a59f3cb9 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1166,7 +1166,11 @@ general_scalar_chain::convert_registers ()
   bitmap_iterator bi;
   unsigned id;
   EXECUTE_IF_SET_IN_BITMAP (defs_conv, 0, id, bi)
-defs_map.put (regno_reg_rtx[id], gen_reg_rtx (smode));
+{
+  rtx key = regno_reg_rtx[id];
+  rtx val = gen_reg_rtx (smode);
+  defs_map.put (key, val);
+}
   EXECUTE_IF_SET_IN_BITMAP (insns_conv, 0, id, bi)
 for (df_ref ref = DF_INSN_UID_DEFS (id); ref; ref = DF_REF_NEXT_LOC (ref))
   if (bitmap_bit_p (defs_conv, DF_REF_REGNO (ref)))

but obviously that can't be right, unless gen_reg_rtx() is doing something
horrible to regno_reg_rtx[].  I only see it adding another element at the end,
though.

I think this might indeed be some clang code generation bug, as the assembly
looks a little different with the above patch applied.

Digging further...

[Bug c/91815] questionable error on type definition at file scope

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Created attachment 46900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46900=edit
Proposed fix #2

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/91815] questionable error on type definition at file scope

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
The fixlet slightly breaks Objective-C:

+FAIL: objc.dg/headers.m -fgnu-runtime (test for excess errors)
+FAIL: objc.dg/id-1.m -fgnu-runtime  (test for errors, line 4)
+FAIL: objc.dg/id-1.m -fgnu-runtime  (test for warnings, line )

It looks like the Objective-C compiler uses the code to deal with declarations
conflicting with (or shadowing) the declarations of the basic types in objc.h.

[Bug rtl-optimization/91823] [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug bootstrap/91825] Top-of-tree GCC does not bootstrap (uninitialized warning)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Trying to reduce, but it will take a while.

[Bug tree-optimization/91822] [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Thanks for fixing this, think it was entirely my patch
to blame.  (I'd tested it on SVE only, oops.)

Agree the patch in #c2 looks like the way to go.

[Bug target/91702] [9/10 Regression] ICE with mips16

[g...@hauke-m.de]

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

--- Comment #2 from Hauke Mehrtens  ---
I backported https://gcc.gnu.org/viewcvs/gcc?view=revision=273174 on
top of GCC 9.2.0 and I do not see this problem any more, OpenWrt compiles now
file with these settings. Please backport this change to the gcc 9 branch.

[Bug libstdc++/91827] New: const std::experimental::optional is not std::is_nothrow_move_constructible

[rafael at espindo dot la]

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

Bug ID: 91827
   Summary: const std::experimental::optional is not
std::is_nothrow_move_constructible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

Only the first static_assert in the following example fails.

#include 
#include 

void foo(const std::experimental::optional timeout) {
static_assert(std::is_nothrow_move_constructible>::value, "foobar");
static_assert(std::is_nothrow_move_constructible>::value, "foobar");
}

[Bug c++/91826] New: Unexpected behavior when class defined with namespace alias

[mf at simerics dot com]

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

Bug ID: 91826
   Summary: Unexpected behavior when class defined with namespace
alias
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mf at simerics dot com
  Target Milestone: ---

The following code compile on GCC 7.3, MSVC 2015 & 2019.

It fail on GCC 9.2 with error: declaration of ‘class N2::N::C2’ in namespace
‘N2’ which does not enclose ‘N2::A2’

namespace N1 { class C1; }
namespace A1 = N1;
class A1::C1 {}; //Ok

namespace N2
{
  namespace N { class C2; }
  namespace A2 = N;
  class A2::C2 {}; //Error
}

namespace N3 { namespace N { class C3; } }
namespace A3 = N3::N;
class A3::C3 {}; //Ok

[Bug bootstrap/91825] New: Top-of-tree GCC does not bootstrap (uninitialized warning)

[sje at gcc dot gnu.org]

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

Bug ID: 91825
   Summary: Top-of-tree GCC does not bootstrap (uninitialized
warning)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

GCC bootstrap currently fails with this error:

/home/sellcey/tot/src/gcc/gcc/expmed.c: In function ‘rtx_def*
emit_store_flag_1(rtx, rtx_code, rtx, rtx, machine_mode, int, int,
machine_mode)’:
/home/sellcey/tot/src/gcc/gcc/expmed.c:5602:19: error: ‘int_mode’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
 5602 |   scalar_int_mode int_mode;
  |   ^~~~


This appears to be due to:

https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00923.html

[Bug fortran/91727] [7/8/9/10 Regression] ICE in conformable_arrays, at fortran/resolve.c:7490

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Thanks for bug report.

[Bug fortran/91727] [7/8/9/10 Regression] ICE in conformable_arrays, at fortran/resolve.c:7490

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep 19 17:54:53 2019
New Revision: 275973

URL: https://gcc.gnu.org/viewcvs?rev=275973=gcc=rev
Log:
2019-09-19  Steven G. Kargl  

PR fortran/91727
* resolve.c (conformable_arrays):  If array-spec is NULL, then
allocate-object is a scalar.  a conformability check only occurs
for an array source-expr.

2019-09-19  Steven G. Kargl  

PR fortran/91727
* gfortran.dg/pr91727.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91727.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/resolve.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c/91815] questionable error on type definition at file scope

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
> Yes, that looks like a plausible fix (given testcase added to the 
> testsuite and regression testing).

Thanks, the fixlet was regression-tested with check-c and I'm going to launch a
full testing cycle now.  Where should I put the testcase?  Simply in gcc.dg?

[Bug tree-optimization/91822] [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So I belive we can fix this with

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 275972)
+++ gcc/tree-vect-loop.c(working copy)
@@ -6534,9 +6534,10 @@ vectorizable_reduction (stmt_vec_info st
 {
   /* Only call during the analysis stage, otherwise we'll lose
 STMT_VINFO_TYPE.  */
-  gcc_assert (reduc_index > 0);
+  gcc_assert (nested_cycle || reduc_index > 0);
   if (!vec_stmt && !vectorizable_condition (stmt_info, gsi, NULL,
-   reduc_index, NULL, cost_vec))
+   nested_cycle ? 0 : reduc_index,
+   NULL, cost_vec))
 {
   if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

not sure what in the end exposed it but nested cycle vectorization treats
the stmts as regular stmt, not really caring about reduc_index.  I'll have to
dig (tomorrow) what we've done with the testcase before but it's indeed
the case that relaxing nested cycle things exposes "interesting" paths in
vectorizable_reduction.  One of my goals is to split that out, but I'm doing
baby steps in this code...

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Candidate fix:

diff --git gcc/cp/call.c gcc/cp/call.c
index b780b0af58e..b806faacf03 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -5878,7 +5885,10 @@ build_new_op_1 (const op_location_t , enum tree_code
code, int flags,
 goto builtin;

   if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
-arg2 = integer_zero_node;
+{
+  arg2 = integer_zero_node;
+  arg2_type = integer_type_node;
+}

   vec_alloc (arglist, 3);
   arglist->quick_push (arg1);

[Bug middle-end/91824] New: unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount

[vanyacpp at gmail dot com]

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

Bug ID: 91824
   Summary: unnecessary sign-extension after _mm_movemask_epi8 or
__builtin_popcount
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

gcc -O2 -mpopcnt leaves unnecessary cdqe:

#include 
#include 

void f(uint64_t& val, __m128i mask)
{
val += __builtin_popcount(_mm_movemask_epi8(mask));
}

void g(uint64_t& val, __m128i mask)
{
val += __builtin_popcountll(_mm_movemask_epi8(mask));
}

f:
  pmovmskb eax, xmm0
  popcnt eax, eax
  cdqe
  add QWORD PTR [rdi], rax
  ret
g:
  pmovmskb eax, xmm0
  cdqe
  popcnt rax, rax
  add QWORD PTR [rdi], rax
  ret

Both cdqe are unnecessary, because the results of both pmovmskb and
__builtin_popcount can not be negative.

Only lower 16 bits of pmovmskb can be non-zero. And the image of popcnt is
either [0..32] or [0..64] depending on the argument.

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot 
gnu.org

--- Comment #27 from Jim Wilson  ---
Fixed on mainline and gcc-9 branch.

[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Host|powerpc64le-unknown-linux-g |
   |nu  |
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Build|powerpc64le-unknown-linux-g |
   |nu  |

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
The problem is that for POSTINCREMENT_EXPR build_new_op_1 is called with null
arg2, so arg2_type is also null, but then we make arg2 nonnull
 5887   if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
 5888 arg2 = integer_zero_node;
and so
 5940   else if (! arg2 || ! CLASS_TYPE_P (arg2_type))
crashes.

[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Host|powerpc64le-unknown-linux-g |
   |nu  |
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Build|powerpc64le-unknown-linux-g |
   |nu  |

[Bug tree-optimization/91532] [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 Depends on||33315
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
gcc.target/aarch64/sve/fmla_2.c you mean?

I think this is the old issue of no pass doing hoisting/sinking of stores where
my patch for PR33315 would help, transforming

  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 527260923]:
  _9 = c_30(D) + _2;
  _10 = *_9;
  iftmp.0_31 = __builtin_fma (_10, pretmp_54, pretmp_53);
  *_55 = iftmp.0_31;
  iftmp.1_35 = __builtin_fma (_10, pretmp_53, pretmp_54);
  goto ; [100.00%]

   [local count: 527260923]:
  *_55 = pretmp_53;

   [local count: 1054521846]:
  # iftmp.1_23 = PHI 
  _20 = b_36(D) + _2;

to

  if (_4 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 527260923]:
  _9 = c_30(D) + _2;
  _10 = *_9;
  iftmp.0_31 = __builtin_fma (_10, pretmp_54, pretmp_53);
  iftmp.1_35 = __builtin_fma (_10, pretmp_53, pretmp_54);
  goto ; [100.00%]

   [local count: 527260923]:

   [local count: 1054521846]:
  # tem = PHI 
  # iftmp.1_23 = PHI 
  *_55 = tem;
  _20 = b_36(D) + _2;

with the disadvantage of increasing lifetime of the sources.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug 33315] stores not commoned by sinking

[Bug rtl-optimization/91823] New: [10 regression] r275959 breaks gcc.target/powerpc/altivec-32.c with ICE

[seurer at gcc dot gnu.org]

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

Bug ID: 91823
   Summary: [10 regression] r275959 breaks
gcc.target/powerpc/altivec-32.c with ICE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/altivec-32.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -O2 -ftree-vectorize -mdejagnu-cpu=power6 -maltivec
-ffat-lto-objects -fno-ident -S -o altivec-32.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/altivec-32.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -ftree-vectorize -mdejagnu-cpu=power6 -maltivec
-ffat-lto-objects -fno-ident -S -o altivec-32.s
during RTL pass: cse1
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/altivec-32.c: In
function 'vector_copysign':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/altivec-32.c:59:1:
internal compiler error: in decompose, at rtl.h:2279
0x10a488a3 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/home/seurer/gcc/gcc-test2/gcc/rtl.h:2277
0x10a488a3 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/home/seurer/gcc/gcc-test2/gcc/wide-int.h:1023
0x10a488a3 generic_wide_int
>::generic_wide_int >(std::pair const&)
/home/seurer/gcc/gcc-test2/gcc/wide-int.h:782
0x10a488a3 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/home/seurer/gcc/gcc-test2/gcc/simplify-rtx.c:6215
0x10a482c3 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/home/seurer/gcc/gcc-test2/gcc/simplify-rtx.c:6185
0x10a567cf simplify_const_vector_subreg
/home/seurer/gcc/gcc-test2/gcc/simplify-rtx.c:6534
0x10a567cf simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/home/seurer/gcc/gcc-test2/gcc/simplify-rtx.c:6649
0x114f000b equiv_constant
/home/seurer/gcc/gcc-test2/gcc/cse.c:3852
0x114f3b07 fold_rtx
/home/seurer/gcc/gcc-test2/gcc/cse.c:3231
0x114f389b fold_rtx
/home/seurer/gcc/gcc-test2/gcc/cse.c:3266
0x114f58b3 cse_insn
/home/seurer/gcc/gcc-test2/gcc/cse.c:4705
0x114fa43b cse_extended_basic_block
/home/seurer/gcc/gcc-test2/gcc/cse.c:6651
0x114fa43b cse_main
/home/seurer/gcc/gcc-test2/gcc/cse.c:6830
0x114faf3f rest_of_handle_cse
/home/seurer/gcc/gcc-test2/gcc/cse.c:7667
0x114faf3f execute
/home/seurer/gcc/gcc-test2/gcc/cse.c:7710
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.target/powerpc/altivec-32.c (internal compiler error)
FAIL: gcc.target/powerpc/altivec-32.c (test for excess errors)

[Bug tree-optimization/91822] [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/91822] New: [10 Regression] FAIL: gcc.dg/pr88031.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Bug ID: 91822
   Summary: [10 Regression] FAIL: gcc.dg/pr88031.c (internal
compiler error)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

One of my reduction changes together with the new asserts from r275962 cause
this to ICE.

#0  fancy_abort (file=0x2527b40 "../../src/trunk/gcc/tree-vect-loop.c",
line=6662, 
function=0x252aa10 *)::__FUNCTION__>
"vectorizable_reduction") at ../../src/trunk/gcc/diagnostic.c:1617
#1  0x015a788e in vectorizable_reduction (stmt_info=0x357a5d0, gsi=0x0,
vec_stmt=0x0, slp_node=0x0, slp_node_instance=0x0, 
cost_vec=0x7fffc490) at ../../src/trunk/gcc/tree-vect-loop.c:6662
#2  0x015876d5 in vect_analyze_stmt (stmt_info=0x357a5d0,
need_to_vectorize=0x7fffc49f, node=0x0, node_instance=0x0,
cost_vec=0x7fffc490)
at ../../src/trunk/gcc/tree-vect-stmts.c:10668
#3  0x01598071 in vect_analyze_loop_operations (loop_vinfo=0x357a030)
at ../../src/trunk/gcc/tree-vect-loop.c:1580
#4  0x01599818 in vect_analyze_loop_2 (loop_vinfo=0x357a030,
fatal=@0x7fffd15f: false, n_stmts=0x7fffd1a4)
at ../../src/trunk/gcc/tree-vect-loop.c:2026

[Bug testsuite/91821] [10 regression] r275928 breaks gcc.target/powerpc/sad-vectorize-2.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I'll take a look.

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 19 17:05:51 2019
New Revision: 275971

URL: https://gcc.gnu.org/viewcvs?rev=275971=gcc=rev
Log:
2019-09-19  Richard Biener  

PR target/91814
* config/i386/i386-features.c (gen_gpr_to_xmm_move_src):
Force operand to a register if it isn't nonimmediate_operand.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/91820] missing error diagnosis of '&' in initialization

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
This is probably a duplicate of other bugs for cases that are not required 
in the standard to be constant expressions but are permitted as additional 
implementation-defined kinds of constant expressions in initializers (and 
that GCC permits as such).

[Bug c/91815] questionable error on type definition at file scope

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Yes, that looks like a plausible fix (given testcase added to the 
testsuite and regression testing).

[Bug testsuite/91821] New: [10 regression] r275928 breaks gcc.target/powerpc/sad-vectorize-2.c

[seurer at gcc dot gnu.org]

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

Bug ID: 91821
   Summary: [10 regression] r275928 breaks
gcc.target/powerpc/sad-vectorize-2.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test case just looks for instruction counts so it may just need to be
updated.

make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/sad-vectorize-2.c

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sad-vectorize-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O3 -mdejagnu-cpu=power9 -ffat-lto-objects -fno-ident
-S -o sad-vectorize-2.s
PASS: gcc.target/powerpc/sad-vectorize-2.c (test for excess errors)
gcc.target/powerpc/sad-vectorize-2.c: vabsduh found 0 times
FAIL: gcc.target/powerpc/sad-vectorize-2.c scan-assembler-times vabsduh 16
gcc.target/powerpc/sad-vectorize-2.c: vsum4shs found 0 times
FAIL: gcc.target/powerpc/sad-vectorize-2.c scan-assembler-times vsum4shs 16
gcc.target/powerpc/sad-vectorize-2.c: vadduwm found 0 times
FAIL: gcc.target/powerpc/sad-vectorize-2.c scan-assembler-times vadduwm 17
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ vmx_hw_available127190.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -mno-vsx  -lm  -o vmx_hw_available127190.exe   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ vmx_hw_available127190.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available127190.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
testcase
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/powerpc.exp
completed in 0 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures3


The generated assembler is quite different:

seurer@makalu-lp1:~/gcc/build/gcc-test$ diff sad-vectorize-2.s.r275927
../gcc-test2/sad-vectorize-2.s.r275928 
16,116c16,123
<   lxv 33,0(3)
<   xxspltib 32,0
<   lxv 49,0(4)
<   sldi 10,5,1
<   lxv 36,80(3)
<   lxv 37,96(3)
<   lxvx 50,4,10
<   lxv 38,112(3)
<   add 9,4,10
<   lxv 39,128(3)
<   lxv 40,144(3)
<   lxvx 51,9,10
<   lxv 41,160(3)
<   add 9,9,10
<   vabsduh 17,1,17
<   lxv 33,16(3)
<   lxv 42,176(3)
<   lxvx 34,9,10
<   lxv 43,192(3)
<   add 9,9,10
<   lxv 44,208(3)
<   lxv 45,224(3)
<   vsum4shs 17,17,0
<   lxvx 35,9,10
<   add 9,9,10
<   vabsduh 18,1,18
<   lxv 33,32(3)
<   lxvx 48,9,10
<   add 9,9,10
<   lxvx 47,9,10
<   add 9,9,10
<   vsum4shs 18,18,0
<   vabsduh 19,1,19
<   lxv 33,48(3)
<   vabsduh 4,4,16
<   lxvx 48,9,10
<   add 9,9,10
<   vabsduh 5,5,15
<   vsum4shs 19,19,0
<   vabsduh 2,1,2
<   lxv 33,64(3)
<   vadduwm 18,18,17
<   lxvx 49,9,10
<   add 9,9,10
<   vabsduh 6,6,16
<   vsum4shs 2,2,0
<   vabsduh 3,1,3
<   lxv 33,240(3)
<   vadduwm 19,19,18
<   lxvx 50,9,10
<   add 9,9,10
<   vabsduh 7,7,17
<   vsum4shs 3,3,0
<   vsum4shs 4,4,0
<   vsum4shs 5,5,0
<   vsum4shs 6,6,0
<   vadduwm 2,2,19
<   lxvx 51,9,10
<   add 9,9,10
<   vsum4shs 7,7,0
<   vabsduh 8,8,18
<   vsum4shs 8,8,0
<   vadduwm 3,3,2
<   lxvx 34,9,10
<   add 9,9,10
<   vabsduh 9,9,19
<   vadduwm 4,4,3
<   lxvx 35,9,10
<   add 9,9,10
<   vsum4shs 9,9,0
<   vabsduh 10,10,2
<   vadduwm 5,5,4
<   lxvx 36,9,10
<   add 9,9,10
<   vsum4shs 10,10,0
<   vabsduh 11,11,3
<   vadduwm 6,6,5
<   lxvx 37,9,10
<   add 9,9,10
<   vsum4shs 11,11,0
<   vabsduh 12,12,4
<   vadduwm 7,7,6
<   lxvx 38,9,10
<   vsum4shs 12,12,0
<   vabsduh 13,13,5
<   vadduwm 8,8,7
<   vsum4shs 13,13,0
<   vabsduh 1,1,6
<   vadduwm 9,9,8
<   vsum4shs 1,1,0
<   vadduwm 10,10,9
<   vadduwm 11,11,10
<   

[Bug c/91820] missing error diagnosis of '&' in initialization

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
-pedantic-errors

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |ice-on-valid-code
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r275745.

[Bug c/91820] missing error diagnosis of '&' in initialization

[tangyixuan at mail dot dlut.edu.cn]

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

--- Comment #3 from tangyixuan  ---
(In reply to Andrew Pinski from comment #1)
> does adding -pedantic help?
Thanks for your reply.
When I add -padantic, gcc-trunk reports warning :
 2:45: warning：initialization of ‘volatile int * volatile* const*’ from
incompatible pointer type ‘volatile int * volatile* const’
[-Wincompatible-pointer-types]
2 | static volatile int * volatile * const *b = a;
target:  Ubuntu 4.8.5-4ubuntu8~14.04.2
If I use -w, I do not know where is error. I think reporting an error would be
better if possible.

[Bug debug/91817] compile with -O3 is more-than-expectedly slower than -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||5.3.1
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
On x86_64-linux with GCC 8 I see

rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g
0.39user 0.02system 0:00.42elapsed 99%CPU (0avgtext+0avgdata 90428maxresident)k
0inputs+3648outputs (0major+20612minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O
1.77user 0.05system 0:01.82elapsed 100%CPU (0avgtext+0avgdata
141920maxresident)k
0inputs+5280outputs (0major+33933minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O2
8.01user 0.08system 0:08.10elapsed 99%CPU (0avgtext+0avgdata
330268maxresident)k
0inputs+6272outputs (0major+86763minor)pagefaults 0swaps
rguenther@murzim:/tmp> /usr/bin/time gcc-8 -S 1.i -m32 -g -O3
8.19user 0.11system 0:08.31elapsed 99%CPU (0avgtext+0avgdata
332380maxresident)k
0inputs+6344outputs (0major+94164minor)pagefaults 0swaps

Same for GCC 7.

note GCC 4.6 is very old so it's somewhat pointless to complain about its
compile-time speed.  Nevertheless I can reproduce the slowness with that
version so I am assuming this issue has been fixed, in 5.3.1 at least.

[Bug target/91818] SSE optimization flaw with float vs. double

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It's a feature, using vrsqrtps plus newton raphson is supposed to be faster
than vsqrtps.

[Bug c++/91819] [10 Regression] ICE when iterating over enum values

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
   Target Milestone|--- |10.0
Summary|ICE when iterating over |[10 Regression] ICE when
   |enum values |iterating over enum values
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

t.ii: In function ‘int main()’:
t.ii:15:29: internal compiler error: Segmentation fault
   15 |for (Foo f = a; f <= b; f++) {
  | ^~
0x14b0c1f crash_signal
../../src/trunk/gcc/toplev.c:326
0x8ff84b build_new_op_1
../../src/trunk/gcc/cp/call.c:5933
0x9008aa build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
../../src/trunk/gcc/cp/call.c:6278
0xc38922 build_x_unary_op(unsigned int, tree_code, cp_expr, int)
../../src/trunk/gcc/cp/typeck.c:5783
0xbd1bc4 finish_increment_expr(cp_expr, tree_code)
../../src/trunk/gcc/cp/semantics.c:2702
0xac961a cp_parser_postfix_expression
../../src/trunk/gcc/cp/parser.c:7462

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Richard Biener from comment #2)
> > ISTR discussing this but holding back a fix at the time we weren't sure if
> > we'd preserve the non-subreg sets.  So sth like 
> > 
> > Index: gcc/config/i386/i386-features.c
> > ===
> > --- gcc/config/i386/i386-features.c (revision 275698)
> > +++ gcc/config/i386/i386-features.c (working copy)
> > @@ -668,6 +668,8 @@ scalar_chain::emit_conversion_insns (rtx
> >  static rtx
> >  gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
> >  {
> > +  if (!x86_64_general_operand (gpr, GET_MODE_INNER (vmode)))
> > +gpr = force_reg (GET_MODE_INNER (vmode), gpr);
> >switch (GET_MODE_NUNITS (vmode))
> >  {
> >  case 1:
> > 
> > fixes it with the question whether the use of x86_64_general_operand
> > is correct and whether it's necessary for the NUNITS == 1 case
> > (which IIRC isn't exercised anyway).

Tested the above successfully.

> We should use nonimmediate_operand for NUNITS != 1. Perhaps also add
> gcc_unreachable () for NUNITS == 1 case.

OK, will test the following which works on the testcase as well

Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 275959)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -668,10 +668,13 @@ scalar_chain::emit_conversion_insns (rtx
 static rtx
 gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
 {
+  if (!nonimmediate_operand (gpr, GET_MODE_INNER (vmode)))
+gpr = force_reg (GET_MODE_INNER (vmode), gpr);
   switch (GET_MODE_NUNITS (vmode))
 {
 case 1:
-  return gen_rtx_SUBREG (vmode, gpr, 0);
+  /* We are not using this case currently.  */
+  gcc_unreachable ();
 case 2:
   return gen_rtx_VEC_CONCAT (vmode, gpr,
 CONST0_RTX (GET_MODE_INNER (vmode)));

[Bug tree-optimization/91812] [7/8/9 Regression] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
  Known to work||10.0
   Target Milestone|--- |7.5
Summary|GCC ignores volatile|[7/8/9 Regression] GCC
   |modifier|ignores volatile modifier

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.  Regression from before phiprop addition.

[Bug c/91820] missing error diagnosis of '&' in initialization

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
My bet is that a is being treated as a "NULL Pointer cosntant"

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 19 12:49:45 2019
New Revision: 275960

URL: https://gcc.gnu.org/viewcvs?rev=275960=gcc=rev
Log:
2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiprop.c

[Bug c/91820] missing error diagnosis of '&' in initialization

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
does adding -pedantic help?

[Bug c/91820] New: missing error diagnosis of '&' in initialization

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 91820
   Summary: missing error diagnosis of '&' in initialization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

GCC-trunk do not report the error diagnosis when there misses '&' in the
initialization. For example:

$: cat s.c
  static volatile int * volatile * const a = (void*)0;
  static volatile int * volatile * const *b = a;
  int main (int argc, char* argv[])
  {
  if((void*)0 != b)   printf("error");  
  }

$: ../gcc-7.4/bin/gcc s.c
  s.c:2:45: error: Inilializer element is not constant

$: ../gcc-trunk/bin/gcc s.c

version of GCC: 
gcc version 10.0.0 20190913 (experimental) (GCC)

gcc-7 can not generate an executable file but gcc-trunk can.

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
OK, so while the comment says to exclude volatile the code never checked for
that:

/* We cannot replace a load that may throw or is volatile.  */
&& !stmt_can_throw_internal (cfun, use_stmt)))

the situation is also more subtle as generally replacing a volatile load is
OK but only when the number of times it is executed does not change.
Currently we're set up for (post-)dominator checks but with those there's
no guarantee of this.  Instead we'd have to use loop information and look
out for irreducible regions.  Not worth the trouble, but it will make
code doing std::max (volatile, ..) less optimal (and I do remember C++
code ticking const volatile on all incoming parameters just to avoid
warnings when passing in volatile qualified pointers...).

[Bug c++/91819] New: ICE when iterating over enum values

[moritz.kreutzer at siemens dot com]

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

Bug ID: 91819
   Summary: ICE when iterating over enum values
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz.kreutzer at siemens dot com
  Target Milestone: ---

Created attachment 46899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46899=edit
Preprocessed source and backtrace

Hi,

we are getting an ICE with the latest trunk of GCC with the following code:


enum Foo
{
  a,
  b
};

inline Foo operator++(Foo , int) 
{
  return f = (Foo)(f + 1);
}

int main()
{
  int count = 0;
  for (Foo f = a; f <= b; f++) {
count++;
  }
  return count;
}


GCC 9 and older seem to be working: https://godbolt.org/z/UO37hz

The preprocessed source and backtrace are attached. Let me know if you need
further information.


Thanks,
Moritz

[Bug target/86811] Vax port needs updating for CVE-2017-5753

[coypu at sdf dot org]

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

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #1 from coypu  ---
I sent a patch to gcc-patches.
vax does not need speculation barriers. it doesn't speculate.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01031.html

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

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

--- Comment #7 from coypu  ---
I sent a patch to gcc-patches.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00896.html

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> ISTR discussing this but holding back a fix at the time we weren't sure if
> we'd preserve the non-subreg sets.  So sth like 
> 
> Index: gcc/config/i386/i386-features.c
> ===
> --- gcc/config/i386/i386-features.c (revision 275698)
> +++ gcc/config/i386/i386-features.c (working copy)
> @@ -668,6 +668,8 @@ scalar_chain::emit_conversion_insns (rtx
>  static rtx
>  gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
>  {
> +  if (!x86_64_general_operand (gpr, GET_MODE_INNER (vmode)))
> +gpr = force_reg (GET_MODE_INNER (vmode), gpr);
>switch (GET_MODE_NUNITS (vmode))
>  {
>  case 1:
> 
> fixes it with the question whether the use of x86_64_general_operand
> is correct and whether it's necessary for the NUNITS == 1 case
> (which IIRC isn't exercised anyway).

We should use nonimmediate_operand for NUNITS != 1. Perhaps also add
gcc_unreachable () for NUNITS == 1 case.

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

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
One other thing I was thinking of would be the do_sleep function with:

   #pragma omp declare target device_type(host)

(using usleep) AND (using busy wait or similar)

   #pragma omp declare target device_type(host)

However, that's an unimplemented OpenMP 5 feature.

[Bug c++/91818] New: SSE optimization flaw with float vs. double

[warp at iki dot fi]

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

Bug ID: 91818
   Summary: SSE optimization flaw with float vs. double
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: warp at iki dot fi
  Target Milestone: ---

Consider the following code:

//-
#include 
#include 

using Float = std::array;

Float p(Float a, Float b)
{
Float result;
for(unsigned i = 0; i < result.size(); ++i)
result[i] = std::sqrt(a[i]*a[i] + b[i]*b[i]);
return result;
}
//-

When compiled with gcc 9.2, using -Ofast -march=skylake, it produces the
following result:

//-
pushrbp
mov rax, rdi
mov rbp, rsp
vmovupd ymm1, YMMWORD PTR [rbp+48]
vmovupd ymm0, YMMWORD PTR [rbp+16]
vmulpd  ymm1, ymm1, ymm1
vfmadd132pd ymm0, ymm1, ymm0
vsqrtpd ymm0, ymm0
vmovupd YMMWORD PTR [rdi], ymm0
vzeroupper
pop rbp
ret
//-

Besides the surrounding boilerplate (which might or might not be necessary, I'm
not knowledgeable enough to fully understand this), the actual operations are
sensible.

However, consider what happens if we change the type alias to:

using Float = std::array;

One would think the result would be almost identical, yet this is produced:

//-
pushrbp
vxorps  xmm2, xmm2, xmm2
mov rax, rdi
mov rbp, rsp
vmovups ymm1, YMMWORD PTR [rbp+48]
vmovups ymm0, YMMWORD PTR [rbp+16]
vmulps  ymm1, ymm1, ymm1
vfmadd132ps ymm0, ymm1, ymm0
vrsqrtpsymm1, ymm0
vcmpneqps   ymm2, ymm2, ymm0
vandps  ymm1, ymm1, ymm2
vmulps  ymm0, ymm1, ymm0
vmulps  ymm1, ymm0, ymm1
vmulps  ymm0, ymm0, YMMWORD PTR .LC1[rip]
vaddps  ymm1, ymm1, YMMWORD PTR .LC0[rip]
vmulps  ymm0, ymm1, ymm0
vmovups YMMWORD PTR [rdi], ymm0
vzeroupper
pop rbp
ret
.LC0:
.long   3225419776
.long   3225419776
.long   3225419776
.long   3225419776
.long   3225419776
.long   3225419776
.long   3225419776
.long   3225419776
.LC1:
.long   3204448256
.long   3204448256
.long   3204448256
.long   3204448256
.long   3204448256
.long   3204448256
.long   3204448256
.long   3204448256
//-

This is not a question of the number of loops being 8, as

using Float = std::array;

produces a very similar result.

Note that clang 8.0 produces this (from the  version of the code):

//-
mov rax, rdi
vmovups ymm0, ymmword ptr [rsp + 8]
vmulps  ymm0, ymm0, ymm0
vmovups ymm1, ymmword ptr [rsp + 40]
vfmadd213ps ymm1, ymm1, ymm0
vsqrtps ymm0, ymm1
vmovups ymmword ptr [rdi], ymm0
vzeroupper
ret
//-

[Bug c/91817] compile with -O3 is more-than-expectedly slower than -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-19
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Maybe a duplicate of PR78288?

[Bug c/91817] New: compile with -O3 is more-than-expectedly slower than -O2

[hehaochen at hotmail dot com]

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

Bug ID: 91817
   Summary: compile with -O3 is more-than-expectedly slower than
-O2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hehaochen at hotmail dot com
  Target Milestone: ---

Created attachment 46898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46898=edit
this test case is from gcc-45364

### This is normal in GCC 5.3.1(Docker version): ### 

root@ubuntu:/home/jxl# time gcc -m32 -o1 -g -c 1.i -o test.o
real 0m1.017s
user 0m0.876s
sys 0m0.072s

root@ubuntu:/home/jxl# time gcc -m32 -o2 -g -c 1.i -o test.o
real 0m1.250s
user 0m0.864s
sys 0m0.064s

root@ubuntu:/home/jxl# time gcc -m32 -o3 -g -c 1.i -o test.o
real 0m4.446s
user 0m0.700s
sys 0m0.476s


### HOWEVER, it is extremely slow in GCC 4.6(Docker version): ### 

root@4beb8027e1fb:/# time gcc -m32 -o1 -g -c 1.i -o test.o
real 0m3.066s
user 0m0.656s
sys 0m0.772s

root@4beb8027e1fb:/# time gcc -m32 -o2 -g -c 1.i -o test.o
real 0m1.112s
user 0m0.796s
sys 0m0.156s

root@4beb8027e1fb:/# time gcc -m32 -O3 -g -c 1.i -o test.o
real 2m55.363s
user 2m41.224s
sys 0m1.908s

## Root cause locates in "var-tracking dataflow" ##

root@4beb8027e1fb:/# gcc -m32 -O3 -ftime-report -g -c 1.i -o test.o

Execution times (seconds)
 callgraph construction:   0.00 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall   
1432 kB ( 1%) ggc
 callgraph optimization:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
 137 kB ( 0%) ggc
 ipa function splitting:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 528 kB ( 1%) ggc
 ipa pure const:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
  25 kB ( 0%) ggc
 ipa SRA   :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall   
 405 kB ( 0%) ggc
 cfg cleanup   :   0.08 ( 0%) usr   0.01 ( 0%) sys   0.11 ( 0%) wall   
 549 kB ( 1%) ggc
 trivially dead code   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 df scan insns :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall   
   6 kB ( 0%) ggc
 df multiple defs  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 df reaching defs  :   0.12 ( 0%) usr   0.02 ( 1%) sys   0.12 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs  :   0.35 ( 0%) usr   0.01 ( 0%) sys   0.35 ( 0%) wall   
   0 kB ( 0%) ggc
 df live regs:   0.20 ( 0%) usr   0.01 ( 0%) sys   0.25 ( 0%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   0.04 ( 0%) usr   0.02 ( 1%) sys   0.07 ( 0%)
wall   0 kB ( 0%) ggc
 df live reg subwords  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 df reg dead/unused notes:   0.10 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
   585 kB ( 1%) ggc
 register information  :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
2860 kB ( 3%) ggc
 alias stmt walking:   0.11 ( 0%) usr   0.06 ( 2%) sys   0.17 ( 0%) wall   
   8 kB ( 0%) ggc
 register scan :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   9 kB ( 0%) ggc
 rebuild jump labels   :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 preprocessing :   0.07 ( 0%) usr   0.35 (14%) sys   0.45 ( 0%) wall   
3387 kB ( 3%) ggc
 lexical analysis  :   0.19 ( 0%) usr   0.57 (23%) sys   0.74 ( 0%) wall   
   0 kB ( 0%) ggc
 parser:   0.13 ( 0%) usr   0.47 (19%) sys   0.72 ( 0%) wall  
18502 kB (18%) ggc
 inline heuristics :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall   
 133 kB ( 0%) ggc
 integration   :   0.07 ( 0%) usr   0.05 ( 2%) sys   0.14 ( 0%) wall   
8467 kB ( 8%) ggc
 tree gimplify :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
4760 kB ( 5%) ggc
 tree CFG construction :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
1460 kB ( 1%) ggc
 tree CFG cleanup  :   0.04 ( 0%) usr   0.02 ( 1%) sys   0.11 ( 0%) wall   
 318 kB ( 0%) ggc
 tree VRP  :   0.10 ( 0%) usr   0.04 ( 2%) sys   0.14 ( 0%) wall   
2898 kB ( 3%) ggc
 tree copy propagation :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall   
 197 kB ( 0%) ggc
 tree PTA  :   0.07 ( 0%) usr   0.02 ( 1%) sys   0.06 ( 0%) wall   
 582 kB ( 1%) ggc
 tree SSA rewrite  :   0.05 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) wall   
1884 kB ( 2%) ggc
 tree SSA other:   0.02 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall   
  17 kB ( 0%) ggc
 tree SSA incremental  :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.08 ( 0%) wall   
 706 kB ( 1%) ggc
 tree operand scan :   0.05 ( 0%) usr   0.09 ( 4%) sys   0.13 ( 0%) wall   
4319 kB ( 4%) ggc
 dominator optimization:   0.05 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall   
1525 kB ( 1%) ggc
 

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  ---
Regarding the code in comment 1 (which additionally lacks a "void" in the
decl):
The omp_is_initial_device() is only resolved at run time - hence, I think the
linker still wants to see "usleep".


I was wondering whether one shouldn't clone the files and use:

/* { dg-do run { target { { ! openacc_nvidia_accel_selected } && { !
openacc_amdgcn_accel_selected } } } } */

And the clone without "!" but with "||".


Other remarks:

* libgomp.c/target-32.c fails at run time with:
libgomp: GOMP_OFFLOAD_async_run unimplemented
as soon as one got passed the usleep issue (e.g. by replacing it by a no-op)

* libgomp.c/thread-limit-2.c compiles - but it doesn't do anything on the GPU
due to:
  #pragma omp target if (0)


Regarding the do_sleep replacement:

* One needs to use additionally __attribute__((always_inline)) otherwise, it
fails with:
  function 'do_sleep' has been referenced in offloaded code but hasn't been
marked to be included in the offloaded code

* If one tries it with:
   #pragma omp declare target
that fails to compile with


libgomp.c/thread-limit-2.c compiles - but it doesn't do anything on the GPU due
to:
  #pragma omp target if (0)
many errors of the kind:
  .omp_data_kinds.24 / .omp_data_sizes.26 has been referenced in offloaded code
but hasn't been marked to be included in the offloaded code

[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #3 from Wilco  ---
Fixed.

[Bug target/91816] Arm generates out of range conditional branches in Thumb2

[tnfchris at gcc dot gnu.org]

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

--- Comment #1 from Tamar Christina  ---
This needs to be Backported to all supported GCC versions.

[Bug target/91816] New: Arm generates out of range conditional branches in Thumb2

[tnfchris at gcc dot gnu.org]

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

Bug ID: 91816
   Summary: Arm generates out of range conditional branches in
Thumb2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: assemble-failure, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: arm-*

Originally reported at binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=24991

The testcase in the report generates an out of range conditional branch because
the body of the if is too large.

This condition should have been changed into an unconditional branch by the
compiler.

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
ISTR discussing this but holding back a fix at the time we weren't sure if we'd
preserve the non-subreg sets.  So sth like 

Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 275698)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -668,6 +668,8 @@ scalar_chain::emit_conversion_insns (rtx
 static rtx
 gen_gpr_to_xmm_move_src (enum machine_mode vmode, rtx gpr)
 {
+  if (!x86_64_general_operand (gpr, GET_MODE_INNER (vmode)))
+gpr = force_reg (GET_MODE_INNER (vmode), gpr);
   switch (GET_MODE_NUNITS (vmode))
 {
 case 1:

fixes it with the question whether the use of x86_64_general_operand
is correct and whether it's necessary for the NUNITS == 1 case
(which IIRC isn't exercised anyway).

[Bug c/91815] New: questionable error on type definition at file scope

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 91815
   Summary: questionable error on type definition at file scope
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

The C compiler currently rejects the following code:

int f (void)
{
  extern int t;
  extern float v;   

  return (v > 0.0f);
}

typedef float t;

t v = 4.5f;

with the message:

t.c:9:15: error: 't' redeclared as different kind of symbol
9 | typedef float t;
  |   ^
t.c:3:14: note: previous declaration of 't' was here
3 |   extern int t;
  |

This behavior looks questionable and both Clang and MSVC disagree with GCC.

And a cursory look at the relevant code in pushdecl seems to point to an
overzealous implementation of C99 6.2.7p2, leading to a possible simple fix:

Index: c-decl.c
===
--- c-decl.c(revision 275746)
+++ c-decl.c(working copy)
@@ -3131,7 +3131,8 @@ pushdecl (tree x)
  what scope they are in; this is what we do here.  (C99 6.2.7p2:
  All declarations that refer to the same object or function shall
  have compatible type; otherwise, the behavior is undefined.)  */
-  if (DECL_EXTERNAL (x) || scope == file_scope)
+  if ((DECL_EXTERNAL (x) || scope == file_scope)
+  && VAR_OR_FUNCTION_DECL_P (x))
 {
   tree type = TREE_TYPE (x);
   tree vistype = NULL_TREE;

[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist  ---
Like Jerry said, we've recently had an ABI break (two, actually!), and I think
we should try hard to avoid yet another one.  I think it should be possible to
create some new st_parameter_dt_2 or such, as well as a new
data_transfer_init_2 entry point, and keep the old ones around for backwards
compatibility, rewriting data_transfer_init to wrap the new way of doing
things.

We can actually start with that, by moving private fields from st_parameter_dt
to gfc_unit. Or maybe make a separate per-data-transfer struct that is part of
gfc_unit, so that it can easily be memset() to 0 when starting a new data
transfer instead of having to separately touch every field.

I'm also thinking one way to speed up IO statements, if instead of memset()ing
said struct to zero, then go through every possible I/O specifier and set it to
the default value if missing etc., what if we had a few "ready-made" structs
(say one for formatted sequential, one for unformatted sequential, one for
unformatted direct etc.), and we just memcpy() the default struct. Then we'd
need to modify only the few fields that the flags variable say are present in
the I/O statement. But this can be done later.

Finally, for the new ABI entry points to save stack space, if for
data_transfer_init_2 we adopt approach b) that I described in the first message
in this PR, the st_parameter_dt_2 struct need to only contain the pointer to
the gfc_unit structure, and maybe a few other things.

That is, what the frontend passes is the unit number (that can be handled
separately since it's always present), the flags variable, the
st_parameter_dt_2 struct which contains the pointer to the gfc_unit struct (and
maybe a few other fields?), and a pointer to an array (that the frontend
creates on the stack prior to calling data_transfer_init_2) with elements

union dt_elem {
void* ptr;
int   c_int;
size_t  usize;
ptrdiff_t isize;
GFC_IO_INT  io_int;
}

and then popcount(flags) would tell the number of elements in the array, except
for character arguments which would take two elements, one for the pointer to
the string and another for the length. And the order of the elements in the
array would be determined by the flags argument.

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(insn 22 7 8 2 (set (subreg:V2DI (reg:DI 93) 0)
(vec_concat:V2DI (mem/u:DI (const:DI (plus:DI (symbol_ref/f:DI
("*.LC0") [flags 0x2]  )
(const_int 11532131096 [0x2af5e5b18]))) [1 MEM[(long
int *)"empty" + 11532131096B]+0 S8 A8])
(const_int 0 [0]))) "pr67271.c":11:17 -1
 (nil))

This is invalid memory address, it should be loaded to a temporary using
movabs.

[Bug target/91814] [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
  Known to work||9.2.0
   Host||x86_64-linux-gnu
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug target/91814] New: [10 Regression] ICE in elimination_costs_in_insn, at reload1.c:3549 since r274926

[marxin at gcc dot gnu.org]

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

Bug ID: 91814
   Summary: [10 Regression] ICE in elimination_costs_in_insn, at
reload1.c:3549 since r274926
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr67271.c -mavx512vl
-fno-tree-ter --param max-cse-insns=0 -O2 -c
during RTL pass: ira
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr67271.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr67271.c:13:1: internal
compiler error: in elimination_costs_in_insn, at reload1.c:3549
   13 | }
  | ^
0x6a637e elimination_costs_in_insn
/home/marxin/Programming/gcc/gcc/reload1.c:3549
0xd3ab0d calculate_elim_costs_all_insns()
/home/marxin/Programming/gcc/gcc/reload1.c:1611
0xbe2f1d ira_costs()
/home/marxin/Programming/gcc/gcc/ira-costs.c:2300
0xbdc5fb ira_build()
/home/marxin/Programming/gcc/gcc/ira-build.c:3428
0xbd355f ira
/home/marxin/Programming/gcc/gcc/ira.c:5325
0xbd355f execute
/home/marxin/Programming/gcc/gcc/ira.c:5638
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[kito at gcc dot gnu.org]

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

--- Comment #26 from Kito Cheng  ---
Author: kito
Date: Thu Sep 19 06:38:23 2019
New Revision: 275929

URL: https://gcc.gnu.org/viewcvs?rev=275929=gcc=rev
Log:
RISC-V: Fix bad insn splits with paradoxical subregs.

Shifting by more than the size of a SUBREG_REG doesn't work, so we either
need to disable splits if an input is paradoxical, or else we need to
generate a clean temporary for intermediate results.

Jakub wrote the first version of this patch, so gets primary credit for it.

gcc/
PR target/91635
* config/riscv/riscv.md (zero_extendsidi2, zero_extendhi2,
extend2): Don't split if
paradoxical_subreg_p (operands[0]).
(*lshrsi3_zero_extend_3+1, *lshrsi3_zero_extend_3+2): Add clobber and
use as intermediate value.

gcc/testsuite/
PR target/91635
* gcc.c-torture/execute/pr91635.c: New test.
* gcc.target/riscv/shift-shift-4.c: New test.
* gcc.target/riscv/shift-shift-5.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91635.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-4.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-5.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/riscv/riscv.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> On trunk we remove the loop because it has no side-effects (oops).

actually no, it's the same issue (phiprop).

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
And the GCC 8 issue is phiprop doing bogus invariant motion of the load.

[Bug tree-optimization/91811] 256-bit vector store isn't used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 CC||rguenth at gcc dot gnu.org
 Blocks||53947

--- Comment #1 from Richard Biener  ---
0x4ef6030 width_2(D) 1 times vec_construct costs 32 in prologue
0x4ef6030 width_2(D) 1 times vector_store costs 24 in body
0x4f59760 width_2(D) 1 times scalar_store costs 12 in body
0x4f59760 height_4(D) 1 times scalar_store costs 12 in body
0x4f59760 x_6(D) 1 times scalar_store costs 12 in body
0x4f59760 y_8(D) 1 times scalar_store costs 12 in body
t2.c:18:3: note:  Cost model analysis:
  Vector inside of basic block cost: 24
  Vector prologue cost: 32
  Vector epilogue cost: 0
  Scalar cost of basic block: 48
t2.c:18:3: missed:  not vectorized: vectorization is not profitable.
t2.c:18:3: note: * Re-trying analysis with vector size 16

so target costs say that this isnt profitable.  Probably a dup of one of the
bugs saying we don't take into account function boundary ABI for costing.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
On trunk we remove the loop because it has no side-effects (oops).