[Bug c++/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Thomas, can I ping on this?

[Bug c++/93314] [8/9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Jason, your thoughts on this?

[Bug middle-end/93399] [8/9/10 Regression] Annotate assembler option failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 47969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47969&action=edit
gcc10-pr93399.patch

Untested fix.  This function is what we use in the gimple dumps for the
DEBUG_STMTs with STRING_CST values.

[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 8.5+, 9.3+ and 10+.

[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #2)
> Bisection points to r254630 which doesn't look related to -Walloca:

It is related, in particular the
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/gimple.c?limit_changes=0&r1=254630&r2=254629&pathrev=254630
hunk.
* gimple.c (gimple_build_call_from_tree): Set call location.
which sets the location on the __builtin_alloca call newly to one with sysp =
true flag.

[Bug rtl-optimization/93159] [10 Regression] ICE (segfault) during RTL pass on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Ping.

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-04
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
Summary|[9/10 Regression] GCC adds  |[9/10 Regression] GCC adds
   |unwanted nops to align  |unwanted nops to align
   |loops on powerpc 8xx|loops on powerpc 8xx since
   ||r9-1623
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819.
At first I thought it is because of the rs6000.c changes, where previously it
was using 15 in the last two spots, but now "16" like in the earlier cases, but
most likely it is some other change.  Martin, can you please have a look?

[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So do you think you could attach preprocessed sources from both the working and
failing builds so that we can look up at the differences?

[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The sanitization boils down to adding COMPOUND_EXPRs with the checking in the
first operand and whatever it would normally have in the second operand.

using uc = unsigned char;

auto
foo (const uc &a, const uc &b, const uc &c)
{
  return static_cast(static_cast(a << 1U) | b) | c;
}

auto
bar (const uc &a, const uc &b, const uc &c, int &d)
{
  return static_cast(static_cast((d++, a) << 1U) | b) | c;
}

warns in bar the same even with just -Wconversion and doesn't warn in foo.
Now, I wonder if a way out of this wouldn't be in cp_build_binary_op to look
through COMPOUND_EXPRs (say set some temporary to (not sure if op0 or
orig_op0),
and then while (TREE_CODE (op0) == COMPOUND_EXPR) op0 = TREE_OPERAND (op0, 1);
and similarly for op1 (or orig_op1?) and then at the end readd the lhs's from
the COMPOUND_EXPRs to the result (guess for doing_shift case and
flag_strong_eval_order == 2 we'd need to either not do that or be extra
careful, because in that case op0 is ordered before op1).

Thoughts on this?

[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47971&action=edit
gcc10-pr91993-wip.patch

As implemented in this completely untested (so far) patch, which makes the
-Wconversion warning go away both in the case of comma operator with user
side-effects as well as -fsanitize=undefined.

[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|temporary object destructor |[10 Regression] temporary
   |called before the end of|object destructor called
   |the full-expression |before the end of the
   ||full-expression since
   ||r10-5577

--- Comment #1 from Jakub Jelinek  ---
Started with r10-5577-g942d334ec3fdf360dfedc0f97d1b4747a1f56f08

[Bug target/94037] Runtime varies 2x just by order of two int assignments

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The
setge   %sil
movzbl  %sil, %esi
to
xorl%esi, %esi
setge   %sil
transformation is something GCC does too with the
;; Convert setcc + movzbl to xor + setcc if operands don't overlap.
peephole2s.
The reason it doesn't trigger here is that the single comparison has 3 uses
(why not 2 and something didn't CSE those?).
So, at least for the two setcc quite long after cmp case, we might need to
either not have the comparison in the peephole2 and instead walk backwards,
looking for the FLAGS_REG setter (or stopping on something that clobbers it)
and stopping on if the register we'd want to xor first is mentioned by any insn
in between.
We have at the start of peephole2:
(insn 37 36 38 5 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:SI 1 dx [orig:86 pivot ] [86])
(reg:SI 0 ax [orig:242 pretmp_404 ] [242]))) "pr94037.C":6:19 11
{*cmpsi_1}
 (expr_list:REG_DEAD (reg:SI 0 ax [orig:242 pretmp_404 ] [242])
(nil)))
(note 38 37 39 5 NOTE_INSN_DELETED)
(note 39 38 1178 5 NOTE_INSN_DELETED)
(insn 1178 39 1179 5 (set (reg:QI 2 cx [288])
(lt:QI (reg:CCGC 17 flags)
(const_int 0 [0]))) "pr94037.C":6:21 732 {*setcc_qi}
 (nil))
(insn 1179 1178 41 5 (set (reg:DI 2 cx [288])
(zero_extend:DI (reg:QI 2 cx [288]))) "pr94037.C":6:21 115
{zero_extendqidi2}
 (nil))
(insn 41 1179 42 5 (set (reg:SI 2 cx [289])
(mem:SI (plus:DI (plus:DI (mult:DI (reg:DI 2 cx [288])
(const_int 4 [0x4]))
(reg/f:DI 7 sp))
(const_int 120 [0x78])) [1 MEM[(int[2] *)_213] S4 A32]))
"pr94037.C":6:15 67 {*movsi_internal}
 (expr_list:REG_EQUIV (mem:SI (reg/v/f:DI 36 r8 [orig:283 begin ] [283]) [1
*begin_329+0 S4 A32])
(nil)))
(insn 42 41 45 5 (set (mem:SI (reg/v/f:DI 36 r8 [orig:283 begin ] [283]) [1
*begin_329+0 S4 A32])
(reg:SI 2 cx [289])) "pr94037.C":6:15 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 2 cx [289])
(nil)))
(note 45 42 1180 5 NOTE_INSN_DELETED)
(insn 1180 45 1181 5 (set (reg:QI 0 ax [290])
(ge:QI (reg:CCGC 17 flags)
(const_int 0 [0]))) "pr94037.C":15:10 732 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCGC 17 flags)
(nil)))
(insn 1181 1180 47 5 (set (reg:DI 0 ax [290])
(zero_extend:DI (reg:QI 0 ax [290]))) "pr94037.C":15:10 115
{zero_extendqidi2}
 (nil))
and current peephole2 manages to handle the first setcc+movzbl.  The second one
actually isn't doable because of the RA decisions, as the comparison uses ax
and we'd need to clear rax before the comparison.
Similarly, in partition we have 3 setcc+movzbls, but the first one has the
movzbl not adjacent to the setcc, second one would be doable if the peephole2
pattern didn't include the FLAGS_REG setter and walked back and the third one
isn't doable because the comparison uses cx, i.e. the register that's set by
setcc and extended by movzbl.

Now, on the GIMPLE level, we have e.g. in partition:
  _2 = MEM[base: right_35, offset: 0B];
  _3 = _2 <= pivot_12;
  _4 = (int) _3;
  _19 = *left_31;
  _7 = {_19, _2};
  MEM  [(int *)&v] = _7;
  _21 = v[_4];
  *left_31 = _21;
  _22 = _2 > pivot_12;
  _23 = (int) _22;
  _24 = v[_23];
  MEM[base: right_35, offset: 0] = _24;
  v ={v} {CLOBBER};
  _5 = _2 <= pivot_12 ? 4 : 0;
so I wonder why sccvn has not at least replaced the last _2 <= pivot_12 with
_3.
And, if SCCVN could be taught that if we have _3 = _2 <= pivot_12 and later _22
= _2 > pivot_12, we can simplify the latter to _22 = 1 - _3;
1 -

[Bug c/94040] [9/10 Regression] ICE in get_constant, at c-family/c-format.c:325 (error: 'format' attribute argument 2 value '3' refers to parameter type 'int *')

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
struct tm
{
  int tm_sec, tm_min, tm_hour, tm_mday, tm_mon;
  int tm_year, tm_wday, tm_yday, tm_isdst;
};

__SIZE_TYPE__
strftime (char *, __SIZE_TYPE__, int *, struct tm *);

int
foo (char *p, struct tm *t)
{
  return strftime (p, 0, 0, t);
}

ICEs with -Wformat even without -m32.

[Bug middle-end/93399] [8/9 Regression] Annotate assembler option failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8/9 Regression] Annotate
   |Annotate assembler option   |assembler option failure
   |failure |

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far, will wait a little bit before backporting.

[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #21 from Jakub Jelinek  ---
Perhaps that is something store-merging should handle too and related to the
issue Xionghu Luo showed in the "Run store-merging pass once more before pass
fre/pre" thread on gcc-patches.  Ideally store-merging should handle both, and
SLP too.

[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
You were faster.
I came up with:
struct T { T (); ~T (); static int t; };
int T::t = 0;
struct A { A () noexcept; A (const T &) noexcept; const T *a; };
struct B { ~B (); };
struct Pair { A a; B b; };

T::T ()
{
  t++;
}

T::~T ()
{
  t--;
}

A::A () noexcept : a (nullptr)
{
}

A::A (const T &t) noexcept : a (&t)
{
}

B::~B ()
{
}

T
baz () noexcept
{
  return T ();
}

void
foo (const Pair &p) noexcept
{
  if (T::t == 0)
__builtin_abort ();
}

void
bar (const Pair& p) noexcept
{
  foo ({A (baz ()), p.b});
}

int
main ()
{
  Pair p;
  bar (p);
}

[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Possible dup of PR94027 ?

[Bug middle-end/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Seems to be var-tracking.  I see e.g. 17900 nested find_base_term calls.
E.g. the setupUi method has 6372 basic blocks, 10337 edges, which is still not
enough to make var-tracking bail out, but contains almost 10 instructions
and in lots of cases suffers from those extremely long VALUE chains.

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Shall we punt in find_base_term for VALUEs if visited_vals.length () is larger
than a new param with some reasonable default?  Or do it only during
var-tracking and not during alias analysis?
With:
--- gcc/alias.c.jj  2020-03-03 19:39:53.228598307 +0100
+++ gcc/alias.c 2020-03-05 12:13:13.772182997 +0100
@@ -2005,6 +2005,9 @@ find_base_term (rtx x, vec 2048)
+   return ret;
+
   f = val->locs;
   /* Reset val->locs to avoid infinite recursion.  */
   if (f)
the testcase compiles (x86_64 with those -m32 ... options) in 3m11s on
i9-7960X.

[Bug debug/93888] Incorrect DW_AT_location generated for copy-constructed function argument

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Yeah, I'm considering a backport, but didn't want to rush it into 9.3, want to
wait a few weeks.

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
BTW, unpatched gcc doesn't really hang, but it takes 16m31s to compile it, so
over 5 times longer than with the patch.
Besides turning it into a param, other possibilities include guarding the
punting  also with cselib_preserve_constants, or doing it only for
cselib_preserved_value_p vals above the depth, etc.
Richard, any opinions on this?

[Bug target/91710] [9/10 Regression] unexpected ABI change note since r9-5650

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org
Summary|[9/10 Regression]   |[9/10 Regression]
   |unexpected ABI change note  |unexpected ABI change note
   |since   |since r9-5650
   |r9-5650-gc590597c45948c6e6f |
   |a282878198fd226da9599   |

--- Comment #5 from Jakub Jelinek  ---
The warning has been added in r9-5650-gc590597c45948c6e6fa282878198fd226da95998
CCing author.

[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/91913] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2211

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2211|recog.c:2211
  Known to fail|10.0|

--- Comment #11 from Jakub Jelinek  ---
Testcase has been committed, so should be fixed on the trunk.
Awaiting potential backports to release branches.

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
--- gcc/alias.c.jj  2020-03-03 19:39:53.228598307 +0100
+++ gcc/alias.c 2020-03-05 13:32:10.115235397 +0100
@@ -2005,6 +2005,10 @@ find_base_term (rtx x, vec 2048
+ && cselib_preserved_value_p (val))
+   return ret;
+
   f = val->locs;
   /* Reset val->locs to avoid infinite recursion.  */
   if (f)
works the same on the testcase, and doesn't affect non-var-tracking.

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I'd like to ping this, anyone familiar with ARM instruction set as well as the
backend can have a look?

[Bug rtl-optimization/90311] [9 Regression] wrong code with -O and __builtin_add_overflow() and compare

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
If fixed on the trunk, I think it would be nice to commit the testcase (there
is nothing arm specific on it, so I'd say it should go into
gcc.c-torture/execute/).
I can handle that.

[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll handle it.

[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This shows a couple of suspect conversions in macros, will need to verify all
of them:
grep '(__v[0-9]*[qhsd][if])(__m\(128\|256\|512\)\(\|d\|i\))' *.h | grep -v
'\((__v2di)(__m128i)\|(__v4si)(__m128i)\|(__v8hi)(__m128i)\|(__v16qi)(__m128i)\|(__v4di)(__m256i)\|(__v8si)(__m256i)\|(__v16hi)(__m256i)\|(__v32qi)(__m256i)\|(__v8di)(__m512i)\|(__v16si)(__m512i)\|(__v32hi)(__m512i)\|(__v64qi)(__m512i)\|(__v2df)(__m128d)\|(__v4sf)(__m128)\|(__v4df)(__m256d)\|(__v8sf)(__m256)\|(__v8df)(__m512d)\|(__v16sf)(__m512)\)'
avx2intrin.h:  (__m128) __builtin_ia32_gathersiv4sf ((__v4sf)(__m128d)SRC, 
 \
avx2intrin.h:   (__v4sf)(__m128d)MASK,   \
avx2intrin.h:   (__v8sf)(__m256d)MASK,  \
avx2intrin.h:   (__v4sf)(__m128d)MASK,   \
xopintrin.h:(__v2di)(__m128d)(C),  
\
xopintrin.h:   (__v4di)(__m256d)(C),   
\
xopintrin.h:   (__v4si)(__m128)(C),
\
xopintrin.h:  (__v8si)(__m256)(C), 
\

[Bug c++/94050] New: [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[jakub at gcc dot gnu.org]

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

Bug ID: 94050
   Summary: [10 Regression] C++ ABI change on
armv7hl-linux-gnueabi since r10-1302
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r10-1302-gc3337b44c40dd1545e00034cb8e1ae1c0dae0fa6
the following test FAILs on armv7hl-linux-gnueabi (but not on i686 or x86_64).
This breaks at least mozjs68 build:

struct alignas(8) Cell {};
struct TenuredCell : public Cell {};
struct BaseShape : public TenuredCell {
  void *p;
  unsigned q, r;
  void *s;
  __UINTPTR_TYPE__ t;
};
static_assert (sizeof (BaseShape) % 8 == 0, "");

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-05
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47980&action=edit
gcc10-pr94046.patch

Full untested patch.

[Bug target/94046] cast to __m256d in mask argument of avx2 float gather intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 9.3+ and 10+ so far.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
This does happen even with 9.2 and current trunk, you just need to read the
first line in #c0.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
--enable-checking=release (the default on release branches) is not
--enable-checking=yes (which is needed to reproduce this checking
error-recovery failure).

[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|[9/10 Regression]   |[9/10 Regression]
   |-std=gnu++20 causes failure |-std=gnu++20 causes failure
   |naming nested templated |naming nested templated
   |class   |class since r9-4536

--- Comment #1 from Jakub Jelinek  ---
Started with r9-4536-g96c35892bea68ac180f19079cf08fea3b6cda0a8

[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Version|unknown |10.0
   Target Milestone|--- |8.5
Summary|ICE (starting/ending union  |[8/9/10 Regression] ICE
   |member lifetime) in |(starting/ending union
   |cxx_eval_bare_aggregate, at |member lifetime) in
   |cp/constexpr.c:3790 |cxx_eval_bare_aggregate, at
   ||cp/constexpr.c:3790 since
   ||r6-7592

--- Comment #2 from Jakub Jelinek  ---
Started (with -std=c++17) with
r6-7592-g426b9428081f1ec16d9e7ca6bd34ce50ff8cde37

[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
clang++ diagnostics is
assignment to member 'y' of union with active member 'a' is not allowed in a
constant expression
Note, in C++17 things are clear and we shouldn't reject all changes of union
active member, there is diagnostics for that e.g. since PR89336 (though unsure,
do we need to mark the member as active as soon as we start evaluating its
NSDMI?), but C++20 dropped the requirement that in constant expressions the
active member can't be changed, so what exactly is the basis of this being
invalid?

[Bug c++/94067] New: [10 Regression] ICE on rotate with -Wconversion since r10-6527

[jakub at gcc dot gnu.org]

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

Bug ID: 94067
   Summary: [10 Regression] ICE on rotate with -Wconversion since
r10-6527
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f we ICE with
-Wconversion on
static inline unsigned short
swap (unsigned short x)
{
  return (x >> 8) | static_cast(x << 8);
}

[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-03-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I guess in this case we should add the rotates to both potential_* and
cxx_eval_*, one just have to worry what other trees created during cp_fold,
including match.pd and fold-const.c folding, might appear and we don't handle.

[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47986&action=edit
gcc10-pr94067.patch

Untested fix.

[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-06
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|Internal compiler error |[9/10 Regression] Internal
   |when trying to resolve  |compiler error when trying
   |function overload   |to resolve function
   ||overload since r9-2384
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r9-2384-ged4f2c001a883b2456fc607a33f1c59f9c4ee65d

[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase with -std=c++17 or -std=c++2a:
enum class A { A1, A2 };
A foo ();
long foo (int);

template 
void
bar ()
{
  const auto c{foo ()};
}

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 47989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47989&action=edit
gcc10-pr94045.patch

Patch I'll be testing.

[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
For the second testcase, I think we could in undefined_shift_range_check or its
2 callers intersect the value range of the last [lr]shift operand with the
range of [0, prec-1], and if that yields empty range, do what we use right now,
but if it narrows the op2 range to something smaller, use that in the
range_operator::fold_range call instead of op2.

[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Well, 64-bit time_t/off_t/ino_t on an arch where they weren't previously 64-bit
is an ABI change which of course needs to have support added to various parts
of the toolchain, including libsanitizer (for which it should go through the
upstream).

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Last reconfirmed||2020-03-09

--- Comment #1 from Jakub Jelinek  ---
Started with r10-1938-g460bf043c8266dd080308f4783137aee0d0f862c

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Guess *testqi_ext_3 needs to be adjusted to test CCZmode instead of CCNOmode if
the constant we'll be created matches the new testdi_1 conditions.

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47997&action=edit
gcc10-pr94088.patch

Untested fix.

[Bug tree-optimization/94094] [meta-bug] store-merging and/or bswap load/store-merging missed optimizations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The two passes share infrastructure for the bswap discovery etc., but otherwise
they aren't dependent on each other.

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
commit r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796
Author: Jakub Jelinek 
Date:   Mon Mar 9 13:38:23 2020 +0100

alias: Punt after walking too many VALUEs during a toplevel find_base_term
call [PR94045]

As mentioned in the PR, on a largish C++ testcase the compile time
on i686-linux is about 16 minutes on a fast box, mostly spent in
find_base_term recursive calls dealing with very deep chains of preserved
VALUEs during var-tracking.

The following patch punts after we process many VALUEs (we already have
code
to punt if we run into a VALUE cycle).

I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
function columns piped through sort | uniq -c | sort -n):
 36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
108 32 _first_test.go reflect_test.reflect_test..import
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
   6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
   6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
   8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
   8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
  41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
Additionally, for most of these (for the builtins definitions tested just
one) I've verified with a different alias.c change which didn't punt but
in the toplevel find_base_term recorded if visited_vals reached the limit
whether the return value was NULL_RTX or something different, and in all
these cases the end result was NULL_RTX, so at least in these cases it
should just shorten the time until it returns NULL.

2020-03-09  Jakub Jelinek  

PR rtl-optimization/94045
* params.opt (-param=max-find-base-term-values=): New option.
* alias.c (find_base_term): Add cut-off for number of visited
VALUEs
in a single toplevel find_base_term call.

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
commit r10-7087-g314b91220a07bd63f13c58e37f1b5b9430a3702b
Author: Martin Liska 
Date:   Mon Mar 9 14:13:04 2020 +0100

Restore alignment in rs6000 target.

PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.
PR target/93800
* gcc.target/powerpc/pr93800.c: New test.

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
commit r10-7089-g8475f2902a2e2ca5f7ace8bc5265bd1a815dda20
Author: Marek Polacek 
Date:   Thu Mar 5 14:07:25 2020 -0500

c++: Fix ABI issue with alignas on armv7hl [PR94050]

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

  CLASSTYPE_AS_BASE (t) = t;

While TYPE_USER_ALIGN of TenuredCell was 0, because finalize_type_size
called from finish_record_layout reset it, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE still remained 1.  After we replace it, it's no longer
1.  Then we perform layout_empty_base_or_field for TenuredCell and since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
adjustment:

  if (CLASSTYPE_USER_ALIGN (type))
{
  rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
  if (warn_packed)
rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN
(type));
  TYPE_USER_ALIGN (rli->t) = 1;
}

where rli->t is BaseShape.  Then finalize_record_size won't use the
correct rli->record_align and therefore
  /* Round the size up to be a multiple of the required alignment.  */
  TYPE_SIZE (rli->t) = round_up (unpadded_size, TYPE_ALIGN (rli->t));
after this we end up with the wrong size.

Since the original fix was to avoid creating extra copies for LTO
purposes, I think the following fix should be acceptable.

PR c++/94050 - ABI issue with alignas on armv7hl.
* class.c (layout_class_type): Don't replace a class's
CLASSTYPE_AS_BASE if their TYPE_USER_ALIGN don't match.

* g++.dg/abi/align3.C: New test.

[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The standard seems to say a union member becomes active when the constructor
finishes, not when it starts, so what wording prevents changing the active
member during the construction?

[Bug target/93930] [8/9/10 Regression] Unnecessary broadcast instructions for AVX512

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The cost changes affect the RTL LIM.-Set in insn 22 is invariant (0), cost 32,
depends on 
-Set in insn 27 is invariant (1), cost 32, depends on 
-Set in insn 32 is invariant (2), cost 32, depends on 
-Set in insn 37 is invariant (3), cost 32, depends on 
-Set in insn 61 is invariant (4), cost 32, depends on 
-Set in insn 66 is invariant (5), cost 32, depends on 
-Set in insn 71 is invariant (6), cost 32, depends on 
-Set in insn 76 is invariant (7), cost 32, depends on 
-Set in insn 101 is invariant (8), cost 32, depends on 
-Set in insn 106 is invariant (9), cost 32, depends on 
-Set in insn 111 is invariant (10), cost 32, depends on 
-Set in insn 116 is invariant (11), cost 32, depends on 
-Decided to move invariant 0 -- gain 32
-Decided to move invariant 1 -- gain 32
-Decided to move invariant 2 -- gain 32
-Decided to move invariant 3 -- gain 32
-Decided to move invariant 4 -- gain 32
-Decided to move invariant 5 -- gain 32
-Decided to move invariant 6 -- gain 32
-Decided to move invariant 7 -- gain 32
-Decided to move invariant 8 -- gain 32
-Decided to move invariant 9 -- gain 32
-Decided to move invariant 10 -- gain 10
-Decided to move invariant 11 -- gain 30
+Set in insn 22 is invariant (0), cost 4, depends on 
+Set in insn 27 is invariant (1), cost 4, depends on 
+Set in insn 32 is invariant (2), cost 4, depends on 
+Set in insn 37 is invariant (3), cost 4, depends on 
+Set in insn 61 is invariant (4), cost 4, depends on 
+Set in insn 66 is invariant (5), cost 4, depends on 
+Set in insn 71 is invariant (6), cost 4, depends on 
+Set in insn 76 is invariant (7), cost 4, depends on 
+Set in insn 101 is invariant (8), cost 4, depends on 
+Set in insn 106 is invariant (9), cost 4, depends on 
+Set in insn 111 is invariant (10), cost 4, depends on 
+Set in insn 116 is invariant (11), cost 4, depends on 
+Decided to move invariant 0 -- gain 4
+Decided to move invariant 1 -- gain 4
+Decided to move invariant 2 -- gain 4
+Decided to move invariant 3 -- gain 4
+Decided to move invariant 4 -- gain 4
+Decided to move invariant 5 -- gain 4
+Decided to move invariant 6 -- gain 4
+Decided to move invariant 7 -- gain 4
+Decided to move invariant 8 -- gain 4
+Decided to move invariant 9 -- gain 4
which means invariant 10 and 11 aren't moved anymore.
Those two are:
-(insn 111 106 116 3 (set (reg:V16SF 210)
-(vec_duplicate:V16SF (vec_select:SF (reg:V4SF 234)
-(parallel [
-(const_int 0 [0])
-] "include/avx512fintrin.h":207 4206
{avx512f_vec_dupv16sf}
- (expr_list:REG_EQUAL (const_vector:V16SF [
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-])
-(nil)))
-(insn 116 111 139 3 (set (reg:V16SF 214)
-(vec_duplicate:V16SF (vec_select:SF (reg:V4SF 235)
-(parallel [
-(const_int 0 [0])
-] "include/avx512fintrin.h":207 4206
{avx512f_vec_dupv16sf}
- (expr_list:REG_EQUAL (const_vector:V16SF [
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-])
-(nil)))
and I bet the reason they are using the const costs are the REG_EQUAL notes.
The setters of their sources are:
(insn 169 168 170 3 (set (reg:V4SF 234)
(mem/u/c:V4SF (symbol_ref/u:DI ("*.LC10") [flags 0x2]) [2 

[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The placement new is inlined at this point, the operator new that remains is
replaceable and because a is a global variable, its address needs to be
considered escaped.
While access to not yet fully constructed var from another TU might be
problematic, in what the restrict pass we actually don't know (unless we look
at abstract origin and prove there is no post-ctor code in between) it is a
ctor which would have such restrictions.

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Testcase modified to be usable in the testsuite:
// PR c++/93922
// { dg-do link { target c++11 } }

template 
struct A {
  A () {}
  template 
  A (A const &) {}
  ~A () {}
};
int t;
struct B {};
struct C : B { C (B const &) { if (t) throw 1; } };
struct S { A x; C y; };

A
bar (B *)
{
  return A ();
}

S *
foo (B *x, B const &y)
{
  return new S {bar (x), y};
}

int
main ()
{
}

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The problem as I understand it is that
#1  0x00abeb95 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5686
#2  0x00987243 in build_over_call (cand=0x375c910, flags=35,
complain=3) at ../../gcc/cp/call.c:9020
#3  0x0098c640 in build_new_method_call_1 (instance=, fns=, 
args=0x0, conversion_path=, flags=35, fn_p=0x0,
complain=3) at ../../gcc/cp/call.c:10305
#4  0x0098cb2e in build_new_method_call (instance=, fns=, args=0x0, 
conversion_path=, flags=35, fn_p=0x0,
complain=3) at ../../gcc/cp/call.c:10380
#5  0x0098a256 in build_special_member_call (instance=, name=, 
args=0x0, binfo=, flags=35, complain=3) at
../../gcc/cp/call.c:9781
#6  0x00afa23c in build_dtor_call (exp=,
dtor_kind=sfk_complete_destructor, flags=35, complain=3)
at ../../gcc/cp/init.c:4786
#7  0x00afaaca in build_delete (loc=0, otype=, addr=, 
auto_delete=sfk_complete_destructor, flags=35, use_global_delete=0,
complain=3) at ../../gcc/cp/init.c:4979
#8  0x00a9e585 in cxx_maybe_build_cleanup (decl=, complain=3) at ../../gcc/cp/decl.c:17394
#9  0x00d130b8 in split_nonconstant_init_1 (dest=, init=, nested=false)
at ../../gcc/cp/typeck2.c:714
#10 0x00d1351a in split_nonconstant_init (dest=, init=) at
../../gcc/cp/typeck2.c:784
happens too late, after pending templates have been instantiated.
So, either mark_used or maybe_instantiate_decl needs to not defer if at_eof (or
at_eof == 2?), or perhaps better discover that split_nonconstant_init_1 will
need to call the descriptor earlier (dunno where exactly, cp_fold or
cp_genericize_r?).
I think the latter would be better, e.g. with OpenMP implicit declare target
discovery I was hoping one could hook somewhere into cgraph in between where
the FE already saw all functions and before first functions are gimplified, but
if gimplification can result in new functions to be instantiated, genericized
and later on gimplified and again and again, this wouldn't be possible.

[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
commit r10-7094-g81fa6d7321dd9b645d86de4a8a6967c603f176e3
Author: Jakub Jelinek 
Date:   Mon Mar 9 21:52:18 2020 +0100

c++: Readd [LR]ROTATE_EXPR support to constexpr.c [PR94067]

Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c

2020-03-09  Jakub Jelinek  

PR c++/94067
Revert
2019-10-11  Paolo Carlini  

* constexpr.c (cxx_eval_constant_expression): Do not handle
RROTATE_EXPR and LROTATE_EXPR.

* g++.dg/warn/Wconversion-pr94067.C: New test.

[Bug tree-optimization/94114] [8/9/10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10 Regression] ICE in  |[8/9/10 Regression] ICE in
   |gimplify_modify_expr, at|gimplify_modify_expr, at
   |gimplify.c:5936 |gimplify.c:5936
   Last reconfirmed||2020-03-10
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |8.5
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r10-619-g5879ab5fafedc8f6f9bfe95a4cf8501b0df90edd only because
that enabled -ftree-loop-distribute-patterns at -O2.
With -O2 -ftrapv -ftree-loop-distribute-patterns it started with
r0-127193-gb83b550780a6ee31c6e8b9da922c2a087f7bd44c.
Guess we need to add rewrite_to_non_trapping_overflow somewhere.

[Bug tree-optimization/94114] [8/9/10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48004&action=edit
gcc10-pr94114.patch

Untested fix.

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
In r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796 I've added a param
controlled cap on the number of VALUEs walked by a single toplevel
find_base_term.
Does it make a difference on this?

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
commit r10-7101-gcc5c935937d01d96c6b070dae31854180249064c
Author: Jakub Jelinek 
Date:   Tue Mar 10 09:26:44 2020 +0100

i386: Fix up *testqi_ext_3 insn&split for the *testdi_1 changes [PR94088]

In r10-1938-g460bf043c8266dd080308f4783137aee0d0f862c *testdi_1 has been
changed, so that if the mask has upper 32-bits 0 and then at least one bit
set, it requires CCZmode rather than CCNOmode, because in that case it uses
testl instruction rather than testq and so the SF flag wouldn't respect the
state of the 64-bit result.
The *testqi_ext_3 define_insn_and_split needs to match that though,
otherwise it can create an RTL pattern that used to match *testdi_1 but
doesn't anymore and we'd ICE due to an unrecognizable insn.

2020-03-10  Jakub Jelinek  

PR target/94088
* config/i386/i386.md (*testqi_ext_3): Call ix86_match_ccmode with
CCZmode instead of CCNOmode if operands[2] has DImode and pos + len
is 32.

* gcc.target/i386/pr94088.c: New test.

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Vlad, do you think you could have a look?  Seems the function isn't that big,
23 bbs and < 1200 insns before LRA, 1000 pseudos, but during LRA it turns those
into 12+ insns and counting, 10GB *.lra log (didn't wait until it
completes).
Thanks.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek  ---
So, with the reversion, can this be closed as FIXED?

[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This doesn't ICE anymore since
r10-6926-g586b016cd48f5a5f6f2ba9f179105fabaa3e85dd
Is it worth adding the reduced testcase or is the cpp2a/concepts-conv1.C
sufficient?  Was the unreduced testcase valid, or invalid?  The reduced one is
rejected by the trunk:
pr93895.C:158:67: error: the value of ‘bf::{anonymous}::bb, false> >’ is not usable in a constant
expression
pr93895.C:208:1: warning: no return statement in function returning non-void
[-Wreturn-type]
pr93895.C:174:35: warning: ‘bd::be::operator()(di) [with di
= as::bl]’ used but never defined
pr93895.C:81:42: warning: ‘as::bq::operator()(am, br)
[with am = bd::chunk_base_fn; br = int]’ used but never defined

[Bug c++/93596] [10 Regression] ICE related to templates and vectors.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:
template  struct A {};
template  struct B {};
template  struct C {
  void foo () { B a = A { foo }; }
};

[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Indeed, this is a folding bug and simplified testcase is:
int
main ()
{
  _Decimal32 d = (_Decimal32) __builtin_inff ();
  if (!__builtin_isinf ((double) d))
__builtin_abort ();
  return 0;
}

[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
And was miscompiled already in GCC 4.3 where _Decimal32 support was added (at
least on x86_64-linux).  I'll have a look.

[Bug c++/94117] non-dependent expr treated as-if dependent

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Related or dup of PR93901 ?  Guess I'll bisect to see if it is the same commit.

[Bug c++/94117] non-dependent expr treated as-if dependent

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Maybe not, as it doesn't seem to be a regression, it has never been rejected
(at least not in anything since r20 I've tried).
clang++ rejects with
exception specification is not available until end of class definition

[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Note, 7.x is not supported anymore.  If this is going to be changed, it would
be for GCC 11, different source file, different routine...

[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48009&action=edit
gcc10-pr94111.patch

Untested fix.

[Bug c/94106] [8/9/10 Regression] error on a function redeclaration with attribute transaction_safe

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm afraid nobody really maintains the -fgnu-tm stuff anymore.

[Bug middle-end/92096] [10 Regression] segmentation fault in 'example_labels' building gcc trunk on cygwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Can you still reproduce with current trunk?
If so, can you see where exactly it segfaulted (add -v to the xgcc invocation
line, run debugger with whatever it prints for cc1)?

[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
I think even the using of std::abs in the #c8 case isn't correct, because the
std::abs (long long); overload has been only added in C++11 and we in GCC 10
still do support C++98 compilers.
So I think we instead should use abs_hwi (or absu_hwi, depending on if the most
negative value can appear or not) instead of std::abs or abs in value-prof.c.
So e.g.
--- gcc/value-prof.c2020-03-05 07:58:02.693135980 +0100
+++ gcc/value-prof.c2020-03-10 14:32:10.723649888 +0100
@@ -266,7 +266,7 @@ dump_histogram_value (FILE *dump_file, h
  if (hist->hvalue.counters)
{
  fprintf (dump_file, " all: %" PRId64 "%s, values: ",
-  std::abs ((int64_t) hist->hvalue.counters[0]),
+  absu_hwi (hist->hvalue.counters[0]),
   hist->hvalue.counters[0] < 0
   ? " (values missing)": "");
  for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
@@ -743,7 +743,7 @@ get_nth_most_common_value (gimple *stmt,
   *count = 0;
   *value = 0;

-  gcov_type read_all = abs (hist->hvalue.counters[0]);
+  gcov_type read_all = absu_hwi (hist->hvalue.counters[0]);

   gcov_type v = hist->hvalue.counters[2 * n + 1];
   gcov_type c = hist->hvalue.counters[2 * n + 2];

or with s/absu/abs/.

[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Comment on attachment 48010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48010
[PATCH PR94121] fix ICE on aarch64 in abs_hwi, at hwint.h:324

Can't you instead just use absu_hwi instead of abs_hwi and change moffset type
to unsigned HOST_WIDE_INT?  With the latter, the moffset < 0x100 comparison
will DTRT and for HOST_WIDE_INT_MIN DImode it really doesn't matter if we use
addition or subtraction.

[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Ok, I'll test a patch with abs_hwi in both spots then.  There will be an
assertion in there that it is not INT64_MIN.

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
That IMHO just made a latent issue no longer latent.
I'd say it is either a LRA issue or some backend issue related to RA, on a
relatively short function LRA shouldn't take hours.

[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed by r10-6926.

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
richi's change basically on the testcase just changed 6 times in the function:
   hl_.v_ = a11_334;
-  accvhi4__777 = hl_.hilo_.hi_;
-  accvlo4__778 = hl_.hilo_.lo_;
+  _612 = BIT_FIELD_REF ;
+  _613 = BIT_FIELD_REF ;
or so (plus different SSA_NAME_VERSION).
That is given:
typedef unsigned char rc_vec4_type_ __attribute__((__vector_size__(4)));
struct { rc_vec4_type_ hi_, lo_; } hilo_; } RC_hl_type_;
so I don't really see anything wrong on that, a11_334 has type
typedef unsigned char rc_vec_t __attribute__((__vector_size__(8)));
and this is a valid way to extract low or high half of a vector.

Simplified testcase that still hangs in LRA:
/* { dg-do compile } */
/* { dg-require-effective-target lp64 } */
/* { dg-options "-O2 -mcpu=ultrasparc -mvis" } */

typedef unsigned char rc_vec_t __attribute__((__vector_size__(8)));
typedef short rc_svec_type_ __attribute__((__vector_size__(8)));
typedef unsigned char rc_vec4_type_ __attribute__((__vector_size__(4)));
void foo (unsigned int, unsigned int);

void
bar (rc_vec_t *pv)
{
  rc_vec_t v = {};
  for (int i = 0; i < 64; i++)
{
  typedef union { rc_vec_t v_; struct { rc_vec4_type_ hi_, lo_; } hilo_; }
RC_hl_type_; RC_hl_type_ hl_ = (RC_hl_type_) v;
  rc_vec4_type_ a = hl_.hilo_.hi_;
  rc_vec4_type_ b = hl_.hilo_.lo_;
  union U { rc_vec4_type_ v; unsigned int u; };
  foo (((union U) { .v = a }).u, ((union U) { .v = b }).u);
  v = pv[i];
}
}

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I think the difference on the reduced testcase between success (first) and hang
(second) is:
(insn 10 16 21 3 (set (reg/v:DI 117 [ hl_ ])
(subreg:DI (reg/v:V8QI 114 [ v ]) 0)) "ultrasp13.c":19:105 125
{*movdi_insn_sp64}
 (nil))
(insn 21 10 17 3 (set (reg:DI 111 [ ivtmp.11 ])
(plus:DI (reg:DI 111 [ ivtmp.11 ])
(const_int 8 [0x8]))) 224 {*adddi3_sp64}
 (nil))
(insn 17 21 18 3 (set (reg:DI 9 %o1)
(zero_extend:DI (subreg:SI (reg/v:V8QI 114 [ v ]) 4)))
"ultrasp13.c":23:7 179 {*zero_extendsidi2_insn_sp64}
 (expr_list:REG_DEAD (reg/v:V8QI 114 [ v ])
(nil)))
(insn 18 17 19 3 (set (reg:DI 8 %o0)
(lshiftrt:DI (reg/v:DI 117 [ hl_ ])
(const_int 32 [0x20]))) "ultrasp13.c":23:7 403 {*lshrdi3_sp64}
 (expr_list:REG_DEAD (reg/v:DI 117 [ hl_ ])
(nil)))
vs.
(insn 14 13 18 3 (set (reg:DI 9 %o1)
(zero_extend:DI (subreg:SI (reg/v:V8QI 114 [ v ]) 4)))
"ultrasp13.c":23:7 179 {*zero_extendsidi2_insn_sp64}
 (nil))
(insn 18 14 15 3 (set (reg:DI 111 [ ivtmp.11 ])
(plus:DI (reg:DI 111 [ ivtmp.11 ])
(const_int 8 [0x8]))) 224 {*adddi3_sp64}
 (nil))
(insn 15 18 16 3 (set (reg:DI 8 %o0)
(zero_extend:DI (subreg:SI (reg/v:V8QI 114 [ v ]) 0)))
"ultrasp13.c":23:7 179 {*zero_extendsidi2_insn_sp64}
 (expr_list:REG_DEAD (reg/v:V8QI 114 [ v ])
(nil)))
SPARC is big-endian, so I'd guess the non-lowpart subreg in the zero extension
might be a problem.
But in the expand dump it shows up both in the good and bad cases, like:
(insn 11 10 12 4 (set (reg:V4QI 119)
(subreg:V4QI (reg/v:DI 117 [ hl_ ]) 4)) "ultrasp13.c":23:7 -1
 (nil))

[Bug target/94121] ICE on aarch64-linux-gnu: in abs_hwi, at hwint.h:324

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48013&action=edit
gcc10-pr94121.patch

Ok, I'll test this then.

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The reason that the non-lowpart subreg is allowed here is:
sparc_regmode_natural_size (machine_mode mode)
which returns for MODE_VECTOR_INT modes 4 rather than UNITS_PER_WORD (and for
MODE_FLOAT too).
IRA decision for the pseudo 114 seems to be mem.

[Bug target/94123] [10 regression] r10-7093 causes gcc.target/powerpc/pr87507.c to fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, did it fail also two weeks ago when the patch that got reverted wasn't even
in?

[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Somewhat reduced testcase:

unsigned char b, f;
short d[1][8][1], *g = &d[0][3][0];

int
main ()
{
  int k[] = { 0, 0, 0, 4, 0, 0 };
  for (int c = 2; c >= 0; c--)
{
  b = f;
  *g = k[c + 3];
  k[c + 1] = 0;
}
  for (int i = 0; i < 8; i++)
if (d[0][i][0] != 0)
  __builtin_abort ();
  return 0;
}

[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Seems it is the ldist pass, which fails to figure out that k[c+3] load in the
loop might alias with the k[c+1] = 0; store and moves all the 3 stores into a
memset after the loop.

[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
So, quite early during LRA we get:
(insn 14 13 18 3 (set (reg:DI 9 %o1)
(zero_extend:DI (subreg:SI (mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -8 [0xfff8])) [4 %sfp+-8 S8
A64]) 4))) "ultrasp13.c":23:7 179 {*zero_extendsidi2_insn_sp64}
 (nil))
(insn 18 14 15 3 (set (reg:DI 111 [ ivtmp.11 ])
(plus:DI (reg:DI 111 [ ivtmp.11 ])
(const_int 8 [0x8]))) "ultrasp13.c":17:3 224 {*adddi3_sp64}
 (nil))
(insn 15 18 16 3 (set (reg:DI 8 %o0)
(zero_extend:DI (subreg:SI (mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -8 [0xfff8])) [4 %sfp+-8 S8
A64]) 0))) "ultrasp13.c":23:7 179 {*zero_extendsidi2_insn_sp64}
 (expr_list:REG_DEAD (reg/v:V8QI 114 [ v ])
(nil)))
It isn't clear why the subreg of the mem isn't folded to a mem/c:SI.
Further iteration tries to do:
(insn 44 13 45 3 (set (reg:V8QI 126)
(mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -8 [0xfff8])) [4 %sfp+-8 S8 A64]))
"ultrasp13.c":23:7 470 {*movv8qi_insn_sp64}
 (nil))
(insn 45 44 14 3 (set (reg:SI 127)
(subreg:SI (reg:V8QI 126) 4)) "ultrasp13.c":23:7 116 {*movsi_insn}
 (expr_list:REG_DEAD (reg:V8QI 126)
(nil)))
(insn 14 45 18 3 (set (reg:DI 9 %o1)
(zero_extend:DI (reg:SI 127))) "ultrasp13.c":23:7 179
{*zero_extendsidi2_insn_sp64}
 (expr_list:REG_DEAD (reg:SI 127)
(nil)))
(insn 18 14 42 3 (set (reg:DI 111 [ ivtmp.11 ])
(plus:DI (reg:DI 111 [ ivtmp.11 ])
(const_int 8 [0x8]))) "ultrasp13.c":17:3 224 {*adddi3_sp64}
 (nil))
(insn 42 18 43 3 (set (reg:V8QI 124)
(mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -8 [0xfff8])) [4 %sfp+-8 S8 A64]))
"ultrasp13.c":23:7 470 {*movv8qi_insn_sp64}
 (nil))
(insn 43 42 15 3 (set (reg:SI 125)
(subreg:SI (reg:V8QI 124) 0)) "ultrasp13.c":23:7 116 {*movsi_insn}
 (expr_list:REG_DEAD (reg:V8QI 124)
(nil)))
(insn 15 43 16 3 (set (reg:DI 8 %o0)
(zero_extend:DI (reg:SI 125))) "ultrasp13.c":23:7 179
{*zero_extendsidi2_insn_sp64}
 (expr_list:REG_DEAD (reg:SI 125)
(nil)))
and the insn 43 then reloaded into:
(insn 46 42 43 3 (set (mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -16 [0xfff0])) [4 %sfp+-16 S8 A64])
(reg:V8QI 124)) "ultrasp13.c":23:7 470 {*movv8qi_insn_sp64}
 (expr_list:REG_DEAD (reg:V8QI 124)
(nil)))
(insn 43 46 15 3 (set (reg:SI 125)
(subreg:SI (mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -16 [0xfff0])) [4 %sfp+-16 S8 A64])
0)) "ultrasp13.c":23:7 116 {*movsi_insn}
 (expr_list:REG_DEAD (reg:V8QI 128 [124])
(nil)))
and then
(insn 47 46 48 3 (set (reg:V8QI 129)
(mem/c:V8QI (plus:DI (reg/f:DI 101 %sfp)
(const_int -16 [0xfff0])) [4 %sfp+-16 S8 A64]))
"ultrasp13.c":23:7 470 {*movv8qi_insn_sp64}
 (nil))
(insn 48 47 43 3 (set (reg:SI 130)
(subreg:SI (reg:V8QI 129) 0)) "ultrasp13.c":23:7 116 {*movsi_insn}
 (expr_list:REG_DEAD (reg:V8QI 129)
(nil)))
(insn 43 48 15 3 (set (reg:SI 125)
(reg:SI 130)) "ultrasp13.c":23:7 116 {*movsi_insn}
 (expr_list:REG_DEAD (reg:SI 130)
(nil)))
and now we are back at two steps before with insn 48 now being what insn 43
used to be, and like that forever.

[Bug middle-end/92096] [10 Regression] segmentation fault in 'example_labels' building gcc trunk on cygwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Jakub Jelinek  ---
.

[Bug c++/93901] [10 Regression] noexcept specifier on ctor does not work with constexpr variable or expression since r10-4394

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
commit r10-7116-g481fcfe6fec156ca2a6baea4b623076e2eefa6a6   
Author: Jason Merrill 
Date:   Tue Mar 10 17:31:33 2020 -0400  

c++: Fix deferred noexcept on constructor [PR93901].

My change in r10-4394 to only update clones when we actually instantiate a  
deferred noexcept-spec broke this because deferred parsing updates the  
primary function but not the clones.  For GCC 10, let's just revert it. 

gcc/cp/ChangeLog
2020-03-10  Jason Merrill 

PR c++/93901
* pt.c (maybe_instantiate_noexcept): Always update clones.

[Bug c++/93596] [10 Regression] ICE related to templates and vectors.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
commit r10-7115-gdf15a82804e1f7f4a7432670b33387779de46549
Author: Jason Merrill 
Date:   Tue Mar 10 17:51:46 2020 -0400

c++: Fix ICE with omitted template args [PR93956].

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A.  maybe_aggr_guide should also use that test.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93956
* pt.c (maybe_aggr_guide): Check BRACE_ENCLOSED_INITIALIZER_P.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek  ---
commit r10-7110-g14af5d9b19b0f4ee1d929e505e245ae5c2f6bdc6
Author: Jason Merrill 
Date:   Tue Mar 10 16:05:18 2020 -0400

c++: Partially revert patch for PR66139.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time,
introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93922
PR c++/94041
PR c++/52320
PR c++/66139
* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
66139: Don't split_nonconstant_init.  Remove pre_p parameter.

[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
commit r10-7110-g14af5d9b19b0f4ee1d929e505e245ae5c2f6bdc6
Author: Jason Merrill 
Date:   Tue Mar 10 16:05:18 2020 -0400

c++: Partially revert patch for PR66139.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time,
introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93922
PR c++/94041
PR c++/52320
PR c++/66139
* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
66139: Don't split_nonconstant_init.  Remove pre_p parameter.

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
commit r10-7110-g14af5d9b19b0f4ee1d929e505e245ae5c2f6bdc6
Author: Jason Merrill 
Date:   Tue Mar 10 16:05:18 2020 -0400

c++: Partially revert patch for PR66139.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time,
introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93922
PR c++/94041
PR c++/52320
PR c++/66139
* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
66139: Don't split_nonconstant_init.  Remove pre_p parameter.

[Bug c++/52320] missing destructor call after thrown exception in initializer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
commit r10-7110-g14af5d9b19b0f4ee1d929e505e245ae5c2f6bdc6
Author: Jason Merrill 
Date:   Tue Mar 10 16:05:18 2020 -0400

c++: Partially revert patch for PR66139.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time,
introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  

PR c++/93922
PR c++/94041
PR c++/52320
PR c++/66139
* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
66139: Don't split_nonconstant_init.  Remove pre_p parameter.

[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Well, in the testcase you've provided the variable isn't modified in any way
(nor used), so there is nothing wrong in optimizing it away completely or
putting it into a read-only section.
But say:
static volatile int zero = 0;
static volatile int one = 1;
int main () { zero++; one++; return 0; }
shows it is a real bug, assuming that the .text section is not modifiable on
pdp11-aout.

[Bug tree-optimization/94114] [8/9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |gimplify_modify_expr, at|gimplify_modify_expr, at
   |gimplify.c:5936 |gimplify.c:5936

--- Comment #3 from Jakub Jelinek  ---
commit r10-7120-g05ac4d9c7b336e30413dd80c3630981151499f9e
Author: Jakub Jelinek 
Date:   Wed Mar 11 09:32:22 2020 +0100

ldist: Further fixes for -ftrapv [PR94114]

As the testcase shows, arithmetics that for -ftrapv would need multiple
basic blocks can show up not just in nb_bytes expressions where we
are calling rewrite_to_non_trapping_overflow for a while already,
but also in the pointer expression to the start of the region.
While the testcase covers just the first hunk and I've failed to create
a testcase for the latter, it is at least in theory possible too, so I've
adjusted that hunk too.

2020-03-11  Jakub Jelinek  

PR tree-optimization/94114
* tree-loop-distribution.c (generate_memset_builtin): Call
rewrite_to_non_trapping_overflow even on mem.
(generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow
even
on dest and src.

* gcc.dg/pr94114.c: New test.

[Bug middle-end/94111] Wrong constant folding: decimal floating-point infinity casted to double -> zero

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
commit r10-7121-g312992f5a07ca25f94d538b08401789c2c764293
Author: Jakub Jelinek 
Date:   Wed Mar 11 09:33:52 2020 +0100

dfp: Fix decimal_to_binary [PR94111]

As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation
contains a decimal128 embedded in ->sig only if it is rvc_normal, for
other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is
contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).
decimal_to_binary which is used when folding a decimal{32,64,128} constant
to a binary floating point type ignores this and thus folds infinities and
NaNs into +0.0.
The following patch fixes that by only doing that for rvc_normal.
Similarly to the binary to decimal folding, it goes through a string, in
order to e.g. deal with canonical NaN mantissas, or binary float formats
that don't support infinities and/or NaNs.

2020-03-11  Jakub Jelinek  

PR middle-end/94111
* dfp.c (decimal_to_binary): Only use decimal128ToString if
from->cl
is rvc_normal, otherwise use real_to_decimal to print the number to
string.

* gcc.dg/dfp/pr94111.c: New test.

[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
commit r10-7122-g60342fdbfb0630243d2b85d2ca45204ded990b17
Author: Jakub Jelinek 
Date:   Wed Mar 11 09:34:59 2020 +0100

value-prof: Fix abs uses in value-prof.c [PR93962]

Jeff has recently fixed dump_histogram_value to use std::abs instead of
abs,
because on FreeBSD apparently the ::abs isn't overloaded and only has
int abs (int);
Seems on Solaris /usr/include/iso/stdlib_iso.h abs has:
int abs (int);
long abs (long);
overloads but already not
long long abs (long long);
and there is another abs use in get_nth_most_common_value, also on int64_t.
The long long std::abs (long long); overload is there only in C++11 and we
in GCC10 still support C++98.

Martin has said that a counter should never be INT64_MIN, so IMHO it is
better to use abs_hwi which will assert that.

2020-03-11  Jakub Jelinek  

PR bootstrap/93962
* value-prof.c (dump_histogram_value): Use abs_hwi instead of
std::abs.
(get_nth_most_common_value): Use abs_hwi instead of abs.