[Bug c/84173] Support glibc multiarch interpreter names

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Javier Serrano Polo from comment #3)
> Upstream wants to make multiarch harder; the patch will not be posted here.

As long as the new behavior is optional (not the default), the patch stands a
chance of being accepted. But I am not sure what exactly this PR is for, asking
to support names that haven't been decided yet.
(the discussion about names is probably more appropriate on the libc side,
since that's usually where ld.so comes from)

[Bug target/84172] option "-O3" create slower code

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

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

--- Comment #9 from Andreas Otto  ---
after morning "boot" it seems OK… BUT the bug come back

→ star without "-g" option

#:~/test> make test
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 663.640015 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.407990 ms → HI = 0x1, LO = 0
./test.1 → T1 = 137.326996 ms → HI = 0x1, LO = 0
./test.1 → T2 = 133.870010 ms → HI = 0x1, LO = 0
./test.2 → T1 = 138.035995 ms → HI = 0x1, LO = 0
./test.2 → T2 = 135.183014 ms → HI = 0x1, LO = 0
./test.3 → T1 = 137.481003 ms → HI = 0x1, LO = 0
./test.3 → T2 = 134.893997 ms → HI = 0x1, LO = 0
#:~/test> make test
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 656.669983 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.566986 ms → HI = 0x1, LO = 0
./test.1 → T1 = 134.537994 ms → HI = 0x1, LO = 0
./test.1 → T2 = 132.356003 ms → HI = 0x1, LO = 0
./test.2 → T1 = 144.015991 ms → HI = 0x1, LO = 0
./test.2 → T2 = 134.715012 ms → HI = 0x1, LO = 0
./test.3 → T1 = 137.255997 ms → HI = 0x1, LO = 0
./test.3 → T2 = 134.914001 ms → HI = 0x1, LO = 0

add "-g" option again

#:~/test> make test
gcc-5 -march=native -mtune=native -g -static -O0 -o test.0 main.c
gcc-5 -march=native -mtune=native -g -static -O1 -o test.1 main.c
gcc-5 -march=native -mtune=native -g -static -O2 -o test.2 main.c
gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 655.403992 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.989014 ms → HI = 0x1, LO = 0
./test.1 → T1 = 132.431000 ms → HI = 0x1, LO = 0
./test.1 → T2 = 133.049988 ms → HI = 0x1, LO = 0
./test.2 → T1 = 141.020004 ms → HI = 0x1, LO = 0
./test.2 → T2 = 135.460999 ms → HI = 0x1, LO = 0
./test.3 → T1 = 211.210999 ms → HI = 0x1, LO = 0
./test.3 → T2 = 225.455002 ms → HI = 0x1, LO = 0
#:~/test> make test
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 662.700989 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.704010 ms → HI = 0x1, LO = 0
./test.1 → T1 = 146.843994 ms → HI = 0x1, LO = 0
./test.1 → T2 = 133.729996 ms → HI = 0x1, LO = 0
./test.2 → T1 = 140.351990 ms → HI = 0x1, LO = 0
./test.2 → T2 = 134.825012 ms → HI = 0x1, LO = 0
./test.3 → T1 = 213.688995 ms → HI = 0x1, LO = 0
./test.3 → T2 = 225.066010 ms → HI = 0x1, LO = 0

disable "-g" option

#:~/test> make test
gcc-5 -march=native -mtune=native -static -O0 -o test.0 main.c 
gcc-5 -march=native -mtune=native -static -O1 -o test.1 main.c 
gcc-5 -march=native -mtune=native -static -O2 -o test.2 main.c 
gcc-5 -march=native -mtune=native -static -O3 -o test.3 main.c 
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 652.817017 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.574005 ms → HI = 0x1, LO = 0
./test.1 → T1 = 139.962006 ms → HI = 0x1, LO = 0
./test.1 → T2 = 134.207001 ms → HI = 0x1, LO = 0
./test.2 → T1 = 134.936005 ms → HI = 0x1, LO = 0
./test.2 → T2 = 135.485001 ms → HI = 0x1, LO = 0
./test.3 → T1 = 217.895004 ms → HI = 0x1, LO = 0
./test.3 → T2 = 224.744003 ms → HI = 0x1, LO = 0
#:~/test> make test
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 660.490967 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.671997 ms → HI = 0x1, LO = 0
./test.1 → T1 = 141.137009 ms → HI = 0x1, LO = 0
./test.1 → T2 = 133.236008 ms → HI = 0x1, LO = 0
./test.2 → T1 = 136.444000 ms → HI = 0x1, LO = 0
./test.2 → T2 = 135.473999 ms → HI = 0x1, LO = 0
./test.3 → T1 = 256.563019 ms → HI = 0x1, LO = 0
./test.3 → T2 = 225.742996 ms → HI = 0x1, LO = 0

do som additional testing

#:~/test> rm test.
test.0  test.1  test.2  test.3  
#:~/test> rm test.*
#:~/test> make test
gcc-5 -march=native -mtune=native -static -O0 -o test.0 main.c 
gcc-5 -march=native -mtune=native -static -O1 -o test.1 main.c 
gcc-5 -march=native -mtune=native -static -O2 -o test.2 main.c 
gcc-5 -march=native -mtune=native -static -O3 -o test.3 main.c 
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 652.343994 ms → HI = 0x1, LO = 0
./test.0 → T2 = 490.720978 ms → HI = 0x1, LO = 0
./test.1 → T1 = 132.760010 ms → HI = 0x1, LO = 0
./test.1 → T2 = 132.718994 ms → HI = 0x1, LO = 0
./test.2 → T1 = 135.055008 ms → HI = 0x1, LO = 0
./test.2 → T2 = 135.212997 ms → HI = 0x1, LO = 0
./test.3 → T1 = 221.292007 ms → HI = 0x1, LO = 0
./test.3

[Bug libfortran/84156] [8 Regression] valgrind error with print *,1

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
I think this is related to the front end initializing the dtp common structure
and the runtime using it. This looking unititiaklzed and therefore a false
error.

I am not sure valgrind can detect this and I think this is why one is allowed
to tell valgind to ignore these things. But 

I am certainly not an expert in this area and I simply presume this is not a
real bug.

[Bug c++/84177] New: Attributes on C++17 nested namespaces

[akim.demaille at gmail dot com]

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

Bug ID: 84177
   Summary: Attributes on C++17 nested namespaces
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

One would expect this to work:

$ cat /tmp/foo.cc
namespace a::b __attribute__ ((visibility ("protected")) {}

$ g++-mp-7 -std=c++17 /tmp/foo.cc
/tmp/foo.cc:1:16: error: expected '{' before '__attribute__'
 namespace a::b __attribute__ ((visibility ("protected")) {}
^
/tmp/foo.cc:1:58: error: expected ')' before '{' token
 namespace a::b __attribute__ ((visibility ("protected")) {}
  ^
/tmp/foo.cc:1:59: error: expected unqualified-id at end of input
 namespace a::b __attribute__ ((visibility ("protected")) {}
   ^
/tmp/foo.cc:1:59: error: expected '}' at end of input


This is:

$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7.2.0_0) 7.2.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.

FWIW, it's quite hard to navigate in the documentation to find
information about attributes for namespaces.  I have not found
clear evidence that this feature had been considered and eliminated,
or whether it's just an overlook.

Cheers!

[Bug target/84176] New: Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet

[hjl.tools at gmail dot com]

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

Bug ID: 84176
   Summary: Need a different thunk for
-mindirect-branch=thunk-extern -fcf-protection -mcet
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

When -fcf-protection -mcet is used to compile kernel, nocf_check attribute
can be used to add notrack prefix:

[hjl@gnu-skx-1 nt-1]$ cat x.i
void (*func1) (void) __attribute__((nocf_check));
void (*func2) (void);

void
bar (void)
{
  func1 ();
  func2 ();
}
[hjl@gnu-skx-1 nt-1]$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fcf-protection -mcet
-S x.i
[hjl@gnu-skx-1 nt-1]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl  bar
.type   bar, @function
bar:
.LFB0:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
notrack call*func1(%rip)
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp *func2(%rip)
.cfi_endproc
.LFE0:
.size   bar, .-bar

When -mindirect-branch=thunk-extern is added, we need a thunk with
a different name to tell a thunk for indirect branch with notrack
prefix from a thunk for indirect branch without notrack prefix

[hjl@gnu-skx-1 nt-1]$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -fcf-protection -mcet
-mindirect-branch=thunk-extern  -S -o y.s x.i
[hjl@gnu-skx-1 nt-1]$ cat y.s
.file   "x.i"
.text
.p2align 4,,15
.globl  bar
.type   bar, @function
bar:
.LFB0:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movqfunc1(%rip), %rax
call__x86_indirect_thunk_rax
movqfunc2(%rip), %rax
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp __x86_indirect_thunk_rax
.cfi_endproc
.LFE0:
.size   bar, .-bar

Otherwise kernel can't properly update a thunk to an indirect branch with
notrack prefix for indirect branch with notrack prefix.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug target/81739] Replace calls to memcmp with more efficient code if possible

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Clang 5.0 emits semi-optimal code.  For x86_64:

cmp1(unsigned long long, unsigned long long): # @cmp1(unsigned long long,
unsigned long long)

  mov qword ptr [rsp - 8], rdi
  mov qword ptr [rsp - 16], rsi
  bswap rdi
  bswap rsi
  xor ecx, ecx
  cmp rdi, rsi
  mov edx, -1
  mov eax, 1
  cmovb eax, edx
  cmove eax, ecx
  ret

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #18 from Jason Merrill  ---
Assigning to Martin.  I was convinced of his position by discussion on the Core
reflector, which pointed out that in general explicit specializations are
treated as entirely separate from their templates, such that for instance a
specialization of a class template isn't required to define members with the
same name.  But the abi_tag attribute still needs to affect explicit
specializations, as it applies to the name rather than any particular instance
of a template.

[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Feb  2 02:07:09 2018
New Revision: 257325

URL: https://gcc.gnu.org/viewcvs?rev=257325=gcc=rev
Log:
PR c++/84160 - ICE with nested variadic capture.

* lambda.c (is_capture_proxy_with_ref): New.
(insert_capture_proxy): Don't set DECL_CAPTURED_VARIABLE from a
COMPONENT_REF.
* expr.c (mark_use): Use is_capture_proxy_with_ref.
* constexpr.c (potential_constant_expression_1): Likewise.
* semantics.c (process_outer_var_ref): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/expr.c
trunk/gcc/cp/lambda.c
trunk/gcc/cp/semantics.c

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #25 from Jürgen Reuter  ---
The other errors actually appear in I/O procedures of external libraries that
we link to our code. It would be hard(er) to come up with a test case here.
Hope you can fix all of that, keeping fingers crossed.

[Bug c++/81716] Bogus -Wlto warning with forward-declared pointers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |DUPLICATE
  Known to fail||6.4.0, 7.3.0

--- Comment #3 from Martin Sebor  ---
I can confirm this with GCC 7 and 6 but not with GCC 8.  r257183 was the last
commit I see that dealt with the warning for bug 83954.  It also had to do with
arrays of pointers so based on that I'll resolve this as a duplicate of that
bug.  Please reopen if you have evidence it isn't the same thing.

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

[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||sgunderson at bigfoot dot com

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

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #24 from Jürgen Reuter  ---
Created attachment 43322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43322=edit
Additional failing test case (after the prelim. fix)

This is still lengthy, and I can reduce it further but maybe the error helps
you when you run it in the debugger. I get 
Running test: resonance_insertion_2seg_prod(64951,0x7fff9ae91340) malloc: ***
mach_vm_map(size=9223372036854779904) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10900d64c
#1  0x10900c9f3
#2  0x7fff620bcf59

[Bug c++/81714] incorrect location for uninitialised variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with 8, 7, and 6.

[Bug c++/81678] Variadic template parameters containing pointer to member function fail to be parsed unless name of the parameter is specified

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
GCC 8.0 prints the following error (please remember to include compiler
output):

pr81678.C:2:19: error: variable or field ‘f’ declared void
 void f (void (T::*...)())
   ^~~
pr81678.C:2:9: error: expected primary-expression before ‘void’
 void f (void (T::*...)())
 ^~~~
pr81678.C: In function ‘int main()’:
pr81678.C:14:3: error: ‘f’ was not declared in this scope
   f (::f);
   ^

Clang compiles it fine but MSVC and EDG don't.  EDG gives the following error:

$ eccp -A --c++17 pr81678.C
"pr81678.C", line 2: error: an unnamed parameter pack declaration cannot be
  parenthesized
  void f (void (T::*...)())
^

Based on [dcl.fct] of N4700 I suspect this may be an ambiguity in the grammar
that Clang handles more gracefully than other implementations but I'm not an
expert on the C++ grammar so I'll leave it to someone else to either confirm or
close.

[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=19808
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Bug 19808 is similar but not quite the same.  It (and its duplicates) asks for
a warning when an uninitialized member is used to initialized another.  This
one seems to be asking for a warning for members that are left uninitialized,
even when they are not used.  This would be a noisier warning that
-Wuninitialized so it would probably need its own option, but I think it would
useful nonetheless.

It's likely that there already is a request like this one but I can't find it. 
Let me confirm this in the meantime.

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

--- Comment #3 from Javier Serrano Polo  ---
Upstream wants to make multiarch harder; the patch will not be posted here.
Nevertheless, Adam, please answer to my previous question.

[Bug middle-end/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  The default constructor appears to be used in the definition of
fibonacci_heap::replace_key_data (fibonacci_node *node, K key, V *data):

  ...
  /* If we wanted to, we do a real increase by redeleting and
 inserting.  */
  if (node->compare_data (key) > 0)
{
  delete_node (node, false);

  node = new (node) fibonacci_node_t ();
  insert (node, key, data);

  return odata;


Having a test case showing what breaks because of it would provide motivation
to fix it.

[Bug tree-optimization/81600] tree-vect-loop.c:6075:22: runtime error: index -1 out of bounds for type 'tree_node *[3]'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I'm not having any luck reproducing it on trunk with 
gcc.c-torture/execute/pr68250.c testcase at -O3.  Can it still reproduced still
a problem and is the fix from comment #1 still needed or can this bug be
resolved?

[Bug c/84173] Support glibc multiarch interpreter names

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The ABI is fixed so we cannot change it.

[Bug tree-optimization/81603] Various compiler UB on very large constant offsets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Are the committed fixes enough to resolve the bug?

[Bug c/84174] FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Similar fail:
FAIL: c-c++-common/Wattributes.c  -Wc++-compat   (test for warnings, line 404)

[Bug c/84175] New: FAIL: c-c++-common/Warray-bounds-4.c -Wc++-compat strcpy (test for warnings, line 67)

[danglin at gcc dot gnu.org]

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

Bug ID: 84175
   Summary: FAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat
strcpy (test for warnings, line 67)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c: In function
'tes
t_memcpy_bounds_memarray_range':
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:47:3: warning:
'm
emcpy' offset [6, 8] from the object at 'ma' is out of the bounds of referenced
subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds]
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:48:3: warning:
'm
emcpy' offset [6, 10] from the object at 'ma' is out of the bounds of
referenced
 subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds]

PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat   (test for warnings, line
47
)
PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat   (test for warnings, line
48
)
XFAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat  strcpy (test for warnings,
line 66)
FAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat  strcpy (test for warnings,
line 67)
PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat  (test for excess errors)

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

Javier Serrano Polo  
changed:

   What|Removed |Added

 CC||adconrad at 0c3 dot net

--- Comment #1 from Javier Serrano Polo  ---
Adam, if you had to come up with multiarch interpreter names for traditional
architectures, which would be the proper place to discuss?

[Bug c/84174] New: FAIL: gcc.dg/Wattributes-6.c (test for warnings, line 404)

[danglin at gcc dot gnu.org]

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

Bug ID: 84174
   Summary: FAIL: gcc.dg/Wattributes-6.c  (test for warnings, line
404)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/Wattributes-6.c -fno-diagnostics-show-caret
-fdiagnostics
-color=never -Wall -Wattributes -ftrack-macro-expansion=0 -S -o Wattributes-6.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Wattributes-6.c:42:1: warning: 'packed'
a
ttribute ignored [-Wattributes]
[...]
FAIL: gcc.dg/Wattributes-6.c  (test for warnings, line 404)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 410)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 421)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 424)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 428)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 431)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 435)
PASS: gcc.dg/Wattributes-6.c  (test for warnings, line 439)
FAIL: gcc.dg/Wattributes-6.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Wattributes-6.c:404:1: error: alignment
for 'finline_hot_noret_align' must be at least 8

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
Updated patch with fixes for the false positives discussed in comment #12:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00076.html

[Bug c/84173] New: Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

Bug ID: 84173
   Summary: Support glibc multiarch interpreter names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net
  Target Milestone: ---

Preferred multiarch names refer to the /lib directory and are unique, e.g.
/lib/ld-linux-x86-64.so.2. Please consider accepting a future patch that
selects glibc multiarch names instead of traditional ones. It looks like these
multiarch names are yet to be decided.

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[paul.richard.thomas at gmail dot com]

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

--- Comment #23 from paul.richard.thomas at gmail dot com  ---
Hi Everybody,

I just got in from the lab.. Obviously, I will not be working on this
problem tonight!

I suspect that fact that I have had to pick out allocatable components
for special treatment is the smoking gun. I will be giving the large
chunk of specialised code devoted to allocatable components in
trans-array.c a good looking over tomorrow. Somewhere, a perfectly
good dtype is being overwirtten with zeros

Paul


On 1 February 2018 at 22:23, juergen.reuter at desy dot de
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
>
> --- Comment #22 from Jürgen Reuter  ---
> I'm actually running our code right now. It fixes _almost all_ of our unit and
> functional tests. There is still one failing unit test and at least one 
> failing
> functional test. Still waiting for the full results. Will try to add a
> reproducer for the test. For the unit test that is straightforward, for the
> functional test maybe not so much.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
This fixes almost all of our unit and functional test, but not all of them.
There are still 19 functional tests failing, all of them seem to have to do
with some sort of I/O . And one unit tests, which I cannot see what it directly
does. For the latter I could do a reproducer, however, but it might take me a
day or two.

[Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #48 from Aldy Hernandez  ---
Is this still an issue?

int t(void);
void tt(int);

void
f (int i, long *a, long *b)
{
  int sum = 0;
  for (; --i >=  0; a++, b++)
{
  b[i] = 0;
#define PART(I) if (t()) sum+=100+I;
  PART (1);
  PART (2);
  PART (3);
  PART (4);
  PART (5);
  PART (6);
  tt (sum);
}
}

For --target=arc-elf, I've done:

./cc1 a.c -fdump-tree-all -quiet -I/tmp -O3 -mcpu=arc700

The inner loop looks like this:
bl @t;1
tst_s r0,r0
bl.d @t;1
add1.ne r13,r13,51   ;; r13 += 51 << 1 (which is 102)
tst_s r0,r0
add.ne r13,r13,103
bl @t;1
tst_s r0,r0
bl.d @t;1
add3.ne r13,r13,13   ;; r13 += 13 << 3 (which is 104)
tst_s r0,r0
add.ne r13,r13,105

...
...

I do not see any of the long sequences of integer constants on the stack, or
stack shuffling as was originally reported.

If I understand the first comment, i686 is presumably broken, but I see:

callt
testl   %eax, %eax
je  .L4
addl$101, %ebx
.L4:
callt
testl   %eax, %eax
je  .L5
addl$102, %ebx
.L5:
callt
testl   %eax, %eax
je  .L6
addl$103, %ebx
...

which doesn't look like long sequence of integers being pushed on the stack
either.

The PRE dump for arc700 doesn't show anything weird, or any combined ORed
values.

Has PRE changed and moved this bug around?  Am I missing something?

[Bug c++/81589] Possible False-Positive with decltype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||msebor at gcc dot gnu.org
  Known to work||8.0
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0

--- Comment #2 from Martin Sebor  ---
Confirmed with GCC 6 and 7.  GCC 8 compiles the translation unit without an
error.  Bisection points to r248153 as the revision that made it work.

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #22 from Jürgen Reuter  ---
I'm actually running our code right now. It fixes _almost all_ of our unit and
functional tests. There is still one failing unit test and at least one failing
functional test. Still waiting for the full results. Will try to add a
reproducer for the test. For the unit test that is straightforward, for the
functional test maybe not so much.

[Bug rtl-optimization/84123] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:908, alpha linux.

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb  1 22:22:03 2018
New Revision: 257318

URL: https://gcc.gnu.org/viewcvs?rev=257318=gcc=rev
Log:
PR rtl-optimization/84123
* combine.c (change_zero_ext): Check if hard register satisfies
can_change_dest_mode before calling gen_lowpart_SUBREG.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/combine.c

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> A temporary fix:
> ...

Preliminary tests look good! Thanks.

[Bug target/84172] option "-O3" create slower code

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

  Known to work||7.2.0
  Known to fail||5.5.0, 6.4.0

--- Comment #8 from Marc Glisse  ---
As far as I can tell, this is already fixed in gcc-7.

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  ---
% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/assumed_rank_7.f90
-fsanitize=address
% ./a.out
=
==77100==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffeed4a1f28 at pc 0x000102a2f4b4 bp 0x7ffeed4a1b70 sp 0x7ffeed4a1320
READ of size 400 at 0x7ffeed4a1f28 thread T0
#0 0x102a2f4b3 in wrap_memmove (libasan.5.dylib:x86_64+0x184b3)
#1 0x102760657 in bar.3811 (a.out:x86_64+0x13657)
#2 0x10275efa3 in MAIN__ (a.out:x86_64+0x11fa3)
#3 0x10276076e in main (a.out:x86_64+0x1376e)
#4 0x7fff7011c114 in start (libdyld.dylib:x86_64+0x1114)

Address 0x7ffeed4a1f28 is located in stack of thread T0 at offset 312 in frame
#0 0x10275e0a8 in MAIN__ (a.out:x86_64+0x110a8)

  This frame has 5 object(s):
[32, 48) 'FRAME.13'
[96, 184) 'at'
[224, 312) 'atmp.6'
[352, 760) 'class.4' <== Memory access at offset 312 partially underflows
this variable
[800, 1208) 'class.5'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
(libasan.5.dylib:x86_64+0x184b3) in wrap_memmove
Shadow bytes around the buggy address:
  0x1fffdda94390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffdda943a0: 00 00 00 00 00 00 00 00 00 f2 f3 f3 f3 f3 00 00
  0x1fffdda943b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x1fffdda943c0: f1 f1 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00
  0x1fffdda943d0: 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00
=>0x1fffdda943e0: 00 00 00 00 00[f2]f2 f2 f2 f2 00 00 00 00 00 00
  0x1fffdda943f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffdda94400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffdda94410: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2
  0x1fffdda94420: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffdda94430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==77100==ABORTING

[Bug c++/81475] missing -Wsequence-point on a self-referential array access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||msebor at gcc dot gnu.org
Summary|Missing "undefined  |missing -Wsequence-point on
   |behavior" warning   |a self-referential array
   ||access
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
You can download draft revisions of the C++ standard from the ISO/IEC WG21 C++
site: http://www.open-std.org/jtc1/sc22/wg21
But please keep in mind this is not the right place to ask for language
reference manuals.

That said, I can confirm that the test case has undefined behavior and should
trigger a -Wsequence-point warning.  Here's a smaller C/C++ test case the
demonstrates the same limitation.

No GCC release diagnosed this code so this is not a regression.


int f (void)
{
  int ar[2], *a = ar;

  a[0] = 1;

  return a[(*a)++ - 1];   // missing -Wsequence-point
}

[Bug target/84172] option "-O3" create slower code

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

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

--- Comment #7 from Andreas Otto  ---
Created attachment 43321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43321=edit
cat /proc/cpuinfo

[Bug target/84172] option "-O3" create slower code

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Can you also send the output of:
cat /proc/cpuinfo
?

[Bug target/84172] option "-O3" create slower code

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

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

--- Comment #5 from Andreas Otto  ---
Created attachment 43320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43320=edit
output of command you requested…

gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v

[Bug target/84172] option "-O3" create slower code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andreas Otto from comment #3)
> send me the command that I should run…

I did:
(In reply to Andrew Pinski from comment #2)
> gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[renlin at gcc dot gnu.org]

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

--- Comment #5 from Renlin Li  ---
Author: renlin
Date: Thu Feb  1 21:33:05 2018
New Revision: 257315

URL: https://gcc.gnu.org/viewcvs?rev=257315=gcc=rev
Log:
[PR83370][AARCH64]Use tighter register constraint for sibcall patterns.

gcc/

backport from mainline
2018-02-01  Renlin Li  

PR target/83370
* config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle
TAILCALL_ADDR_REGS.
(aarch64_register_move_cost): Likewise.
* config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS.
(REG_CLASS_NAMES): Likewise.
(REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS. Remove IP registers.
* config/aarch64/aarch64.md (Ucs): Update register constraint.

gcc/testsuite/

backport from mainline
2018-02-01  Richard Sandiford  

PR target/83370
* gcc.target/aarch64/pr83370.c: New.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/pr83370.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/aarch64.c
branches/gcc-6-branch/gcc/config/aarch64/aarch64.h
branches/gcc-6-branch/gcc/config/aarch64/constraints.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/84172] option "-O3" create slower code

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

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

--- Comment #3 from Andreas Otto  ---
send me the command that I should run…

[Bug target/84172] option "-O3" create slower code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-suse-linux
  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
Can you provide the output of the following command:
gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c -v

We need to know what -march=native expands to.

[Bug c/84172] option "-O3" create slower code

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

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

--- Comment #1 from Andreas Otto  ---
forget last "}"

[Bug c/84172] New: option "-O3" create slower code

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

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

Bug ID: 84172
   Summary: option "-O3" create slower code
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aotto1...@t-online.de
  Target Milestone: ---

here my test…

#:~/test> make test
gcc-5 -march=native -mtune=native -g -static -O0 -o test.0 main.c 
gcc-5 -march=native -mtune=native -g -static -O1 -o test.1 main.c 
gcc-5 -march=native -mtune=native -g -static -O2 -o test.2 main.c 
gcc-5 -march=native -mtune=native -g -static -O3 -o test.3 main.c 
for t in test.0 test.1 test.2 test.3; do ./$t; done
./test.0 → T1 = 673.300964 ms → HI = 0x1, LO = 0
./test.0 → T2 = 506.130981 ms → HI = 0x1, LO = 0
./test.1 → T1 = 136.671005 ms → HI = 0x1, LO = 0
./test.1 → T2 = 139.194000 ms → HI = 0x1, LO = 0
./test.2 → T1 = 139.225998 ms → HI = 0x1, LO = 0
./test.2 → T2 = 139.294998 ms → HI = 0x1, LO = 0
./test.3 → T1 = 217.908997 ms → HI = 0x1, LO = 0
./test.3 → T2 = 231.663010 ms → HI = 0x1, LO = 0

#:~/test> gcc-5 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp
--disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux) 
dev1usr@linux02:~/test> Selected  "main.c:40 [main]"

#my code

==
#include 
#include 
#include 
#include 

#define SIZE1

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#   define  HI  1
#   define  LO  0
#else
#   define  HI  0
#   define  LO  1
#endif

int main(int argc, char *argv[])
{
int i;
clock_t t1, t2;

// T1
if (1) {
uint64_ta = 0x;
uint64_tb = 0xfffe;
unsigned __int128   r;
t1 = clock();

for (i=0; i>64);
b -= (uint64_t) (r>>0);
} else {
a -= (uint64_t) (r>>64);
b += (uint64_t) (r>>0);
}
}

t2 = clock();
float diff = ((float)(t2 - t1) / (float)CLOCKS_PER_SEC ) * 1000;
printf("%-20s → T1 = %f ms → HI = %#x, LO = %#x\n", argv[0], diff, a,
b);
}

// T2
if (1) {
typedef union valU {
unsigned __int128   ui128;
uint64_tui64[2]  ;
} valU_t;

uint64_ta = 0x;
uint64_tb = 0xfffe;
valU_t  r;

t1 = clock();

for (i=0; i

[Bug c++/83268] [7 Regression] internal compiler error: in lambda_expr_this_capture, at cp/lambda.c:785

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||dmalcolm at gcc dot gnu.org
Summary|internal compiler error: in |[7 Regression] internal
   |lambda_expr_this_capture,   |compiler error: in
   |at cp/lambda.c:785  |lambda_expr_this_capture,
   ||at cp/lambda.c:785
 Ever confirmed|0   |1

--- Comment #4 from David Malcolm  ---
Confirmed that this ICEs gcc 7 (but trunk and gcc 6 don't ICE).

ICE is here in lambda_expr_this_capture:

784   gcc_assert (TYPE_MAIN_VARIANT (TREE_TYPE (current_class_ref))

(gdb) call debug_tree (cfun->language->x_current_class_ref)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x70245888
fields 
used unsigned nonlocal decl_7 DI file /tmp/test.C line 9 col 11
size  unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain > context 
full-name "const struct X::operator()()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this  reference_to_this
>
readonly
arg 0 
unsigned type_6 DI size  unit size

align 64 symtab 0 alias set -1 canonical type 0x70245bd0>
readonly
arg 0 
readonly used unsigned DI file /tmp/test.C line 8 col 25 size
 unit size 
align 64 context  arg-type
 chain >>>

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[renlin at gcc dot gnu.org]

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

--- Comment #4 from Renlin Li  ---
Author: renlin
Date: Thu Feb  1 21:09:06 2018
New Revision: 257314

URL: https://gcc.gnu.org/viewcvs?rev=257314=gcc=rev
Log:
[PR83370][AARCH64]Use tighter register constraint for sibcall patterns.

gcc/

backport from mainline
2018-02-01  Renlin Li  

PR target/83370
* config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle
TAILCALL_ADDR_REGS.
(aarch64_register_move_cost): Likewise.
* config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS.
(REG_CLASS_NAMES): Likewise.
(REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to
TAILCALL_ADDR_REGS. Remove IP registers.
* config/aarch64/aarch64.md (Ucs): Update register constraint.

gcc/testsuite/

backport from mainline
2018-02-01  Richard Sandiford  

PR target/83370
* gcc.target/aarch64/pr83370.c: New.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr83370.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/aarch64/aarch64.c
branches/gcc-7-branch/gcc/config/aarch64/aarch64.h
branches/gcc-7-branch/gcc/config/aarch64/constraints.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #18 from Douglas Mencken  ---
(In reply to Douglas Mencken from comment #17)
> diff of libgcc/unwind-dw2.c between 6.4 and 7.1
> 
Reverting this file doesn’t help

[Bug c++/84125] [8 Regression] ICE in generic lambda when static_assert argument is implicitly converted to bool

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/84125] [8 Regression] ICE in generic lambda when static_assert argument is implicitly converted to bool

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Feb  1 20:32:33 2018
New Revision: 257311

URL: https://gcc.gnu.org/viewcvs?rev=257311=gcc=rev
Log:
PR c++/84125
* typeck.c (build_address): Relax the assert when
processing_template_decl.

* g++.dg/cpp1y/lambda-generic-84125.C:New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-84125.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/33699] [6/7/8 regression] missing optimization on const addr area store

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-04 00:00:00 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #25 from Aldy Hernandez  ---
(In reply to Martin Sebor from comment #23)
> No progress in GCC 7.0 which emits the following code for powerpc64le at -O2
> (-Os is slightly different but the same size):

Same thing on mainline still.

[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Tobias Burnus from comment #0)

> f) The following two examples are invalid - but seemingly gfortran does not
> check the string length of DT character components:
> 
> module mytypes
>use ISO_C_BINDING
>implicit none
>private
>public T
>type, bind(C) :: T
>   character(len=2,kind=C_CHAR) item ! INVALID length: 2
>end type T
> end module mytypes
> 
> module mytypes
>use ISO_C_BINDING
>implicit none
>private
>public T
>type, bind(C) :: T
>   character(len=*,kind=C_CHAR) item*(2) ! INVALID length of 2
>end type T
> end module mytypes

This has been fixed with PR84073.

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #25 from Thomas Koenig  ---
Strange, I don't see it; what I get is

ig25@linux-d6cw:/tmp> gfortran -g -fsanitize=address assumed_rank_7.f90 
ig25@linux-d6cw:/tmp> ./a.out

=
==21952==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fa951f6cf30 in __interceptor_malloc
../../../../trunk/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x4013fc in MAIN__ /tmp/assumed_rank_7.f90:18
#2 0x40333b in main /tmp/assumed_rank_7.f90:25
#3 0x7fa950ec3f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)

SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

... but the memory leak from an allocate in the main program is
something else

I also don't see anything with valgrind.

Can you post your output?

[Bug target/29256] [6/7/8 regression] loop performance regression

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2013-12-09 04:50:02 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #65 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #45)
> This problem still exists and can be seen by making the arrays external and
> using -fno-tree-loop-distribute-patterns.
> 
> .L2:
> evlddx 31,10,9
> addi 7,9,8
> addi 0,9,16
> addi 11,9,24
> addi 3,9,32
> evstddx 31,8,9
> addi 4,9,40
> evlddx 31,10,7
> addi 5,9,48
> addi 6,9,56
> evlddx 12,10,6
> addi 9,9,64
> evstddx 31,8,7
> evlddx 7,10,0
> evstddx 7,8,0
> evlddx 0,10,11
> evstddx 0,8,11
> evlddx 11,10,3
> evstddx 11,8,3
> evlddx 3,10,4
> evstddx 3,8,4
> evlddx 4,10,5
> evstddx 4,8,5
> evstddx 12,8,6
> bdnz .L2
> evldd 31,8(1)
> addi 1,1,16
> blr

Still a problem.  I get the same code Jeff got for comment 45.

[Bug c++/84171] [8 Regression] ICE with -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-01
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll take a look.

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
-fsanitize=address gives:


==21482==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00402624 at pc 0x7f6d755ede76 bp 0x7ffed65778c0 sp 0x7ffed6577070
READ of size 5 at 0x00402624 thread T0
#0 0x7f6d755ede75 in __interceptor_memmove
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720
#1 0x40134d in gfcbug145 /tmp/foo.f90:14
#2 0x402323 in main /tmp/foo.f90:17
#3 0x7f6d745f6f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#4 0x400c89 in _start (/tmp/a.out+0x400c89)

0x00402624 is located 60 bytes to the left of global variable '*.LC6'
defined in 'foo.f90' (0x402660) of size 5
0x00402624 is located 0 bytes to the right of global variable '*.LC5'
defined in 'foo.f90' (0x402620) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:720
in __interceptor_memmove
Shadow bytes around the buggy address:
  0x80078470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078490: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9
  0x800784a0: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x800784b0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
=>0x800784c0: f9 f9 f9 f9[04]f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
  0x800784d0: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
  0x800784e0: f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9 00 00 00 00
  0x800784f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb

This is the   print *,  pack (obstyp% name, mask) line.

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #24 from Dominique d'Humieres  ---
Still failing at r257125 when the test is compiled with -fsanitize=address.

[Bug c++/84171] New: [8 Regression] ICE with -Wsign-compare

[reichelt at gcc dot gnu.org]

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

Bug ID: 84171
   Summary: [8 Regression] ICE with -Wsign-compare
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk if compiled
with -Wsign-compare (included in -Wall):

=
bool foo (char c)
{
  const int i = 0 = 0;
  return c = i;
}
=

bug.cc: In function 'bool foo(char)':
bug.cc:3:21: error: lvalue required as left operand of assignment
   const int i = 0 = 0;
 ^
bug.cc:4:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in warn_for_sign_compare, at c-family/c-warn.c:1926
   return c = i;
  ^
0x788cda tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9375
0x689286 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3255
0x689286 warn_for_sign_compare(unsigned int, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_code)
../../gcc/gcc/c-family/c-warn.c:1926
0x9dae42 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5324
0x86e4c1 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:812
0x86fa1e cp_convert(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:623
0x86fa1e cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/gcc/cp/cvt.c:642
0x81de78 convert_like_real
../../gcc/gcc/cp/call.c:7111
0x81eb5f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:10574
0x9e22aa check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9371
0x99cf2e finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:890
0x91a054 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12368
0x91a054 cp_parser_statement
../../gcc/gcc/cp/parser.c:10773
0x91add0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11218
0x91aea7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11172
0x931630 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21710
0x931630 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21747
0x931ee0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26648
0x932bf7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26564
0x932bf7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19436
Please submit a full bug report, [etc.]

Jason, the regression started with your patch
https://gcc.gnu.org/viewcvs?rev=249083=gcc=rev

Would you mind having a look?

[Bug fortran/79886] [6 Regression] ICE in pp_format, at pretty-print.c:681

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #9 from Thomas Koenig  ---
Any plans to backport to gcc-6?

If not, I think we can close this.

[Bug fortran/59781] [6 Regression] [F03] Incorrect initialisation of derived type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||tkoenig at gcc dot gnu.org

--- Comment #17 from Thomas Koenig  ---
(In reply to janus from comment #15)
> (In reply to Dominique d'Humieres from comment #14)
> > AFAICT the above piece of dump appeared between revisions r241883
> > (2016-11-06, none) and r241924 (2016-11-07, present), likely r241885.
> 
> Yes, very likely. Thanks for pinpointing this, Dominique.
> 
> 
> > If I
> > am correct, I am not sure that the commit qualifies for back port.
> 
> Andre, do you think it would be reasonable to backport r241885?

I think this is a bit too invasive.

My vote would be to close this as FIXED.

[Bug c++/84160] [8 Regression] ICE on valid C++11 code: in build_capture_proxy, at cp/lambda.c:446

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb  1 19:47:15 2018
New Revision: 257310

URL: https://gcc.gnu.org/viewcvs?rev=257310=gcc=rev
Log:
PR 83975 Associate target with non-constant character length

When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-02-01  Janne Blomqvist  

PR 83975
PR 83344
* resolve.c (resolve_assoc_var): Generate an error if
target length unknown.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb  1 19:47:15 2018
New Revision: 257310

URL: https://gcc.gnu.org/viewcvs?rev=257310=gcc=rev
Log:
PR 83975 Associate target with non-constant character length

When associating a variable of type character, if the length of the
target isn't known at compile time, generate an error. See PR 83344
for more details.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-02-01  Janne Blomqvist  

PR 83975
PR 83344
* resolve.c (resolve_assoc_var): Generate an error if
target length unknown.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[aldyh at gcc dot gnu.org]

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

--- Comment #32 from Aldy Hernandez  ---
errr, slightly LESS worse code

[Bug fortran/60576] [6/7/8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #23 from Thomas Koenig  ---
I just tested it with current trunk and gcc 7.  It is fixed.

Closing.

[Bug middle-end/28831] [6/7/8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2010-01-17 13:10:45 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #31 from Aldy Hernandez  ---
Still a problem, though we now generate slightly worse code by using rep;movsl
instead of a memcpy:

movl%esp, %esi
subl$12, %esp
pushl   %esi
callf
subl$3988, %esp
movl$1000, %ecx
movl%esp, %edi
rep; movsl
callg

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #26 from Thomas Koenig  ---
I have a patch.

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #54 from Aldy Hernandez  ---
Results from comparing trunk and gcc-4_6-branch on (average of 7 runs):

Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz

4.6.x
-O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc
atlasmm   60   1000   0.100 5415.4

-O2 -ffast-math -msse4.1 -DTYPE=double
atlasmm   60   1000   0.082 4797.4

Performance penalty: 12.9%

trunk:
-O2 -ffast-math -msse4.1 -DTYPE=double -fno-tree-reassoc
atlasmm   60   1000   0.105 5217.0

-O2 -ffast-math -msse4.1 -DTYPE=double
atlasmm   60   1000   0.108 4773.0

Performance change: 9.3%

It looks like the penalty for using fno-tree-reassoc now is even less than it
was in 4.6.x.  The original report was for a 30% drop.

Has this been fixed, or am I missing something? (different flags for my 4.6
run?  Is the 4.6 branch not a suitable representation of the 4.6.2 compiler
against which this bug was originally filed against?)

[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #17 from Douglas Mencken  ---
diff of libgcc/unwind-dw2.c between 6.4 and 7.1

--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -1,5 +1,5 @@
 /* DWARF2 exception handling and frame unwind runtime interface routines.
-   Copyright (C) 1997-2016 Free Software Foundation, Inc.
+   Copyright (C) 1997-2017 Free Software Foundation, Inc.

This file is part of GCC.

@@ -136,6 +136,8 @@ struct _Unwind_Context
 #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
   /* Context which has version/args_size/by_value fields.  */
 #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+  /* Bit reserved on AArch64, return address has been signed with A key.  */
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
   _Unwind_Word flags;
   /* 0 for now, can be increased when further fields are added to
  struct _Unwind_Context.  */
@@ -1185,6 +1187,11 @@ execute_cfa_program (const unsigned char *insn_ptr,
  break;

case DW_CFA_GNU_window_save:
+#if defined (__aarch64__) && !defined (__ILP32__)
+ /* This CFA is multiplexed with Sparc.  On AArch64 it's used to
toggle
+return address signing status.  */
+ fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
+#else
  /* ??? Hardcoded for SPARC register window configuration.  */
  if (__LIBGCC_DWARF_FRAME_REGISTERS__ >= 32)
for (reg = 16; reg < 32; ++reg)
@@ -1192,6 +1199,7 @@ execute_cfa_program (const unsigned char *insn_ptr,
fs->regs.reg[reg].how = REG_SAVED_OFFSET;
fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
  }
+#endif
  break;

case DW_CFA_GNU_args_size:
@@ -1513,10 +1521,15 @@ uw_update_context (struct _Unwind_Context *context,
_Unwind_FrameState *fs)
stack frame.  */
 context->ra = 0;
   else
-/* Compute the return address now, since the return address column
-   can change from frame to frame.  */
-context->ra = __builtin_extract_return_addr
-  (_Unwind_GetPtr (context, fs->retaddr_column));
+{
+  /* Compute the return address now, since the return address column
+can change from frame to frame.  */
+  context->ra = __builtin_extract_return_addr
+   (_Unwind_GetPtr (context, fs->retaddr_column));
+#ifdef MD_POST_EXTRACT_FRAME_ADDR
+  context->ra = MD_POST_EXTRACT_FRAME_ADDR (context, fs, context->ra);
+#endif
+}
 }

 static void
@@ -1550,6 +1563,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
   void *outer_cfa, void *outer_ra)
 {
   void *ra = __builtin_extract_return_addr (__builtin_return_address (0));
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+  ra = MD_POST_EXTRACT_ROOT_ADDR (ra);
+#endif
   _Unwind_FrameState fs;
   _Unwind_SpTmp sp_slot;
   _Unwind_Reason_Code code;
@@ -1586,6 +1602,9 @@ uw_init_context_1 (struct _Unwind_Context *context,
  initialization context, then we can't see it in the given
  call frame data.  So have the initialization context tell us.  */
   context->ra = __builtin_extract_return_addr (outer_ra);
+#ifdef MD_POST_EXTRACT_ROOT_ADDR
+  context->ra = MD_POST_EXTRACT_ROOT_ADDR (context->ra);
+#endif
 }

 static void _Unwind_DebugHook (void *, void *)
@@ -1608,6 +1627,21 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
 #endif
 }

+/* Frob exception handler's address kept in TARGET before installing into
+   CURRENT context.  */
+
+static inline void *
+uw_frob_return_addr (struct _Unwind_Context *current
+__attribute__ ((__unused__)),
+struct _Unwind_Context *target)
+{
+  void *ret_addr = __builtin_frob_return_addr (target->ra);
+#ifdef MD_POST_FROB_EH_HANDLER_ADDR
+  ret_addr = MD_POST_FROB_EH_HANDLER_ADDR (current, target, ret_addr);
+#endif
+  return ret_addr;
+}
+
 /* Install TARGET into CURRENT so that we can return to it.  This is a
macro because __builtin_eh_return must be invoked in the context of
our caller.  */
@@ -1616,7 +1650,7 @@ _Unwind_DebugHook (void *cfa __attribute__
((__unused__)),
   do   \
 {  \
   long offset = uw_install_context_1 ((CURRENT), (TARGET));   
\
-  void *handler = __builtin_frob_return_addr ((TARGET)->ra);   \
+  void *handler = uw_frob_return_addr ((CURRENT), (TARGET));   \
   _Unwind_DebugHook ((TARGET)->cfa, handler);  \
   __builtin_eh_return (offset, handler);   \
 }  \

[Bug web/84167] bugzilla should have a "next bug" button

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Frédéric Buclin  ---
(In reply to Richard Biener from comment #0)
> I'm currently using the web gcc-bug mailinglist archive to cycle through all
> new bugs each morning.

Instead of doing this, you should click the "Bugs reported in the last 24
hours" link on the Bugzilla home page. This will generate a list, and the
Prev/Next link will automatically appear on each bug page.

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Feb  1 18:44:41 2018
New Revision: 257307

URL: https://gcc.gnu.org/viewcvs?rev=257307=gcc=rev
Log:
PR c++/84126 - ICE with variadic generic lambda

PR c++/84036
PR c++/82249
* pt.c (tsubst_pack_expansion): Handle function parameter_packs in
PACK_EXPANSION_EXTRA_ARGS.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug tree-optimization/21485] [6/7/8 Regression] missed load PRE, PRE makes i?86/7/8 suck

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2011-02-06 23:54:40 |2018-2-1
 CC||aldyh at gcc dot gnu.org

--- Comment #65 from Aldy Hernandez  ---
Still a problem.  I get a score of 1750.7 on a:

model name  : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht
   |ml  |ml
 Resolution|--- |FIXED

--- Comment #7 from Peter Bergner  ---
Fixed on trunk.  Will wait a few days and then will back port it to FSF 7.

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2018-01/msg02059.ht |patches/2018-01/msg02469.ht
   |ml  |ml
 Resolution|--- |FIXED

--- Comment #12 from Peter Bergner  ---
Fixed on trunk.  Will wait a few days and then will back port it to FSF 7.

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
Author: bergner
Date: Thu Feb  1 18:26:51 2018
New Revision: 257305

URL: https://gcc.gnu.org/viewcvs?rev=257305=gcc=rev
Log:
PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
#include "opts.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/driver-rs6000.c

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Thu Feb  1 18:26:51 2018
New Revision: 257305

URL: https://gcc.gnu.org/viewcvs?rev=257305=gcc=rev
Log:
PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
#include "opts.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/driver-rs6000.c

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I think combine is at fault here. The faulty assembly is:
foo:
ldrbw0, [sp, 16]
neg x0, x0, lsl 4
csetm   x3, ne


The csetm is supposed to set the top 64 bits of the TImode value (in x3) to
ones, based on the CC content, but the CC-setting instruction has disappeared.
The correct sequence (by hacking the assembly output and checking that it
passes) would be:
ldrbw0, [sp, 16]
negs x0, x0, lsl 4 // NEG sets the condition code as well.
csetm   x3, ne

There's a few complex combinations going on, but before combine we have (some
RTL edited to tone down verbosity):

(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(insn 19 17 20 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 85)
(reg:DI 105)))
(set (reg:DI 90)
(minus:DI (reg:DI 85)
(reg:DI 105)))
]) "wrong.c":9 270 {subdi3_compare1}

(insn 20 19 23 2 (set (reg:DI 91)
(minus:DI (minus:DI (reg:DI 85)
(reg:DI 87))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 327 {*subdi3_carryin}

where insn 19 sets the CC and insn 20 uses it. After combine we have:
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(note 19 17 20 2 NOTE_INSN_DELETED)
(insn 20 19 23 2 (set (reg:DI 91)
(neg:DI (ne:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 441 {cstoredi_neg}

with insn 20 still using the CC but the CC setting instruction being deleted.
There's a number of exciting things going on in combine so my analysis may not
be entirely accurate, but I see things like:
Trying 14 -> 20:
   14: r87:DI=r103:DI 0>>0x3c
   20: r91:DI=r85:DI-r87:DI-ltu(cc:CC,0)
  REG_DEAD r87:DI
  REG_DEAD r85:DI
  REG_DEAD cc:CC
  REG_EQUAL -r87:DI-ltu(cc:CC,0)
Successfully matched this instruction:
(set (reg:DI 91)
(neg:DI (ltu:DI (reg:CC 66 cc)
(const_int 0 [0]

and

Trying 19 -> 26:
   19: cc:CC=cmp(r103:DI,0)
  REG_DEAD r103:DI
   26:
{cc:CC_C=zero_extend(r90:DI)+zero_extend(r111:DI)!=zero_extend(r90:DI+r111:DI);r95:DI=r90:DI+r111:DI;}
  REG_DEAD r111:DI
  REG_DEAD r90:DI
Successfully matched this instruction:
(parallel [
(set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 90))
(zero_extend:TI (reg:DI 111 [ b ])))
(zero_extend:TI (plus:DI (reg:DI 90)
(reg:DI 111 [ b ])
(set (reg:DI 95)
(plus:DI (reg:DI 90)
(reg:DI 111 [ b ])))
])
deferring deletion of insn with uid = 19.

So insn 19 ends up being combined into a subsequent instruction and ends up
being deleted even though insn 20 depends on it's CC-setting effects

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-01
 CC||ktkachov at gcc dot gnu.org
  Known to work||7.3.1
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug debug/83935] DWARF for a variant part is incorrect

[derodat at adacore dot com]

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

--- Comment #6 from Pierre-Marie de Rodat  ---
Just got a notification that it got assigned issue #180123.1:
http://dwarfstd.org/ShowIssue.php?issue=180123.1

[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #4)
> Is this valid C++? bar.mem is non-POD and is already constructed and it
> seems fishy to placement new it to something different.

It's very fishy; the code should use aligned_storage rather a different
non-trivial type.  My old proposed resolution for wg21.link/cwg1116 would have
clarified that this is undefined, and might still happen to resolve
wg21.link/cwg1027 , but it hasn't been accepted yet.

On the other hand, it is careful to use the pointer returned from placement new
rather than a pointer derived from mem, and it seems like we ought to use the
information from placement new to guide devirtualization.

So...sketchy code in a volatile area of semantics, but it seems like we could
get it right without breaking important optimizations.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed in trunk.

[Bug libstdc++/84170] New: std::find_if performance issues

[barannikov88 at gmail dot com]

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

Bug ID: 84170
   Summary: std::find_if performance issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barannikov88 at gmail dot com
  Target Milestone: ---

Hi,

There are two internal implementations of std::find_if in bits/stl_algo.h. One
is for the input iterator case, the other is for the random access iterator
case. They are almost identical, except that the second is somewhat
"optimized".

>  /// This is an overload used by find algos for the Input Iterator case.
>  template
>inline _InputIterator
>__find_if(_InputIterator __first, _InputIterator __last,
> _Predicate __pred, input_iterator_tag)
>{
>  while (__first != __last && !__pred(__first))
>   ++__first;
>  return __first;
>}
>
>  /// This is an overload used by find algos for the RAI case.
>  template
>_RandomAccessIterator
>__find_if(_RandomAccessIterator __first, _RandomAccessIterator __last,
> _Predicate __pred, random_access_iterator_tag)
>{
>  typename iterator_traits<_RandomAccessIterator>::difference_type
>   __trip_count = (__last - __first) >> 2;
>
>  for (; __trip_count > 0; --__trip_count)
>   {
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>
> if (__pred(__first))
>   return __first;
> ++__first;
>   }
>
>  switch (__last - __first)
>   {
>   case 3:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 2:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 1:
> if (__pred(__first))
>   return __first;
> ++__first;
>   case 0:
>   default:
> return __last;
>   }
>}

Manual unrolling increases the code size and reduces the chances of this
function to be inlined. Inlining of this function is critical because it can
contain indirect calls to the predicate function, and inlining can change this
calls to direct improving performance.

I would suggest to revert manual unrolling and let the compiler decide which
optimization steps should be taken.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez  ---
Author: aldyh
Date: Thu Feb  1 17:12:28 2018
New Revision: 257304

URL: https://gcc.gnu.org/viewcvs?rev=257304=gcc=rev
Log:
PR target/84089
* config/pa/predicates.md (base14_operand): Handle E_VOIDmode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/predicates.md

[Bug c/84166] Wrong warning message emitted for loss of qualifiers

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
It's not confused.  It's saying that it's type-safe to convert 
"uint32_t **" to "volatile uint32_t *const *", but not to convert it to 
"volatile uint32_t *".

http://c-faq.com/ansi/constmismatch.html

[Bug target/84169] New: [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[zsojka at seznam dot cz]

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

Bug ID: 84169
   Summary: [8 Regression] wrong code with u128 multiplication
result at aarch64 -O
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 43319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43319=edit
reduced testcase

Output:
$ aarch64-unknown-linux-gnu-gcc testcase.c -static -O
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The most-significant 64bit are zeros, but should be ones.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-257303-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-257303-checking-yes-rtl-df-extra-aarch64
Thread model: posix
gcc version 8.0.1 20180201 (experimental) (GCC)

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I tested the modified C++ 11 example below with Clang, EDG, GCC, ICC, and MSVC.
 Of these, only MSVC implements the behavior I expect and doesn't warn.  The
others do.  (I verified that MSVC does support the attribute.)

Still, given that it's obviously meaningful to define a specialization that
does return, treating it as noreturn based on the definition of the primary is
incorrect.

Given the difference among implementations I think the standard ought to be
clarified which of the two is intended.

(See https://godbolt.org/g/sYPbD2 for Clang and MSVC output.)

template 
[[noreturn]] T
g (T) { throw "not implemented"; }

template <> int
g (int) { return 0; }

int h (int i)
{
  return g (i);
}

Your Weekly Breeze - February. 01 - February. 07

[Oasis Living Magazine]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlptrack7.com/zwbctq



Having problems viewing  Weekly Breeze Click here (
http://myoasisliving.com/weekly_breeze/weekly_breeze.php ).

>> ( y )

-->

Feeling bloated after too much turkey and plates of mince pies? Get
into the shape of your life in 2018 with a new fitness regime – here
are some helpful expert tips >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/b53a230d6e6d918b0a7f1526b2dedefa
)

The end of last year saw the 21st Faldo Series Grand Final tee up
in Al Ain’s AESGC, bringing Sir Nick himself to the greens. Oasis
Living was lucky enough to have a chat with a living legend >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/fac8c74f2e95c9cb9c7741faf6748425
)

Al Ain Rugby Club activities in full swing >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/2d6476579c954312447ad6df5fb08e4c
)

Abu Dhabi set to host over 4,000 tri-athletes on one of the most
unique triathlon courses in the world >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/36d37ef8f848677bebb848d561055902
)

A once-in-a-lifetime opportunity bounces in for youth basketball
players worldwide >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/4fea2c60a18b5d7a466458f897ede786
)

Eighth edition of Abu Dhabi’s famed community sporting event to
take place in February 2018 >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/1df55ebf7501156898d6b16f4e415cc8
)

breeze@ myoasisliving.com for your chance to win aHanayen gift voucher
in Bawadi Mall worth Dh100. To win, simply email your complete name
and indicate Hanayenin the subject and you will qualify for a random
draw.

*If you win, you have 30 days to pick up your prize. If your prize is
not collected within 30 days of notification, it will be cancelled.
Participants who have won before are not eligible to win again within
90 days after winning

-->
www.nascintl.com.

Al Nada Beauty Salon will be having a 50% discount on beauty and hair
services for the first 10 days of Ramadan. Al Nada Beauty Salon
timings will be 10:30 a.m. until 2 p.m. and 8 p.m. until 12 a.m. For
appointments and inquiries call 03-7664017.

-->

Money matters
Looking to create a financial plan for 2018 but don’t know where to
start? Oasis Living chats with expert Catalin Voicu for some insights
– as VAT rolls into the UAE >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/710718018521202fc85448c2b2c1976f
)

What’s hot in health?
Abu Dhabi’s Intercare Wellness Consultants, Dr Nas Al-Jafari and Dr
Mourad Habib, predict some of the wellness trends you will be seeing
everywhere this year >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/46e5535e8caf136bbebd41547cb67aa1
)

What to expect in 2018
Six new things coming to the UAE this year >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/9183cbcbf2b3187e12154b1401ef156b
)

2017 in search
Google releases most trending searches in the UAE of last year >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/175b84862b37613ad8bcd2a6b8b19a56
)

Greener pastures
GCC's first vertical farm launches in Dubai >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/15d9bb997af04708d42e8499fe699a9b
)

Omar Abdulrahman says Al Ain target three points against Al Jazira 'to
get back on a better footing'

Al Ain are out to restore their battered pride when they meet Arabian
Gulf League leaders Al Jazira in their rescheduled Round 1 match on
Monday at the Hazza bin Zayed Stadium. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dna/opt/local_news_catch/offset/15
)

Al Ain in talks with 'two potential' replacements for Zlatko Dalic,
with Jorge da Silva one of them

Al Ain say they are yet to finalise a replacement for departed
manager Zlatko Dalic but "are in talks" with two candidates with
experience in the Arabian Gulf League. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn8/opt/local_news_catch/offset/0
)

Zlatko Dalic to depart Al Ain after Al Jazira defeat: 'Thanks for
three great years'

Al Ain manager Zlatko Dalic is leaving the Garden City club after
more than two years in charge following their 3-1 defeat at home to Al
Jazira on Monday night. >> (
http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn9/opt/local_news_catch/offset/5
)

Get a recap ( ALDAR Young Chef Award : March 14, 2017 )

This year’s ALDAR Young Chef Award, held in collaboration with the
local Ayla hotels, saw talented students present some of their finest
dishes for a panel of judges 

[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Feb  1 16:22:56 2018
New Revision: 257303

URL: https://gcc.gnu.org/viewcvs?rev=257303=gcc=rev
Log:
PR target/84128
* config/i386/i386.c (release_scratch_register_on_entry): Add new
OFFSET and RELEASE_VIA_POP arguments.  Use SP+OFFSET to restore
the scratch if RELEASE_VIA_POP is false.
(ix86_adjust_stack_and_probe_stack_clash): Un-constify SIZE.
If we have to save a temporary register, decrement SIZE appropriately.
Pass new arguments to release_scratch_register_on_entry.
(ix86_adjust_stack_and_probe): Likewise.
(ix86_emit_probe_stack_range): Pass new arguments to
release_scratch_register_on_entry.

PR target/84128
* gcc.target/i386/pr84128.c: New test.

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

[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #11 from Uroš Bizjak  ---
Fixed.

[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb  1 16:04:18 2018
New Revision: 257302

URL: https://gcc.gnu.org/viewcvs?rev=257302=gcc=rev
Log:
PR rtl-optimization/84157
* combine.c (change_zero_ext): Use REG_P predicate in
front of HARD_REGISTER_P predicate.


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

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #3)
> As C++ now has standardized attributes, the question is what does the
> standard say about whether standard attributes on a template are inherited
> to specializations or not, and if the standard is fuzzy about it, what do
> other compilers do.

To my reading the standard doesn't specify attributes with enough detail to
answer the question, but inheriting attributes wouldn't make sense.  For
another example, consider class templates and alignas:

  template 
  struct alignas (32) A { T a; };

  template <>
  struct A { char c; };

  static_assert (alignof (A) < 32, "alignof A < 32");

This passes with all compilers I tried, including Clang, GCC, ICC, and MSVC. 
It would be most surprising if the rules for class templates were different
than for function templates.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jason at redhat dot com]

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

--- Comment #17 from Jason Merrill  ---
On Wed, Jan 31, 2018 at 9:45 PM, msebor at gcc dot gnu.org
 wrote:
> Jason, I'm only starting to look into it but if I understand your suggestion
> correctly, I don't think the bug can be fixed by relying on attribute
> exclusions.
>
> Based on the test cases alone (I haven't yet stepped through the code) the
> underlying problem seems to be that explicit specializations "inherit"
> attributes from their primary template rather than starting with a clean 
> slate.

Often that will be correct; I don't think we want to require people to
repeat all attributes on every explicit specialization.  The problem
here is that there's a conflicting attribute on the specialization,
and we want that to win, so I'm suggesting that when we see that, we
go through and remove conflicting attributes which came from the
template.

[Bug c++/83796] [6/7 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] Abstract |[6/7 Regression] Abstract
   |classes allowed to be   |classes allowed to be
   |instantiated when   |instantiated when
   |initialised as default  |initialised as default
   |parameter to function or|parameter to function or
   |constructor |constructor

--- Comment #6 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Feb  1 15:36:04 2018
New Revision: 257298

URL: https://gcc.gnu.org/viewcvs?rev=257298=gcc=rev
Log:
/cp
2018-02-01  Paolo Carlini  

PR c++/83796
* call.c (convert_like_real): If w're initializing from {} explicitly
call abstract_virtuals_error_sfinae.

/testsuite
2018-02-01  Paolo Carlini  

PR c++/83796
* g++.dg/cpp0x/abstract-default1.C: New.

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

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)
> I actually think it is the right thing that the attributes from templates
> are inherited by specializations.

That cannot be correct.  Because there is no way to remove an attribute from a
declaration such a design would make it impossible to declare a specialization
that differed from the primary.

Here's a modified example that should bring the problem into focus:

template  T __attribute__ ((noreturn)) f (T) { __builtin_abort (); }

template <> int f (int) { return 0; }   // bogus warning here

int g (int i)
{
  f (i);   // missing -Wreturn-type
}
t.C: In function ‘T f(T) [with T = int]’:
t.C:3:34: warning: function declared ‘noreturn’ has a ‘return’ statement
 template <> int f (int) { return 0; }
  ^
t.C:3:34: warning: ‘noreturn’ function does return