[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson  ---
Created attachment 46392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46392=edit
stacked-qualified-types-3.s generated for cris-elf at r271469

[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|hppa64-hp-hpux11.11,|cris-elf
   |*-*-solaris2.1[01], |
   |x86_64-unknown-linux-gnu|
 Status|RESOLVED|REOPENED
 CC||hp at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #12 from Hans-Peter Nilsson  ---
I still see this for cris-elf, introduced in (r224151:r224167], i.e. consistent
with the other observations in this report (yes, that old), but *not* fixed by
the committed patch, so I'm reopening this with the target field adjusted.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[conradsand.arma at gmail dot com]

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

--- Comment #39 from Conrad S  ---
> A better question might be: Are you going to fix your code?

Yes [1], but that's besides the point here. I can certainly fix my code, but
that leaves 99% of other software.

Backports to gcc 8.x and 9.x would be very beneficial.

[1] in progress: https://gitlab.com/conradsnicta/armadillo-code/issues/123

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #38 from Steve Kargl  ---
On Wed, May 22, 2019 at 04:38:40AM +, conradsand.arma at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
> 
> --- Comment #37 from Conrad S  ---
> Thanks for the workaround.
> Will the patches be backported to gcc 8.x and 9.x ?
> 

A better question might be: Are you going to fix your code?

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[conradsand.arma at gmail dot com]

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

--- Comment #37 from Conrad S  ---
Thanks for the workaround.
Will the patches be backported to gcc 8.x and 9.x ?

[Bug fortran/89782] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> In fortran/io.c we are excluding this case since it is not a variable. So we
> should be able to accept in the case of READ from an expression type
> constant and reject an attempt to WRITE to it. (at least intuitively it
> would seem OK to do)
> 
> I have a partial patch.  I want to make sure there is no constraint in the
> standards.  "scalar character variable" is fairly specific in standardese.
> My guess is we never did the check for the vector case so it just works.

The Fortran standard is very clear.  Accepting a named constant
is an error.

R1201 io-unit is file-unit-number
  or *
  or internal-file-variable
R1202 file-unit-numberis scalar-int-expr

R1203 internal-file-variable  is char-variable

A named constant is not a variable.

[Bug fortran/89782] Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #3 from Jerry DeLisle  ---
In fortran/io.c we are excluding this case since it is not a variable. So we
should be able to accept in the case of READ from an expression type constant
and reject an attempt to WRITE to it. (at least intuitively it would seem OK to
do)

I have a partial patch.  I want to make sure there is no constraint in the
standards.  "scalar character variable" is fairly specific in standardese. My
guess is we never did the check for the vector case so it just works.

[Bug other/90315] [10 regression] help text (or test for help text) problem after r270788

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  ---
(I was looking into local autotester regressions, finding this PR.
Just a gentle reminder...)

(In reply to Martin Liška from comment #2)
> I've got a patch candidate.

Is it perhaps ready to post to gcc-patches now?

[Bug target/90568] stack protector should use cmp or sub, not xor, to allow macro-fusion on x86

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
https://godbolt.org/z/hHCVTc

Forgot to mention, stack-protector also disables use of the red-zone for no
apparent reason, so that's another missed optimization.  (Perhaps rarely
relevant; probably most functions that get stack protection are big enough that
they need more stack, or non-leaf.  I sidestepped that with volatile.)

[Bug target/90568] New: stack protector should use cmp or sub, not xor, to allow macro-fusion on x86

[peter at cordes dot ca]

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

Bug ID: 90568
   Summary: stack protector should use cmp or sub, not xor, to
allow macro-fusion on x86
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

cmp/jne is always at least as efficient as xor/jne, and more efficient on CPUs
that support macro-fusion of compare and branch.  Most support cmp/jne fusion
(including all mainstream Intel and AMD, not low-power), but none support
xor/jne fusion.

void foo() {
volatile int buf[4];
buf[1] = 2;
}

gcc trunk on Godbolt, but same code-gen all the way back to gcc4.9

foo:
subq$40, %rsp
movq%fs:40, %rax
movq%rax, 24(%rsp)
xorl%eax, %eax
movl$2, 4(%rsp)
movq24(%rsp), %rax
xorq%fs:40, %rax  ## This insn should be CMP
jne .L5
addq$40, %rsp
ret
.L5:
call__stack_chk_fail

As far as I can tell, the actual XOR result value in RAX is not an input to
__stack_chk_fail because gcc sometimes uses a different register.

Therefore we don't need it, and can use any other way to check for equality.

If we need to avoid "leaking" the canary value in a register, we can use SUB,
otherwise CMP is even better and can macro-fuse on more CPUs.

Only Sandybridge-family can fuse SUB/JCC.  (And yes, it can fuse even with a
memory-source and a segment override prefix.  SUB %fs:40(%rsp), %rax / JNE  is
a single uop on Skylake; I checked this with perf counters in an asm loop.)

AMD can fuse any TEST or CMP/JCC, but only those instructions (so SUB is as bad
as XOR for AMD).  See Agner Fog's microarch PDF.



Linux test program (NASM) that runs  sub (mem), %reg with an FS prefix to prove
that it does macro-fuse and stays micro-fused as a single uop:


default rel
%use smartalign
alignmode p6, 64

global _start
_start:

cookie equ 12345
mov  eax, 158   ; __NR_arch_prctl
mov  edi, 0x1002; ARCH_SET_FS
lea  rsi, [buf]
syscall
   ;  wrfsbase   rsi; not enabled by the kernel
mov  qword [fs: 0x28], cookie

mov ebp, 10

align 64
.loop:
mov   eax, cookie
sub   rax, [fs: 0x28]
jne   _start
and   ecx, edx

dec ebp
jnz .loop
.end:

xor edi,edi
mov eax,231   ; __NR_exit_group
syscall   ; sys_exit_group(0)


section .bss
align 4096
buf:resb 4096



nasm -felf64  branch-fuse-mem.asm &&
ld -o branch-fuse-mem  branch-fuse-mem.o
to make a static executable

taskset -c 3 perf stat
-etask-clock:u,context-switches,cpu-migrations,page-faults,cycles:u,branches:u,instructions:u,uops_issued.any:u,uops_executed.thread:u
-r2 ./branch-fuse-mem

On my i7-6700k

 Performance counter stats for './branch-fuse-mem' (2 runs):

240.78 msec task-clock:u  #0.999 CPUs utilized 
  ( +-  0.23% )
 2  context-switches  #0.010 K/sec 
  ( +- 20.00% )
 0  cpu-migrations#0.000 K/sec  
 3  page-faults   #0.012 K/sec  
 1,000,764,258  cycles:u  #4.156 GHz   
  ( +-  0.00% )
 2,000,000,076  branches:u# 8306.384 M/sec 
  ( +-  0.00% )
 6,000,000,088  instructions:u#6.00  insn per cycle
  ( +-  0.00% )
 4,000,109,615  uops_issued.any:u # 16613.222 M/sec
  ( +-  0.00% )
 5,000,098,334  uops_executed.thread:u# 20766.367 M/sec
  ( +-  0.00% )

  0.240935 +- 0.000546 seconds time elapsed  ( +-  0.23% )

Note 1.0 billion cycles (1 per iteration), and 4B fused-domain uops_issued.any,
i.e. 4 uops per loop iteration.

(5 uops *executed* is because one of those front-end uops has a load
micro-fused).

Changing SUB to CMP has no effect.

With SUB changed to XOR, the loop takes 1.25 cycles per iteration, and the
front-end issues 5 uops per iteration.  Other counters are the same.

Skylake's pipeline is 4-wide, like all Intel since Core2, so an extra uop for
the front-end creates a bottleneck.

--

On Intel pre Haswell, the decoders will only make at most 1 fusion per decode
group, so you may need to make the loop larger to still get fusion.  Or use
this as the loop-branch, e.g. with a  1  in memory

   sub  rax, [fs: 0x28]
   jnz  .loop

or with a 0 in memory, sub or cmp or xor will all set flags according to the
register being non-zero.  But sub or xor will introduce an extra cycle of
latency on the critical path for the loop counter.

[Bug middle-end/90553] Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #4 from Hans-Peter Nilsson  ---
fixed as per above

[Bug middle-end/90553] Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  ---
Author: hp
Date: Wed May 22 00:43:23 2019
New Revision: 271499

URL: https://gcc.gnu.org/viewcvs?rev=271499=gcc=rev
Log:
PR middle-end/90553
* gcc.dg/torture/pr90553.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr90553.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/90553] Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  ---
Author: hp
Date: Wed May 22 00:35:32 2019
New Revision: 271498

URL: https://gcc.gnu.org/viewcvs?rev=271498=gcc=rev
Log:
PR middle-end/90553
* ira-lives.c (process_bb_node_lives): Consider defs
for a call insn to be die before the call, not after.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c

[Bug tree-optimization/90567] GCC bad optimization on recursive functions

[msmaldi at hotmail dot com]

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

--- Comment #4 from msmaldi  ---
-O2 generate better results, but gcc 7 continue faster

gcc-7 with -O3
real0m3,143s
user0m3,119s
sys 0m0,008s

gcc-8 with -O2
real0m4,802s
user0m4,793s
sys 0m0,009s

gcc 7 assembly generated:

fibo:
pushr15
lea eax, [rdi-1]
pushr14
pushr13
pushr12
pushrbp
pushrbx
sub rsp, 104
cmp eax, 1
mov DWORD PTR [rsp+68], 0
jbe .L2
mov edx, edi
lea ecx, [rdi-4]
lea eax, [rdi-2]
sub edx, 3
and edx, -2
sub ecx, edx
mov DWORD PTR [rsp+88], ecx
.L19:
cmp eax, 1
jbe .L21
lea ecx, [rax-3]
lea edx, [rax-1]
sub eax, 2
mov DWORD PTR [rsp+80], eax
and eax, -2
mov DWORD PTR [rsp+72], 0
sub ecx, eax
mov DWORD PTR [rsp+92], ecx
.L18:
cmp edx, 1
jbe .L22
lea eax, [rdx-2]
lea esi, [rdx-3]
lea ecx, [rdx-1]
mov DWORD PTR [rsp+60], 0
mov DWORD PTR [rsp+84], eax
and eax, -2
sub esi, eax
mov DWORD PTR [rsp+76], esi
.L17:
cmp ecx, 1
jbe .L23
lea eax, [rcx-2]
lea esi, [rcx-3]
lea edx, [rcx-1]
mov DWORD PTR [rsp+52], 0
mov DWORD PTR [rsp+64], eax
and eax, -2
sub esi, eax
mov DWORD PTR [rsp+56], esi
.L16:
cmp edx, 1
jbe .L24
lea eax, [rdx-2]
lea esi, [rdx-3]
lea ecx, [rdx-1]
mov DWORD PTR [rsp+40], 0
mov DWORD PTR [rsp+48], eax
and eax, -2
sub esi, eax
mov DWORD PTR [rsp+44], esi
.L15:
cmp ecx, 1
jbe .L25
lea eax, [rcx-2]
lea esi, [rcx-3]
lea edx, [rcx-1]
mov DWORD PTR [rsp+28], 0
mov DWORD PTR [rsp+36], eax
and eax, -2
sub esi, eax
mov DWORD PTR [rsp+32], esi
.L14:
cmp edx, 1
jbe .L26
lea eax, [rdx-2]
lea ecx, [rdx-3]
lea r13d, [rdx-1]
mov DWORD PTR [rsp+16], 0
mov DWORD PTR [rsp+24], eax
and eax, -2
sub ecx, eax
mov DWORD PTR [rsp+20], ecx
.L13:
cmp r13d, 1
jbe .L27
lea eax, [r13-2]
lea edx, [r13-1]
lea r15d, [r13-3]
xor ebp, ebp
mov DWORD PTR [rsp+12], eax
and eax, -2
mov ebx, edx
sub r15d, eax
.L12:
cmp ebx, 1
jbe .L28
lea r13d, [rbx-2]
xor r14d, r14d
mov r12d, r13d
and r12d, 1
.L11:
mov edi, ebx
sub ebx, 2
callfibo
add r14d, eax
cmp r12d, ebx
jne .L11
add r14d, 1
.L10:
add ebp, r14d
cmp r15d, r13d
mov ebx, r13d
jne .L12
mov r13d, DWORD PTR [rsp+12]
add ebp, 1
.L9:
add DWORD PTR [rsp+16], ebp
cmp DWORD PTR [rsp+20], r13d
jne .L13
mov eax, DWORD PTR [rsp+16]
mov edx, DWORD PTR [rsp+24]
add eax, 1
.L8:
add DWORD PTR [rsp+28], eax
cmp DWORD PTR [rsp+32], edx
jne .L14
mov eax, DWORD PTR [rsp+28]
mov ecx, DWORD PTR [rsp+36]
add eax, 1
.L7:
add DWORD PTR [rsp+40], eax
cmp DWORD PTR [rsp+44], ecx
jne .L15
mov eax, DWORD PTR [rsp+40]
mov edx, DWORD PTR [rsp+48]
add eax, 1
.L6:
add DWORD PTR [rsp+52], eax
cmp DWORD PTR [rsp+56], edx
jne .L16
mov eax, DWORD PTR [rsp+52]
mov ecx, DWORD PTR [rsp+64]
add eax, 1
.L5:
add DWORD PTR [rsp+60], eax
cmp DWORD PTR [rsp+76], ecx
jne .L17
mov eax, DWORD PTR [rsp+60]
mov edx, DWORD PTR [rsp+84]
add eax, 1
.L4:
add DWORD PTR [rsp+72], eax
cmp DWORD PTR [rsp+92], edx
jne .L18
mov edx, DWORD PTR [rsp+72]
mov eax, DWORD PTR [rsp+80]
add edx, 1
.L3:
add DWORD PTR [rsp+68], edx
cmp DWORD PTR [rsp+88], eax
jne .L19
.L2:
mov eax, DWORD PTR [rsp+68]
add rsp, 104
pop rbx
pop rbp
add eax, 1
pop r12
pop r13
pop r14
pop r15
ret
.L28:
mov r14d, 1
lea r13d, 

[Bug tree-optimization/68008] Pessimization of simple non-tail-recursive functions

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
*** Bug 90567 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/90567] GCC bad optimization on recursive functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Actually it is.

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

[Bug tree-optimization/90567] GCC bad optimization on recursive functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
-O2 produces better results.

Dup of bug 68008.

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

[Bug tree-optimization/90567] GCC bad optimization on recursive functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Maybe not ...

[Bug tree-optimization/68008] Pessimization of simple non-tail-recursive functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||msmaldi at hotmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 90567 has been marked as a duplicate of this bug. ***

[Bug c/90567] New: GCC bad optimization on recursive functions

[msmaldi at hotmail dot com]

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

Bug ID: 90567
   Summary: GCC bad optimization on recursive functions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msmaldi at hotmail dot com
  Target Milestone: ---

consider code:

int fibo (int n)
{
if (n == 1 || n == 2)
return 1;
else
return fibo(n - 1) + fibo(n - 2);
}
int main()
{
printf ("%d\n", fibo (45));

return 0;
}

with flags: -m64 -flto -march=native -O3

GCC-7
real0m3,066s
user0m3,065s
sys 0m0,000s

GCC-8
real0m4,868s
user0m4,864s
sys 0m0,004s

GCC-9
real0m5,015s
user0m5,010s
sys 0m0,004s

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely  ---
I've been working on this again, and I think that the resource_adaptor type is
the wrong place to fix the malloc alignment problem.

The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__ on
targets where malloc doesn't agree with GCC's alignof(max_align_t). Otherwise
even if I make resource_adaptor work for those targets, this test will still
fail:

#include 
#include 
#include 
#include 

template
  inline bool aligned(void* p)
  { return (reinterpret_cast(p) % alignof(T)) == 0; }

int
main()
{
  using test_type = std::max_align_t; // largest fundamental alignment
  std::allocator a;
  for (int i = 0; i < 10; ++i)
  {
test_type* p1 = a.allocate(1);
VERIFY( aligned(p1) );
test_type* p2 = a.allocate(20);
VERIFY( aligned(p2) );
a.deallocate(p1, 1);
a.deallocate(p2, 20);
  }
}

If we make std::allocator work then the tests for resource_adaptor
will also work, at least on Solaris.

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  ---
Fixed.

[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 21 22:26:42 2019
New Revision: 271491

URL: https://gcc.gnu.org/viewcvs?rev=271491=gcc=rev
Log:
/cp
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* call.c (build_over_call): Devirtualize when the final overrider
comes from the base.

/testsuite
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final4.C: Likewise.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final5.C

[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 21 22:26:10 2019
New Revision: 271490

URL: https://gcc.gnu.org/viewcvs?rev=271490=gcc=rev
Log:
/cp
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* call.c (build_over_call): Devirtualize when the final overrider
comes from the base.

/testsuite
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final4.C: Likewise.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final3.C
trunk/gcc/testsuite/g++.dg/other/final4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 21 22:26:10 2019
New Revision: 271490

URL: https://gcc.gnu.org/viewcvs?rev=271490=gcc=rev
Log:
/cp
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* call.c (build_over_call): Devirtualize when the final overrider
comes from the base.

/testsuite
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final4.C: Likewise.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final3.C
trunk/gcc/testsuite/g++.dg/other/final4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May 21 22:26:42 2019
New Revision: 271491

URL: https://gcc.gnu.org/viewcvs?rev=271491=gcc=rev
Log:
/cp
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* call.c (build_over_call): Devirtualize when the final overrider
comes from the base.

/testsuite
2019-05-21  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final4.C: Likewise.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final5.C

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[m...@tobias-neumann.eu]

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

--- Comment #8 from Tobias  ---
Looks like this has just been addressed in my original report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Tue, May 21, 2019 at 09:43:29PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237
> 
> --- Comment #6 from Dominique d'Humieres  ---
> > Why does this *warning* actually cause an error and abort the compilation?
> > This is what I consider the bug, not the fact that it can't catch
> > all cases properly.
> 
> A warning is not an error unless you use -Werror or in some cases -pedantic.
> 

Re-read Tobias's PR then.

% gfcx -Wdo-subscript a.f90
a.f90:11:28:

   11 |   p(j) = p(swap(j))
  |1
Error: Index in dimension 1 is out of bounds at (1)
a.f90:11:28:

9 |   do j=1,6
  |  2  
   10 |   if (j<5) then
   11 |   p(j) = p(swap(j))
  |1
Warning: Array reference at (1) out of bounds (6 > 4) in loop beginning at (2)
-Wdo-subscript]

Why is there an error?

[Bug c/68193] _Generic -Woverflow false alarm

[la...@linux-mips.org]

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

Ladislav Michl  changed:

   What|Removed |Added

 CC||la...@linux-mips.org

--- Comment #6 from Ladislav Michl  ---
Created attachment 46391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46391=edit
Ternary if

That ternary operator makes warning disappear. In the testcase 'gcc -Woverflow
-o x x.c' gives:
x.c:14:9: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes
value from ‘1000’ to ‘232’ [-Woverflow]
   baz = 1000;
 ^~~~
x.c:16:9: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes
value from ‘2000’ to ‘208’ [-Woverflow]
   baz = 2000;
 ^~~~
while 'gcc -DNO -Woverflow -o x x.c' silently ignores overflow.
I would welcome any advice, how o properly categorize this bug, so eventually
new bugreport will be created.

Thank you.

[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |8.4
Summary|[9/10 Regression] Out of|[8/9/10 Regression] Out of
   |bounds error when compiling |bounds error when compiling
   |with -Wextra|with -Wextra

[Bug fortran/90563] [9/10 Regression] Out of bounds error when compiling with -Wextra

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2019-05-21
 CC||tkoenig at gcc dot gnu.org
 Resolution|DUPLICATE   |---
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
Summary|Out of bounds error when|[9/10 Regression] Out of
   |compiling with -Wextra  |bounds error when compiling
   ||with -Wextra
 Ever confirmed|0   |1

--- Comment #2 from Thomas Koenig  ---
Ah, I see the problem - for some reason, the (in this case
masked by the if statement) out of bounds error should
only issue a warning, not an error.

I broke it, so I might as well fix it.

[Bug other/90566] New: Support demangling with underscore-prefixed string after mangled name

[eyalroz at technion dot ac.il]

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

Bug ID: 90566
   Summary: Support demangling with underscore-prefixed string
after mangled name
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

libiberty performs the demangling for c++filt, the most commonly-used (and
perhaps only?) tool for demangling C++ names in object files and related file
formats. One of the "ecosystems" which produces such files is CUDA;
specifically in its intermediary representation for GPU code. 

Now, a GPU-device-side function, compiled with clang to PTX, can look like
this, for example: 

  .visible .entry _Z6squarePii(
  .param .u64 _Z6squarePii_param_0,
  .param .u32 _Z6squarePii_param_1
  )
  {

  ld.param.u32%r1, [_Z6squarePii_param_1];
  mov.u32 %r2, %ctaid.x;
  setp.ge.s32 %p1, %r2, %r1;
  @%p1 braLBB6_2;
  ld.param.u64%rd2, [_Z6squarePii_param_0];
  cvta.to.global.u64  %rd3, %rd2;
  mul.wide.u32%rd4, %r2, 4;
  add.s64 %rd1, %rd3, %rd4;
  ld.global.u32   %r3, [%rd1];
  mul.lo.s32  %r4, %r3, %r3;
  st.global.u32   [%rd1], %r4;
  ret; 
  }

(see https://godbolt.org/z/GcDTVh for cland and nvcc output)

which clearly has mangled names. However, it seems the function parameter name
is somewhat malformed, or non-standard - being a mangled name, followed
immediately by an underscore and more text: mangledblahblah_param_0.

When demangling, the function name gets demangled fine, but the parameter does
not:

.visible .entry square(int*, int)(
.param .u64 _Z6squarePii_param_0,
.param .u32 _Z6squarePii_param_1
)

and from what the c++filt people say - this is libiberty's output. I ask that
libiberty either auto-detect this case, or have an option to detect it; and
when that's turned on, demangle the above into:

  .visible .entry square(int*, int)(
  .param .u64 square(int*, int)_param_0,
  .param .u32 square(int*, int)_param_1
  )

or

  .visible .entry square(int*, int)(
  .param .u64 square(int*, int) param_0,
  .param .u32 square(int*, int) param_1
  )

or something else that's meaningful.

Caveat: I realize that libiberty is FOSS and CUDA involves a bunch of
closed-source software by a company notorious for keeping code and specs
closed, and not making it easy for FOSS developers. Still, we are talking about
something clang compiles; and it's only being mindful of an underscore.

(Note: I first filed this as a bug against c++filt:
https://sourceware.org/bugzilla/show_bug.cgi?id=24557 ) and was directed to
file here.

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Why does this *warning* actually cause an error and abort the compilation?
> This is what I consider the bug, not the fact that it can't catch
> all cases properly.

A warning is not an error unless you use -Werror or in some cases -pedantic.

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[m...@tobias-neumann.eu]

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

--- Comment #5 from Tobias  ---
(In reply to Dominique d'Humieres from comment #4)
> *** Bug 90563 has been marked as a duplicate of this bug. ***

Why does this *warning* actually cause an error and abort the compilation? This
is what I consider the bug, not the fact that it can't catch all cases
properly.

[Bug fortran/90563] Out of bounds error when compiling with -Wextra

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||m...@tobias-neumann.eu

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 90563 has been marked as a duplicate of this bug. ***

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[glisse at gcc dot gnu.org]

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

--- Comment #34 from Marc Glisse  ---
(In reply to Richard Biener from comment #33)
> (In reply to Stefan Vigerske from comment #32)
> > Is there any hope this could actually be improved?
> > Now, 10 years later, the FENV_ACCESS pragma seems to be implemented, but the
> > problem here seems to persist.
> 
> The pragma still has no effect (not sure if we would be allowed to diagnose
> that fact).

I don't remember ever seeing anything in the C or C++ standard that would
prevent from printing as many diagnostics as we want, even for perfectly valid
code. Most warnings would be illegal otherwise.

> Nobody stepped up with a poor-mans "solution" to the issue (not sure if there
> even exists one) and a complete solution is not even on a drawing board.

One approach could be producing IFN_PLUS instead of PLUS_EXPR, for
floating-point types inside a "pragma on" region (or everywhere with
-frounding-math), and expanding it using the barrier mentioned below by default
(maybe with a possibility for targets to override that expansion). But then it
is tempting to refine IFN_PLUS and have variants (an argument?) specifying the
rounding mode when known, specifying if we only care about rounding, only about
exceptions, or both, etc. We could also produce PLUS_EXPR and the barriers
directly from the front-end, but with IFN_PLUS we at least have a chance to
fold exact constant operations (say 2.+2.), and more with the refined version.

Most lacking, whatever the approach, is a volunteer motivated enough to work on
it ;-)

clang doesn't handle the pragma either (AFAIK there was a recent effort, but it
stalled). Intel and Microsoft supposedly handle it, but Microsoft only applies
it to scalars and not SIMD vectors. That's not a lot of support...

> Other people running into this issue live with inserting compiler-barriers
> like
> 
> __asm__("# %0" : "=r" (x) : "0" (x));
> 
> for hiding 'x' from the compiler across this point.

You need to make it volatile, or it might be moved across fesetround. Also, you
can refine the constraint, say "=gx" on x86_64 (or just "=x"), and a different
one on each platform. An operation is then: *lo = hide(hide(x)/hide(y));

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #7 from Rich Townsend  ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 89864 ***
> 
> Are you sure? The discussion in 89864 indicates that the patch to fix this
> bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> configuring without the --with-sysroot and --with-build-sysroot flags
> (although I'm just rechecking that now).

Yep, confirmed that configuring without those flags allows the compile to
complete.

Now going to try out the patch mentioned by Iain in #5.

(In reply to Rich Townsend from comment #6)
> (In reply to Rich Townsend from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Dup.
> > > 
> > > *** This bug has been marked as a duplicate of bug 89864 ***
> > 
> > Are you sure? The discussion in 89864 indicates that the patch to fix this
> > bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> > configuring without the --with-sysroot and --with-build-sysroot flags
> > (although I'm just rechecking that now).
> 
> Yep, confirmed that configuring without those flags allows the compile to
> complete.
> 
> Now going to try out the patch mentioned by Iain in #5.

The patch successfully applied to the 9.1 release (with offsets), and the build
completed without hitch. Nice work, Iain!

[Bug testsuite/90565] New: [10 regression] test cases gcc.dg/uninit-18.c and uninit-pr90394-1-gimple.c broken as of r271460

[seurer at gcc dot gnu.org]

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

Bug ID: 90565
   Summary: [10 regression] test cases gcc.dg/uninit-18.c and
uninit-pr90394-1-gimple.c broken as of r271460
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Looks like the update changed the output for a couple of existing test cases.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-18.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -Wuninitialized -S -o uninit-18.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-18.c: In function 'foo':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-18.c:13:12: warning:
'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
FAIL: gcc.dg/uninit-18.c  (test for bogus messages, line 13)
PASS: gcc.dg/uninit-18.c  (test for bogus messages, line 16)
PASS: gcc.dg/uninit-18.c  (test for bogus messages, line 23)
PASS: gcc.dg/uninit-18.c (test for excess errors)
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

=== gcc Summary ===

# of expected passes3
# of unexpected failures1

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fgimple -O -Wmaybe-uninitialized -S -o
uninit-pr90394-1-gimple.s
FAIL: gcc.dg/uninit-pr90394-1-gimple.c  (test for warnings, line 9)
PASS: gcc.dg/uninit-pr90394-1-gimple.c (test for excess errors)
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0
seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1

[Bug testsuite/90564] [10 regression] gcc.target/powerpc/pr80315-X tests updated in r271455 are broken

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-21
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug testsuite/90564] New: [10 regression] gcc.target/powerpc/pr80315-X tests updated in r271455 are broken

[seurer at gcc dot gnu.org]

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

Bug ID: 90564
   Summary: [10 regression] gcc.target/powerpc/pr80315-X tests
updated in r271455 are broken
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

several of them are broken this way

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -mpower8-vector -c
-o powerpc_p8vector_ok53790.o powerpc_p8vector_ok53790.c
ERROR: gcc.target/powerpc/pr80315-4.c: unknown dg option: 0, 15\\ for "
dg-error 15 "argument 3 must be in the range \\[0, 15\\]" "

ERROR: gcc.target/powerpc/pr80315-4.c: unknown dg option: 0, 15\\ for "
dg-error 15 "argument 3 must be in the range \\[0, 15\\]" "

[Bug other/84889] Ideas on revamping how we format diagnostics

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
@David: Can we close this now?

[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Eric, can you please backport this patch to 8.4?
On x86_64-linux, it isn't a link failure, but as is mentioned in PR90562, the
incorrect LD model means the addresses of the thread_local variable inside of
inline function aren't the same in the same thread, but different shared
libraries.

[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #2)
> The variable should have been marked as GNU_UNIQUE object.

That is not the problem, the problem is that for the thread_local variable we
use in this case TLS LD model instead of GD.  For C++17 thread_local inline
variables GD model is used even in 8.x, for 9.x/trunk this has been fixed by
PR85400.
I guess we want to backport that to 8 branch too.

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

[Bug fortran/90563] New: Out of bounds error when compiling with -Wextra

[m...@tobias-neumann.eu]

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

Bug ID: 90563
   Summary: Out of bounds error when compiling with -Wextra
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@tobias-neumann.eu
  Target Milestone: ---

The following program fails to compile with gfortran 8 and 9 (not with 7 and
below) when compiling with -Wextra. -Wextra is supposed to only enable
additional warnings, not enable new errors. I also can't see additional bounds
checks in the additional warnings that are enabled with extra:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

% gfortran9 -Wextra -o test ./bcheck.f90
[14:20:23]
./bcheck.f90:11:28:

   11 |   p(j) = p(swap(j))
  |1
Error: Index in dimension 1 is out of bounds at (1)
./bcheck.f90:11:28:

9 |   do j=1,6
  |  2  
   10 |   if (j<5) then
   11 |   p(j) = p(swap(j))
  |1
Warning: Array reference at (1) out of bounds (6 > 4) in loop beginning at (2)
[-Wdo-subscript]

Obviously the compiler is not clever enough to take into account the constraint
from the if, but I don't think this should throw an error with -Wextra.

program test
  implicit none
  integer, parameter :: swap(4) = [2,1,3,4]
  real :: p(20)
  integer :: j

  p = 0.0

  do j=1,6
  if (j<5) then
  p(j) = p(swap(j))
  endif
  enddo
end program

[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||tudorb at gmail dot com

--- Comment #11 from Jakub Jelinek  ---
*** Bug 90562 has been marked as a duplicate of this bug. ***

[Bug d/90560] ICE in visit, at d/dmd/dcast.c:1872

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Reproducible in upstream dmd, bug raised here:
https://issues.dlang.org/show_bug.cgi?id=19890

[Bug d/90559] Out of memory because of negative length

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
This was fixed in upstream dmd, I'll backport the patch for 9.2.

[Bug c++/90309] Spurious warning shift-negative-value

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Marek Polacek from comment #3)
> Seems we need to add a warning sentinel.

...but first it'd be nice to find out *why* we're shifting by -4 and how that
can be.

[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries

[tudorb at gmail dot com]

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

--- Comment #3 from Tudor Bosman  ---
The bug also exists in gcc 8.3.0.

[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
The variable should have been marked as GNU_UNIQUE object.

[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries

[tudorb at gmail dot com]

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

--- Comment #1 from Tudor Bosman  ---
Note that the behavior is correct (the thread local variable has the same
address) with -O0, but incorrect with -O1 or above.

[Bug c++/90562] New: thread_local variables in inline functions have different addresses across shared libraries

[tudorb at gmail dot com]

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

Bug ID: 90562
   Summary: thread_local variables in inline functions have
different addresses across shared libraries
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tudorb at gmail dot com
  Target Milestone: ---

This is reduced from production code.

I have an inline function (not "static inline", just "inline") that has a
thread_local variable. The thread_local variable has a different address in
different shared libraries.

Code is at https://github.com/tudor/gcc_tl_bug

The function is defined in a.h, and used in a.cc and b.cc. If all files are
linked together (as per "mkstatic"), the function has the same address (as per
the C++ standard), and so does the thread-local variable:

$ ./main-static
0x5583a6b1a790 0x7f9e5acee4fc
0x5583a6b1a790 0x7f9e5acee4fc

If a.cc and b.cc are compiled in the different shared libraries (as per
"mkshared"), the function still has the same address, but the thread-local
variable does not:

$ ./main-shared
0x7f501b1d87c0 0x7f501b5e673c
0x7f501b1d87c0 0x7f501b5e6738


This is gcc 7.4.0, Ubuntu 18.04, x86-64.

$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
Copyright (C) 2017 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.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-21
 Ever confirmed|0   |1

--- Comment #12 from Iain Sandoe  ---
(In reply to Jack Howarth from comment #11)
> Just a reminder that clang solves finding the position of the SDK via xcrun
> and SDKROOT.

There are a few important points here.

1. We might be able to do some things in a similar manner, but "clang" is not
doing all the work you describe - there's effectively a wrapper that's
providing input for the clang driver.

2. xcrun is not open-sourced AFAIK, so we have to write an open equivalent /
emulate it in some way - the DEVELOPER_DIR etc require to find a suitable
executable at a specific path in the toolchain installation.

3. when clang is using a "different" SDK to target a version of MacOS, it is
using the runtimes provided by the target MacOS version.  
  GCC on the other hand is providing a series of runtimes and those runtimes
are configured on the basis of the version of the system they are intending to
target.  Likewise, the fixincludes are run against the sysroot provided at
build time (whether it comes from --with-sysroot, or --build-sysroot is
immaterial to that).

4. for a number of sub-ranges of system versions we might be able to get away
with single copies of the runtimes (build for the oldest version you wish to
support).  However, that does not guarantee that all APIs will be carried
forward (sometimes they are retired).

5. anything that means N more process launches per source file build seems like
we've picked a bad solution - so some form of caching somehow is highly
desirable.

For "target=host=build" single user cases, the --with-sysroot version works,
and we still have to find a good story for how to handle the more general case.
 We've long resisted the notion of having multilibs by system version, but if
one really wants to cover the full range of possibilities - then either muliple
compilers or some form of system-revision multilib seems unavoidable.

Inactivity on this and related subjects (basically how to build and package GCC
for Darwin) should not be taken as meaning we don't care - actually we care
very much - it's just that a good solution has yet to be found.

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #6 from Rich Townsend  ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 89864 ***
> 
> Are you sure? The discussion in 89864 indicates that the patch to fix this
> bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> configuring without the --with-sysroot and --with-build-sysroot flags
> (although I'm just rechecking that now).

Yep, confirmed that configuring without those flags allows the compile to
complete.

Now going to try out the patch mentioned by Iain in #5.

[Bug target/90547] [8/9/10 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 21 17:57:11 2019
New Revision: 271479

URL: https://gcc.gnu.org/viewcvs?rev=271479=gcc=rev
Log:
PR target/90547
* config/i386/i386.md (anddi_1 to andsi_1_zext splitter):
Avoid calling gen_lowpart with CONST operand.

testsuite/ChangeLog:

PR target/90547
* gcc.target/i386/pr90547.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr90547.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Rich Townsend from comment #0)
> I'm running into a bug building on OSX Mojave, which seems to be tied into
> the problems with _Atomic in Apple's system headers. The error itself is:

> /Users/townsend/devel/sdk2/build/gcc/configure CC=
> --build=x86_64-apple-darwin18.5.0 --prefix=/Applications/mesasdk-dev
> --with-gmp=/Applications/mesasdk-dev --with-mpfr=/Applications/mesasdk-dev
> --with-mpc=/Applications/mesasdk-dev --enable-languages=c,c++,fortran
> --disable-multilib --disable-nls --disable-libsanitizer --with-sysroot=/
> --with-build-sysroot=/Users/townsend/devel/sdk2/build/xcode
> 
> The messing around with --with-sysroot and --with-build-sysroot is so that
> the resulting compiler can be used on older OSX versions, without any
> undefined symbols cropping up. My understanding of these flags is that:

This part is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

there's an experimental patch at comment #10

[Bug middle-end/90114] Predetermined private levels for variables declared in OpenACC accelerator routines

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #2)
> Is it fixed?

No, I just committed a few test cases to document the status quo.

[Bug fortran/90067] Loop variables in Fortran 'do' statements within a compute construct must be predetermined private

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #2)
> Is it fixed?

No, I just committed a few test cases to document the status quo.

[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-21
 CC||pault at gcc dot gnu.org
  Known to work||8.3.0
 Blocks||68241
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r264657 (2018-09-26, OK) and r264722
(2018-09-30, ICE).

I am pretty sure this is a duplicate, but I cannot find it right now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Rich Townsend from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Dup.
> > > 
> > > *** This bug has been marked as a duplicate of bug 89864 ***
> > 
> > Are you sure? The discussion in 89864 indicates that the patch to fix this
> > bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> > configuring without the --with-sysroot and --with-build-sysroot flags
> > (although I'm just rechecking that now).
> 
> in the 9.2 release - but you can grab a snapshot from any time after it was
> applied.

scrub that - the change to fix the problem _is_ in 9.1 - there's a follow up
change that adjusts the testing only, that will be in 9.2.

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Iain Sandoe  ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 89864 ***
> 
> Are you sure? The discussion in 89864 indicates that the patch to fix this
> bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> configuring without the --with-sysroot and --with-build-sysroot flags
> (although I'm just rechecking that now).

in the 9.2 release - but you can grab a snapshot from any time after it was
applied.

[Bug fortran/90561] New: [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747

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

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

Bug ID: 90561
   Summary: [9/10 Regression] ICE in gimplify_var_or_parm_decl, at
gimplify.c:2747
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180923 and 20180930 :


$ cat z1.f90
program p
   character(:), allocatable :: z(:)
   z = [character(2):: 'ab', 'xy']
   z = z(2)
end


$ gfortran-9-20180923 -c z1.f90
$
$ gfortran-10-20190519 -c z1.f90
z1.f90:4:0:

4 |z = z(2)
  |
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2747
0x8f7134 gimplify_var_or_parm_decl
../../gcc/gimplify.c:2747
0x8f86f7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12909
0x902c29 gimplify_modify_expr
../../gcc/gimplify.c:5678
0x8f8fed gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12464
0x8fb888 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0x8f9c8b gimplify_statement_list
../../gcc/gimplify.c:1788
0x8f9c8b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12893
0x8fb888 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0x8fc1e1 gimplify_bind_expr
../../gcc/gimplify.c:1356
0x8f93fb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12665
0x8fb888 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0x8f9c8b gimplify_statement_list
../../gcc/gimplify.c:1788
0x8f9c8b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12893
0x8fb888 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0x8fc1e1 gimplify_bind_expr
../../gcc/gimplify.c:1356
0x8f93fb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12665
0x8fb888 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6709
0x8fcc1a gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:13673
0x8fcf05 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:13817
0x7adc37 cgraph_node::analyze()
../../gcc/cgraphunit.c:667
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/88099] ICE in maybe_legitimize_operand, at optabs.c:7170

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

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

G. Steinmetz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from G. Steinmetz  ---

Can be regarded as a variation of pr50974 with same root cause.
For the records, ifort refuses it with  

z1.f90(5): error #6423: This name has already been used as an external function
name.   [N2]
  n1 = n1 + n2
^
z1.f90(5): error #8497: Illegal use of a procedure name in an expression,
possibly a function call missing parenthesis.   [N2]
  n1 = n1 + n2
^

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

[Bug fortran/50974] ICE on invalid on function used as variable

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

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

--- Comment #6 from G. Steinmetz  ---
*** Bug 88099 has been marked as a duplicate of this bug. ***

[Bug d/90560] New: ICE in visit, at d/dmd/dcast.c:1872

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

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

Bug ID: 90560
   Summary: ICE in visit, at d/dmd/dcast.c:1872
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Another variation with negative length :

$ cat z1.d
void[] f = cast(void[-1]) "a";


$ gdc-10-20190519 -c z1.d
d21: internal compiler error: Segmentation fault
0xb6ed9f crash_signal
../../gcc/toplev.c:326
0x63b663 visit
../../gcc/d/dmd/dcast.c:1872
0x64051a castTo(Expression*, Scope*, Type*)
../../gcc/d/dmd/dcast.c:2370
0x6aff10 Expression::castTo(Scope*, Type*)
../../gcc/d/dmd/expression.h:173
0x6aff10 ExpressionSemanticVisitor::visit(CastExp*)
../../gcc/d/dmd/expressionsem.c:4243
0x6a8495 semantic(Expression*, Scope*)
../../gcc/d/dmd/expressionsem.c:8158
0x6d893d InitializerSemanticVisitor::visit(ExpInitializer*)
../../gcc/d/dmd/initsem.c:348
0x6d85db semantic(Initializer*, Scope*, Type*, NeedInterpret)
../../gcc/d/dmd/initsem.c:520
0x64c123 VarDeclaration::semantic2(Scope*)
../../gcc/d/dmd/declaration.c:1619
0x66b2ef Module::semantic2(Scope*)
../../gcc/d/dmd/dmodule.c:782
0x76660d d_parse_file()
../../gcc/d/d-lang.cc:1185

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #1)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 89864 ***

Are you sure? The discussion in 89864 indicates that the patch to fix this bug
should be in the 9.1 release. Also, IIRC I don't see the bug when configuring
without the --with-sysroot and --with-build-sysroot flags (although I'm just
rechecking that now).

[Bug d/90559] New: Out of memory because of negative length

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

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

Bug ID: 90559
   Summary: Out of memory because of negative length
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Some variations with negative length :

$ cat z1.d
int[0][-1] a;

$ cat z2.d
int[-1][0] a;

$ cat z3.d
int[-1][-1] a;


$ gdc-10-20190519 -c z1.d
d21: out of memory allocating 18446744073709551608 bytes after a total of
3334144 bytes


$ gdc-10-20190519 -c z3.d
z3.d:1:13: error: int[18446744073709551615LU] size 4 * 18446744073709551615
exceeds 0x7fff size limit for static array
1 | int[-1][-1] a;
  | ^
z3.d:1:13: error: int[18446744073709551615LU] size 4 * 18446744073709551615
exceeds 0x7fff size limit for static array
1 | int[-1][-1] a;
  | ^

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #97 from Andrew Pinski  ---
*** Bug 90558 has been marked as a duplicate of this bug. ***

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug bootstrap/90558] New: '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

Bug ID: 90558
   Summary: '_Atomic does not name a type' error resurfaces when
building with old headers on OSX Mojave
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm running into a bug building on OSX Mojave, which seems to be tied into the
problems with _Atomic in Apple's system headers. The error itself is:

/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/xg++
-B/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/
-B/Applications/mesasdk-dev/x86_64-apple-darwin18.5.0/bin/ -nostdinc++
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs

-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include/x86_64-apple-darwin18.5.0

-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include
 -I/Users/townsend/devel/sdk2/build/gcc/libstdc++-v3/libsupc++
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/Applications/mesasdk-dev/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/Applications/mesasdk-dev/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"9.1.0\"
-DDEFAULT_REAL_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DDEFAULT_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DSTANDARD_BINDIR_PREFIX=\"/Applications/mesasdk-dev/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" -DACCEL_DIR_SUFFIX=\"\"
-DTARGET_SYSTEM_ROOT=\"/\"  -DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\""
-DTOOL_INCLUDE_DIR=\"/Applications/mesasdk-dev/lib/gcc/x86_64-apple-darwin18.5.0/9.1.0/../../../../x86_64-apple-darwin18.5.0/include\"
-DNATIVE_SYSTEM_HEADER_DIR=\"/usr/include\" -DIN_GCC_FRONTEND -g -O2 
-fno-checking  -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -Ifortran -I/Users/townsend/devel/sdk2/build/gcc/gcc
-I/Users/townsend/devel/sdk2/build/gcc/gcc/fortran
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../include
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libcpp/include
-I/Applications/mesasdk-dev/include -I/Applications/mesasdk-dev/include
-I/Applications/mesasdk-dev/include 
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I/Users/townsend/devel/sdk2/build/gcc/gcc/../libbacktrace  
-o fortran/gfortranspec.o -MT fortran/gfortranspec.o -MMD -MP -MF
fortran/.deps/gfortranspec.TPo
/Users/townsend/devel/sdk2/build/gcc/gcc/fortran/gfortranspec.c
In file included from /usr/include/sys/sysctl.h:83,
 from
/Users/townsend/devel/sdk2/build/gcc/gcc/config/darwin-driver.c:30:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
   94 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
make[3]: *** [darwin-driver.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

What makes this instance of the bug rather different than other bug reports
I've seen, is that I'm compiling using an old set of system headers (as
provided by the Xcode SDK for OSX 10.10). You can see this from my configure
invocation:

/Users/townsend/devel/sdk2/build/gcc/configure CC=
--build=x86_64-apple-darwin18.5.0 --prefix=/Applications/mesasdk-dev
--with-gmp=/Applications/mesasdk-dev --with-mpfr=/Applications/mesasdk-dev
--with-mpc=/Applications/mesasdk-dev --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer --with-sysroot=/
--with-build-sysroot=/Users/townsend/devel/sdk2/build/xcode

The messing around with --with-sysroot and --with-build-sysroot is so that the
resulting compiler can be used on older OSX versions, without any undefined
symbols cropping up. My understanding of these flags is that:

*) during the compiler and library build, system headers will be obtained from
/Users/townsend/devel/sdk2/build/xcode/usr/include -- here, the xcode subdir
contains the SDK for OSX 10.10, including headers

*) the built compiler, however, will obtain system headers from /usr/include.
Running fixheaders is usually required to make sure these system headers are
cleaned up.

Using this approach, I've 

[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
Author: iains
Date: Tue May 21 16:33:48 2019
New Revision: 271475

URL: https://gcc.gnu.org/viewcvs?rev=271475=gcc=rev
Log:
darwin, testsuite - fix PR 67958

These tests require specific scan-asms in some cases because
of the different codegen for Dawin.  Added some explanations
too.

2019-05-21  Iain Sandoe  

PR testsuite/67958
* gcc.target/i386/pr32219-1.c: Adjust scan-asms for Darwin, comment
the differences.
* gcc.target/i386/pr32219-2.c: Likewise.
* gcc.target/i386/pr32219-3.c: Likewise.
* gcc.target/i386/pr32219-4.c: Likewise.
* gcc.target/i386/pr32219-5.c: Likewise.
* gcc.target/i386/pr32219-6.c: Likewise.
* gcc.target/i386/pr32219-7.c: Likewise.
* gcc.target/i386/pr32219-8.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr32219-1.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-2.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-3.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-4.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-5.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-6.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-7.c
trunk/gcc/testsuite/gcc.target/i386/pr32219-8.c

[Bug target/63891] [7/8/9/10 regression] Failure of darwin-weakimport-3.c

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  ---
Author: iains
Date: Tue May 21 16:24:25 2019
New Revision: 271474

URL: https://gcc.gnu.org/viewcvs?rev=271474=gcc=rev
Log:
darwin, testsuite - fix PR 63891.

This is a testcase failing because one part of the codegen is
(correctly) generating the scan-asm-not signature.

Fixed by altering the build options.

gcc/testsuite/

2019-05-18  Iain Sandoe  

PR target/63891
* gcc.dg/darwin-weakimport-3.c: Adjust options and explain
the reasons.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/darwin-weakimport-3.c

[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table::find_slot_with_hash

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
I can't help much as I don't have a ia64 system.

I don't think the issue in this PR relates directly to hpux.  Rather, the
bootstrap compiler has
miscompiled the stage1 compiler.

The 4.9 branch has been closed for a long time.  gcc-8 is known to work
reasonably well
on ia64 Debian linux.  I would suggest the interested parties see if they can
find a bootstrap
compiler that will successfully build gcc-8.

No one seems to have tried testcase using a ia64-hpux cross compiler.

Haven't heard back status of PR 61577.  It's also a bootstrap issue.

[Bug bootstrap/87338] [8/9 Regression] gcc 8.2 fails to bootstrap on ia64

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-21
 CC||law at redhat dot com
Summary|gcc 8.2 fails to bootstrap  |[8/9 Regression] gcc 8.2
   |on ia64 |fails to bootstrap on ia64
 Ever confirmed|0   |1

--- Comment #12 from Jeffrey A. Law  ---
Fixed on trunk so far.

[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Tue May 21 15:42:00 2019
New Revision: 271472

URL: https://gcc.gnu.org/viewcvs?rev=271472=gcc=rev
Log:
PR bootstrap/87338
* dwarf2out.c (dwarf2out_inline_entry): Use ASM_OUTPUT_DEBUG_LABEL
instead of ASM_GENERATE_INTERNAL_LABEL and ASM_OUTPUT_LABEL.

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

[Bug libfortran/90038] execute_command_line should not use fork()

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist  ---
Author: jb
Date: Tue May 21 15:24:30 2019
New Revision: 271470

URL: https://gcc.gnu.org/viewcvs?rev=271470=gcc=rev
Log:
libfortran/90038: Document new wait=.false. implementation

2019-05-21  Janne Blomqvist  

   PR libfortran/90038
   * intrinsic.texi (EXECUTE_COMMAND_LINE): Explain new
   wait=.false. implementation.

Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/intrinsic.texi

[Bug libfortran/90038] execute_command_line should not use fork()

[jb at gcc dot gnu.org]

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

--- Comment #12 from Janne Blomqvist  ---
Author: jb
Date: Tue May 21 15:17:44 2019
New Revision: 271468

URL: https://gcc.gnu.org/viewcvs?rev=271468=gcc=rev
Log:
libfortran/90038: Document new wait=.false. implementation

2019-05-21  Janne Blomqvist  

PR libfortran/90038
* intrinsic.texi (EXECUTE_COMMAND_LINE): Explain new
wait=.false. implementation.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug libstdc++/90557] Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Arnaud Desitter from comment #0)
> However, the defect comes from
> fs_path.cc:281
> 
> std::uninitialized_copy_n(to + oldsize, newsize - oldsize,
>   from + oldsize);
> should be:
> std::uninitialized_copy_n(from + oldsize, newsize - oldsize,
>   to + oldsize);

Yikes, thanks.

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #18 from Iain Sandoe  ---
(In reply to Nenad Vukicevic from comment #15)
> Just updated Xcode to 7.2.  Still the same issue, even though dsymutil 
> changed.
> 
> On 12/7/2015 1:19 AM, iains at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
> >
> > --- Comment #14 from Iain Sandoe  ---
> > (In reply to Nenad Vukicevic from comment #13)
> >> For what is worth I filed two bug reports:
> >
> > Thanks!
> >
> >> LLVM:
> >> https://llvm.org/bugs/show_bug.cgi?id=25757
> >>
> >> APPLE:
> >> Bug 23778972 (not sure how to get URL for this bug)

The actual issue seems to be that ld64 only issues the OSO for the first use
of a source file seen when linking an exe.  Therefore, in cases where
conditional
compilation (or LTO) causes multiple objects to be created from one source,
there's
no OSO for some of the .o files. 

dsymutil complains - but its complaint is correct.

FWIW; I have a fix for the ld64 bug here:

https://github.com/iains/darwin-xtools/commit/c2b58c3328cb002459fba9b312949c9fd9f0165e

> > It's on my TODO to deal with problem #1 (shouldn't be calling dsymutil
> > unconditionally), but I'll attach that to PR 61352.

lto-wrapper and friends have has some TLC in the 9 timeframe, and for at least
9.x and 10, I think that dsymutil is only now being called when it's needed.

LTO debug for Darwin does require some more work (and a change to dsymutil to
deal with it) - but that's tracked in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 so don't let's duplicate
here.

(so ... I don't expect all aspects of this to be fixed yet - but running some
checks with revised ld64).

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #9 from nsz at gcc dot gnu.org ---
spec2017 521.wrf_r never finishes on aarch64

gcc rev 271291 runs fine
gcc rev 271380 does not finish (possibly a crash that the spec scripts don't
detect)

[Bug libstdc++/90557] New: Incorrect std::filesystem::path::operator=(std::filesystem::path const&) in gcc 9.1.0

[arnaud02 at users dot sourceforge.net]

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

Bug ID: 90557
   Summary: Incorrect
std::filesystem::path::operator=(std::filesystem::path
const&) in gcc 9.1.0
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

Using gcc 9.1.0, I observe some memory issues detected with valgrind when using
std::filesystem:path:
==23251== Conditional jump or move depends on uninitialised value(s)
==23251==at 0x6CDD45: void std::__cxx11::basic_string, std::allocator >::_M_construct(char*,
char*, std::forward_iterator_tag) (basic_string.tcc:211)
==23251==by 0xA807D5: _M_construct_aux (basic_string.h:247)
==23251==by 0xA807D5: _M_construct (basic_string.h:266)
==23251==by 0xA807D5: basic_string (basic_string.h:451)
==23251==by 0xA807D5: path (fs_path.h:175)
==23251==by 0xA807D5: _Cmpt (fs_path.h:690)
==23251==by 0xA807D5: _Construct (stl_construct.h:75)
==23251==by 0xA807D5: __uninit_copy (stl_uninitialized.h:83)
==23251==by 0xA807D5:
uninitialized_copy (stl_uninitialized.h:134)
==23251==by 0xA807D5:
__uninitialized_copy_n (stl_uninitialized.h:767)
==23251==by 0xA807D5:
uninitialized_copy_n (stl_uninitialized.h:814)
==23251==by 0xA807D5:
std::filesystem::__cxx11::path::_List::operator=(std::filesystem::__cxx11::path::_List
const&) (fs_path.cc:281)
==23251==by 0xA80858:
std::filesystem::__cxx11::path::operator=(std::filesystem::__cxx11::path
const&) (fs_path.cc:451)

I was not able to extract a small reproducer. However, the defect comes from
fs_path.cc:281

  std::uninitialized_copy_n(to + oldsize, newsize - oldsize,
from + oldsize);
should be:
  std::uninitialized_copy_n(from + oldsize, newsize - oldsize,
to + oldsize);

[Bug libstdc++/90252] PSTL test failures

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 21 13:50:41 2019
New Revision: 271466

URL: https://gcc.gnu.org/viewcvs?rev=271466=gcc=rev
Log:
PR libstdc++/90252 fix effective-target check for TBB

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Use "additional_flags" to pass -ltbb to v3_target_compile command.
Use check_v3_target_prop_cached to cache the result of the test.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

--- Comment #17 from Eric Gallager  ---
(In reply to David Malcolm from comment #16)
> (In reply to Martin Liška from comment #14)
> > David: Can the bug be marked as resolved?
> 
> Much of this is implemented for gcc 9.
> 
> I want to keep this open, to revisit it in gcc 10.

It's gcc 10 now.

> I think the main pending items are:
> 
> (In reply to David Malcolm from comment #0)
> [...]
> > * the diagnostic and the followup notes are grouped, so it's easier to pick
> > out what messages relate to what
> [...]
> > IIRC, clang does something where the left-hand column is only non-empty for
> > the start of a diagnostic; followup lines (e.g. due to line wrapping) are
> > indented by 1 char, so that the "wall of text" is broken up somewhat
> [...]

[Bug c/53063] encode group options in the .opt files

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Eric Gallager  ---
(In reply to Eric Gallager from comment #12)
> (In reply to Martin Liška from comment #11)
> > Can the bug be marked as resolved?
> 
> WAITING on a reply

no reply; assuming this was fixed

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989
Bug 40989 depends on bug 53063, which changed state.

Bug 53063 Summary: encode group options in the .opt files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug target/90545] [10 regression] gcc.target/powerpc/fold-vec-splats-floatdouble.c fails starting with r271022

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #2 from Alan Modra  ---
Patch applied.

[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Eric Gallager  ---
(In reply to Eric Gallager from comment #13)
> (In reply to Martin Liška from comment #12)
> > Can the bug be marked as resolved?
> 
> WAITING on a reply

no reply; assuming this was fixed

[Bug target/90545] [10 regression] gcc.target/powerpc/fold-vec-splats-floatdouble.c fails starting with r271022

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra  ---
Author: amodra
Date: Tue May 21 13:36:04 2019
New Revision: 271464

URL: https://gcc.gnu.org/viewcvs?rev=271464=gcc=rev
Log:
PR90545, gcc.target/powerpc/fold-vec-splats-floatdouble.c fails

I figure a tweak to register_move_cost is better than sprinkling ?s
in instruction operand alternatives.

PR target/90545
* config/rs6000/rs6000.c (rs6000_register_move_cost): Increase
power9 direct move cost.
* testsuite/gcc.target/powerpc/fold-vec-splats-floatdouble.c:
Correct comments and rename functions to suit parameters.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-splats-floatdouble.c

[Bug middle-end/90549] missing -Wreturn-local-addr maybe returning an address of a local array plus offset

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> Agreed.  Please go ahead abd create one.
> 
> I'm working on a combined patch for this and PR 71924.

OK, I created bug 90556

[Bug other/90556] New: [meta-bug] bogus/missing -Wreturn-local-addr

[egallager at gcc dot gnu.org]

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

Bug ID: 90556
   Summary: [meta-bug] bogus/missing -Wreturn-local-addr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic, meta-bug
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Depends on: 19972, 49974, 69433, 71924, 81811, 90549
  Target Milestone: ---

-Wreturn-local-addr bugs are spread out between so many different components
that I couldn't pick a decent one for this one and ended up just going with
"other"


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19972
[Bug 19972] -Wreturn-local-addr misses return of local (nested) function
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
[Bug 49974] missing -Wreturn-local-addr for indirectly returning reference to
local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433
[Bug 69433] missing -Wreturn-local-addr assigning address of a local to a
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71924
[Bug 71924] missing -Wreturn-local-addr returning alloca result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811
[Bug 81811] missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549
[Bug 90549] missing -Wreturn-local-addr maybe returning an address of a local
array plus offset

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Not working on this anymore.

[Bug ipa/79966] [9/10 Regression] run time more than twice slower when using -fipa-cp-clone

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
The run time on the 9 branch and trunk with/without -fipa-cp-clone is now as
slow as for the 8 branch with -fipa-cp-clone:

% gfc9 pr79966.f90 -O2 -fpeel-loops -finline-functions
% time ./a.out
 Using SUM, time: 0.291947961

[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #17 from Dominique d'Humieres  ---
AFAICT these warnings are gone with Xcode 10.

[Bug c++/90309] Spurious warning shift-negative-value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Seems we need to add a warning sentinel.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46388|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46390=edit
gcc10-pr88335-wip.patch

Updated patch.  This one tries to evaluate immediate function calls immediately
in build_over_call, adds some testsuite coverage etc.
What still doesn't work is:
1) consteval constructors, I think evaluating those in build_over_call is too
early, we need a TARGET_EXPR for them or something similar that supplies to the
constexpr evaluation the object that is being initialized; so, where should we
do that and should we do that that way only for ctors, or everything?
2) the example added to the end of [expr.const] doesn't work - we have in
cxx_eval_outermost_constant_expr:
  if (VOID_TYPE_P (type))
return t;
early exit.  Is that something that is correct for anything?  I mean, aren't we
supposed to evaluate the constexpr (and consteval) functions anyway?
constexpr void foo (bool x) { if (x) throw 1; }
constexpr int a = (foo (false), 1);
constexpr int b = (foo (true), 2);
is handled correctly though, because in that case the void type expressions are
the outermost ones.  Perhaps we should do this early exit only if the
expression isn't a call to an immediate function?
3) consteval virtual members not handled at all, and I'm afraid that is out of
my area of expertise

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/90450] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 46389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46389=edit
patch

The attached should fix the issue.  Martin?

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue May 21 12:01:00 2019
New Revision: 271463

URL: https://gcc.gnu.org/viewcvs?rev=271463=gcc=rev
Log:
2019-05-21  Richard Biener  

PR middle-end/90510
* fold-const.c (fold_read_from_vector): New function.
* fold-const.h (fold_read_from_vector): Declare.
* match.pd (VEC_PERM_EXPR): Build BIT_INSERT_EXPRs for
single-element insert permutations.  Canonicalize selector
further and fix issue with last commit.

* gcc.target/i386/pr90510.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr90510.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/fold-const.h
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Thomas Koenig  ---
(In reply to Martin Liška from comment #6)
> So there's somebody who is having the file in a public git repository.
> That's probably violating SPEC rules :) But anyway, the .f90 file is here:
> https://gitlab.bcamath.org/atrucchia/randomfront-wrfsfire-lsfire/blob/
> 152f8c92b89b20021403acba9536553fda7a527b/wrfv2_fire/share/solve_interface.f90
> 
> @Thomas: Is it enough info?

I'm afraid not, it is neither complete nor self-contained (nor is the
bug report in comment#7).  So, this is not a valid bug report according
to https://www.gnu.org/software/gcc/bugs/ .  It's a heads-up, nothing
more.

SPEC is proprietary software, none of the Fortran maintainers has
access to it. I will deal with this bug the same as I deal with
all other bug reports - no test case, no possibility of fixing.