[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[seurer at linux dot vnet.ibm.com]

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

--- Comment #3 from Bill Seurer  ---
All the compilation failures disappear if the two casts

/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'

are fixed.

[Bug fortran/84276] Invalid error for valid statement function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Thu, Feb 08, 2018 at 02:26:50AM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276
> 
> --- Comment #1 from Steve Kargl  ---
> Reduced testcase.
> 
>   subroutine stepns(hh,h,s,w)
>   real, intent(inout) :: h,hh,s
>   real, intent(out)  :: w
>   real :: qofs
>   qofs(s)=s
>   w=qofs(hh+h)
>   end subroutine stepns
> 
> Problem occurs with interface.c:3219.
> 

So, the problem appears to boil down to gfortran acquiring
not only the type and type parameters from the declaration
statements, but also the attributes.  Statement functions
should not inherit the attributes.

[Bug c++/82930] [C++17] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments

[hotguest1 at hotmail dot com]

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

sandthorn  changed:

   What|Removed |Added

 CC||hotguest1 at hotmail dot com

--- Comment #3 from sandthorn  ---
I also confirm this on GCC 8.0.1 20180206,
but GCC 7.3 seems okey with code below.

https://godbolt.org/g/kwDaVE

auto lam = [](auto structured_bindable){ // also error with auto&
   auto [first,second] = structured_bindable; // also error with
auto&
   auto test_access = first;
};


g++ (GCC-Explorer-Build) 8.0.1 20180206 (experimental) 
: In lambda function:
:3:35: internal compiler error: in is_normal_capture_proxy, at
cp/lambda.c:288
auto test_access = first;
   ^
mmap: Invalid argument

[Bug fortran/84276] Invalid error for valid statement function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #1 from Steve Kargl  ---
Reduced testcase.

  subroutine stepns(hh,h,s,w)
  real, intent(inout) :: h,hh,s
  real, intent(out)  :: w
  real :: qofs
  qofs(s)=s
  w=qofs(hh+h)
  end subroutine stepns

Problem occurs with interface.c:3219.

[Bug c/84258] Bogus -Wformat warning "wide character string" for const unsigned char

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00380.html

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to fail||6.4.1, 7.3.1, 8.0

[Bug fortran/84276] New: Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

Bug ID: 84276
   Summary: Invalid error for valid statement function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found in c.l.f, but significantly reduced by me

https://groups.google.com/forum/#!topic/comp.lang.fortran/MtbUxdhz_6k


  subroutine stepns(hh,h,s,y,yp,y1,y2,w)

  real, intent(inout):: h,hh,s,y,y1,yp,y2
  real, intent(out) :: w

  real :: z2,z4,z1,z3,d,a,b,c,e,qofs

  z1(a,b,d)=(b-a)/d
  z2(a,c,b,d)=(z1(a,b,d)-c)/d
  z3(a,b,e,d)=(e-z1(a,b,d))/d
  z4(a,c,b,e,d)=(z3(a,b,e,d)-z2(a,c,b,d))/d
  qofs(a,c,b,e,d,s)=((z4(a,c,b,e,d)*(s-d)+z2(a,c,b,d))*s+c)*s+a

  w=qofs(y1,y2,y,yp,hh,hh+h)

  end subroutine stepns

% gfcx -c HOMPACK90.f
HOMPACK90.f:14:27:

   w=qofs(y1,y2,y,yp,hh,hh+h)
   1
Error: Non-variable expression in variable definition context (actual argument
to INTENT = OUT/INOUT) at (1)

Code compiles if the INTENT is removed.

[Bug middle-end/84275] New: missing warning on conflicting attributes on different declara

[msebor at gcc dot gnu.org]

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

Bug ID: 84275
   Summary: missing warning on conflicting attributes on different
declara
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC silently accepts function declarations with attributes whose parameters
contradict or conflict with one another, both on distinct declarations of the
same function and even on the same declaration.

The test case below shows that if two declarations specify such conflicting
attributes GCC honors the first one (at least the object size pass does). 
Since the other attribute is ignored GCC should point that out (e.g., by
-Wattributes or by -Wignored-attributes).

Similar bugs were reported in pr32960 and pr81544.

$ cat t.C && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -xc t.C
#include 

#define ATTR(list)   __attribute__ (list)

void* ATTR ((alloc_align (1), alloc_size (2),// this conflicts...
 alloc_align (2), alloc_size (1)))   // ...with this
foo (int, int);


void* ATTR ((alloc_size (1), alloc_align (2)))   // this conflicts...
bar (int, int);

void* ATTR ((alloc_size (2), alloc_align (1)))   // ...with this
bar (int, int);

void* foobar (void)
{
  void *p = bar (3, 5);
  memset (p, 0, 7);
  return p;
}
In file included from /usr/include/string.h:635,
 from t.C:1:
In function ‘memset’,
inlined from ‘foobar’ at t.C:19:3:
/usr/include/bits/string3.h:90:10: warning: ‘__builtin___memset_chk’ writing 7
bytes into a region of size 3 overflows the destination [-Wstringop-overflow=]
   return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
  ^

[Bug c/84274] New: [feature request] mbind attribute

[jeff.science at gmail dot com]

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

Bug ID: 84274
   Summary: [feature request] mbind attribute
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

https://sourceware.org/ml/binutils/2017-03/msg00261.html describes
as-of-yet-unimplemented attributes to control the placement of data into new
variants of bss, data, etc.

> The goal is to place data in special memory sections via 
> attribute. To place an uninitialized variable, foo, in a
> mbind bss section with memory type 1:
> 
> int foo __attribute__ ((mbind(0x1)));
> 
> To place a variable, foo, in a mbind data section with 
> memory type 2:
> 
> int foo __attribute__ ((mbind(0x2))) = 1;
> 
> To place a read-only variable, foo, in a mbind rodata 
> section with memory type 3:
> 
> const int foo __attribute__ ((mbind(0x3))) = 1;

This is a feature request to support these in GCC, since the underlying
functionality is supported
(https://fossies.org/diffs/binutils/2.28_vs_2.29/include/ChangeLog-diff.html).

# Additional references

https://sourceware.org/ml/gnu-gabi/2017-q1/msg0.html

[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 257570.

[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Wed Feb  7 22:54:59 2018
New Revision: 257470

URL: https://gcc.gnu.org/viewcvs?rev=257470=gcc=rev
Log:
[gcc]
2018-02-07  Michael Meissner  

PR target/84154
* config/rs6000/rs6000.md (fix_trunc2):
Convert from define_expand to be define_insn_and_split.  Rework
float/double/_Float128 conversions to QI/HI/SImode to work with
both ISA 2.07 (power8) or ISA 3.0 (power9).  Fix regression where
conversions to QI/HImode types did a store and then a load to
truncate the value.  For conversions to VSX registers, don't split
the insn, instead emit the code directly.  Use the code iterator
any_fix to combine signed and unsigned conversions.
(fix_truncsi2_p8): Likewise.
(fixuns_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_di2_hw): Likewise.
(fixuns_di2_hw): Likewise.
(fix_si2_hw): Likewise.
(fixuns_si2_hw): Likewise.
(fix_2_hw): Likewise.
(fix_trunc2): Likewise.
(fctiwz__smallint): Rename fctiwz__smallint to
fix_truncsi2_p8.
(fix_trunc2_internal): Delete, no longer
used.
(fixuns_trunc2_internal): Likewise.
(fix__mem): Likewise.
(fctiwz__mem): Likewise.
(fix__mem): Likewise.
(fix_trunc2_mem): On ISA 3.0, prevent
the register allocator from doing a direct move to the GPRs to do
a store, and instead use the ISA 3.0 store byte/half-word from
vector register instruction.  For IEEE 128-bit floating point,
also optimize stores of 32-bit ints.
(fix_trunc2_mem): Likewise.

[gcc/testsuite]
2018-02-07  Michael Meissner  

PR target/84154
* gcc.target/powerpc/pr84154-1.c: New tests.
* gcc.target/powerpc/pr84154-2.c: Likewise.
* gcc.target/powerpc/pr84154-3.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr84154-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84154-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr84154-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 22:41:59 2018
New Revision: 257468

URL: https://gcc.gnu.org/viewcvs?rev=257468=gcc=rev
Log:
2018-02-07  Steven G. Kargl  

PR fortran/82994
* match.c (gfc_match_deallocate): Check for NULL pointer.

2018-02-07  Steven G. Kargl  

PR fortran/82994
* gfortran.dg/deallocate_error_3.f90: New test.
* gfortran.dg/deallocate_error_4.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deallocate_error_3.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deallocate_error_4.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/match.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for the bug report.

[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32

[willschm at gcc dot gnu.org]

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

--- Comment #3 from Will Schmidt  ---
Created attachment 43360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43360=edit
.expand dump from a build with -O1.

the .expand dump from a build with -O1.

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 22:36:24 2018
New Revision: 257467

URL: https://gcc.gnu.org/viewcvs?rev=257467=gcc=rev
Log:
2018-02-07  Steven G. Kargl  

PR fortran/82994
* match.c (gfc_match_deallocate): Check for NULL pointer.

2018-02-07  Steven G. Kargl  

PR fortran/82994
* gfortran.dg/deallocate_error_3.f90: New test.
* gfortran.dg/deallocate_error_4.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deallocate_error_3.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deallocate_error_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #2 from Will Schmidt  ---

The troublesome snippet of code reads as so
( from gcc/testsuite/g++.dg/eh/simd-3.C )
" 
int main(void)
{
  v v1 = vt;
  try {
thrower();
  } catch (int x) {
  }
  v2 = v1;
  if (memcmp(,,...)) abort();
"
where thrower() is a function meant to scramble contents of the VSRs.
And the problem (that we abort during the test run) occurs when any non-zero
optimization level is specified, due to vt != v2.  

high-level debug suggests that we are not storing the v1=vt result to memory,
(only to a reg), so the call to thrower clobbers the contents, and we
ultimately fail. 


When built with -O0, on the "v1 = vt" statement, i can see (.expand dump)

;; Generating RTL for gimple basic block 2

;; v1_5 ={v} vt;

(insn # # # (set (reg:SI 129)
(high:SI (symbol_ref:SI ("vt") [flags 0x2]  )))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # # (set (reg/f:SI 128)
(lo_sum:SI (reg:SI 129)
(symbol_ref:SI ("vt") [flags 0x2]  )))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (expr_list:REG_EQUAL (symbol_ref:SI ("vt") [flags 0x2]  )
(nil)))

(insn # # # (set (reg:V4SI 130)
(mem/v/c:V4SI (reg/f:SI 128) [1 vt+0 S16 A128]))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # 0 (set (mem/c:V4SI (plus:SI (reg/f:SI 116 virtual-stack-vars)
(const_int 8 [0x8])) [1 v1+0 S16 A128])
(reg:V4SI 130))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

;; thrower ();

Noting the "set (mem/c..." statement.  This code works, in that the v1 value
survives the call to thrower.


When built with -O1, that chunk of the dump now reads:
;; v1_4 ={v} vt;

(insn # # # (set (reg:SI 128)
(high:SI (symbol_ref:SI ("*.LANCHOR1") [flags 0x182])))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

(insn # # # (set (reg/f:SI 127)
(lo_sum:SI (reg:SI 128)
(symbol_ref:SI ("*.LANCHOR1") [flags 0x182])))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR1") [flags 0x182])
(nil)))

(insn # # 0 (set (reg/v:V4SI 123 [ v1 ])
(mem/v/c:V4SI (reg/f:SI 127) [1 vt+0 S16 A128]))
"/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56#
 (nil))

;; thrower ();


And here, note that this is a "set (reg".  There is no "set (mem" until after
the "v2 = v1" statement, after the call to thrower(). 

This seems to fit with what I see via objdump : 
(working code)
xx :
xx: 94 21 ff c0 stwur1,-64(r1)
xx: 7c 08 02 a6 mflrr0
xx: 90 01 00 44 stw r0,68(r1)
xx: 93 e1 00 3c stw r31,60(r1)
xx: 7c 3f 0b 78 mr  r31,r1
xx: 3d 20 10 02 lis r9,4098
xx: 39 29 00 40 addir9,r9,64
xx: 7c 00 4e 18 lxvw4x  vs0,0,r9   <- load.
xx: 39 20 00 10 li  r9,16
xx: 7c 1f 4f 18 stxvw4x vs0,r31,r9  <- store.
xx: 4b ff ff 61 bl  174c <_Z7throwerv>

versus (failing code):
xx :
xx: 94 21 ff d0 stwur1,-48(r1)
xx: 7c 08 02 a6 mflrr0
xx: 90 01 00 34 stw r0,52(r1)
xx: 38 00 00 10 li  r0,16
xx: 7f e1 01 ce stvxv31,r1,r0
xx: 3d 20 10 02 lis r9,4098
xx: 39 29 00 40 addir9,r9,64
xx: 7f e0 4e 19 lxvw4x  vs63,0,r9<- load, no store.
xx: 4b ff ff 89 bl  16f0 <_Z7throwerv>


most previous tree dump before expand (232t.optimized) shows bb2 having:
   :
  v1_5 ={v} vt;
  thrower ();

versus 
   [local count: 1073741825]:
  v1_4 ={v} vt;
  thrower ();

[Bug c++/84082] [7/8 Regression] ICE with broken template function definition

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb  7 22:30:51 2018
New Revision: 257466

URL: https://gcc.gnu.org/viewcvs?rev=257466=gcc=rev
Log:
PR c++/84082
* parser.c (cp_parser_dot_deref_incomplete): New function.
(cp_parser_postfix_dot_deref_expression): Use it.

* g++.dg/template/incomplete11.C: New test.
* g++.dg/parse/crash67.C: Expect an incomplete type diagnostics too.

Added:
trunk/gcc/testsuite/g++.dg/template/incomplete11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash67.C

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 22:29:22 2018
New Revision: 257465

URL: https://gcc.gnu.org/viewcvs?rev=257465=gcc=rev
Log:
2018-02-07  Steven G. Kargl  

PR fortran/82994
* match.c (gfc_match_deallocate): Check for NULL pointer.

2018-02-07  Steven G. Kargl  

PR fortran/82994
* gfortran.dg/deallocate_error_3.f90: New test.
* gfortran.dg/deallocate_error_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/deallocate_error_3.f90
trunk/gcc/testsuite/gfortran.dg/deallocate_error_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend

[zamazan4ik at tut dot by]

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

Alexander Zaitsev  changed:

   What|Removed |Added

 CC||zamazan4ik at tut dot by

--- Comment #6 from Alexander Zaitsev  ---
One more problematic case: 

#include 

class A {
int a;
friend class B;
};

class B {
public:

template 
struct trait: std::false_type {};

template 
struct trait().a)>>:
std::true_type {};
};

int main() {
static_assert(B::trait{});
return 0;
}


On clang(trunk) this code works well. On gcc(trunk) we have: 

prog.cc: In function 'int main()':
prog.cc:15:61: error: 'int A::a' is private within this context
 struct trait().a)>>:
std::true_type {};
  ~~~^
prog.cc:4:9: note: declared private here
 int a;

[Bug fortran/84273] New: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

[janus at gcc dot gnu.org]

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

Bug ID: 84273
   Summary: Reject allocatable passed-object dummy argument
(proc_ptr_47.f90)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

implementing C453 (F03), C456 (F08), C461(F15)

see https://github.com/nncarlson/gfortran.dg/issues/4

[Bug c/83390] valgrind error in lra_eliminate_regs_1

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
(In reply to David Binderman from comment #0)
> A build of today's gcc trunk with valgrind produces this:
> 
> ==8995== Conditional jump or move depends on uninitialised value(s)
> ==8995==at 0xA39BBE: lra_eliminate_regs_1 (lra-eliminations.c:403)
> ==8995==by 0xA39BBE: eliminate_regs_in_insn(rtx_insn*, bool, bool, long)
> (lra-eliminations.c:1114)
> ==8995==by 0xA3A147: process_insn_for_elimination
> (lra-eliminations.c:1396)
> ==8995==by 0xA3A147: lra_eliminate(bool, bool) (lra-eliminations.c:1459)
> 
> svn blame gives us
> 
> 23   vmakarov if (CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x,
> 1)) == -offset)
> 
> I suspect local variable offset isn't correct.
> 
> Configure lines are
> 
> ../trunk/configure --prefix=/home/dcb/gcc/results.255572.valgrind \
>   --disable-bootstrap \
>   --disable-multilib \
>   --disable-werror \
>   --enable-checking=valgrind \
>   --enable-languages=c,c++,fortran
> 
> sed 's/-O2/-O3 -funroll-loops -Wtautological-compare/' < Makefile >
> Makefile.tmp
> mv Makefile.tmp Makefile
> 
> svn info tells us current revision number is 255572.

Sorry, I tried to reproduce it according to these instructions (without and
with editing the Makefile) but I've failed.

Could you confirm that it is still the problem in your environment.

[Bug fortran/84218] ICE in free_expr0, at fortran/expr.c:451

[neil.n.carlson at gmail dot com]

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

Neil Carlson  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from Neil Carlson  ---
Note that the DATA statement

   data (x(j:i), i=1,2,2) /'a'/

is not valid Fortran.  Implied do objects, here x(j:i), are restricted by R538
(F08) to array elements, scalar structure component, or an implied-do.  x(j:i)
is an array section not an array element.  But this may be a language extension
that gfortran supports.

[Bug fortran/84270] optimization bug with assumed size array argument

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
The bug disappears with -fno-frontend-optimize.

[Bug target/84272] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2018-2-7
   Target Milestone|--- |8.0

[Bug target/84272] New: AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

[marxin at gcc dot gnu.org]

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

Bug ID: 84272
   Summary: AddressSanitizer: heap-use-after-free
../../gcc/config/aarch64/cortex-a57-fma-steering.c:519
in fma_node::get_parity()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org, kyrylo.tkachov at arm dot com,
ramana at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-linux-gnu
Target: aarch64-linux-gnu

Seen both on a native machine and cross compiler (on x86_64):

$ cat model.ii
class a
{
public:
  float b, c;
  a ();
  a (float, float, float);
  float operator* (a)
  {
float d = b * b + c * c;
return d;
  }
} typedef e;
void
f ()
{
  e g[1];
  e h (0, 0, h * g[2]);
}
$ ./xg++  -B. model.ii -c  -march=armv8-a -mtune=cortex-a57 -O2
=
==20120==ERROR: AddressSanitizer: heap-use-after-free on address 0x60423ca8
at pc 0x02e669b2 bp 0x7fffd1b0 sp 0x7fffd1a8
READ of size 8 at 0x60423ca8 thread T0
#0 0x2e669b1 in fma_node::get_parity()
../../gcc/config/aarch64/cortex-a57-fma-steering.c:519
#1 0x2e669b1 in fma_node::rename(fma_forest*)
../../gcc/config/aarch64/cortex-a57-fma-steering.c:600
#2 0x2e67b0a in func_fma_steering::dfs(void (*)(fma_forest*), void
(*)(fma_forest*, fma_root_node*), void (*)(fma_forest*, fma_node*), bool)
../../gcc/config/aarch64/cortex-a57-fma-steering.c:882
#3 0x2e686b9 in func_fma_steering::rename_fma_trees()
../../gcc/config/aarch64/cortex-a57-fma-steering.c:1006
#4 0x2e6aac2 in func_fma_steering::execute_fma_steering()
../../gcc/config/aarch64/cortex-a57-fma-steering.c:1036
#5 0x2e6c7ad in pass_fma_steering::execute(function*)
../../gcc/config/aarch64/cortex-a57-fma-steering.c:1071
#6 0x1dadc09 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497
#7 0x1daf5e2 in execute_pass_list_1 ../../gcc/passes.c:2586
#8 0x1daf60c in execute_pass_list_1 ../../gcc/passes.c:2587
#9 0x1daf60c in execute_pass_list_1 ../../gcc/passes.c:2587
#10 0x1daf68f in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2597
#11 0x11619a9 in cgraph_node::expand() ../../gcc/cgraphunit.c:2139
#12 0x116454c in expand_all_functions ../../gcc/cgraphunit.c:2275
#13 0x116454c in symbol_table::compile() ../../gcc/cgraphunit.c:2624
#14 0x116dc76 in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2717
#15 0x2132fe4 in compile_file ../../gcc/toplev.c:480
#16 0x690921 in do_compile ../../gcc/toplev.c:2081
#17 0x690921 in toplev::main(int, char**) ../../gcc/toplev.c:2216
#18 0x69b444 in main ../../gcc/main.c:39
#19 0x75a65f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#20 0x69dba9 in _start
(/home/marxin/Programming/gcc2/objdir2/gcc/cc1plus+0x69dba9)

0x60423ca8 is located 24 bytes inside of 48-byte region
[0x60423c90,0x60423cc0)
freed by thread T0 here:
#0 0x76f02ff8 in operator delete(void*, unsigned long)
(/usr/lib64/libasan.so.4+0xdeff8)
#1 0x2e682e5 in func_fma_steering::dfs(void (*)(fma_forest*), void
(*)(fma_forest*, fma_root_node*), void (*)(fma_forest*, fma_node*), bool)
../../gcc/config/aarch64/cortex-a57-fma-steering.c:896
#2 0x60423bcf  ()

previously allocated by thread T0 here:
#0 0x76f01c70 in operator new(unsigned long)
(/usr/lib64/libasan.so.4+0xddc70)
#1 0x2e69e52 in func_fma_steering::analyze_fma_fmul_insn(fma_forest*,
du_chain*, du_head*) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:774

SUMMARY: AddressSanitizer: heap-use-after-free
../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in
fma_node::get_parity()
Shadow bytes around the buggy address:
  0x0c087fffc740: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
  0x0c087fffc750: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fa
  0x0c087fffc760: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
  0x0c087fffc770: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 fa
  0x0c087fffc780: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fa
=>0x0c087fffc790: fa fa fd fd fd[fd]fd fd fa fa 00 00 00 00 00 fa
  0x0c087fffc7a0: fa fa 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x0c087fffc7b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fffc7c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fffc7d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fffc7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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:  

[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

--- Comment #28 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Feb  7 21:08:51 2018
New Revision: 257462

URL: https://gcc.gnu.org/viewcvs?rev=257462=gcc=rev
Log:
2018-02-07  Thomas Koenig  

PR fortran/68560
* trans-intrinsic.c (gfc_conv_intrinsic_shape): New function.
(gfc_conv_intrinsic_function): Call it.

2018-02-07  Thomas Koenig  

PR fortran/68560
* gfortran.dg/shape_9.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/shape_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for the bug report.

[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 21:01:00 2018
New Revision: 257461

URL: https://gcc.gnu.org/viewcvs?rev=257461=gcc=rev
Log:
2018-02-07  Steven G. Kargl  

PR fortran/82049
* match.c (gfc_match_type_spec): If the charlen is non-NULL, then
try to resolve it.  While here return early if possible.

2018-02-07  Steven G. Kargl  

PR fortran/82049
* gfortran.dg/assumed_charlen_parameter.f90: New test.

Added:
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/match.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
If -maltivec=be is not used, I support removing it.  Deprecating it with a
warning on use will show if anyone care enough to tell us they do use it ;-)

[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #22 from David Malcolm  ---
Assigning this to me in the hope that I'll get to it in gcc 9 stage 1.

[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 20:45:40 2018
New Revision: 257460

URL: https://gcc.gnu.org/viewcvs?rev=257460=gcc=rev
Log:
2018-02-07  Steven G. Kargl  

PR fortran/82049
* match.c (gfc_match_type_spec): If the charlen is non-NULL, then
try to resolve it.  While here return early if possible.

2018-02-07  Steven G. Kargl  

PR fortran/82049
* gfortran.dg/assumed_charlen_parameter.f90: New test.

Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/match.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Feb  7 20:43:33 2018
New Revision: 257459

URL: https://gcc.gnu.org/viewcvs?rev=257459=gcc=rev
Log:
2018-02-06  Steven G. Kargl  

PR fortran/82049
* match.c (gfc_match_type_spec): If the charlen is non-NULL, then
try to resolve it.  While here return early if possible.

2018-02-06  Steven G. Kargl  

PR fortran/82049
* gfortran.dg/assumed_charlen_parameter.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
I wonder how many failures are left if that invalid cast is removed from the
code?  It is just wrong and unnecessary.

[Bug lto/84212] -Wno-* does not disable warnings from -flto link stage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00350.html

[Bug target/84220] rs6000 builtin __builtin_vec_sld() ICEs on invalid 3rd argument

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-02/msg00325.ht
   ||ml
   Last reconfirmed||2018-02-07
   Assignee|unassigned at gcc dot gnu.org  |willschm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
Will has a patch submitted.

[Bug fortran/84270] New: optimization bug with assumed size array argument

[weinert at cmth dot phys.uwm.edu]

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

Bug ID: 84270
   Summary: optimization bug with assumed size array argument
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weinert at cmth dot phys.uwm.edu
  Target Milestone: ---

Created attachment 43359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43359=edit
simple test case

Optimization bug at -O2, -O3 with message

vr = matmul( orth(:,:,n), v )
1
Error: The upper bound in the last dimension must appear in the reference to
the assumed size array ‘orth’ at (1) lhcal.f90:33:25:

Attached test case is taken from larger program, and only appears to be a
problem if orth is an assumed size arrays with the * in the last dimension. (If
assumed shape, also fine.) Obviously easy to work around, so minor.

[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Kaushik: is this fixed with r256762?

[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84269

--- Comment #9 from David Malcolm  ---
I've filed PR c++/84269 to track improving the "memset" handling (for next
stage 1).

[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-07
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/84269] New: C++ FE does not suggest which #include to use for "memset"

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84269
   Summary: C++ FE does not suggest which #include to use for
"memset"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As noted in the fix for PR c++/81610 and PR c++/80567 here:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02200.html

> The C++ FE is missing a suggestion about which #include to use for
> "memset", but I'd prefer to treat that as a follow-up patch (and
> probably for next stage 1).

I've filing this PR to capture that (for gcc 9 stage 1).

See those PRs for more info.

[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed by r257456.

[Bug c++/81610] [8 Regression] bogus fix-it hint for a call to an undeclared function: for

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r257456.

[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Wed Feb  7 17:55:54 2018
New Revision: 257456

URL: https://gcc.gnu.org/viewcvs?rev=257456=gcc=rev
Log:
C++: avoid most reserved words as misspelling suggestions (PR c++/81610 and PR
c++/80567)

lookup_name_fuzzy can offer some reserved words as suggestions for
misspelled words, helping with "singed"/"signed" typos.

PR c++/81610 and PR c++/80567 report problems where the C++ frontend
suggested "if", "for" and "else" as corrections for misspelled variable
names.

The root cause is that in r247233
  ("Fix spelling suggestions for reserved words (PR c++/80177)")
I loosened the conditions on these reserved words, adding this condition:
   if (kind == FUZZY_LOOKUP_TYPENAME)
to the logic for rejecting words that don't start decl-specifiers, to
allow for "static_assert" to be offered.

This is too loose a condition: we don't want to suggest *any* reserved word
when we're in a context where we don't know we expect a typename.

For the kinds of error-recover situations where we're suggesting
spelling corrections we don't have much contextual information, so it
seems prudent to be stricter about which reserved words we offer
as spelling suggestions; I don't think it makes sense for us to
suggest e.g. "for".

This patch implements that by effectively reinstating the old logic,
but special-casing RID_STATIC_ASSERT, moving the logic to a new
subroutine (in case we want to allow for other special-cases).

I attempted to add suggestions for the various RID_*CAST, to cope
with e.g. "reinterptet_cast" (I can never type that correctly on the
first try), but the following '<' token confuses the error-recovery
enough that the suggestion code isn't triggered.

gcc/cp/ChangeLog:
PR c++/81610
PR c++/80567
* name-lookup.c (suggest_rid_p): New function.
(lookup_name_fuzzy): Replace enum-rid-filtering logic with call to
suggest_rid_p.

gcc/testsuite/ChangeLog:
PR c++/81610
PR c++/80567
* g++.dg/spellcheck-reswords.C: New test case.
* g++.dg/spellcheck-stdlib.C: Remove xfail from dg-bogus
suggestion of "if".


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-reswords.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C

[Bug c++/81610] [8 Regression] bogus fix-it hint for a call to an undeclared function: for

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Wed Feb  7 17:55:54 2018
New Revision: 257456

URL: https://gcc.gnu.org/viewcvs?rev=257456=gcc=rev
Log:
C++: avoid most reserved words as misspelling suggestions (PR c++/81610 and PR
c++/80567)

lookup_name_fuzzy can offer some reserved words as suggestions for
misspelled words, helping with "singed"/"signed" typos.

PR c++/81610 and PR c++/80567 report problems where the C++ frontend
suggested "if", "for" and "else" as corrections for misspelled variable
names.

The root cause is that in r247233
  ("Fix spelling suggestions for reserved words (PR c++/80177)")
I loosened the conditions on these reserved words, adding this condition:
   if (kind == FUZZY_LOOKUP_TYPENAME)
to the logic for rejecting words that don't start decl-specifiers, to
allow for "static_assert" to be offered.

This is too loose a condition: we don't want to suggest *any* reserved word
when we're in a context where we don't know we expect a typename.

For the kinds of error-recover situations where we're suggesting
spelling corrections we don't have much contextual information, so it
seems prudent to be stricter about which reserved words we offer
as spelling suggestions; I don't think it makes sense for us to
suggest e.g. "for".

This patch implements that by effectively reinstating the old logic,
but special-casing RID_STATIC_ASSERT, moving the logic to a new
subroutine (in case we want to allow for other special-cases).

I attempted to add suggestions for the various RID_*CAST, to cope
with e.g. "reinterptet_cast" (I can never type that correctly on the
first try), but the following '<' token confuses the error-recovery
enough that the suggestion code isn't triggered.

gcc/cp/ChangeLog:
PR c++/81610
PR c++/80567
* name-lookup.c (suggest_rid_p): New function.
(lookup_name_fuzzy): Replace enum-rid-filtering logic with call to
suggest_rid_p.

gcc/testsuite/ChangeLog:
PR c++/81610
PR c++/80567
* g++.dg/spellcheck-reswords.C: New test case.
* g++.dg/spellcheck-stdlib.C: Remove xfail from dg-bogus
suggestion of "if".


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-reswords.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C

[Bug rtl-optimization/83530] [7/8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

Summary|[8 Regression] ICE in   |[7/8 Regression] ICE in
   |reset_sched_cycles_in_curre |reset_sched_cycles_in_curre
   |nt_ebb, at sel-sched.c:7150 |nt_ebb, at sel-sched.c:7150

--- Comment #10 from Pat Haugen  ---
Marking as 7 regression also as that is when the change to use -fsched-pressure
--param sched-pressure-algorithm=2 as the default for PowerPC happened. But as
I mentioned in Comment 7, the failure can be reproduced on prior versions by
adding those two options.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
(In reply to Andrey Belevantsev from comment #8)
> I will take a look.  The ICE is within the code that models the scheduling
> loop in order to get the proper insn ticks and everything for later MD
> processing (it is equivalent to always scheduling the next insn).  Either
> there is an issue in that loop that wasn't uncovered anywhere but powerpc or
> there is some subtlety in the powerpc cpu model that is triggered there.  It
> is not very pleasant to find out and fix usually so it will take time.

Thanks, appreciate that. I did find out the isssue is not very pleasant to
track down as you state.

[Bug lto/84212] -Wno-* does not disable warnings from -flto link stage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
You're right.  I fixed it for bug 78768 in r244326 (-Walloca-larger-than and
-Wformat-overflow et al.) but missed -Wstringop-overflow.  Let me take care of
this.

I wonder if LTO should be implied for all warnings to avoid these mistakes.

Alternatively, have a script check to make sure that middle-end warnings are
enabled for in the .opt file(s), run it for each build and fail if not.

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Additional testcases now fixed as well.

[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed Feb  7 16:02:50 2018
New Revision: 257454

URL: https://gcc.gnu.org/viewcvs?rev=257454=gcc=rev
Log:
PR c++/84182 - ICE with captured lambda

PR c++/84181
* pt.c (extract_locals_r, extract_local_specs): New.
(tsubst_pack_expansion): Use them.

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

[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed Feb  7 16:02:50 2018
New Revision: 257454

URL: https://gcc.gnu.org/viewcvs?rev=257454=gcc=rev
Log:
PR c++/84182 - ICE with captured lambda

PR c++/84181
* pt.c (extract_locals_r, extract_local_specs): New.
(tsubst_pack_expansion): Use them.

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

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||munroesj at gcc dot gnu.org

--- Comment #1 from Bill Seurer  ---
Most of the failures (well, the first couple dozen or so anyway) appear to be
like this:

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O3  -lm  -o
./bmi-andn-1.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o
./bmi-andn-1.exe
In file included from
/home/seurer/gcc/build/gcc-trunk/gcc/include/x86intrin.h:39,
 from
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c:7:
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h: In function
'_mm_cmpeq_pi32':
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:3: note: use
-flax-vector-conversions to permit conversions between vectors with differing
element types or numbers of subparts
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h: In function
'_mm_cmpgt_pi32':
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'
compiler exited with status 1
FAIL: gcc.target/powerpc/bmi-andn-1.c (test for excess errors)
Excess errors:
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'
/home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error:
incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector(8) short int'

[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644

[amker at gcc dot gnu.org]

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

--- Comment #23 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> So after r257453 we improve the situation pre-IVOPTs to just
> 6 IVs (duplicated but trivially equivalent) plus one counting IV.  But then
> when SLP is enabled IVOPTs comes along and adds another 4 IVs which makes us
> spill... (for AVX256, so you need -march=core-avx2 for example).
> 
> Bin, any chance you can take a look?  In the IVO dump I see
> 
>   target_avail_regs 15
>   target_clobbered_regs 9
>   target_reg_cost 4
>   target_spill_cost 8
>   regs_used 3
> ^^^
> 
> and regs_used looks awfully low to me.  The loop has even more IVs initially
> plus variable steps for that IVs which means we need two regs per IV.
> 
> There doesn't seem to be a way to force IVOPTs to use the minimal set of IVs?
> Or just use the original set, removing the obvious redundancies?  There is
> a microarchitectural issue left with the vectorization but the spilling
> obscures the look quite a bit :/

Sure, I will have a look based on your commit.  Thanks

[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Wed Feb  7 15:46:17 2018
New Revision: 257453

URL: https://gcc.gnu.org/viewcvs?rev=257453=gcc=rev
Log:
2018-02-07  Richard Biener  

PR tree-optimization/84037
* tree-vectorizer.h (struct _loop_vec_info): Add ivexpr_map member.
(cse_and_gimplify_to_preheader): Declare.
(vect_get_place_in_interleaving_chain): Likewise.
* tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize
ivexpr_map.
(_loop_vec_info::~_loop_vec_info): Delete it.
(cse_and_gimplify_to_preheader): New function.
* tree-vect-slp.c (vect_get_place_in_interleaving_chain): Export.
* tree-vect-stmts.c (vectorizable_store): CSE base and steps.
(vectorizable_load): Likewise.  For grouped stores always base
the IV on the first element.
* tree-vect-loop-manip.c (vect_loop_versioning): Unshare versioning
condition before gimplifying.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop-manip.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
So after r257453 we improve the situation pre-IVOPTs to just
6 IVs (duplicated but trivially equivalent) plus one counting IV.  But then
when SLP is enabled IVOPTs comes along and adds another 4 IVs which makes us
spill... (for AVX256, so you need -march=core-avx2 for example).

Bin, any chance you can take a look?  In the IVO dump I see

  target_avail_regs 15
  target_clobbered_regs 9
  target_reg_cost 4
  target_spill_cost 8
  regs_used 3
^^^

and regs_used looks awfully low to me.  The loop has even more IVs initially
plus variable steps for that IVs which means we need two regs per IV.

There doesn't seem to be a way to force IVOPTs to use the minimal set of IVs?
Or just use the original set, removing the obvious redundancies?  There is
a microarchitectural issue left with the vectorization but the spilling
obscures the look quite a bit :/

[Bug target/84266] New: mmintrin.h intrinsic headers for PowerPC code fails on power9

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 84266
   Summary: mmintrin.h intrinsic headers for PowerPC code fails on
power9
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

(more details coming)

This is the complete list of failures:

FAIL: gcc.target/powerpc/bmi-andn-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-andn-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-bextr-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-bextr-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-bextr-4.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-bextr-5.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsi-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsi-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsmsk-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsmsk-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsr-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-blsr-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-tzcnt-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi-tzcnt-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi2-bzhi32-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi2-bzhi64-1.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi2-bzhi64-1a.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi2-mulx32-2.c (test for excess errors)
FAIL: gcc.target/powerpc/bmi2-mulx64-2.c (test for excess errors)
times)
FAIL: gcc.target/powerpc/mmx-packs.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-packssdw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-packsswb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-packuswb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddsb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddsw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddusb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddusw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-paddw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpeqb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpeqd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpeqw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpgtb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpgtd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pcmpgtw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pmaddwd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pmulhw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pmullw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-pslld-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psllw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psrad-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psraw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psrld-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psrlw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubb-2.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubd-2.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubsb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubsw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubusb-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubusw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-psubw-2.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpckhbw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpckhdq-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpckhwd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpcklbw-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpckldq-1.c (test for excess errors)
FAIL: gcc.target/powerpc/mmx-punpcklwd-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-addps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-addss-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-andnps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-andps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cmpss-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cvtpi16ps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cvtpi32ps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cvtpi32x2ps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cvtpi8ps-1.c (test for excess errors)
FAIL: gcc.target/powerpc/sse-cvtpspi16-1.c (test for excess errors)
FAIL: 

[Bug c/84258] Bogus -Wformat warning "wide character string" for const unsigned char

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-07
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
Confirmed.  The wording seems to date back to r36586 (18 years ago).

I'll have a look at fixing it.

[Bug c/84240] Error in extract_constrain_insn, at recog.c:2246

[xvl5190 at psu dot edu]

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

--- Comment #2 from xvl5190 at psu dot edu ---
Please try this example with optimization level -O1/-O2/-O3:

/* Executable testcase for 'output flags.' */
/* { dg-do rund *nbum; } */
char TestC() {
  char r;
  __asm__("stc": "=@ccc" (r));
  if (r) {
__asm__("clc": "=@ccnc" (r));
if (r) return 1;
  }
  return 0;
}
char TestE() {
  char r; /* 1 equals 1. */
  __asm__("cmp $1, %1": "=@cce" (r): "r" (1));
  if (r) { /* 1 not equals 2. */
__asm__("cmp $2, %1": "=@ccne" (r): "r" (1));
if (r) return 1;
  }
  return 0;
}
char TestZ() {
  char r; /* 1 equals 1. */
  __asm__("cmp $1, %1": "=@ccz" (r): "r" (1));
  if (r) { /* 1 not equals 2. */
__asm__("cmp $2, %1": "=@ccnz" (r): "r" (1));
if (r) return 1;
  }
  return 0;
}
char TestA() {
  char r; /* 1 a 0. */
  __asm__("cmp $0, %1": "=@cca" (r): "r" (1));
  if (r) { /* 1 na 2. */
__asm__("cmp $2, %1": "=@ccna" (r): "r" (1));
if (r) { /* 1 na 1. */
  __asm__("cmp $1, %1": "=@ccna" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestAE() {
  char r; /* 1 ae 0. */
  __asm__("cmp $0, %1": "=@ccae" (r): "r" (1));
  if (r) { /* 1 nae 2. */
__asm__("cmp $2, %1": "=@ccnae" (r): "r" (1));
if (r) { /* 1 ae 1. */
  __asm__("cmp $1, %1": "=@ccae" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestB() {
  char r; /* 1 b 2. */
  __asm__("cmp $2, %1": "=@ccb" (r): "r" (1));
  if (r) { /* 1 nb 0. */
__asm__("cmp $0, %1": "=@ccnb" (r): "r" (1));
if (r) { /* 1 nb 1. */
  __asm__("cmp $1, %1": "=@ccnb" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestBE() {
  char r; /* 1 be 2. */
  __asm__("cmp $2, %1": "=@ccbe" (r): "r" (1));
  if (r) { /* 1 nbe 0. */
__asm__("cmp $0, %1": "=@ccnbe" (r): "r" (1));
if (r) { /* 1 be 1. */
  __asm__("cmp $1, %1": "=@ccbe" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestG() {
  char r; /* 1 g 0. */
  __asm__("cmp $0, %1": "=@ccg" (r): "r" (1));
  if (r) { /* 1 ng 2. */
__asm__("cmp $2, %1": "=@ccng" (r): "r" (1));
if (r) { /* 1 ng 1. */
  __asm__("cmp $1, %1": "=@ccng" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestGE() {
  char r; /* 1 ge 0. */
  __asm__("cmp $0, %1": "=@ccge" (r): "r" (1));
  if (r) { /* 1 nge 2. */
__asm__("cmp $2, %1": "=@ccnge" (r): "r" (1));
if (r) { /* 1 ge 1. */
  __asm__("cmp $1, %1": "=@ccge" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestL() {
  char r; /* 1 l 2. */
  __asm__("cmp $2, %1": "=@ccl" (r): "r" (1));
  if (r) { /* 1 nl 0. */
__asm__("cmp $0, %1": "=@ccnl" (r): "r" (1));
if (r) { /* 1 nl 1. */
  __asm__("cmp $1, %1": "=@ccnl" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestLE() {
  char r; /* 1 le 2. */
  __asm__("cmp $2, %1": "=@ccle" (r): "r" (1));
  if (r) { /* 1 nle 0. */
__asm__("cmp $0, %1": "=@ccnle" (r): "r" (1));
if (r) { /* 1 le 1. */
  __asm__("cmp $1, %1": "=@ccle" (r): "r" (1));
  if (r) return 1;
}
  }
  return 0;
}
char TestO() {
  char r;
  unsigned char res = 128; /* overflow. */
  __asm__("addb $128, %1": "=@cco" (r), "+r" (res));
  if (r) { /* not overflow. */
__asm__("addb $1, %1": "=@ccno" (r), "+r" (res));
if (r) return 1;
  }
  return 0;
}
char TestP() {
  char r, res = 1;
  /* even 
# bits. */
  __asm__("addb $2, %1": "=@ccp" (r), "+r" (res));
  if (r) {
/* odd 
# bits. */
__asm__("addb $1, %1": "=@ccnp" (r), "+r" (res));
if (r) return 1;
  }
  return 0;
}
char TestS() {
  char r, res = 1; /* sign bit set. */
  __asm__("addb $128, %1": "=@ccs" (r), "+r" (res));
  if (r) { /* sign bit not set. */
__asm__("subb $128, %1": "=@ccns" (r), "+r" (res));
if (r) return 1;
  }
  return 0;
} /* dg-do treats exit code of 0 as success. */
int main() {
  if (TestC() && TestE() && TestZ() && TestA() && TestAE() && TestB() &&
TestBE() && TestG() && TestGE() && TestL() && TestLE() && TestO() && TestP() &&
TestS()) return 0;
  __builtin_abort();
}

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
> > 
> > --- Comment #9 from Jakub Jelinek  ---
> > I think the bug is in the ARRAY_REF design, because at least in C one can 
> > have
> > arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND 
> > (,
> > 3)
> > is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make 
> > sense,
> > because what you really get from array_ref_element_size in cases where the 
> > size
> > of element is not a multiple of the TYPE_ALIGN_UNIT is something that 
> > doesn't
> > have anything to do with the element size.
> > Is that some Ada specific stuff?
> > Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN,
> > supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but
> > something smaller.
> 
> It is an optimization so that for variable-sized stuff it's easier to
> get at an alignment value.  We've experimented with removing this
> but it regressed some cases (even in C).  Eric may know more and I
> think there was a bug tracking this ... or some ml posts.
> 
> So arrays of over-aligned types in C do not contain padding?  Thus
> the elements are not aligned but only the first element?  Wasn't

I believe so.

> this to be implemented as aligning the array type but not its element
> type?

Not sure how it would be possible.  There is the debug info question (perhaps
not a show stopper with early debug), another one is that for aggregates the
alignment is an essential part, we don't have for the same aggregate
differently aligned variants.  And we can have arrays of arrays, or arrays of
VLA structures etc.

Anyway, seems with the _Alignas(16) or __attribute__((aligned (16))) before the
struct keyword we actually don't have array of over-aligned fields, that is
what you get when using struct __attribute__((aligned (16))) { short aa; }
a[size];

That is somewhat simpler case, it is only the array field itself that is
aligned, array_ref_element_size is not involved at all in that case, but we
still compute an incorrect rli->offset_align somewhere for the b field.
While the previous field is 16 bytes aligned, the element is only 2 bytes
aligned and variable size, so b is only guaranteed to be 4 bytes aligned (2
bytes if it was say char b[size];).

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
I am testing fix for the missing resolution info. It turns out to be related to
rather early LTO hack to not put into symbol table symbols used only by
external definitions.

Concerning multiversioning this is different bug (it produces cgraph node with
wrong visibility flags) I will fix next.

[Bug target/84264] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
It ICEs on

  gcc_assert (!lra_in_progress && !reload_completed);

but this is called from the movv4si expander, and that is something LRA is
allowed to use.

[Bug other/80589] Typing mistakes in two messages

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

[Bug other/80589] Typing mistakes in two messages

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|8.0 |
  Known to fail||8.0

--- Comment #9 from Martin Liška  ---
(In reply to Göran Uddeborg from comment #8)
> This doesn't seem completely fixed.  I don't see the second mistake any
> more.  But the first mistake still remains in param.def, while the same
> string in doc/invoke.texi is fixed.

Confirmed, let me fix that.

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
> 
> --- Comment #9 from Jakub Jelinek  ---
> I think the bug is in the ARRAY_REF design, because at least in C one can have
> arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (,
> 3)
> is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make 
> sense,
> because what you really get from array_ref_element_size in cases where the 
> size
> of element is not a multiple of the TYPE_ALIGN_UNIT is something that doesn't
> have anything to do with the element size.
> Is that some Ada specific stuff?
> Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN,
> supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but
> something smaller.

It is an optimization so that for variable-sized stuff it's easier to
get at an alignment value.  We've experimented with removing this
but it regressed some cases (even in C).  Eric may know more and I
think there was a bug tracking this ... or some ml posts.

So arrays of over-aligned types in C do not contain padding?  Thus
the elements are not aligned but only the first element?  Wasn't
this to be implemented as aligning the array type but not its element
type?

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 43358 [details]
> gcc8-pr84252.patch
> 
> Full untested fix.

Thanks.  Bootstrapped & regression-tested on aarch64-linux-gnu, no new
failures.

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target|powerpc64-unknown-linux-gnu |
   |, aarch64-none-linux-gnu,   |
   |arm |
 CC||hjl.tools at gmail dot com

--- Comment #7 from H.J. Lu  ---
I also saw it on x86-64 and

spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc9.c
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt/.libs
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -lm -o
./mvc9.exe^M
lto1: fatal error: missing resolution data for foo.default.3^M
compilation terminated.^M
lto-wrapper: fatal error: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
returned 1 exit status^M
compilation terminated.^M
/usr/local/bin/ld: error: lto-wrapper failed^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
FAIL: gcc.target/i386/mvc9.c (test for excess errors)

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I think the bug is in the ARRAY_REF design, because at least in C one can have
arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (,
3)
is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make sense,
because what you really get from array_ref_element_size in cases where the size
of element is not a multiple of the TYPE_ALIGN_UNIT is something that doesn't
have anything to do with the element size.
Is that some Ada specific stuff?
Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN,
supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but
something smaller.

[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
I'm looking a bit into this. First blush I'm also wondering if we don't want
something like the below - which passes testing on x86_64-linux:

Index: pt.c
===
--- pt.c(revision 257438)
+++ pt.c(working copy)
@@ -17210,8 +17210,8 @@ tsubst_copy_and_build (tree t,
  r = build_x_indirect_ref (input_location, r, RO_UNARY_STAR,
complain|decltype_flag);

-   if (TREE_CODE (r) == INDIRECT_REF)
- REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t);
+   if (REF_PARENTHESIZED_P (t))
+ r = force_paren_expr (r);

RETURN (r);
   }

[Bug target/84264] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-07
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Needs -mlittle, -fstack-protector=strong, any -On with n > 0.

[Bug target/84265] ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. In case you're having trouble reproducing it on trunk, adding
-mcpu=cortex-a53 helps (some vector costs are probably involved)

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
MODULE MODULE_RA_GFDLETA
  REAL   , SAVE :: EM1(28,180)
  REAL   ,SAVE, DIMENSION(5040):: EM1V
  EQUIVALENCE (EM1V(1),EM1(1,1))
END MODULE module_RA_GFDLETA

[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So the issue here is that the early debug generated for module_ra_gfdleta.F90
contains relocations to text symbols.  That's a no-no.

So this is reproducible with just compiling this file with -flto -g, the
resulting object file has

Relocation section '.rela.gnu.debuglto_.debug_info' at offset 0xd6610 contains
4636 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
...
04d9  00860001 R_X86_64_64   
module_ra_gfdleta.eq.1 + 0
04ed  00860001 R_X86_64_64   
module_ra_gfdleta.eq.1 + 0
...

etc.  So reducing a testcase should be possible by grepping readelf -r (it's
the only relocation section) for module_ra_gfdleta.eq ...

Tryign to reduce.

[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Wed Feb  7 13:16:04 2018
New Revision: 257451

URL: https://gcc.gnu.org/viewcvs?rev=257451=gcc=rev
Log:
Revert behavior to r251316.

2018-02-07  Martin Liska  

PR c++/84059.
* class.c (add_method): Append argument value.
* cp-tree.h (maybe_version_functions): Add new argument.
* decl.c (decls_match): Call it if a declaration does not
have DECL_FUNCTION_VERSIONED.
(maybe_version_functions): record argument is added.
2018-02-07  Martin Liska  

PR c++/84059.
* g++.dg/ext/mv26.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/mv26.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13

[191919 at gmail dot com]

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

--- Comment #3 from 191919 <191919 at gmail dot com> ---
In macOS 10.12.6 with SIP disabled, the value of DYLD_LIBRARY_PATH was modified
to the same as in macOS 10.13.3, but the compilation speed was not affected.

I guess this is a regression of macOS code to handle DYLD_LIBRARY_PATH in an
SIP-disabled environment.

Long since OS X El Capitan which introduced SIP (aka rootless),
DYLD_LIBRARY_PATH was practically screened and no one complained about it, I
think it is safe to say that the line #3 of the following code taken from
configure.ac of gcc is not necessary and can be removed.

1 | case "${host}" in
2 |  *-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
3 |  *-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
4 |  *-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
5 |  *) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
6 | esac

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 43358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43358=edit
gcc8-pr84252.patch

Full untested fix.

[Bug target/84265] ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Priority|P3  |P1
   Last reconfirmed||2018-2-7
   Target Milestone|--- |8.0

[Bug target/84265] New: ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933

[marxin at gcc dot gnu.org]

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

Bug ID: 84265
   Summary: ICE in vect_permute_load_chain, at
tree-vect-data-refs.c:5933
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org, rdsandiford at googlemail dot com
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: aarch64-linux-gnu

Both seen on native machine and cross compiler:

$ cat ice.i
struct a
{
  unsigned long b;
  unsigned long c;
  int d;
  int *e;
  char f;
};

struct
{
  int g;
  struct a h[];
} i;

int j, k;
void l ()
{
  for (; k; k++)
j += (int) (i.h[k].c - i.h[k].b);
}

$ ./xgcc -B. -O3 ice.i -c
during GIMPLE pass: vect
ice.i: In function ‘l’:
ice.i:17:6: internal compiler error: in vect_permute_load_chain, at
tree-vect-data-refs.c:5933
 void l ()
  ^
0x134b950 vect_permute_load_chain
../../gcc/tree-vect-data-refs.c:5933
0x134c46f vect_transform_grouped_load(gimple*, vec, int, gimple_stmt_iterator*)
../../gcc/tree-vect-data-refs.c:6355
0xe31758 vectorizable_load
../../gcc/tree-vect-stmts.c:8366
0xe3c1df vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/tree-vect-stmts.c:9453
0xe4b522 vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:8872
0xe6b173 vectorize_loops()
../../gcc/tree-vectorizer.c:740

[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Martin has confirmed i686 host & target.  (not just target)

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #39 from Christophe Lyon  ---
Maybe we can demote this from P1?
I'm sure armeb is getting a lot of attention, given other bug reports.

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #38 from Christophe Lyon  ---
(In reply to Aldy Hernandez from comment #37)
> (In reply to Christophe Lyon from comment #31)
> > Created attachment 43352 [details]
> > Reduced testcase
> > 
> > I commented out most calls, since abort() is called from csub4.
> 
> Can you also remove the csub8, isub4, and isub8 unused functions as well?
> 
> I see you've commented out this in csub4:
> 
> !!  if (any(bb /= b)) call abort
> 
> I assume this is irrelevant to the failure?
> 
> Can you also verify that after these changes you have a revision of GCC for
> which this reduced testcase succeeds (regardless of the vect cost model
> rabbit hole), and a revision of GCC for which this fails?
> 
> I'm trying to make sure all this removing of stuff didn't cause an
> inconditional abort.

I don't speak fortran, but I thought the program did:
main-> call csub4-> call abort if some condition
In my testing, removing all calls but csub4 from main is sufficient to make the
program fail, and then it seems the first call to abort in csub4 is taken too.

What would it change to remove csub8/isub4/isub8? (except not generating dead
code, which is irrelevant to the current problem)


> 
> Also, is this only reproducible with -g?
I don't know, it's added by the torture harness. I wouldn't expect this to
change code generation, though.

> 
> BTW, no need to include the assembly.  I should be able to generate it with
> a cross ./cc1.

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Though, in e.g. *.ehcleanup2 dump we still have:
  pretmp.25_64 = D.1613_19 /[ex] 16;
  D.2749_73 = _61->b{off: pretmp.25_64 * 16}[0];
  ivtmp.35_86 = (long unsigned int) D.2749_73;
both before and after that revision, which matches what we emit now, but
somehow in the *.optimized dump it gets optimized away into:
  ivtmp.35 = (long unsigned int) >b{off: D.1613}[0];
where the exact division and multiplication are cancelled.  Though, /[ex] is a
guarantee that it is an exact division and thus we are invoking UB if at
runtime that isn't the case.
The *.original dump still doesn't have this:
s.b{off: (long unsigned int) SAVE_EXPR  * 2}[i] = 0;
but *.gimple does:
  D.1634 = D.1613 /[ex] 16;
  s.2->b{off: D.1634 * 16}[i] = 0;

[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Nathan Sidwell  ---
Well, that's exciting

[Bug target/84264] New: ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367

[marxin at gcc dot gnu.org]

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

Bug ID: 84264
   Summary: ICE in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:10367
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---

Following code snippet ICEs:

$ cat ice.ii
void _setjmp ();
void a (unsigned long *);
void
b ()
{
  for (;;)
{
  _setjmp ();
  unsigned long args[9]{};
  a (args);
}
}

$ ./xgcc -B. ice.ii -O1 -fstack-protector-strong -c
during RTL pass: reload
ice.ii: In function ‘void b()’:
ice.ii:12:1: internal compiler error: in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:10367
 }
 ^
0x10e2dd6 rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode)
../../gcc/config/rs6000/rs6000.c:10367
0x12b5e68 gen_movv4si(rtx_def*, rtx_def*)
../../gcc/config/rs6000/vector.md:142
0xa1e514 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc/recog.h:301
0xa1e514 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.c:3661
0xa1e8ce emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3757
0xbe3422 lra_emit_move(rtx_def*, rtx_def*)
../../gcc/lra.c:497
0xbfb8c4 curr_insn_transform
../../gcc/lra-constraints.c:4297
0xbfd137 lra_constraints(bool)
../../gcc/lra-constraints.c:4883
0xbe6864 lra(_IO_FILE*)
../../gcc/lra.c:2410
0xb9a821 do_reload
../../gcc/ira.c:5465
0xb9a821 execute
../../gcc/ira.c:5649

Happens both on native and x86 cross compiler.

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The difference with that revision is:
addq$2, %rax
cmpq%rcx, %rax
jne .L3
-   leaq(%r12,%rdx), %rdx
+   andq$-16, %rdx
xorl%eax, %eax
+   leaq(%r12,%rdx), %rdx

[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2018-2-7
   Target Milestone|--- |8.0

[Bug c++/84263] New: [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code

[marxin at gcc dot gnu.org]

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

Bug ID: 84263
   Summary: [8 Regression] ICE in lookup_page_table_entry at
gcc/ggc-page.c:646 on valid C++ code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---
  Host: i686-linux-gnu

Starting from r248826 we ICE on:

$ cat /tmp/ice.ii
namespace std {
template  struct b {
  int c;
  a d;
};
template  class g;
template  class initializer_list {
  int *e;
  unsigned f;
};
class h;
class j {
  typedef b i;

public:
  j();
  j(initializer_list);
};
template  struct m;
template  struct m {};
class h {
public:
  template  h(l &);
};
class G {
  G();
  j n;
};
G::G() { n = decltype(n){{0, ""}, {1, ".unoLineArrowEnd"}}; }
}

$ ./gcc/xg++ -Bgcc /tmp/ice.ii  --param ggc-min-expand=0 --param
ggc-min-heapsize=0 -c
/tmp/ice.ii:29:61: internal compiler error: Segmentation fault
 G::G() { n = decltype(n){{0, ""}, {1, ".unoLineArrowEnd"}}; }
 ^
0x8c82124 crash_signal
../../gcc/toplev.c:338
0x870f9d6 lookup_page_table_entry
../../gcc/ggc-page.c:646
0x87106f6 ggc_set_mark(void const*)
../../gcc/ggc-page.c:1536
0x864b7de gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:138
0x857f789 gt_ggc_mx(deferred_access_check&)
./gt-cp-parser.h:45
0x8581ab4 void gt_ggc_mx(vec*)
../../gcc/vec.h:1107
0x857f760 gt_ggc_mx_vec_deferred_access_check_va_gc_(void*)
./gt-cp-parser.h:37
0x857f838 gt_ggc_mx_tree_check(void*)
./gt-cp-parser.h:57
0x857f907 gt_ggc_mx(cp_token&)
./gt-cp-parser.h:79
0x8581aff void gt_ggc_mx(vec*)
../../gcc/vec.h:1107
0x857f8a4 gt_ggc_mx_vec_cp_token_va_gc_(void*)
./gt-cp-parser.h:68
0x857f986 gt_ggc_mx_cp_lexer(void*)
./gt-cp-parser.h:95
0x857fbdc gt_ggc_mx_cp_parser(void*)
./gt-cp-parser.h:155
0x892e005 ggc_mark_root_tab
../../gcc/ggc-common.c:77
0x892e082 ggc_mark_roots()
../../gcc/ggc-common.c:94
0x871167b ggc_collect()
../../gcc/ggc-page.c:2206
0x87b0a77 cgraph_node::finalize_function(tree_node*, bool)
../../gcc/cgraphunit.c:488
0x861b497 expand_or_defer_fn(tree_node*)
../../gcc/cp/semantics.c:4299
0x852f409 maybe_clone_body(tree_node*)
../../gcc/cp/optimize.c:670
0x861b378 expand_or_defer_fn_1(tree_node*)
../../gcc/cp/semantics.c:4272

I can repeat that only on i686 target.

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
This changed with r146817, so I'd look at a problem in expansion rather than
much earlier.  DECL_SIZE_UNIT should match what sizeof is, so you can't just
change it at will, it is part of the ABI.  Arrays of overaligned structures are
just weird, but I believe they don't grow the size of the elements, so only the
first array element is aligned and the remaining ones are not.

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 7 Feb 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
> 
> Aldy Hernandez  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
> 
> --- Comment #4 from Aldy Hernandez  ---
> [Looping in the experts: Hi Jakub.  Hi Richard.]
> 
> Imagine this:
> 
> struct big_container {
>   __attribute__((aligned(16)))
>   struct aa_container {
> short aa;
>   } a[size];
>   int b[size];
> } s;
> 
> While laying out the type of big_container, and looking at field "a" in
> place_field() we get a DECL_SIZE_UNIT(a) of SAVE_EXPR  * 2 (courtesy of
> update_alignment_for_field).
> 
> This size*2 is used in calculating the size of the record thus far:
> 
>   /* Now add size of this field to the size of the record.  If the size is
>  not constant, treat the field as being a multiple of bytes and just
>  adjust the offset, resetting the bit position.
> ...
>   else if (TREE_CODE (DECL_SIZE (field)) != INTEGER_CST
>|| TREE_OVERFLOW (DECL_SIZE (field)))
> {
>   rli->offset
> = size_binop (PLUS_EXPR, rli->offset,
>   fold_convert (sizetype,
> size_binop (CEIL_DIV_EXPR, rli->bitpos,
> bitsize_unit_node)));
>   rli->offset
> = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field));
>   rli->bitpos = bitsize_zero_node;
>   rli->offset_align = MIN (rli->offset_align, desired_align);
> }
> 
> (gdb) p debug_generic_stmt(rli.offset)
> (sizetype) SAVE_EXPR  * 2;
> 
> Which means that when we call place_field(b), we think we have to start at
> size*2.  Surely the start of field b should take into consideration the
> alignment of aa_container, no?
> 
> Question:
> 
> 1. Should DECL_SIZE_UNIT(a) include the size of the alignment padding?

I'm not sure whether the attribute aligns the array elements or the
array.  If it aligns the array then no.

> 2. Or, should the snippet above add the padding?

This is for b, so why?  There should be no padding needed.

> Or, am I missing something?
> 
> Thanks.
> 
>

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
[Looping in the experts: Hi Jakub.  Hi Richard.]

Imagine this:

struct big_container {
  __attribute__((aligned(16)))
  struct aa_container {
short aa;
  } a[size];
  int b[size];
} s;

While laying out the type of big_container, and looking at field "a" in
place_field() we get a DECL_SIZE_UNIT(a) of SAVE_EXPR  * 2 (courtesy of
update_alignment_for_field).

This size*2 is used in calculating the size of the record thus far:

  /* Now add size of this field to the size of the record.  If the size is
 not constant, treat the field as being a multiple of bytes and just
 adjust the offset, resetting the bit position.
...
  else if (TREE_CODE (DECL_SIZE (field)) != INTEGER_CST
   || TREE_OVERFLOW (DECL_SIZE (field)))
{
  rli->offset
= size_binop (PLUS_EXPR, rli->offset,
  fold_convert (sizetype,
size_binop (CEIL_DIV_EXPR, rli->bitpos,
bitsize_unit_node)));
  rli->offset
= size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field));
  rli->bitpos = bitsize_zero_node;
  rli->offset_align = MIN (rli->offset_align, desired_align);
}

(gdb) p debug_generic_stmt(rli.offset)
(sizetype) SAVE_EXPR  * 2;

Which means that when we call place_field(b), we think we have to start at
size*2.  Surely the start of field b should take into consideration the
alignment of aa_container, no?

Question:

1. Should DECL_SIZE_UNIT(a) include the size of the alignment padding?

2. Or, should the snippet above add the padding?

Or, am I missing something?

Thanks.

[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration

[gcc.account at lemaitre dot re]

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

--- Comment #6 from Florian Lemaitre  ---
I want auto-vectorization, not guided vectorization.
Basically, I try to write a fast RSQRT that will not break auto vectorization,
and this will be integrated in a large scale project where it is easy to tell
people "use this function" than to make them writing guided vectorization.

As far as I'm concerned, I'm completely fine with telling the compiler my
function doesn't have any side effect.
But this should be written somewhere for other people.

[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Serguei Kolos from comment #2)
> If you read my original message through the end you should have noticed that
> I have admitted that already. My question was different:
> 
> Is it normal that the same code (seemingly bogus) compiles fine with
> optimize tags and gives errors without them?

That question might have been more appropriate on the gcc-help mailing list,
not as a bug report.

Anyway, as I said, the answer is yes. It's expected.

[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Serguei Kolos from comment #0)
> According to the article 9.4.2/4 of the C++ standard the code is probably
> missing definitions of the c1, c2 and c3 constants:
> 
> "If a static data member is of const integral or const enumeration type, its
> declaration in the class definition can specify a constant initializer which
> shall be an integral constant expression (5.19). In that case, the member
> can appear in integral constant expressions within its scope. The member
> shall still be defined in a namespace scope if it is used in the program and
> the namespace scope definition shall not contain an initializer."

Right. https://isocpp.org/wiki/faq/ctors#link-errs-static-data-mems

> But what bothers me is the fact that the same (seemingly bogus) code
> compiles fine with -OX flag. Is that normal?

Yes, see
https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
#pragma omp declare simd or simd attribute say that on the definition compiler
should create alternate entry point(s) for the vectorized variants, and on
declarations that on the definition they were created, and that the compiler
can use them on vectorized loops.  That is true also on your testcase, just the
compiler decided not to use them because it couldn't prove it doesn't have a
side-effect that would prevent it.

What I don't understand is when you are using #pragma omp declare simd why
aren't you also using #pragma omp simd on the loops you want to vectorize.

[Bug c/84261] gcc fails to vectorize a function call

[marcin.krotkiewski at gmail dot com]

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

--- Comment #3 from Marcin Krotkiewski  ---
(In reply to Richard Biener from comment #1)
> Also vectorization of loops with using vectors isn't supported.

Not sure what you mean. If instead of a function call I do some floating point
computations in test1, e.g., 


#pragma omp declare simd simdlen(4)
double test1(double v1)
{
for(int i=0; i<4; i++){
v1 = v1*1.1;
}
return v1;
}


then the loop is 'vectorized' as expected, i.e., executed for short vector
arguments, and not for scalars.

[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization

[Serguei.Kolos at cern dot ch]

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

--- Comment #2 from Serguei Kolos  ---
If you read my original message through the end you should have noticed that I
have admitted that already. My question was different:

Is it normal that the same code (seemingly bogus) compiles fine with optimize
tags and gives errors without them?

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
That patch changed behavior rather than just change representation from hwis to
poly_int*.

--- gcc/var-tracking.c.jj   2018-01-04 00:43:15.007702432 +0100
+++ gcc/var-tracking.c  2018-02-07 11:13:59.388135311 +0100
@@ -1853,8 +1853,7 @@ static bool
 track_offset_p (poly_int64 offset, HOST_WIDE_INT *offset_out)
 {
   HOST_WIDE_INT const_offset;
-  if (!offset.is_constant (_offset)
-  || !IN_RANGE (const_offset, 0, MAX_VAR_PARTS - 1))
+  if (!offset.is_constant (_offset))
 return false;
   *offset_out = const_offset;
   return true;
@@ -5355,7 +5354,8 @@ track_loc_p (rtx loc, tree expr, poly_in
 }

   HOST_WIDE_INT const_offset;
-  if (!track_offset_p (offset, _offset))
+  if (!track_offset_p (offset, _offset)
+  || !IN_RANGE (const_offset, 0, MAX_VAR_PARTS - 1))
 return false;

   if (mode_out)

would restore previous behavior.

The primary point of MAX_VAR_PARTS is to make sure that no value is tracked in
more than 16 parts, which in many cases is enforced just by giving up if we
need more than 16 bytes of memory or offsets above that, but other parts of the
code just care that not more than 16 unique offsets are tracked for the var.

The patch added:
  /* vt_get_decl_and_offset has already checked that the offset
 is a valid variable part.  */
comment which just isn't correct, because vt_get_decl_and_offset could have
failed and we'd still get here.

So, another possible fix is to:
--- gcc/var-tracking.c.jj   2018-01-04 00:43:15.007702432 +0100
+++ gcc/var-tracking.c  2018-02-07 12:47:09.735980882 +0100
@@ -9653,6 +9653,7 @@ vt_add_function_parameter (tree parm)
   poly_int64 offset;
   dataflow_set *out;
   decl_or_value dv;
+  bool incoming_ok = true;

   if (TREE_CODE (parm) != PARM_DECL)
 return;
@@ -9743,6 +9744,7 @@ vt_add_function_parameter (tree parm)

   if (!vt_get_decl_and_offset (incoming, , ))
 {
+  incoming_ok = false;
   if (MEM_P (incoming))
{
  /* This means argument is passed by invisible reference.  */
@@ -9861,6 +9863,10 @@ vt_add_function_parameter (tree parm)
 {
   int i;

+  /* The following code relies on vt_get_decl_and_offset returning true
for
+incoming, which might not be always the case.  */
+  if (!incoming_ok)
+   return;
   for (i = 0; i < XVECLEN (incoming, 0); i++)
{
  rtx reg = XEXP (XVECEXP (incoming, 0, i), 0);

[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration

[gcc.account at lemaitre dot re]

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

--- Comment #4 from Florian Lemaitre  ---
Ah... ok. I understand.
Indeed, declaring the function const works as expected.

So, I guess we can say it is not a bug, and close the bug report?

However, I really think this should be documented somewhere.
Currently, there is no mention of side effects within GCC existing
documentation
either here:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
or here (referenced by previous page):
https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt