[Bug rtl-optimization/80791] [8/9 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[amker at gcc dot gnu.org]

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

--- Comment #23 from bin cheng  ---
(In reply to Kewen Lin from comment #22)
> As the discussion above, on Power any IV should have an extend (sign/zero)
> if its width is less than the GPR width (POINTER_SIZE equivalent here).
> Although we don't model this precisely on Power, in most cases it's trivial
> since we have TYPE_PRECISION check for those inconsistent width uses, extra
> cost will be added, the IV is still the one we prefer even with extension
> consideration in cost modeling, that is, considering extension or not
> doesn't affect the result.
I wonder if a pre-Loop-Opt pass promotes (maybe only induction) variables to
GPR size for usual/simple cases could be helpful? That is, lift burden by
canonicalizing input to IVOPTs as much as possible.  As a mono pass, the
extensibility is not good enough to cover every case, especially based on
possible following optimization.

> 
> In this case, we have one GENERIC use and one CMP use. Cand 4 was chosen as
> the best, but later RTL opts can eliminate CMP use by using counter register
> for the loop closing, it means we don't need to consider CMP use in ivopts
> phase. Since there is no any uses for 32bit IV, the extension cost can NOT
> be covered (ignored) as usual.
> 
> The cost for GENERIC use looks like [cand $index ($iv_cost + $comp_cost)]:
>   1) without considering extension cost, cand 4 (4 + 4) vs. cand 6 (5 + 0) 
>   2) with considering extension cost, cand 4 (8 + 4) vs. cand 6 (9 + 0)
> Since cand 6 can't be used for CMP use, so if we still need to consider CMP,
> cand 4 is always selected, the cost would be larger introducing cand 6. 
> But if can predict CMP is useless and model extension, the cost would be:
> cand 4 (8 + 4) vs. cand 6 (9 + 0). Cand 6 is better.
Elimination of CMP with doloop is not modeled in IVOPTs now, would be great to
have that.  With that support, cand 6 would be chosen regardless of extension
here, right?  Of course, computing cost based on possibly eliminable cand/use
is totally another issue and is even harder.


> 
> I did some hacks locally and it works. But the most tricky and hardest part
> would be how to predict CMP will be optimized away with CTR eventually, 
> the correctness of predict is more important. It looks better to think about
> the simplest case first. The proposed idea is that:
>   1) one target specific hook/flag to enable this adjust
>   2) one target specific predict function to determine the loop can benefit
> do_loop CTR transformation (like innermost loop, no calls, niter determined
> etc.)
>   3) check only one CMP with biv after find_interesting_uses, biv's width <
> POINTER_SIZE, remove the group
>   4) mark the biv preserved to avoid to be removed in remove_unused_ivs
>   5) adjust determine_iv_cost for those IVs which require extension
> (optinal, for this case, it's not necessary but probably good as more
> precise modeling)
> 
> Hi All,
> 
> I'm a new comer to gcc and not sure the above idea is practical enough,
> could you kindly give me some comments and suggestion?

Gibberish, I thought IVOPTs has been improved, but if we continue getting this
kind of sub-optimal issues, maybe we should try to re-implement it, as a group
of small passes each dedicating to specific transformation, rather than a big
mono pass.

Thanks

[Bug c/89520] [7/8 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Jakub Jelinek  ---
Fixed only for 9+ so far though.

[Bug c/89525] [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/89520] [7/8 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[7/8/9 Regression] ICE tree |[7/8 Regression] ICE tree
   |check: accessed operand 4   |check: accessed operand 4
   |of call_expr with 3 |of call_expr with 3
   |operands in |operands in
   |convert_to_integer_1, at|convert_to_integer_1, at
   |convert.c:668   |convert.c:668

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[gccbugzilla at limegreensocks dot com]

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

--- Comment #7 from David  ---
(In reply to ktkachov from comment #6)
> I think David (CC'ed) was interested in this?
Well, the news here is mixed.

While I attempted to write this (see
https://www.limegreensocks.com/arm/Extended-Asm.html#AArch64Operandmodifiers),
I don't actually speak ARM assembler.  AAR, my confidence in my attempts to
explain things or give examples is limited.  I'm not excited about posting a
doc patch that turns out to be stupid when viewed by ARM experts.

Unless someone who does speak ARM is prepared to comment/review, I'm not sure
how to proceed.  And the few people I know who do speak ARM aren't responding.

- David

[Bug c/89525] [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 28 07:17:49 2019
New Revision: 269274

URL: https://gcc.gnu.org/viewcvs?rev=269274=gcc=rev
Log:
PR c/89525
* c-typeck.c (convert_arguments): Call inform_declaration only if
the previous warning_at call returned true.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr89525.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89520] [7/8/9 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 28 07:16:38 2019
New Revision: 269273

URL: https://gcc.gnu.org/viewcvs?rev=269273=gcc=rev
Log:
PR c/89520
* convert.c (convert_to_real_1, convert_to_integer_1): Punt for
builtins if they don't have a single scalar floating point argument.
Formatting fixes.

* gcc.dg/pr89520-1.c: New test.
* gcc.dg/pr89520-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr89520-1.c
trunk/gcc/testsuite/gcc.dg/pr89520-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/convert.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[mike at spertus dot com]

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

Mike Spertus  changed:

   What|Removed |Added

 CC||mike at spertus dot com

--- Comment #5 from Mike Spertus  ---
Since this deduction comes from the standard’s set(set, Allocator) constructor,
I would say that in this case the gnu behavior is conforming and the MSVC
behavior is not (not implying anything here about what the standard should say,
just what it does...).

[Bug target/88100] no warning reported when value for vec_splat_{su}{8,16} would overflow

[helijia at gcc dot gnu.org]

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

--- Comment #5 from Li Jia He  ---
Author: helijia
Date: Thu Feb 28 06:24:57 2019
New Revision: 269272

URL: https://gcc.gnu.org/viewcvs?rev=269272=gcc=rev
Log:
Backport from trunk
2019-02-20  Li Jia He  

PR target/88100
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin)
: Don't convert the operand before
range checking it.

* gcc/testsuite/gcc.target/powerpc/pr88100.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr88100.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[arthur.j.odwyer at gmail dot com]

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

--- Comment #4 from Arthur O'Dwyer  ---
libstdc++ passes all my test cases now except this one:
```
// https://godbolt.org/z/kvh9Ih
#include 
std::set s;
std::set t(s, std::allocator());
```

The issue is that we humans can logically deduce t's Allocator parameter as
"the same as s's Allocator parameter", but due to an implementation detail, the
compiler is also trying to deduce t's Allocator parameter as
std::allocator, and so it deduces conflicting types and fails deduction.

This test case could be made to work if you changed
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_set.h#L124
from
typedef _Alloc   allocator_type;
to
typedef typename __identity<_Alloc>::type   allocator_type;
or whatever libstdc++'s equivalent of __identity is.

MSVC's `set` already effectively does this, by inheriting its `allocator_type`
typedef from a base class. I don't know whether the paper standard has a
definite interpretation one way or the other; it might be open to
interpretation, or it might even say that MSVC is wrong in this case.
(Logically, I think MSVC *should* be right.)

Perhaps a new bugzilla issue should be opened for this one.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[yyc1992 at gmail dot com]

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

--- Comment #24 from Yichao Yu  ---
Oh, and the test case above was compiled with -O3 (and -g -Wall -Wextra).

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[yyc1992 at gmail dot com]

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

Yichao Yu  changed:

   What|Removed |Added

 CC||yyc1992 at gmail dot com

--- Comment #23 from Yichao Yu  ---
> It is GCC does not realign the stack at all that is the issue.

I hit another related issue that might confirm this as well.

I noticed this when I tried to manually align the stack with inline assembly.

C++ code reduced from my test case,

```
#include 
#include 
#include 

__attribute__((target("avx")))
__attribute__((noinline)) __m256d f(__m256d x, uint32_t a, const double *p)
{
__m256d res;
asm volatile ("vxorpd %0, %0, %0" :
  "=x"(res), "+x"(x), "+r"(a), "+r"(p) ::
  "memory", "rax", "rcx", "rdx", "r8", "r9", "r10",
  "r11", "rbp");
return res;
}

__attribute__((target("avx")))
__attribute__((noinline)) __m256d f2(__m256d x, uint32_t a, const double *p)
{
__m256d res;
asm volatile ("vxorpd %0, %0, %0" :
  "=x"(res), "+x"(x), "+r"(a), "+r"(p) ::
  "memory", "rax", "rcx", "rdx", "r8", "r9", "r10",
  "r11", "rbp");
return res;
}

__attribute__((target("avx")))
__attribute__((noinline)) __m256d f(__m256d x, __m256d y, __m256d z,
uint32_t a, const double *p)
{
__m256d res;
asm volatile ("vxorpd %0, %0, %0" :
  "=x"(res), "+x"(x), "+x"(y), "+x"(z), "+r"(a), "+r"(p) ::
  "memory", "rax", "rcx", "rdx", "r8", "r9", "r10",
  "r11", "rbp");
return res;
}

const double points[] = {0, 0.1, 0.2, 0.6};

__attribute__((target("avx"))) void test_avx()
{
f(__m256d{0, 0, 0, 0}, __m256d{0, 0, 0, 0},
   __m256d{0, 0, 0, 0}, 4, points);
f(__m256d{0, 0, 0, 0}, 4, points);
}

__attribute__((target("avx"))) void test_avx2()
{
f2(__m256d{0, 0, 0, 0}, 4, points);
}

static void call_aligned_stack(void (*p)(void))
{
asm volatile ("movq %%rsp, %%rbp\n"
  "andq $-64, %%rsp\n"
  "subq $64, %%rsp\n"
  "callq *%0\n"
  "movq %%rbp, %%rsp\n"
  :: "r"(p)
  : "memory", "rax", "rcx", "rdx", "r8", "r9", "r10", "r11",
"rbp");
}

int main()
{
call_aligned_stack(test_avx);
fprintf(stderr, "\n");
fflush(stderr);
call_aligned_stack(test_avx2);
return 0;
}
```

(The `fprintf` is there only to make it easier to see when the crash happens.)
The stack alignment code makes sure that the stack is aligned to 64bytes before
making the `call`, which is verified in the debugger, however, when compiled
with GCC 8.2.1 on msys2 (using the mingw-w64-x86_64-gcc package) the `test_avx`
function is happy while `test_avx2` function is not.

Looking at the generated code, for the crashing function:

```
004015c0 <_Z9test_avx2v>:
  4015c0:   48 83 ec 68 sub$0x68,%rsp
  4015c4:   c5 f9 57 c0 vxorpd %xmm0,%xmm0,%xmm0
  4015c8:   4c 8d 0d 51 7a 00 00lea0x7a51(%rip),%r9# 409020
<_ZL6points>
  4015cf:   41 b8 04 00 00 00   mov$0x4,%r8d
  4015d5:   48 8d 4c 24 40  lea0x40(%rsp),%rcx
  4015da:   48 8d 54 24 20  lea0x20(%rsp),%rdx
  4015df:   c5 fd 29 44 24 20   vmovapd %ymm0,0x20(%rsp)
  4015e5:   c5 f8 77vzeroupper 
  4015e8:   e8 a3 ff ff ff  callq  401590 <_Z2f2Dv4_djPKd>
  4015ed:   90  nop
  4015ee:   48 83 c4 68 add$0x68,%rsp
  4015f2:   c3  retq   
```

which tries to write with 32byte alignment with a stack offset from the initial
call instruction: -8 - 0x68 + 0x20 = -80.

OTOH, for the "good" function,

```
00401640 <_Z8test_avxv>:
  401640:   57  push   %rdi
  401641:   56  push   %rsi
  401642:   53  push   %rbx
  401643:   48 81 ec b0 00 00 00sub$0xb0,%rsp
  40164a:   c5 d9 57 e4 vxorpd %xmm4,%xmm4,%xmm4
  40164e:   48 8d 3d cb 79 00 00lea0x79cb(%rip),%rdi#
409020 <_ZL6points>
  401655:   48 8d 74 24 70  lea0x70(%rsp),%rsi
  40165a:   4c 8d 4c 24 30  lea0x30(%rsp),%r9
  40165f:   48 89 7c 24 28  mov%rdi,0x28(%rsp)
  401664:   48 8d 9c 24 90 00 00lea0x90(%rsp),%rbx
  40166b:   00 
  40166c:   4c 8d 44 24 50  lea0x50(%rsp),%r8
  401671:   48 89 f2mov%rsi,%rdx
  401674:   c5 fd 29 64 24 70   vmovapd %ymm4,0x70(%rsp)
  40167a:   48 89 d9mov%rbx,%rcx
  40167d:   c5 fd 29 64 24 50   vmovapd %ymm4,0x50(%rsp)
  401683:   c5 fd 29 64 24 30   vmovapd %ymm4,0x30(%rsp)
  401689:   c7 44 24 20 04 

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

[egallager at gcc dot gnu.org]

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

--- Comment #21 from Eric Gallager  ---
(In reply to Mark Wielaard from comment #20)
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html

Did this make it in? If not, have you pinged it lately?

[Bug debug/89530] New: Wrong debug informations for C array generated at -Og [gcc-trunk]

[dccitaliano at gmail dot com]

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

Bug ID: 89530
   Summary: Wrong debug informations for C array generated at -Og
[gcc-trunk]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dccitaliano at gmail dot com
  Target Milestone: ---

$ cat a.c
int e, g;
short f;
char h;
short(a)(b) {}
int(c)(d) {}
void i() {
  int j, k;
  unsigned short l_1404[3][9] = {58143, 8, 5, 80};
  for (; f; f = 0)
if (h)
  e = l_1404[0][7];
else {
  for (; g;)
j = k = c(j);
  e = a(k);
}
  optimize_me_not();
}
int main() { i(); }

$ cat outer.c
void optimize_me_not() {}

### -O0

Reading symbols from ./a.out...
(gdb) b 17
Breakpoint 1 at 0x40055c: file 3.c, line 17.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, i () at 3.c:17
17optimize_me_not();
(gdb) p l_1404[0][0]
$1 = 58143

### -Og

Reading symbols from ./a.out...
(gdb) b 17
Breakpoint 1 at 0x4004f5: file 3.c, line 17.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, i () at 3.c:17
17optimize_me_not();
(gdb) p l_1404[0][0]
$1 = 9


$ gcc-trunk --version
gcc-trunk (GCC) 9.0.1 20190227 (experimental) [trunk revision 269248]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb-trunk --version
GNU gdb (GDB) 8.3.50.20190227-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug debug/89529] Wrong debug info generated at -Og [gcc-trunk]

[dccitaliano at gmail dot com]

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

--- Comment #1 from dcci  ---
The breakpoint is set on the line where the decrement happens, so it should
probably print the value before the decrement (at -Og)

[Bug debug/89529] New: Wrong debug info generated at -Og [gcc-trunk]

[dccitaliano at gmail dot com]

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

Bug ID: 89529
   Summary: Wrong debug info generated at -Og [gcc-trunk]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dccitaliano at gmail dot com
  Target Milestone: ---

$ cat 2.c
int a;
void b() {
  short l_1862 = 19071;
  a = 0;
  for (; 0;)
optimize_me_not();
  --l_1862;
}
int main() { b(); }

$ cat outer.c
void optimize_me_not() {}

### -Og

Reading symbols from ./a.out...
(gdb) b 6
Breakpoint 1 at 0x40048c: file 2.c, line 7.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, b () at 2.c:7
7 --l_1862;
(gdb) frame var
No symbol "var" in current context.
(gdb) info locals
l_1862 = 19070

### -O0

Reading symbols from ./a.out...
(gdb) b 6
Breakpoint 1 at 0x400497: file 2.c, line 7.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, b () at 2.c:7
7 --l_1862;
(gdb) info locals
l_1862 = 19071

$ gcc-trunk --version
gcc-trunk (GCC) 9.0.1 20190227 (experimental) [trunk revision 269248]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb-trunk --version
GNU gdb (GDB) 8.3.50.20190227-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug debug/89528] New: Wrong debug info generated at -Og [gcc-trunk]

[dccitaliano at gmail dot com]

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

Bug ID: 89528
   Summary: Wrong debug info generated at -Og [gcc-trunk]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dccitaliano at gmail dot com
  Target Milestone: ---

$ cat 5.c
char b;
int d, e;
static int i = 1;
void a(l) { printf("", l); }
char(c)(char l) { return l || b && l == 1 ? b : b % l; }
short(f)(l, m) { return l * m; }
short(g)(short l, short m) { return m || l == 767 && m == 1; }
int(h)(l, m) { return (l ^ m & l ^ (m & 647) - m ^ m) < m; }
static int(j)(l) { return d == 0 || l == 647 && d == 1 ? l : l % d; }
short(k)(l) { return l >= 2 >> l; }
static short n(void) {
  int l_1127 = ~j(9 || 0) ^ 65535;
  optimize_me_not();
  f(l_1127, i && e ^ 4) && g(0, 0);
  e = 0;
  return 5;
}
int main() { n(); }

$ cat outer.c
void optimize_me_not() {}


### -Og

Reading symbols from ./a.out...
(gdb) b 13
Breakpoint 1 at 0x400590: file 5.c, line 13.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, n () at 5.c:13
13optimize_me_not();
(gdb) info locals
l_1127 = -4258335

### -O0

Reading symbols from ./a.out...
(gdb) b 13
Breakpoint 1 at 0x40064c: file 5.c, line 13.
(gdb) r
Starting program: /home/davide/finished-reducing-gcc/a.out

Breakpoint 1, n () at 5.c:13
13optimize_me_not();
(gdb) info locals
l_1127 = -65535

$ gcc-trunk --version
gcc-trunk (GCC) 9.0.1 20190227 (experimental) [trunk revision 269248]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb-trunk --version
GNU gdb (GDB) 8.3.50.20190227-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug c/89527] New: GCC ICE internal compiler error during RTL pass: mach on arm/thumb2

[raj.khem at gmail dot com]

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

Bug ID: 89527
   Summary: GCC ICE internal compiler error during RTL pass: mach
on arm/thumb2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

While compiling glibc-2.29, timezone/zic, gcc started to ICE( this was working
ok few weeks ago), this only happens when compiling with thumb2, it works ok in
arm mode.

$
../../recipe-sysroot-native/usr/bin/arm-yoe-linux-gnueabi/arm-yoe-linux-gnueabi-gcc
 -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/mnt/a/yoe/build/tmp/work/cortexa7t2hf-neon-vfpv4-yoe-linux-gnueabi/glibc/2.29-r0/recipe-sysroot
a.c -c

a.c: In function 'foo':
a.c:9:1: error: unrecognizable insn:
9 | }
  | ^
(insn 33 32 23 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 3 r3 [ min_year.0_1+4 ])
(const_int -2147483648 [0x8000])))
(set (reg:SI 3 r3 [113])
(minus:SI (plus:SI (reg:SI 3 r3 [ min_year.0_1+4 ])
(const_int -2147483648 [0x8000]))
(ltu:SI (reg:CC_C 100 cc)
(const_int 0 [0]
]) "a.c":6:6 -1
 (nil))
during RTL pass: mach
a.c:9:1: internal compiler error: in extract_insn, at recog.c:2310
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


==
reduced testcase a.c
==


static long long int min_year;
void foo() {
  enum { years_of_observations = 400 + 2 };
  if (min_year >= (-9223372036854775807LL -1) + years_of_observations)
return;
}

==

[Bug c++/88857] [7/8 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |build_value_init|build_value_init

--- Comment #9 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Thu Feb 28 00:07:06 2019
New Revision: 269267

URL: https://gcc.gnu.org/viewcvs?rev=269267=gcc=rev
Log:
PR c++/88857 - ICE with value-initialization of argument in template.
* call.c (convert_like_real): Don't call build_value_init in template.

* g++.dg/cpp0x/initlist-value4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 45846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45846=edit
cmd_go-testlog from x86_64-linux on idle box

real3m9.956s
user9m3.231s
sys 0m39.443s

Though, unlike the normal case, there aren't 63 other tests running
concurrently with that, so it doesn't surprise me if the 3 minute wall time
grows 4 or how many times (especially when the user time is 9 minutes and so it
means it is more than one concurrent process or thread to handle that.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor  ---
Thanks.  In both cases the tests were killed because they ran too long (the
timeout was 11 minutes).  Since the tests were killed, they didn't clean up
after themselves.

Can you cd to the gotools directory and run "time make check-go-tool" and see
how long it takes?  Also whether it passes (the full output will go to
cmd_go-testlog)?  Thanks.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 45845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45845=edit
cmd_go-testlog from i686-linux build

Note, this is on 16c32t skylake-avx512 running:
../configure --enable-languages=default,ada,obj-c++,lto,go,brig,d
--enable-checking=yes,rtl,extra && make -j32 bootstrap > LOG 2>&1 &&
GXX_TESTSUITE_STDS=98,11,14,17,2a make -j32 -k check > LOGC 2>&1;
../contrib/test_summary > LOGT 2>&1
for x86_64-linux and
PATH=~/hbin:$PATH i386 ../configure
--enable-languages=default,obj-c++,lto,go,brig,d
--enable-checking=yes,rtl,extra && PATH=~/hbin:$PATH i386 make -j32 bootstrap >
LOG 2>&1 && PATH=~/hbin:$PATH GXX_TESTSUITE_STDS=98,11,14,17,2a i386 make -j32
-k check > LOGC 2>&1; ../contrib/test_summary > LOGT 2>&1
with
for i in ~/hbin/*; do echo ===$i===; cat $i; done
===/home/jakub/hbin/as===
#!/bin/sh
exec /usr/bin/as --32 "$@"
===/home/jakub/hbin/g++===
#!/bin/sh
exec /usr/bin/g++ -m32 "$@"
===/home/jakub/hbin/gcc===
#!/bin/sh
exec /usr/bin/gcc -m32 "$@"
===/home/jakub/hbin/ld===
#!/bin/sh
case "$*" in
  --version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EOF
  exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"

Both bootstraps/regtests are running in parallel.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 45844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45844=edit
cmd_go-testlog from x86_64

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Can you attach the file gotools/cmd_go-testlog from your build directory?

[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
The patch turned out to require a small adjustment for scalar MOLD
of size 0, so I posted it for review:

https://gcc.gnu.org/ml/fortran/2019-02/msg00237.html

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Yes, some go tests fail pretty much all the time for me, but with quite high
volatility, so I usually ignore them if there aren't too many.  This time
FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
FAIL: go.test/test/nilptr2.go execution,  -O2 -g
FAIL: go test cmd/go
FAIL: go test runtime
on x86_64-linux and
FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
FAIL: go test cmd/go
FAIL: TestScript
FAIL: go test runtime
FAIL: TestAbort
on i686-linux.

[Bug go/89172] FAIL: runtime/pprof

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Did any of the tests fail?

[Bug go/89172] FAIL: runtime/pprof

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Feb 27 22:35:10 2019
New Revision: 269266

URL: https://gcc.gnu.org/viewcvs?rev=269266=gcc=rev
Log:
PR go/89172
internal/cpu, runtime, runtime/pprof: handle function descriptors

When using PPC64 ELF ABI v1 a function address is not a PC, but is the
address of a function descriptor.  The first field in the function
descriptor is the actual PC (see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES).
The libbacktrace library knows about this, and libgo uses actual PC
values consistently except for the helper function funcPC that appears
in both runtime and runtime/pprof.

This patch fixes funcPC by recording, in the internal/cpu package,
whether function descriptors are being used.  We have to check for
function descriptors using a C compiler check, because GCC can be
configured using --with-abi to select the ELF ABI to use.

Fixes https://gcc.gnu.org/PR89172

Reviewed-on: https://go-review.googlesource.com/c/162978

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/go/runtime/pprof/proto.go
trunk/libgo/go/runtime/proc.go
trunk/libgo/testsuite/Makefile.in

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
In today's x86_64-linux and i686-linux bootstrap, I see following in /tmp
(remove all non-systemd directories in /tmp before the bootstrap):
340681328
517045444
844331773
cmd-go-test-051806874
cmd-go-test-051806874/go-build626269585
cmd-go-test-051806874/go-build486488501
cmd-go-test-051806874/go-build486488501/b001
cmd-go-test-051806874/go-build985544238
cmd-go-test-051806874/go-build275250066
cmd-go-test-051806874/go-build206701887
cmd-go-test-051806874/go-build148081200
cmd-go-test-051806874/gotest035473270
cmd-go-test-051806874/gotest035473270/src
cmd-go-test-051806874/gotest035473270/src/p
cmd-go-test-051806874/gotest035473270/src/p/p_test.go
cmd-go-test-051806874/go-build618547490
cmd-go-test-051806874/go-build618547490/b008
cmd-go-test-051806874/go-build618547490/b008/vet.out
cmd-go-test-051806874/go-build618547490/b008/vet.cfg
cmd-go-test-051806874/go-build618547490/b008/_pkg_.a
cmd-go-test-051806874/go-build618547490/b008/_buildid.o
cmd-go-test-051806874/go-build618547490/b008/_buildid.s
cmd-go-test-051806874/go-build618547490/b008/_go_.o
cmd-go-test-051806874/go-build618547490/b008/_importcfgroot_
cmd-go-test-051806874/go-build618547490/b008/_importcfgroot_/libb.a
cmd-go-test-051806874/go-build618547490/b008/_importcfgroot_/liba.a
cmd-go-test-051806874/go-build618547490/b009
cmd-go-test-051806874/go-build618547490/b009/vet.out
cmd-go-test-051806874/go-build618547490/b009/vet.cfg
cmd-go-test-051806874/go-build618547490/b009/_pkg_.a
cmd-go-test-051806874/go-build618547490/b009/_buildid.o
cmd-go-test-051806874/go-build618547490/b009/_buildid.s
cmd-go-test-051806874/go-build618547490/b009/_go_.o
cmd-go-test-051806874/go-build618547490/b009/_importcfgroot_
cmd-go-test-051806874/go-build618547490/b009/_importcfgroot_/libb.a
cmd-go-test-051806874/go-build618547490/b007
cmd-go-test-051806874/go-build618547490/b007/vet.out
cmd-go-test-051806874/go-build618547490/b007/vet.cfg
cmd-go-test-051806874/go-build618547490/b007/_pkg_.a
cmd-go-test-051806874/go-build618547490/b007/_buildid.o
cmd-go-test-051806874/go-build618547490/b007/_buildid.s
cmd-go-test-051806874/go-build618547490/b007/_go_.o
cmd-go-test-051806874/go-build814904079
cmd-go-test-051806874/gotest973510067
cmd-go-test-051806874/gotest973510067/src
cmd-go-test-051806874/gotest973510067/src/p
cmd-go-test-051806874/gotest973510067/src/p/p.go
cmd-go-test-051806874/gotest511784738
cmd-go-test-051806874/gotest511784738/src
cmd-go-test-051806874/gotest511784738/src/p1
cmd-go-test-051806874/gotest511784738/src/p1/p1_test.go
cmd-go-test-051806874/gotest511784738/src/p1/p1.go
cmd-go-test-051806874/gotest648556558
cmd-go-test-051806874/gotest648556558/src
cmd-go-test-051806874/gotest648556558/src/b
cmd-go-test-051806874/gotest648556558/src/b/b_test.go
cmd-go-test-051806874/gotest648556558/src/b/export_test.go
cmd-go-test-051806874/gotest648556558/src/b/b.go
cmd-go-test-051806874/gotest648556558/src/a
cmd-go-test-051806874/gotest648556558/src/a/a.go
cmd-go-test-051806874/gotest294122667
cmd-go-test-051806874/gotest294122667/pkg-config.out
cmd-go-test-051806874/gotest294122667/pkg-config.sh
cmd-go-test-051806874/gotest294122667/src
cmd-go-test-051806874/gotest294122667/src/x
cmd-go-test-051806874/gotest294122667/src/x/b.go
cmd-go-test-051806874/gotest294122667/src/x/a.go
cmd-go-test-051806874/gotest072509820
cmd-go-test-051806874/gotest072509820/x.exe
cmd-go-test-051806874/gotest072509820/src
cmd-go-test-051806874/gotest072509820/src/x
cmd-go-test-051806874/gotest072509820/src/x/a.go
cmd-go-test-051806874/gotest882825809
cmd-go-test-051806874/gotest882825809/pkg
cmd-go-test-051806874/gotest882825809/pkg/gccgo_linux_386
cmd-go-test-051806874/gotest882825809/pkg/gccgo_linux_386/liba.a
cmd-go-test-051806874/gotest882825809/src
cmd-go-test-051806874/gotest882825809/src/a
cmd-go-test-051806874/gotest882825809/src/a/a.go
cmd-go-test-051806874/gotest996175495
cmd-go-test-051806874/gotest996175495/src
cmd-go-test-051806874/gotest996175495/src/example
cmd-go-test-051806874/gotest996175495/src/example/b
cmd-go-test-051806874/gotest996175495/src/example/a
cmd-go-test-051806874/gotest996175495/src/example/a/a.go
cmd-go-test-051806874/gotest996175495/src/example/a/Pkg
cmd-go-test-051806874/gotest996175495/src/example/a/Pkg/pkg.go
cmd-go-test-051806874/gotest996175495/src/example/a/pkg
cmd-go-test-051806874/gotest996175495/src/example/a/pkg/pkg.go
cmd-go-test-051806874/gotest063357645
cmd-go-test-051806874/gotest063357645/src
cmd-go-test-051806874/gotest063357645/src/cgoref
cmd-go-test-051806874/gotest063357645/src/cgoref/cgoref.go
cmd-go-test-051806874/tmpdir706014513
cmd-go-test-051806874/tmpdir706014513/testbin
cmd-go-test-051806874/tmpdir706014513/testbin/go
cmd-go-test-099107789
cmd-go-test-099107789/gotest690010532
cmd-go-test-099107789/gotest690010532/symdir1
cmd-go-test-099107789/gotest690010532/gopath
cmd-go-test-099107789/gotest690010532/gopath/bin

[Bug c++/86969] [8/9 Regression] ICE (in tsubst_copy) for a generic recursive lambda

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Feb 27 21:54:25 2019
New Revision: 269265

URL: https://gcc.gnu.org/viewcvs?rev=269265=gcc=rev
Log:
PR c++/86969 - ICE with constexpr if and recursive generic lambdas.

Here, the problem was that extract_local_specs wasn't seeing that we use
'self' inside the lambda in the else of the inner constexpr if, because we
don't walk into lambda bodies and we didn't capture it in the lambda because
'self' is still dependent.  Marek recently changed process_outer_var_ref to
do more implicit capture in templates; this example shows that we should
always capture non-packs, so that we can continue to not walk into lambda
bodies.  We do walk into lambda bodies for pack expansions, so we can delay
deciding whether we're capturing a single element or the entire pack.

Immediately capturing a VLA means we need to create a dependent VLA capture
type, and not in the context of the lambda op(), since trying to look up the
instantiation of the op() while we're substituting into the capture list
would crash.  So I force TYPE_CONTEXT and the binding level out to the
enclosing function before pushtag, avoid adding a TAG_DEFN, and instead
force the type to be complete in tsubst_lambda_expr.

* semantics.c (process_outer_var_ref): Do capture dependent vars.
* class.c (finish_struct): Only add TAG_DEFN if T is in
current_function_decl.
* lambda.c (vla_capture_type): Force the capture type out into the
lambda's enclosing function.
(add_capture): Pass in the lambda.
* pt.c (tsubst_lambda_expr): complete_type a VLA capture type.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c

[Bug c/89526] New: Diagnose errors in asserts

[david.bolvansky at gmail dot com]

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

Bug ID: 89526
   Summary: Diagnose errors in asserts
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

GCC trunk -Wall -Wextra

#include 

int foo(int *x) {
assert(x && "nullptr");
return *x;
}

int foo2(int *x) {
assert("nullptr");  // should warn
return *x;
}

[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The ICE is triggered by a code path that is executed only when -Wsurprising
is used together with TRANSFER.

I'm currently testing the following patch:

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269227)
+++ gcc/fortran/check.c (working copy)
@@ -5503,7 +5503,8 @@
   if (result_elt_size == 0 && *source_size == 0 && !size)
 {
   *result_size = 0;
-  *result_length_p = 0;
+  if (result_length_p)
+   *result_length_p = 0;
   return true;
 }

Will commit as obvious if it finishes successfully.

[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays

[fche at redhat dot com]

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

--- Comment #70 from Frank Ch. Eigler  ---
> We could add a NATIVE_ENCODE_RANGE_EXPR that encodes a contiguous range of
> bytes in native target representation. Of course that has to be kept
> throughout GIMPLE.

(Just a silly spitballing here ... but if such a native target representation
is
not processed again before being sent to the assembler, it could even be stored
compressed.)

[Bug c/89525] [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Started with r266194.

[Bug c/89520] [7/8/9 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Most likely started with r81269.

[Bug c/89525] [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45843=edit
gcc9-pr89525.patch

Untested fix.

[Bug c/89525] [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-27
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c/89525] New: [9 Regression] inform messages from -Wbuiltin-declaration-mismatch even with -w

[jakub at gcc dot gnu.org]

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

Bug ID: 89525
   Summary: [9 Regression] inform messages from
-Wbuiltin-declaration-mismatch even with -w
   Product: gcc
   Version: 9.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: ---

/* { dg-do compile } */
/* { dg-options "-w" } */

double sqrt (); /* { dg-bogus "declared here" } */

void
foo (void)
{
  sqrt ();
}

emits a bogus message (warning is not emitted, but inform is).

[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays

[rguenther at suse dot de]

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

--- Comment #69 from rguenther at suse dot de  ---
On February 27, 2019 8:52:12 PM GMT+01:00, fche at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
>
>--- Comment #68 from Frank Ch. Eigler  ---
>(In reply to Jakub Jelinek from comment #67)
>> Are the values completely random or are there big chunks with the
>same
>> values?
>
>I'd suspect pretty random, considering that gzip of the 
>generated source code compresses by only 80%.  In the case
>of the systemtap example, it's approximately a byte dump of the
>.debug_line section, which is relatively efficiently encoded,
>ergo incompressible.

We could add a NATIVE_ENCODE_RANGE_EXPR that encodes a contiguous range of
bytes in native target representation. Of course that has to be kept throughout
GIMPLE.

[Bug c/89520] [7/8/9 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45842=edit
gcc9-pr89520.patch

Untested fix.

[Bug c/89520] [7/8/9 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5
Summary|ICE tree check: accessed|[7/8/9 Regression] ICE tree
   |operand 4 of call_expr with |check: accessed operand 4
   |3 operands in   |of call_expr with 3
   |convert_to_integer_1, at|operands in
   |convert.c:668   |convert_to_integer_1, at
   ||convert.c:668

--- Comment #1 from Jakub Jelinek  ---
4.0 compiles this fine, 4.1 already ICEs, can't bisect right now (but have a
fix).

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #37 from Bernd Edlinger  ---
fixed.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[edlinger at gcc dot gnu.org]

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

--- Comment #36 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Feb 27 20:14:55 2019
New Revision: 269264

URL: https://gcc.gnu.org/viewcvs?rev=269264=gcc=rev
Log:
2019-02-27  Bernd Edlinger  

PR rtl-optimization/89490
* varasm.c (get_block_for_section): Bail out for mergeable sections.
(default_use_anchors_for_symbol_p, output_object_block): Assert the
block section is not mergeable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c

[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.0 |7.5

--- Comment #10 from Uroš Bizjak  ---
Fixed everywhere.

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Matt Whitlock from comment #0)
> test.cpp:9:4: warning: ignoring packed attribute because of unpacked non-POD
> field 'S P::s'

I think this diagnostic would be improved if it said "ignoring packed attribute
because of unpacked field 'S P::s' which is not POD for the purposes of layout"

That would refer to the term from the ABI spec that is relevant to class
layout, which is not the same as the property tested by std::is_pod.

(In reply to Matt Whitlock from comment #5)
> For what it's worth, having two conflicting definitions of "POD" is
> confusing.

The std::is_pod trait is deprecated in the C++2a draft, and the clauses
describing the core language no longer use the term POD at all.

[Bug c/89520] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-27
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
The case with NEWUNIT= has been fixed.

I do not see a need to give a warning for

open(20)

except for e.g. -pedantic, but if you feel differently, please reopen.

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Matt Whitlock from comment #3)
> For instance, the ABI of std::string differs between C++98 and C++11.

No it doesn't.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays

[fche at redhat dot com]

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

--- Comment #68 from Frank Ch. Eigler  ---
(In reply to Jakub Jelinek from comment #67)
> Are the values completely random or are there big chunks with the same
> values?

I'd suspect pretty random, considering that gzip of the 
generated source code compresses by only 80%.  In the case
of the systemtap example, it's approximately a byte dump of the
.debug_line section, which is relatively efficiently encoded,
ergo incompressible.

[Bug c/89524] New: -Wno-error doesn't work with warnings from newer versions of GCC

[alexhenrie24 at gmail dot com]

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

Bug ID: 89524
   Summary: -Wno-error doesn't work with warnings from newer
versions of GCC
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

I am working on a Qt4 program that we need to compile with both GCC 4.8.5 and
GCC 8.2.0. The build process sets the -Werror option, but the Qt4 header files
trigger the new class-memaccess warning. I'd like to use
-Wno-error=class-memaccess to permit compilation and still see where we've made
this mistake in our own code, but on GCC 4.8.5 that option causes the following
error:

cc1plus: error: -Werror=class-memaccess: no option -Wclass-memaccess

So I am forced to disable the new warning altogether with -Wno-class-memaccess,
which both GCC 4.8.5 and GCC 8.2.0 accept.

You can reproduce the error on GCC 8.2.0 with any arbitrary C file, for
example:

$ gcc -Werror -Wno-error=foobar test.c
cc1: error: -Werror=foobar: no option -Wfoobar

Can we please avoid this problem in the future by ignoring
-Wno-error=?

[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #67 from Jakub Jelinek  ---
Are the values completely random or are there big chunks with the same values?
Recently in some cases we use RANGE_EXPR to shrink the CONSTRUCTOR sizes if
values are repeated.

[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 27 19:33:15 2019
New Revision: 269263

URL: https://gcc.gnu.org/viewcvs?rev=269263=gcc=rev
Log:
PR target/89397
* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Check
TARGET_SSE in addition to TARGET_SSE_MATH.

(ix86_excess_precision): Ditto.
(ix86_float_exceptions_rounding_supported_p): Ditto.
(use_rsqrt_p): Ditto.
* config/i386/sse.md (rsqrt2): Ditto.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.c
branches/gcc-7-branch/gcc/config/i386/sse.md

[Bug c++/89511] [7/8 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |push_using_decl_1, at   |push_using_decl_1, at
   |cp/name-lookup.c:3845   |cp/name-lookup.c:3845

--- Comment #12 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Wed Feb 27 19:07:18 2019
New Revision: 269262

URL: https://gcc.gnu.org/viewcvs?rev=269262=gcc=rev
Log:
PR c++/89511 - ICE with using-declaration and unscoped enumerator.
* parser.c (cp_parser_using_declaration): For an unscoped enum
only use its context if it's not a function declaration.

* g++.dg/cpp0x/using-enum-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[gcc at mattwhitlock dot name]

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

Matt Whitlock  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Matt Whitlock  ---
I found this:

https://gcc.gnu.org/ml/gcc/2012-01/msg00056.html

It seems pretty resolute. I guess that means this report is a WONTFIX.

For what it's worth, having two conflicting definitions of "POD" is confusing.

[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #6 from Jason Merrill  ---
On gcc-patches (https://gcc.gnu.org/ml/gcc-patches/2019-02/threads.html#01619)
richi pointed out that the testcase is invalid because the undefined functions
we warn about can never be defined, and I agree.  And indeed with
-pedantic-errors the warnings become errors, so we reject the testcase at
compile time and never get to LTO.

So another possible fix would be changing the pedwarn in
check_global_declaration to an error.

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #11 from Jason Merrill  ---
Patch still waiting for review.

[Bug ipa/88235] [7/8/9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Created attachment 45841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45841=edit
Heavy handed fix

This patch fixes the verification because it stores to cgraph_node
information that the node is an expanded thunk.  It is a fairly huge
change just to make a verifier shut up, but I cannot think of another
way and I always disliked the node->thunk.thunk_p testa and wanted to
replace them with node->thunk_p () call, so this is a good excuse.
Not sure if we want it for GCC 9 though (if at all, of course).

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Using the expressions valgrind uses for ARM to compute flags from ADDS and SUBS
instructions and a program that simulates it on just 8-bit values instead of
32-bit ones, it seems the only problematic values where the flags change are 0
and INT_MIN.  By swapping the alternatives, I think the desirable one (subs)
should trigger for both, so the above patch should be hopefully correct.  Will
bootstrap/regtest it.

[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #9)
> This is caused by:
> 
> _ZN4itpp1cILNS_1aE0EED2Ev/1 (itpp::c< >::~c() [with itpp::a
>   Referring: _ZN4itpp1cILNS_1aE0EED1Ev/2 (alias)
> 
> this is a destructor which is pointed to from virutal table, but it has no
> DECL_VIRTUAL_P flag set. This makes free_lang_data to modify its context and
> point to outer namespace rather than the containing polymorphic type.
> 
> Why we do not set VIRTUAL_P here?

This is the base (D2) variant of the destructor, which is not virtual and does
not appear in the vtable; the complete (D1) variant of the destructor is
virtual and does appear in the vtable, and in this case is an alias for the
base variant.  I imagine that LTO is treating them as interchangeable, which
causes trouble here.

Unassigning myself.

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Matt Whitlock from comment #3)
> ABI compatibility isn't guaranteed across C++ language standards anyway, is
> it? For instance, the ABI of std::string differs between C++98 and C++11.


What you are thinking about is the old std::string and the new C++11 compatible
std::string.  std::string is not different between C++98 and C++11 in GCC; both
use the new std::string.

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

[tkoenig at gcc dot gnu.org]

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

--- Comment #19 from Thomas Koenig  ---
> Could you check r269249 on trunk? It's a bit different to the patch I
> suggested earlier, but should still solve the problem.

I can confirm that this solves the problem for me.

Thanks a lot!

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #34)
> Passed bootstrap/regtest on powerpc64le-linux, on powerpc64-linux passed
> bootstrap, regtest still ongoing.

Successfully regtested (-m32/-m64) on powerpc64-linux as well.

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I meant adds r0, r0, #imm and subs r0, r0, #-imm of course.

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 45840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45840=edit
gcc9-pr89506.patch

If 0x8000 is the only immediate in which adds r0,r0,#imm and adds
r0,r0,#-imm differ in condition code flags settings, then we could just use
this patch.

[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|hubicka at gcc dot gnu.org |jason at gcc dot gnu.org

[Bug target/70341] [7/8/9 Regression] cost model for addresses is incorrect, slsr is using reg + reg + CST for arm

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 27 18:11:26 2019
New Revision: 269260

URL: https://gcc.gnu.org/viewcvs?rev=269260=gcc=rev
Log:
PR target/70341
* config/aarch64/aarch64.md (casesi): Create the casesi_dispatch
MEM manually here, set MEM_READONLY_P and MEM_NOTRAP_P on it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md

[Bug target/89434] [7/8 Regression] wrong code with -Og and __builtin_mul_overflow()

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 45839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45839=edit
gcc9-pr89434.patch

I'm testing this separately.

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[gcc at mattwhitlock dot name]

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

--- Comment #3 from Matt Whitlock  ---
(In reply to Andrew Pinski from comment #2)
> If there is a change, then using two sources one compiled with -std=c++98
> and one with -std=c++11 (or later) will not be ABI compatible.

ABI compatibility isn't guaranteed across C++ language standards anyway, is it?
For instance, the ABI of std::string differs between C++98 and C++11.

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
int main () {
  for (long long j = -__INT_MAX__ - 1; j <= __INT_MAX__; j++)
{
  int t, t2, c, c2;
  int i = j;
  asm volatile ("adds %0, %2, #1; mrs %1, apsr" : "=r" (t), "=r" (c) : "r"
(i) : "cc");
  asm volatile ("subs %0, %2, %3; mrs %1, apsr" : "=r" (t2), "=r" (c2) :
"r" (i), "r" (-1) : "cc");
  if (t != t2 || c != c2)
__builtin_printf ("%d %d %d %d %d\n", i, t, t2, c, c2);
}
  return 0;
}

suggests though (unless I've screwed up something) that at least for the adds
r0, r0, #1 vs mvn r3, #0; subs r0, r0, r3 it doesn't make a difference.
On the other side,
int main () {
  for (long long j = -__INT_MAX__ - 1; j <= __INT_MAX__; j++)
{
  int t, t2, c, c2;
  int i = j;
  asm volatile ("adds %0, %2, #2147483648; mrs %1, apsr" : "=r" (t), "=r"
(c) : "r" (i) : "cc");
  asm volatile ("subs %0, %2, #2147483648; mrs %1, apsr" : "=r" (t2), "=r"
(c2) : "r" (i) : "cc");
  if (t != t2 || c != c2)
__builtin_printf ("%d %d %d %d %d\n", i, t, t2, c, c2);
}
  return 0;
}
triggers on lots of values.  If INT_MIN is the only problematic value, we could
tweak the patch to only handle that value carefully, or always emit subs
instead of adds for that case (e.g. by swapping the two alternatives).

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
If there is a change, then using two sources one compiled with -std=c++98 and
one with -std=c++11 (or later) will not be ABI compatible.

[Bug c++/89519] POD data member fails to be packed; G++ incorrectly claims it is non-POD

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
C++98 says S is non POD.  This is why the difference comes into play.  To be
abi compatible with the two language options it needs to be that way.

[Bug target/89523] New: Incorrect AVX instructions with VSIB address

[hjl.tools at gmail dot com]

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

Bug ID: 89523
   Summary: Incorrect AVX instructions with VSIB address
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x32

32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
when 32-bit indices are used as addresses, like

%ymm7, 0(,%ymm6,1), %ymm0

0xf7fa3010 is sign-extended to 0xf7fa3010 which leads to
invalid address in x32.
Testcase:

[hjl@gnu-4 0001]$ cat foo.i
void foo (void);

extern float *ncost;

float
bar (int type, int num)
{
  int i;
  float cost;

  cost = 0;
  for (i = 0; i < num; i++)
if (type)
  cost += ncost[i];
else
  foo ();
  return (cost);
}
[hjl@gnu-4 0001]$ gcc -S -mx32 -Ofast -funroll-loops -march=haswell foo.i 
[hjl@gnu-4 0001]$ grep gather foo.s
vgatherdps  %ymm7, 0(,%ymm6,1), %ymm0
vgatherdps  %ymm11, 0(,%ymm10,1), %ymm12
vgatherdps  %ymm15, 0(,%ymm14,1), %ymm5
vgatherdps  %ymm7, 0(,%ymm9,1), %ymm6
vgatherdps  %ymm12, 0(,%ymm11,1), %ymm13
vgatherdps  %ymm5, 0(,%ymm15,1), %ymm2
vgatherdps  %ymm7, 0(,%ymm10,1), %ymm6
vgatherdps  %ymm14, 0(,%ymm13,1), %ymm15
vgatherdps  %ymm7, 0(,%ymm10,1), %ymm6
vgatherdps  %ymm13, 0(,%ymm12,1), %ymm14
vgatherdps  %ymm10, 0(,%ymm9,1), %ymm7
vgatherdps  %ymm12, 0(,%ymm11,1), %ymm13
vgatherdps  %ymm9, 0(,%ymm2,1), %ymm10
vgatherdps  %ymm12, 0(,%ymm11,1), %ymm6
vgatherdps  %ymm5, 0(,%ymm15,1), %ymm2
[hjl@gnu-4 0001]$

[Bug c++/89522] New: [8/9 Regression] ICE: trying to capture 'f' in instantiation of generic lambda

[gs...@t-online.de]

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

Bug ID: 89522
   Summary: [8/9 Regression] ICE: trying to capture 'f' in
instantiation of generic lambda
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190113 (error) and 20190120 (ICE) :


$ cat z1.cc
template 
void foo (F f)
{
  f (1);
}
template 
void bar (T)
{
  auto f = [&](auto i) { if (f); };
  foo (f);
}
int main ()
{
  bar (0);
}


$ g++-9-20190224 -c z1.cc
z1.cc: In instantiation of 'bar(T) [with T = int]:: [with
auto:1 = int]':
z1.cc:4:5:   required from 'void foo(F) [with F = bar(T) [with T =
int]::]'
z1.cc:10:7:   required from 'void bar(T) [with T = int]'
z1.cc:14:9:   required from here
z1.cc:9:30: internal compiler error: trying to capture 'f' in instantiation of
generic lambda
9 |   auto f = [&](auto i) { if (f); };
  |  ^
0x723c84 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/cp/lambda.c:640
0x723fda add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc/cp/lambda.c:702
0x7ef00c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19413
0x7ef07d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19529
0x7d531e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17843
0x7d4a9d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17195
0x7d51b9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17250
0x7d51b9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17250
0x7d51b9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17250
0x817014 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16934
0x817014 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24661
0x6ef157 maybe_instantiate_decl
../../gcc/cp/decl2.c:5286
0x6f1f3c mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5442
0x62754c build_over_call
../../gcc/cp/call.c:8552
0x639d38 build_op_call_1
../../gcc/cp/call.c:4671
0x639d38 build_op_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4700
0x83c1f3 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2586
0x7f0363 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19018
0x7d531e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17843
0x7d50a6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16963

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Where we create larger code, it is:
(insn 7 6 8 2 (set (reg:SI 116)
(const_int -1 [0x])) "builtin-arith-overflow-1.c":11:1
181 {*arm_movsi_insn}
 (nil))
(insn 8 7 9 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg/v:SI 114 [ x ])
(reg:SI 116)))
(set (reg:SI 115)
(minus:SI (reg/v:SI 114 [ x ])
(reg:SI 116)))
]) "builtin-arith-overflow-1.c":11:1 28 {subsi3_compare1}
 (expr_list:REG_DEAD (reg:SI 116)
(expr_list:REG_DEAD (reg/v:SI 114 [ x ])
(nil
(jump_insn 9 8 12 2 (set (pc)
(if_then_else (ltu (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 12)
(pc))) "builtin-arith-overflow-1.c":11:1 203 {arm_cond_branch}
 (expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 536868 (nil)))
where cprop previously managed to turn that subsi3_compare1 into cmpsi2_addneg,
but now it doesn't.  The question is, is
mvn r3, #0
subs r0, r0, r3
setting all the Z, N, C and V flags to the same values as
adds r0, r0, #1
for all the possible values of r0 or not?

And, should I split the
(*subsi3_carryin_compare_const): Similarly, just instead of -UINTVAL.
part of the patch to a separate, non-controversial, patch, to unbreak PR89434
fallout?

[Bug c/89521] New: ICE in expand_builtin_int_roundingfn, at builtins.c:2697

[gs...@t-online.de]

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

Bug ID: 89521
   Summary: ICE in expand_builtin_int_roundingfn, at
builtins.c:2697
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

A variation of pr89520 (closely related, but possibly valid) :


$ cat z1.c
double ceil ();
double floor ();
long aceil () { return ceil (1); }
long afloor () { return floor (1); }


$ gcc-9-20190224 -c z1.c -O2
z1.c: In function 'aceil':
z1.c:3:30: warning: 'ceil' argument 1 type is 'int' where 'double' is expected
in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
3 | long aceil () { return ceil (1); }
  |  ^
z1.c:1:8: note: built-in 'ceil' declared here
1 | double ceil ();
  |^~~~
z1.c: In function 'afloor':
z1.c:4:32: warning: 'floor' argument 1 type is 'int' where 'double' is expected
in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
4 | long afloor () { return floor (1); }
  |^
z1.c:2:8: note: built-in 'floor' declared here
2 | double floor ();
  |^
during RTL pass: expand
z1.c: In function 'aceil':
z1.c:3:24: internal compiler error: in expand_builtin_int_roundingfn, at
builtins.c:2697
3 | long aceil () { return ceil (1); }
  |^~~~
0x73714c expand_builtin_int_roundingfn
../../gcc/builtins.c:2697
0x74c390 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:7332
0x8a9b86 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11029
0x8b5936 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5673
0x8b7228 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5436
0x772112 expand_call_stmt
../../gcc/cfgexpand.c:2722
0x772112 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x772112 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x774cd8 expand_gimple_tailcall
../../gcc/cfgexpand.c:3897
0x774cd8 expand_gimple_basic_block
../../gcc/cfgexpand.c:5863
0x77abde execute
../../gcc/cfgexpand.c:6509

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45838=edit
gcc9-pr89506.patch

Untested version.

With this one, e.g. that t104_4ssub changes compared to vanilla:
-mov r3, #-2147483648
-subs r0, r0, r3
+subs r0, r0, #2147483648
so if that works, would be actually an improvement.
On the other side, there are some changes where the code is larger with the
patch:
-adds r0, r0, #1
+mvn r3, #0
+subs r0, r0, r3

[Bug c/89520] New: ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668

[gs...@t-online.de]

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

Bug ID: 89520
   Summary: ICE tree check: accessed operand 4 of call_expr with 3
operands in convert_to_integer_1, at convert.c:668
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-4.1, at -O[gs123] :
(which means: compiles at -O0)


$ cat z1.c
double ceil ();
double floor ();
double trunc ();
long aceil () { return ceil (); }
long afloor () { return floor (); }
long atrunc () { return trunc (); }


$ gcc-9-20190224 -c z1.c -O2
z1.c: In function 'aceil':
z1.c:4:24: warning: too few arguments to built-in function 'ceil' expecting 1
[-Wbuiltin-declaration-mismatch]
4 | long aceil () { return ceil (); }
  |^~~~
z1.c:1:8: note: declared here
1 | double ceil ();
  |^~~~
z1.c:4:1: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in convert_to_integer_1, at convert.c:668
4 | long aceil () { return ceil (); }
  | ^~~~
0x5cfb6c tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/tree.c:10059
0x7c49d6 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3676
0x7c49d6 convert_to_integer_1
../../gcc/convert.c:668
0x65cc8b convert(tree_node*, tree_node*)
../../gcc/c/c-convert.c:125
0x69cca5 convert_and_check(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:1641
0x635362 convert_for_assignment
../../gcc/c/c-typeck.c:6812
0x6387d0 c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10568
0x68345a c_parser_statement_after_labels
../../gcc/c/c-parser.c:5523
0x684ffe c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5148
0x685786 c_parser_compound_statement
../../gcc/c/c-parser.c:4982
0x68706b c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2354
0x68f633 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x6900f9 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x6900f9 c_parse_file()
../../gcc/c/c-parser.c:19854
0x6f0110 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm afraid I don't understand how the cmpsi2_cmpneg pattern can ever work
reliably.  It uses CCmode, so I think that means all of Z, N, C and V flags
have to be useful, but while the Z and N flags really don't care whether adds
or subs is used, I believe C and V depend on that heavily.
So, I'd understand cmpsi2_addneg pattern with CCmode that would only have the
subs alternative, and another pattern with CC_NOOVmode that would have both.

[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 27 15:56:04 2019
New Revision: 269259

URL: https://gcc.gnu.org/viewcvs?rev=269259=gcc=rev
Log:
PR target/89397
* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Check
TARGET_SSE in addition to TARGET_SSE_MATH.

(ix86_excess_precision): Ditto.
(ix86_float_exceptions_rounding_supported_p): Ditto.
(use_rsqrt_p): Ditto.
* config/i386/sse.md (rsqrt2): Ditto.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/config/i386/sse.md

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Unfortunately the patch regresses:
+FAIL: c-c++-common/torture/builtin-arith-overflow-1.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-12.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-12.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-13.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-13.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-2.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-12.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-12.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-13.c   -O2  execution test
+FAIL: c-c++-common/torture/builtin-arith-overflow-p-13.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test

Looking at the first one, the differences are like:
 t104_4ssub:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
-   mov r3, #-2147483648
-   subsr0, r0, r3
+   addsr0, r0, #-2147483648

[Bug c++/89519] New: POD data member fails to be packed; G++ incorrectly claims it is non-POD

[gcc at mattwhitlock dot name]

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

Bug ID: 89519
   Summary: POD data member fails to be packed; G++ incorrectly
claims it is non-POD
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mattwhitlock dot name
  Target Milestone: ---

/* === BEGIN TEST CASE === */

#include 

class S {
int i;
};

struct P {
char c;
S s;
} __attribute__ ((packed));

static_assert(std::is_pod::value, "S should be a POD type");
static_assert(sizeof(P) == sizeof(char) + sizeof(S), "P should be packed");

/* === END TEST CASE === */


$ g++ -c test.cpp
test.cpp:9:4: warning: ignoring packed attribute because of unpacked non-POD
field 'S P::s'
  S s;
^
test.cpp:13:25: error: static assertion failed: P should be packed
 static_assert(sizeof(P) == sizeof(char) + sizeof(S), "P should be packed");
   ~~^~~


As you can see, S is indeed a POD type, as evidenced by std::is_pod::value
being true, yet the compiler fails to pack it.

This may be due to a discrepancy between C++'s definition of a POD type and
G++'s internal concept of "POD for the purpose of layout," as explained in Bug
83732 Comment 3.

Workaround: changing the access control of S::i to public (for example by
changing "class S" to "struct S") makes G++ pack P::s correctly. However, this
should not be necessary, as the standard only requires all non-static data
members in a standard-layout type to have the *same* access control, which need
not be public.

[Bug tree-optimization/89280] [7/8 Regression] ICE: Segmentation fault (in is_gimple_reg_type)

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 27 15:22:16 2019
New Revision: 269256

URL: https://gcc.gnu.org/viewcvs?rev=269256=gcc=rev
Log:
PR tree-optimization/89280
* gcc.dg/torture/pr57147-2.c (SetNaClSwitchExpectations): Add static
keyword.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr57147-2.c

[Bug libstdc++/89461] FAIL: experimental/net/timer/waitable/cons.cc

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2019-02-27 4:24 a.m., redi at gcc dot gnu.org wrote:
> Maybe libstdc++ should just link to libatomic unconditionally for your target.
Yes, I'm trying that in current build.  The issue is certain functions are
implemented inline on most
architectures but not on hppa-hpux.

There are a couple of other tests in the same boat.

[Bug target/70341] [7/8/9 Regression] cost model for addresses is incorrect, slsr is using reg + reg + CST for arm

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 27 14:50:35 2019
New Revision: 269255

URL: https://gcc.gnu.org/viewcvs?rev=269255=gcc=rev
Log:
PR target/70341
* config/arm/arm.md (arm_casesi_internal): New define_expand.  Rename
old define_insn to ...
(*arm_casesi_internal): ... this.  Add mode to LABEL_REFs.
* config/arm/thumb2.md (thumb2_casesi_internal): New define_expand.
Rename old define_insn to ...
(*thumb2_casesi_internal): ... this.  Add mode to LABEL_REFs.
(thumb2_casesi_internal_pic): New define_expand.  Rename old
define_insn to ...
(*thumb2_casesi_internal_pic): ... this.  Add mode to LABEL_REFs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/thumb2.md

[Bug libstdc++/89461] FAIL: experimental/net/timer/waitable/cons.cc

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2019-02-27 4:19 a.m., fw at gcc dot gnu.org wrote:
> Is it really true that 64-bit PA-RISC lacks 64-bit atomics?  That's … awkward.
PA-RISC only has two atomic instructions (ldcw and ldcd).  These are
insufficient to implement
a full set of 32-bit atomics without kernel support.

In the 32-bit runtime, we can't in general use the ldd and std instructions as
the upper 32 register
bits are not guaranteed to be preserved during context switches.  So, one has
to use 64-bit floating
point loads and stores to ensure the operation operates atomically on memory. 
This makes 64-bit
atomics really ugly with a 32-bit kernel.

We have implemented a kernel helper to implement atomic support on linux. 
There is no documented
kernel helper on hpux although I believe HP implemented pthread support using
light weight system
calls.  Using a kernel helper, tends to make atomics very slow when there is
contention.

I tend to think using 64-bit atomics on 32-bit architectures is not a good
idea.

Dave

[Bug ipa/88235] [7/8/9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
I have looked at this a bit more and the problem is that thunk
inlining expands a thunk which then makes the clone_of_p() part of
cgraph_edge::verify_corresponds_to_fndecl() fail.

I must say that I found the inlining decision that does the expansion
a bit unexpected:

  #2  0x01a53ace in inline_small_functions () at
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2073
  2073  inline_call (edge, true, _indirect_edges,
_size, true);
  (gdb) p edge
  $26 =  *.LTHUNK0/13>

where _ZThn8_N8ItemView5eventEv/14 is a real thunk and *.LTHUNK0/13 is
an alias to the real method.  The thing is that the thunk has no
(known) callers:

  (gdb) p edge->caller->callers
  $29 = 

Is that intentional?  Do we want to inline functions into their thunks
even that thunk is not itself inlined into anything?

Also, the code in clone_of_p assumes that each thunk has one callee,
which seems to be in start contrast with the comment and code in
inline_call():

  /* When thunk is instrumented we may have multiple callees.  */
  for (e = to->callees; e && e->callee != target; e = e->next_callee)
;

[Bug debug/88878] .debug_pubnames/types empty with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 27 14:04:18 2019
New Revision: 269253

URL: https://gcc.gnu.org/viewcvs?rev=269253=gcc=rev
Log:
2019-02-27  Richard Biener  

PR debug/88878
* dwarf2out.c (use_debug_types): Disable when in_lto_p.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #33)
> I've started bootstrap/regtest of this on powerpc64{,le}-linux (on
> CompileFarm).

Passed bootstrap/regtest on powerpc64le-linux, on powerpc64-linux passed
bootstrap, regtest still ongoing.

[Bug c++/89513] constexpr functions with function try block shouldn't be accepted at least with -pedantic in -std=c++{11,14,17} modes

[jakub at gcc dot gnu.org]

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

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 45837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45837=edit
gcc9-pr89513.patch

Untested fix.  Unless we want to go ahead and implement P1002R1 right now, of
course.  And if we do, the question is if we should just accept it everywhere
with a pedwarn.

[Bug debug/88878] .debug_pubnames/types empty with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
-fdebug-types-section now work as expected.

[Bug lto/89497] [8/9 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
GIMPLE testcase that doesn't fail, possibly because of NOPs or because of
missing range info or whatever...

typedef struct {
  char array[81];
} container;
container *get();
int guard = 0;
container c;

void __GIMPLE (startwith("vrp1"))
d ()
{
  long unsigned int len2;
  container * a;
  char * _1;
  int _18;
  int i_19;

  bb_2:
  a_6 = get ();
  if (a_6 != _Literal (struct container *) 0)
goto bb_3;
  else
goto bb_8;

  bb_3:
  _18 = guard;
  if (_18 != 0)
goto bb_5;
  else
goto bb_4;

  bb_4:
  ;

  bb_5:
  i_19 = __PHI (bb_3: 0, bb_4: 1);
  _1 = _6->array[0];
  len2_15 = __builtin_strlen ();
  if (len2_15 > 81ul)
goto bb_6;
  else
goto bb_7;

  bb_6:
  ;

  bb_7:
  len2_17 = __PHI (bb_5: len2_15, bb_6: 81ul);
  __builtin_memmove (_1, , len2_17);

  bb_8:
  return;

}

[Bug debug/88878] .debug_pubnames/types empty with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 27 12:51:43 2019
New Revision: 269251

URL: https://gcc.gnu.org/viewcvs?rev=269251=gcc=rev
Log:
2019-02-27  Richard Biener  

PR debug/88878
* dwarf2out.c (output_comdat_type_unit): Add early_lto_debug
parameter, prefix section name with .gnu.debuglto_ if true.
(dwarf2out_finish): Pass false to output_comdat_type_unit.
(dwarf2out_early_finish): Pass true to output_comdat_type_unit.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug tree-optimization/89518] missed optimisation for array address calculations

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> We do not have a (a / b) * b + (a % b) simplification rule.

Indeed. That's surprising since we do have for trunc_div
/* X - (X / Y) * Y is the same as X % Y.  */

[Bug lto/89497] [8/9 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Created attachment 45836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45836=edit
patch I am testing

So we can now properly "order" CFG cleanup and SSA update by interleaving them.

There's the slight chance that we run update_ssa twice, but the comment looks
outdated and I wonder what would trigger it:

  /* When cleanup_tree_cfg merges consecutive blocks, it may
 perform some simplistic propagation when removing single
 valued PHI nodes.  This propagation may, in turn, cause the
 SSA form to become out-of-date (see PR 22037).  So, even
 if the parent pass had not scheduled an SSA update, we may
 still need to do one.  */
  if (!(flags & TODO_update_ssa_any) && need_ssa_update_p (cfun))
flags |= TODO_update_ssa;

[Bug fortran/53481] Allow for gfortran (f951) specs option

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Dominique d'Humieres  ---
> No activity for more than three years. Is anybody interested or
> should this PR closed as WONTFIX?

Three years later closing as WONTFIX.