[Bug libstdc++/68222] _Safe_iterator provides operators the wrapped iterator can't actually support

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

[Bug c++/85117] New: ARM: Wrong Warning Emits: parameter passing for argument of type 'Handle' changed in GCC 7.1

[manjian2006 at gmail dot com]

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

Bug ID: 85117
   Summary: ARM: Wrong Warning Emits: parameter passing for
argument of type 'Handle' changed in GCC 7.1
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manjian2006 at gmail dot com
  Target Milestone: ---

typedef enum { } Unknown;

class HandleBase {
public:
  void** m_slot;
};

template struct HandleTypes {
typedef T* ExternalType;
};

template<> struct HandleTypes {
typedef long long ExternalType;
};

template 
class Handle: public HandleBase {
public:
  typedef typename HandleTypes::ExternalType ExternalType;

};

void foo(Handle h) {
  extern void bar(Handle h);
  bar(h);
}


The above code emits wrong warning like the title.
This is caused by arm_needs_doubleword_align fails to omit TYPE_DECL when
traversals the fields of a aggregate type.

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

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-29
 Ever confirmed|0   |1

--- Comment #4 from Alan Modra  ---
Here's some analysis.

Yes, with -O, variable v1 is indeed in a register, v31 aka vs63 before the call
to thrower.  This should be fine.  Variables don't need to be in memory for
exceptions to work..

thrower() sets up a frame
stwu 1,-288(1)
stores the vector reg of interest to the stack
li 0,208
stvx 31,1,0
and accurately describes that save with
.cfi_offset 108, -80

At -O, thrower() indeed uses the non-volatile v20..v31, and doesn't restore the
saved values itself.  That's all good.  We are relying on the exception
handling mechanism, ie. frame unwinding to restore the value of v31.

With 8.0.1 20180322 the test passes for me at -O -maltivec -m32 -mcpu=power7,
with LD_LIBRARY_PATH set to pick up the newly built libstdc++ and libgcc.  So
perhaps the problem has been fixed, or maybe you were somehow picking up a bad
version of the unwinder?

Note that my build was with --build=powerpc64-linux --prefix=/home/amodra/gnu
--with-cpu=power8 --enable-valgrind-annotations --enable-gnu-indirect-functions
--enable-__cxa-exit --enable-secure-plt --disable-nls --enable-languages=all
--enable-lto

I'm also using bleeding edge binutils.

[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
It's diagnosed with -Wpedantic (ditto for decltype).  Agreed that it should be
rejected in C++ just like it is in C.

$ cat pr84701.C && gcc -S -Wall -Wextra -Wpedantic pr84701.C
typedef short foo_t;
foo_t s = -1;  /*  */

unsigned u = (unsigned foo_t)s; /* result is  */
unsigned v = (unsigned typeof(s))s; /* result is  */

pr84701.C:4:24: warning: long, short, signed or unsigned used invalidly for
‘type name’ [-Wpedantic]
 unsigned u = (unsigned foo_t)s; /* result is  */
^
pr84701.C:5:32: warning: long, short, signed or unsigned used invalidly for
‘type name’ [-Wpedantic]
 unsigned v = (unsigned typeof(s))s; /* result is  */
^

[Bug driver/84750] Both the driver and cc1 warn for Target Warn option properties

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed with a powepc64le cross:

$ gcc -S -mstring -xc - < /dev/null
xgcc: warning: ‘-mstring’ is deprecated
cc1: warning: ‘-mstring’ is deprecated

With a native x86_64 gcc:

$ gcc -S -mpcommit -xc - < /dev/null
xgcc: warning: ‘-mpcommit’ was deprecated
cc1: warning: ‘-mpcommit’ was deprecated

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[njs at pobox dot com]

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

--- Comment #5 from Nathaniel J. Smith  ---
Julian, are you able to test the patch? I don't have a reproduction setup
currently...

[Bug c++/85116] New: std::min_element does not optimize well with inlined predicate

[christopher.schell at oculus dot com]

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

Bug ID: 85116
   Summary: std::min_element does not optimize well with inlined
predicate
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christopher.schell at oculus dot com
  Target Milestone: ---

According to godbolt (https://godbolt.org/g/igzsnL), the following code:

#define SIZE 1000
std::array testArray;

int getMinIdxCPPStyle(double offset)
{
auto minElement = std::min_element(std::cbegin(testArray),
std::cend(testArray), [offset](auto a, auto b) { return std::abs(a - offset) <
std::abs(b - offset); });
return std::distance(std::cbegin(testArray), minElement );
}

generates as the following under -O3

getMinIdxCPPStyle(double):
  movq xmm3, QWORD PTR .LC1[rip]
  mov eax, OFFSET FLAT:testArray
  mov edx, OFFSET FLAT:testArray+8
.L11:
  movsd xmm1, QWORD PTR [rdx]
  movsd xmm2, QWORD PTR [rax]
  subsd xmm1, xmm0
  subsd xmm2, xmm0
  andpd xmm1, xmm3
  andpd xmm2, xmm3
  ucomisd xmm2, xmm1
  cmova rax, rdx
  add rdx, 8
  cmp rdx, OFFSET FLAT:testArray+8000
  jne .L11
  sub rax, OFFSET FLAT:testArray
  sar rax, 3
  ret

The problem being that the typical c-style loop beats this easily due to
caching the minimum value and not fetching it and recomputing it. Is there a
reason that the generated code should not cache the minimum value in a register
instead of probably causing a cache miss by fetching it and then unnecessarily
running the computations on it again?

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[amodra at gmail dot com]

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

--- Comment #8 from Alan Modra  ---
Hi Breno, the first gcc-8 has not yet been released (current aim is for a
release mid April), nor has there been a release from the gcc-7 or gcc-6
branches containing this bug fix.  I missed out on gcc-7.3 by a few days.

Incidentally, https://gcc.gnu.org/develop.html#timeline is a useful page giving
history of gcc releases.

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #8 from Peter Bergner  ---
Fixed on trunk.  Do we want backports?

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Thu Mar 29 00:06:31 2018
New Revision: 258943

URL: https://gcc.gnu.org/viewcvs?rev=258943=gcc=rev
Log:
PR target/84912
* config/rs6000/rs6000.h (RS6000_BTM_POWERPC64): New define.
(RS6000_BTM_COMMON): Add RS6000_BTM_POWERPC64.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Add support
for RS6000_BTM_POWERPC64.
(rs6000_invalid_builtin): Add handling for RS6000_BTM_POWERPC64
(rs6000_builtin_mask_names): Add RS6000_BTM_POWERPC64.
* config/rs6000/rs6000-builtin.def (BU_P7_POWERPC64_MISC_2): New macro
definition.
(DIVDE): Use it.
(DIVDEU): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h

[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #2 from Jonathan Wakely  ---
This is a front-end bug not library bug, the failing cases can be reduced to:

struct array { char data[10]; };

struct A {
  array x; 
  A(array arr) : x(arr) {}
};
A struct_from_ctr1{ {{"abcdefghi"}} };


Or even more simply:

struct array { char data[2]; };

void f(array) {}

void g() {
f({{"a"}});
}

[Bug target/85075] powerpc: ICE in iszero testcase

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 Ever confirmed|0   |1

[Bug testsuite/82920] cet test failures on darwin

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #0)

Maybe these tests should be limited to Linux targets.

[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #6 from Carl Love  ---
gcc/testsuite/gcc.target/powerpc/builtin-fctid-fctiw-runnable.c
 was fixed by reverting the patch that added them.  Commit 258492

gcc/testsuite/gcc.target/powerpc/sse2-pmuludq-1.c
  was fixed by commit 258539

At this point all of the test cases that were generating and ICE for
-mcpu=power7 have been fixed.  


Closing the issue.

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #12 from Carl Love  ---
Commit 258942 removed the builtins for  __builtin_fctid and  __builtin_fctiw

[Bug tree-optimization/84818] integer_onep must not be used for i18n

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-28
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c/84883] No warning when dereferencing an array as a pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Here's how I think this enhancement could work.  For every access to the first
element of an array via the -> operator the warning would look for a pointer
with a similar name that either a) points to the first element of the same
array object, or b) has the same type as the array, and trigger if it found a
match.  (a) requires data flow analysis so the warning would have be
implemented in the middle-end.  I don't think the middle-end has access to the
algorithm that compares names for similarity so it would have to move.  (b)
could be implemented in the C/C++ front ends which do have access to the
algorithm but not to data flow analysis, so the warning there would be quite
simplistic (basically limited to type and name matching) and could be prone to
false positives.

I'm not sure how often this problem comes up but given the complexities above I
suspect the RoI may not be there.

[Bug tree-optimization/85115] New: Failure to (auto)vectorize sqrtf

[robertw89 at googlemail dot com]

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

Bug ID: 85115
   Summary: Failure to (auto)vectorize sqrtf
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robertw89 at googlemail dot com
  Target Milestone: ---

Fails to (auto)vectorize the code bellow with the flags

-O3 -mavx

#include 

void simdSqrt(
float * __restrict__ a,
float * __restrict__ res,
int size)
{
int i;

float *aAligned = (float*)__builtin_assume_aligned(a, 32);
float *resAligned = (float*)__builtin_assume_aligned(res, 32);

for (i = 0; i < size; i++) {
resAligned[i] = sqrtf(aAligned[i]);
}
}

produces (as displayed by https://godbolt.org/)

simdSqrt(float*, float*, int):
testedx, edx
jle .L8
lea eax, [rdx-1]
pushr12
vxorps  xmm2, xmm2, xmm2
lea r12, [rdi+4+rax*4]
sub rsp, 32
.L3:
vmovss  xmm0, DWORD PTR [rdi]
vucomissxmm2, xmm0
vsqrtss xmm1, xmm1, xmm0
ja  .L12
add rdi, 4
vmovss  DWORD PTR [rsi], xmm1
add rsi, 4
cmp rdi, r12
jne .L3
.L6:
add rsp, 32
pop r12
ret
.L8:
rep ret
.L12:
vmovss  DWORD PTR [rsp+28], xmm2
mov QWORD PTR [rsp+16], rsi
mov QWORD PTR [rsp+8], rdi
vmovss  DWORD PTR [rsp+24], xmm1
callsqrtf
mov rdi, QWORD PTR [rsp+8]
mov rsi, QWORD PTR [rsp+16]
vmovss  xmm1, DWORD PTR [rsp+24]
vmovss  xmm2, DWORD PTR [rsp+28]
add rdi, 4
vmovss  DWORD PTR [rsi], xmm1
add rsi, 4
cmp rdi, r12
jne .L3
jmp .L6

[Bug c++/84974] [8 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

[Bug libstdc++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 CC||msebor at gcc dot gnu.org
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I can confirm that GCC rejects the example and Clang accepts it but I don't
know if that's because of a bug/missing feature in GCC or libstdc++ or an
extension in Clang or libc++.  Let me set the component to libstdc++ and let
Jonathan adjust it if/as necessary.

[Bug c++/84993] Combination of fieldnames and accessor suggestions for misspelled private fields

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I noticed this while experimenting with the suggestions.  Your idea sounds like
a definite improvement.

As an aside, the error uses the term "member" in accordance with the standard
terminology (both C and C++) but the note refers to the field 'double
foo::m_ratio'  It would be more consistent to use "member" in both.

[Bug c++/85114] New: -fstack-check causes internal compiler error

[tk at giga dot or.at]

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

Bug ID: 85114
   Summary: -fstack-check causes internal compiler error
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tk at giga dot or.at
  Target Milestone: ---

When compiling thunderbird 52.7.0 (currently latest version) with gcc 6.4.0 as
distributed with NetBSD, on NetBSD-8.99.14/amd64, with -fstack-check, I see the
following error:

In file included from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:11:0:
/scratch/mail/thunderbird/work/thunderbird-52.6.0/mozilla/layout/generic/nsBlockFrame.cpp:
In member function 'virtual nscoord
nsBlockFrame::GetMinISize(nsRenderingContext*)':
/scratch/mail/thunderbird/work/thunderbird-52.6.0/mozilla/layout/generic/nsBlockFrame.cpp:704:1:
internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1429
 nsBlockFrame::GetMinISize(nsRenderingContext *aRenderingContext)
 ^~~~
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
/scratch/mail/thunderbird/work/thunderbird-52.6.0/mozilla/config/rules.mk:951:
recipe for target 'Unified_cpp_layout_generic1.o' failed


When I removed the -fstack-check, the internal compiler error is gone and I
see:

In file included from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:101:0:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:
In member function ‘nscoord nsIFrame::ComputeISizeValue(nsRenderingContext*,
nscoord, nscoord, nscoord, const nsStyleCoord&, nsIFrame::ComputeSizeFlags)’:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:5434:11:
warning: ‘result’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   nscoord result;
   ^~
In file included from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:101:0:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:
In member function ‘mozilla::LogicalSize
nsFrame::ComputeSizeWithIntrinsicDimensions(nsRenderingContext*,
mozilla::WritingMode, const mozilla::IntrinsicSize&, nsSize, const
mozilla::LogicalSize&, const mozilla::LogicalSize&, const
mozilla::LogicalSize&, const mozilla::LogicalSize&,
nsIFrame::ComputeSizeFlags)’:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:5006:38:
warning: ‘bSize’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   nscoord iSize, minISize, maxISize, bSize, minBSize, maxBSize;
  ^
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:5006:11:
warning: ‘iSize’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   nscoord iSize, minISize, maxISize, bSize, minBSize, maxBSize;
   ^
In file included from
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsBackdropFrame.cpp:11:0,
 from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:2:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/base/nsDisplayList.h:
In member function ‘void
nsIFrame::BuildDisplayListForStackingContext(nsDisplayListBuilder*, const
nsRect&, nsDisplayList*)’:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/base/nsDisplayList.h:1115:33:
warning: ‘*((void*)(&
autoPreserves3DContext)+8).nsDisplayListBuilder::AutoPreserves3DContext::mBuilder’
may be used uninitialized in this function [-Wmaybe-uninitialized]
   mBuilder->mPreserves3DCtx = mSavedCtx;
   ~~^~~
In file included from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:101:0:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFrame.cpp:2136:55:
note: ‘*((void*)(&
autoPreserves3DContext)+8).nsDisplayListBuilder::AutoPreserves3DContext::mBuilder’
was declared here
   Maybe autoPreserves3DContext;
   ^~
In file included from
/scratch/mail/thunderbird/work/build/layout/generic/Unified_cpp_layout_generic1.cpp:74:0:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFlexContainerFrame.cpp:
In member function ‘void nsFlexContainerFrame::DoFlexLayout(nsPresContext*,
nsIFrame::ReflowOutput&, const ReflowInput&, nsReflowStatus&, nscoord, nscoord,
nsTArray&, const
nsFlexContainerFrame::FlexboxAxisTracker&)’:
/scratch/mail/thunderbird/work/thunderbird-52.7.0/mozilla/layout/generic/nsFlexContainerFrame.cpp:4485:29:
warning: ‘flexContainerAscent’ may be used 

[Bug c++/85011] GCC complains that 2 identical function prototypes are different

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
I'll confirm this as rejects-valid.  I didn't take the time to look it up in
the standard but since the non-template case below is accepted I would expect
the template case to be as well.  It doesn't appear to be a regression.

struct foo
{
  int x;

  auto f1() -> decltype (x);
};

auto foo::f1() -> decltype (this->x) {}

[Bug c++/85045] [8 Regression] ICE+SIGILL on valid C++ code: cxx_pretty_printer::postfix_expression(tree_node*) (), at cp/cxx-pretty-print.c:482

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||schlong at cock dot li

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

[Bug c++/85107] Internal compiler error when casting double to int

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
With the top of trunk (258935) I get:

$ cat pr85107.C && gcc -S pr85107.C
double dbDivisor{ 1.0 };
double dbQuotient{ static_cast(1.0 / dbDivisor) };
pr85107.C:2:20: warning: narrowing conversion of ‘(int)(1.0e+0 / dbDivisor)’
from ‘int’ to ‘double’ inside { } [-Wnarrowing]
 double dbQuotient{ static_cast(1.0 / dbDivisor) };
^

With r258676 I see the SEGV below.  The stack trace suggests infinite recursion
in the pretty-printer.

Program received signal SIGSEGV, Segmentation fault.
0x0089d204 in cxx_pretty_printer::unary_expression (
this=, t=)
at ../../gcc/cp/cxx-pretty-print.c:754
754 {


I'm pretty sure this is a duplicate of bug 85045 (backing out the patch brings
the SEGV back).  If not, please reopen.

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

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Really confirmed also with the first test case, similar stack trace:

internal compiler error: in build_over_call, at cp/call.c:8149
 Part(const std::int32_t& value) : value{std::to_string(value)} {}
  ^
0x80e3f9 build_over_call
/ssd/src/gcc/svn/gcc/cp/call.c:8143
0x814701 build_new_method_call_1
/ssd/src/gcc/svn/gcc/cp/call.c:9363
...

[Bug c++/85110] Missing underlines for some bad arguments

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from David Malcolm  ---
Candidate patches:
 * https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01519.html
 * https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01518.html

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[dominiq at lps dot ens.fr]

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

Bug 83319 Summary: [7/8 Regression] ICE on use of allocatable component in 
derived type coarray defined in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83319

   What|Removed |Added

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

[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #9 from Dominique d'Humieres  ---
> So, is this fixed now and can be RESOLVED FIXED?

I think so.

[Bug c++/85108] [7/8 Regression] Incorrect warning for constexpr lambda with -Wunused-but-set-variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||diagnostic
   Last reconfirmed||2018-03-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Incorrect warning for   |[7/8 Regression] Incorrect
   |constexpr lambda with   |warning for constexpr
   |-Wunused-but-set-variable   |lambda with
   ||-Wunused-but-set-variable
  Known to fail||7.3.0, 8.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r239267 (gcc 7.0.0):

r239267 | jason | 2016-08-09 00:33:42 -0400 (Tue, 09 Aug 2016) | 7 lines

Fix empty class parameters with constexpr.

PR c++/67131
* class.c (is_really_empty_class): Call complete_type.
* constexpr.c (cxx_eval_constant_expression): Check
is_really_empty_class.
(potential_constant_expression_1): Likewise.  Check for error type.

[Bug c++/85112] [8 Regression] ICE with invalid constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r249083 (gcc 8.0.0):

r249083 | jason | 2017-06-09 18:46:51 -0400 (Fri, 09 Jun 2017) | 5 lines

Don't fold conversion from a constant variable.

* call.c (convert_like_real): Remove "inner" parameter.
Don't replace a constant with its value.
* cp-gimplify.c (cp_fully_fold): Use cp_fold_rvalue.

[Bug c++/85087] call to a non-const member function on a const lvalue accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 Ever confirmed|0   |1

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Confirmed with the stack trace below (for the test case in comment #1).  The
failing assertion is the same on as in bug 85101 so it's likely a duplicate.

pr85092.C: In constructor ‘IntSet::IntSet(int)’:
pr85092.C:4:52: internal compiler error: in build_over_call, at cp/call.c:8149
 IntSet(int value) : value_{std::set{value}} {}
^
0x80e3f9 build_over_call
/ssd/src/gcc/svn/gcc/cp/call.c:8143
0x814701 build_new_method_call_1
/ssd/src/gcc/svn/gcc/cp/call.c:9363
0x814ce3 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/ssd/src/gcc/svn/gcc/cp/call.c:9439
0x811dc8 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/call.c:8969
0x93da93 expand_default_init
/ssd/src/gcc/svn/gcc/cp/init.c:1888
0x93e0fb expand_aggr_init_1
/ssd/src/gcc/svn/gcc/cp/init.c:2002
0x93cd0c build_aggr_init(tree_node*, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/init.c:1743
0x938fa4 perform_member_init
/ssd/src/gcc/svn/gcc/cp/init.c:847
0x93b4cd emit_mem_initializers(tree_node*)
/ssd/src/gcc/svn/gcc/cp/init.c:1294
0xab4d2a finish_mem_initializers(tree_node*)
/ssd/src/gcc/svn/gcc/cp/semantics.c:1704
0x9c8078 cp_parser_mem_initializer_list
/ssd/src/gcc/svn/gcc/cp/parser.c:14450
0x9c794d cp_parser_ctor_initializer_opt
/ssd/src/gcc/svn/gcc/cp/parser.c:14363
0x9d6270 cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/svn/gcc/cp/parser.c:21811
0x9e0563 cp_parser_function_definition_after_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:26847
0x9e2dce cp_parser_late_parsing_for_member
/ssd/src/gcc/svn/gcc/cp/parser.c:27728
0x9d8a5f cp_parser_class_specifier_1
/ssd/src/gcc/svn/gcc/cp/parser.c:22765
0x9d8b29 cp_parser_class_specifier
/ssd/src/gcc/svn/gcc/cp/parser.c:22791
0x9cbef5 cp_parser_type_specifier
/ssd/src/gcc/svn/gcc/cp/parser.c:16776
0x9c6642 cp_parser_decl_specifier_seq
/ssd/src/gcc/svn/gcc/cp/parser.c:13631
0x9c4e1a cp_parser_simple_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:12940
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  ---
Author: mikael
Date: Wed Mar 28 20:12:55 2018
New Revision: 258935

URL: https://gcc.gnu.org/viewcvs?rev=258935=gcc=rev
Log:

PR fortran/69497
* symbol.c (gfc_symbol_done_2): Start freeing namespaces
from the root.
(gfc_free_namespace): Restore assert (revert r258839). 


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

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The ICE is due to the assertion below failing.

  /* In C++17 we shouldn't be copying a TARGET_EXPR except into a base
 subobject.  */
  if (CHECKING_P && cxx_dialect >= cxx17)
gcc_assert (TREE_CODE (arg) != TARGET_EXPR
|| force_elide
/* It's from binding the ref parm to a packed field. */
|| convs[0]->need_temporary_p
|| seen_error ()
/* See unsafe_copy_elision_p.  */
|| DECL_BASE_CONSTRUCTOR_P (fn));

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Wed Mar 28 20:09:02 2018
New Revision: 258933

URL: https://gcc.gnu.org/viewcvs?rev=258933=gcc=rev
Log:
gcc/
PR target/84912
* config/rs6000/rs6000-builtin.def (DIVWEO): Delete macro expansion.
(DIVWEUO): Likewise.
(DIVDEO): Likewise.
(DIVDEUO): Likewise.
* config/rs6000/rs6000.c (builtin_function_type): Remove support for
DIVWEUO and DIVDEUO.
* config/rs6000/rs6000.md (UNSPEC_DIVEO, UNSPEC_DIVEUO): Delete
unspecs.
(UNSPEC_DIV_EXTEND): Remove deleted unspecs.
(div_extend): Likewise.
* doc/extend.texi (__builtin_divweo): Remove documention for deleted
builtin function.
(__builtin_divweuo): Likewise.
(__builtin_divdeo): Likewise.
(__builtin_divdeuo): Likewise.

gcc/testsuite/
PR target/84912
* gcc.target/powerpc/extend-divide-1.c (div_weo): Remove test for
deleted builtin function.
(div_weuo): Likewise.
* gcc.target/powerpc/extend-divide-2.c (div_deo): Likewise.
(div_deuo): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/extend-divide-1.c
trunk/gcc/testsuite/gcc.target/powerpc/extend-divide-2.c

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Confirmed with the reduced test case below:

$ cat pr85101.ii && gcc -O2 -S -Wall -std=c++17 pr85101.ii
namespace std {

template 
struct initializer_list {
  const T *a;
  unsigned long n;
};

}

struct A
{
  A (std::initializer_list);
};

A f ();

A a { f () };
pr85101.ii:18:12: internal compiler error: in build_over_call, at
cp/call.c:8149
 A a { f () };
^
0x80e3f9 build_over_call
/ssd/src/gcc/svn/gcc/cp/call.c:8143
0x814701 build_new_method_call_1
/ssd/src/gcc/svn/gcc/cp/call.c:9363
0x814ce3 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/ssd/src/gcc/svn/gcc/cp/call.c:9439
0x811dc8 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/call.c:8969
0x93da7f expand_default_init
/ssd/src/gcc/svn/gcc/cp/init.c:1888
0x93e0e7 expand_aggr_init_1
/ssd/src/gcc/svn/gcc/cp/init.c:2002
0x93ccf8 build_aggr_init(tree_node*, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/init.c:1743
0x8c9e67 build_aggr_init_full_exprs
/ssd/src/gcc/svn/gcc/cp/decl.c:6273
0x8cad62 check_initializer
/ssd/src/gcc/svn/gcc/cp/decl.c:6422
0x8ce90b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/ssd/src/gcc/svn/gcc/cp/decl.c:7127
0x9d1fb7 cp_parser_init_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:19749
0x9c522a cp_parser_simple_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:13067
0x9c4d8e cp_parser_block_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:12885
0x9c4b01 cp_parser_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:12782
0x9c4649 cp_parser_declaration_seq_opt
/ssd/src/gcc/svn/gcc/cp/parser.c:12658
0x9b25c4 cp_parser_translation_unit
/ssd/src/gcc/svn/gcc/cp/parser.c:4563
0xa06eef c_parse_file()
/ssd/src/gcc/svn/gcc/cp/parser.c:39024
0xbb02e6 c_common_parse_file()
/ssd/src/gcc/svn/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
So, is this fixed now and can be RESOLVED FIXED?

[Bug inline-asm/84679] [6/7/8 Regression] internal compiler error: in lra_eliminate_reg_if_possible, at lra-eliminations.c:1382

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fixed by the patch for PR84682 (r258393).

[Bug c++/85113] New: [7/8 Regression] ICE with __builtin_constant_p

[reichelt at gcc dot gnu.org]

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

Bug ID: 85113
   Summary: [7/8 Regression] ICE with __builtin_constant_p
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE on trunk:

===
template struct A {};

constexpr int foo()
{
  A<__builtin_constant_p(0)> a{};
  return 0;
}
===

bug.cc: In function 'constexpr int foo()':
bug.cc:5:28: internal compiler error: in coerce_template_parms, at cp/pt.c:8502
   A<__builtin_constant_p(0)> a{};
^
0x64a25b coerce_template_parms
../../gcc/gcc/cp/pt.c:8502
0x97b406 lookup_template_class_1
../../gcc/gcc/cp/pt.c:9016
0x97b406 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9365
0x9abdfd finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3227
0x928364 cp_parser_template_id
../../gcc/gcc/cp/parser.c:15852
0x92846e cp_parser_class_name
../../gcc/gcc/cp/parser.c:22383
0x93521f cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6580
0x93521f cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6266
0x936c35 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:17179
0x930ce5 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16852
0x93e096 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13627
0x943790 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12937
0x944738 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12884
0x945169 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12478
0x9236d3 cp_parser_statement
../../gcc/gcc/cp/parser.c:10927
0x924640 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11276
0x924717 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11230
0x93b230 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21789
0x93b230 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21826
0x93bae0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26847
Please submit a full bug report, [etc.]

The regression was introduced between 2018-03-17 and 2018-03-20.

In addition the code is rejected on the GCC 7 branch (7.3.1)
while it was still accepted in GCC 7.3.0.

[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #7 from David Malcolm  ---
A downstream bug report that appears to be the same issue:
  https://bugzilla.redhat.com/show_bug.cgi?id=1560932
(seems to be fixed on gcc-7-branch by r258233)

[Bug c++/85028] [8 Regression] ICE on invalid C++ code: in tsubst_default_argument, at cp/pt.c:12340

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

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

[Bug target/85095] [6/7 Regression] worse code generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] worse|[6/7 Regression] worse code
   |code generated  |generated

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85112] New: [8 Regression] ICE with invalid constexpr

[reichelt at gcc dot gnu.org]

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

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

The following invalid code snippet triggers an ICE on trunk:

===
struct A
{
  int m;
  int n : 4;
};

int i;

void foo()
{
  constexpr int j = i;
  A a;
  a.n = j;
}
===

bug.cc: In function 'void foo()':
bug.cc:11:21: error: the value of 'i' is not usable in a constant expression
   constexpr int j = i;
 ^
bug.cc:7:5: note: 'int i' is not const
 int i;
 ^
bug.cc:13:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86
   a.n = j;
   ^~~
0x78cafe tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9372
0x6ce53d tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3258
0x6ce53d useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gcc/gimple-expr.c:86
0x10bc78a tree_ssa_strip_useless_type_conversions(tree_node*)
../../gcc/gcc/tree-ssa.c:1253
0xc645a7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11330
0xc74513 gimplify_modify_expr
../../gcc/gcc/gimplify.c:5625
0xc65c10 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11434
0xc68d16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6658
0xc66bb2 gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:6399
0xc66bb2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11811
0xc68d16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6658
0xc664bb gimplify_statement_list
../../gcc/gcc/gimplify.c:1764
0xc664bb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11863
0xc68d16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6658
0xc69a3c gimplify_bind_expr
../../gcc/gcc/gimplify.c:1331
0xc66b2a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11635
0xc68d16 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6658
0xc6a70a gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:12635
0xc6ac04 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:12800
0xaef847 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:670
Please submit a full bug report, [etc.]

The regression was introduced between 2017-06-06 and 2017-06-10.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

--- Comment #40 from Jakub Jelinek  ---
Workaround applied, should work now even with -flto.  Would be nice to report
it to SPEC though, to make the code accept a few ulps difference.

[Bug c++/85028] [8 Regression] ICE on invalid C++ code: in tsubst_default_argument, at cp/pt.c:12340

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Mar 28 19:21:41 2018
New Revision: 258932

URL: https://gcc.gnu.org/viewcvs?rev=258932=gcc=rev
Log:
/cp
2018-03-28  Paolo Carlini  

PR c++/85028
* pt.c (tsubst_default_argument): Early return if the type of the
parameter is erroneous.

/testsuite
2018-03-28  Paolo Carlini  

PR c++/85028
* g++.dg/other/default13.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/default13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85095] [6/7/8 Regression] worse code generated

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 28 19:16:50 2018
New Revision: 258931

URL: https://gcc.gnu.org/viewcvs?rev=258931=gcc=rev
Log:
PR target/85095
* config/i386/i386.md (*add3_carry_0, *addsi3_carry_zext_0,
*sub3_carry_0, *subsi3_carry_zext_0): New patterns.

* gcc.target/i386/pr85095-1.c: New test.
* gcc.target/i386/pr85095-2.c: New test.
* gcc.c-torture/execute/pr85095.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85095.c
trunk/gcc/testsuite/gcc.target/i386/pr85095-1.c
trunk/gcc/testsuite/gcc.target/i386/pr85095-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 28 19:15:39 2018
New Revision: 258930

URL: https://gcc.gnu.org/viewcvs?rev=258930=gcc=rev
Log:
PR tree-optimization/82004
* gimple-match-head.c (optimize_pow_to_exp): New function.
* match.pd (pow(C,x) -> exp(log(C)*x)): Wrap with #if GIMPLE.
Don't fold to exp if optimize_pow_to_exp is false.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr82004.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-match-head.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[anlauf at gmx dot de]

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

--- Comment #10 from Harald Anlauf  ---
The structure constructor seems to lose the character length, which
can be best seen from the tree dump.

program p
  implicit none
  type t
!   character(3) :: c1(2) = [ 'b', 'c']   ! OK
!   character(3) :: c2(2) = [ character(1) :: 'b', 'c'] // "" ! OK
!   character(3) :: c3(2) = [ 'b', 'c'] // "" ! ICE
character(3) :: c4(2) = [ '' , '' ] // "" ! wrong output
  end type t
  type(t)  :: z
! print *, "'", z%c1(2), "'" ! OK
! print *, "'", z%c2(2), "'" ! OK
! print *, "'", z%c3(2), "'" ! ICE
  print *, "'", z%c4(2), "'" ! wrong output: '^@^@^@'
end

% grep c4 pr68155-zz4b.f90.003t.original
  static struct t z = {.c4={"", ""}};  <--- length 0!
_gfortran_transfer_character_write (_parm.0, [1], 3);

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug fortran/85111] [8 Regression] ICE in min_max_choose, at fortran/simplify.c:4884 (and others)

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug fortran/52473] CSHIFT slow - inline it?

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
For the original test compiled with -Ofast, I get

 Testing explicit DO loops
 Dim =1  Elapsed CPU time =   0.846953988
 Dim =2  Elapsed CPU time =   0.724469006
 Dim =3  Elapsed CPU time =   0.680019855
 Testing built-in cshift
 Dim =1  Elapsed CPU time =   0.506424904
 Dim =2  Elapsed CPU time =   0.391590118
 Dim =3  Elapsed CPU time =   0.352367163

An for the IDRIS test:

=
 Call to test_eoshift
=

 Order of matrix:1000
 test_eoshift> 1) EOSHIFT
   Used CPU time ==> 2.976 ms
 test__eoshift> 2) DO loop
   Used CPU time ==> 0.832 ms
 Results OK


 Call to test_cshift


 Order of matrix:1000
 test_cshift> 1) CSHIFT
   Used CPU time ==> 1.377 ms
 test__cshift> 2) DO loop
   Used CPU time ==> 1.051 ms
 Results OK

=
 Call to test_reshape
=

 Order of matrix:1000
 test__reshape> 1) RESHAPE
   Used CPU time ==> 4.909 ms
 test__reshape> 2) DO loop
   Used CPU time ==> 0.877 ms
 Results OK

May be this PR could be closed.

[Bug inline-asm/84680] [6/7/8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Guess that is the point when the "v" constraint has been introduced.

[Bug fortran/85111] [8 Regression] ICE in min_max_choose, at fortran/simplify.c:4884 (and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 CC||tkoenig at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0.1

--- Comment #3 from Dominique d'Humieres  ---
Likely revision r256088 for the tests in comments 0 and 1.

With r256065 and before I get

pr85111.f90:3:31:

integer, parameter :: b(2) = maxloc(a, dim=1)
   1
Error: transformational intrinsic 'maxloc' at (1) is not permitted in an
initialization expression

For the test in comment 2, it likely r255542.

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-28
 Ever confirmed|0   |1

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #4 from H.J. Lu  ---
Created attachment 43793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43793=edit
A patch

Please try this.

[Bug inline-asm/84677] [6/7 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2205

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-checking
 CC||jakub at gcc dot gnu.org
Summary|[6/7/8 Regression] internal |[6/7 Regression] internal
   |compiler error: in  |compiler error: in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2205|recog.c:2205
  Known to fail|8.0 |

--- Comment #3 from Jakub Jelinek  ---
This got fixed with r258393 aka PR84682 on the trunk; doesn't ICE with
-fno-checking, so doesn't fail on release branches.

[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149

[proski at gnu dot org]

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

Pavel Roskin  changed:

   What|Removed |Added

 CC||proski at gnu dot org

--- Comment #1 from Pavel Roskin  ---
Possibly even simpler case:

#include 
struct IntSet {
IntSet(int value) : value_{std::set{value}} {}
std::set value_;
};

I'm testing gcc-8 on a large project that compiled with an older gcc-8 snapshot
and this bug is triggered on many files. The workaround is to use () rather
than {} for constructor calls.

[Bug fortran/85111] [8 Regression] ICE in min_max_choose, at fortran/simplify.c:4884 (and others)

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

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

--- Comment #2 from G. Steinmetz  ---

Changed between 20171210 and 20171217.


$ cat ze1.f90
program p
   character, parameter :: a(2,0) = reshape(['a','b','c','d'], shape(a))
   character, parameter :: b(2) = maxval(a, dim=1)
end


$ gfortran-8-20180325 -c ze1.f90
f951: internal compiler error: in gfc_resolve_character_array_constructor, at
fortran/array.c:2050
0x67a8a0 gfc_resolve_character_array_constructor(gfc_expr*)
../../gcc/fortran/array.c:2050
0x70f217 fixup_charlen
../../gcc/fortran/resolve.c:5744
0x70f217 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6780
0x6aad1f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ad821 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69b2c2 variable_decl
../../gcc/fortran/decl.c:2642
0x69b2c2 gfc_match_data_decl()
../../gcc/fortran/decl.c:5838
0x6f60b9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f97ae match_word
../../gcc/fortran/parse.c:376
0x6f97ae decode_statement
../../gcc/fortran/parse.c:376
0x6fb6d4 next_free
../../gcc/fortran/parse.c:1230
0x6fb6d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fcfcc parse_spec
../../gcc/fortran/parse.c:3854
0x6ff4b3 parse_progunit
../../gcc/fortran/parse.c:5667
0x700a94 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x74791f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85111] [8 Regression] ICE in min_max_choose, at fortran/simplify.c:4884 (and others)

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

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

--- Comment #1 from G. Steinmetz  ---

$ cat zc1.f90
program p
   integer, parameter :: a(2,0) = reshape([1,2,3,4], shape(a))
   integer, parameter :: b(2) = maxloc(shape(a))
end


$ cat zc7.f90
program p
   character, parameter :: a(2,0) = reshape(['a','b','c','d'], shape(a))
   character, parameter :: b(2) = maxloc(shape(a))
end


$ gfortran-8-20180325 -c zc1.f90
f951: internal compiler error: Segmentation fault
0xb9c38f crash_signal
../../gcc/toplev.c:325
0x725201 simplify_minmaxloc_nodim
../../gcc/fortran/simplify.c:5133
0x72dfe7 gfc_simplify_minmaxloc(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*,
int)
../../gcc/fortran/simplify.c:5418
0x6b99e3 do_simplify
../../gcc/fortran/intrinsic.c:4442
0x6c408c gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4798
0x70de35 resolve_unknown_f
../../gcc/fortran/resolve.c:2870
0x70de35 resolve_function
../../gcc/fortran/resolve.c:3179
0x70df5a gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6709
0x6aad1f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ad821 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69b2c2 variable_decl
../../gcc/fortran/decl.c:2642
0x69b2c2 gfc_match_data_decl()
../../gcc/fortran/decl.c:5838
0x6f60b9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f97ae match_word
../../gcc/fortran/parse.c:376
0x6f97ae decode_statement
../../gcc/fortran/parse.c:376
0x6fb6d4 next_free
../../gcc/fortran/parse.c:1230
0x6fb6d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fcfcc parse_spec
../../gcc/fortran/parse.c:3854
0x6ff4b3 parse_progunit
../../gcc/fortran/parse.c:5667
0x700a94 gfc_parse_file()
../../gcc/fortran/parse.c:6207

[Bug fortran/85111] New: [8 Regression] ICE in min_max_choose, at fortran/simplify.c:4884 (and others)

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

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

Bug ID: 85111
   Summary: [8 Regression] ICE in min_max_choose, at
fortran/simplify.c:4884 (and others)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Introduced between 20171217 and 20180107.
Invalid code, occasionally similar for other basic types.


$ cat za1.f90
program p
   integer, parameter :: a(2,0) = reshape([1,2,3,4], shape(a))
   integer, parameter :: b(2) = maxloc(a, dim=1)
end


$ cat za2.f90
program p
   integer, parameter :: a(2,0) = reshape([1,2,3,4], shape(a))
   integer, parameter :: b(2) = minloc(a, dim=1)
end


$ gfortran-8-20180325 -c za1.f90
f951: internal compiler error: Segmentation fault
0xb9c38f crash_signal
../../gcc/toplev.c:325
0x724896 min_max_choose
../../gcc/fortran/simplify.c:4884
0x724ed3 simplify_minmaxloc_to_array
../../gcc/fortran/simplify.c:5316
0x72ddb2 gfc_simplify_minmaxloc(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*,
int)
../../gcc/fortran/simplify.c:5413
0x6b99e3 do_simplify
../../gcc/fortran/intrinsic.c:4442
0x6c408c gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4798
0x70de35 resolve_unknown_f
../../gcc/fortran/resolve.c:2870
0x70de35 resolve_function
../../gcc/fortran/resolve.c:3179
0x70df5a gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6709
0x6aad1f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ad821 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69b2c2 variable_decl
../../gcc/fortran/decl.c:2642
0x69b2c2 gfc_match_data_decl()
../../gcc/fortran/decl.c:5838
0x6f60b9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f97ae match_word
../../gcc/fortran/parse.c:376
0x6f97ae decode_statement
../../gcc/fortran/parse.c:376
0x6fb6d4 next_free
../../gcc/fortran/parse.c:1230
0x6fb6d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fcfcc parse_spec
../../gcc/fortran/parse.c:3854
0x6ff4b3 parse_progunit
../../gcc/fortran/parse.c:5667

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #8 from Thomas Koenig  ---
Well, this WORKSFORME.

Please re-open if the problem persists.

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 28 17:41:51 2018
New Revision: 258927

URL: https://gcc.gnu.org/viewcvs?rev=258927=gcc=rev
Log:
2018-03-28  Thomas Koenig  

PR fortran/85084
Backport from trunk.
* frontend-passes.c (gfc_run_passes): Do not run front-end
optimizations if a previous error occurred.

2018-03-28  Thomas Koenig  

PR fortran/85084
Backport from trunk.
* gfortran.dg/matmul_rank_1.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/matmul_rank_1.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67445

--- Comment #10 from Eric Gallager  ---
Possibly related to bug 67445?

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 28 17:34:08 2018
New Revision: 258926

URL: https://gcc.gnu.org/viewcvs?rev=258926=gcc=rev
Log:
2018-03-28  Thomas Koenig  

PR fortran/85084
Backport from trunk.
* frontend-passes.c (gfc_run_passes): Do not run front-end
optimizations if a previous error occurred.

2018-03-28  Thomas Koenig  

PR fortran/85084
Backport from trunk.
* gfortran.dg/matmul_rank_1.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/matmul_rank_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/85061] ICE with __builtin_offsetof applied to static member

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #4 from Volker Reichelt  ---
Fixed by Jakub's patch.

[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Working on that I've just noticed Richi that gcc/doc/invoke.texi contains:

  9485  Link-time optimization does not work well with generation of debugging
  9486  information.  Combining @option{-flto} with
  9487  @option{-g} is currently experimental and expected to produce
unexpected
  9488  results.

Now having early-lto debug info, would you change it?

[Bug c++/85110] Missing underlines for some bad arguments

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
In build_new_function_call, we have:

  cand = perform_overload_resolution (fn, *args, , _viable_p,
  complain);

  if (!cand)
{
  if (complain & tf_error)
{
  // If there is a single (non-viable) function candidate,
  // let the error be diagnosed by cp_build_function_call_vec.
  if (!any_viable_p && candidates && ! candidates->next
  && (TREE_CODE (candidates->fn) == FUNCTION_DECL))
return cp_build_function_call_vec (candidates->fn, args,
complain);
*** CASE 1


  // Otherwise, emit notes for non-viable candidates.
  print_error_for_call_failure (fn, *args, candidates);
}
  [...snip...]

}
  else
{
  [...snip...]
  CASE 2 
  result = build_over_call (cand, flags, complain);
}


"CASE 2" is handled by r256448, where perform_overload_resolution has returned
a non-NULL candidate, but there's a failure in convert_like_real.

This new PR (and the example in comment #0) covers "CASE 1" above.

[Bug c++/85110] New: Missing underlines for some bad arguments

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 85110
   Summary: Missing underlines for some bad arguments
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In gcc 8, the C++ FE underlines some bogus arguments to function calls, as of
r256448.

However we're missing some.  Given:

void callee (int one, const char **two, int three);

void
caller (const char *fmt)
{
  callee (1, fmt, 3);
}

We emit:

$ g++ test.cc
test.cc: In function ‘void caller(const char*)’:
test.cc:6:20: error: cannot convert ‘const char*’ to ‘const char**’ for
argument ‘2’ to ‘void callee(int, const char**, int)’
   callee (1, fmt, 3);
^

We ought to underline the problematic argument, and, ideally the decl.

I have a patch for this.

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||itsimbal at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The reason why we do something so weird rather than ix86_expand_vector_set is
that sse.md lacks vec_setv32hi and vec_setv64qi patterns, IMHO it should have
them.

E.g. on:
typedef short V __attribute__((vector_size (64)));

V
foo (V x, int y)
{
  x[0] = y;
  return x;
}

V
bar (V x, int y)
{
  x[7] = y;
  return x;
}

V
baz (V x, int y)
{
  x[11] = y;
  return x;
}

we generate completely terrible code with -O2 -mavx512f -mtune=intel or
-O2 -mavx512bw -mtune=intel.
Moving the word out of the vector, performing masking etc. on the GRPs and then
inserting it again.
clang emits:
vpinsrw $0, %edi, %xmm0, %xmm2
vpblendd $15, %ymm2, %ymm0, %ymm0
(and s/$0/$7/) for foo/bar with -O2 -mavx512f, which makes me wonder if the VEX
256-bit vpblendd with 4 arguments really doesn't clear the upper 256 bits,
128-bit vpblendd is documented to clear them, and for baz:
vextracti128 $1, %ymm0, %xmm2
vpinsrw $3, %edi, %xmm2, %xmm2
vinserti128 $1, %xmm2, %ymm0, %ymm0
With -O2 -mavx512bw they emit:
vpinsrw $0, %edi, %xmm0, %xmm1
vinserti32x4 $0, %xmm1, %zmm0, %zmm0
(and s/$0/$7/) for foo/bar, though none of those instructions actually require
AVX512BW.  And for baz:
vextracti128 $1, %ymm0, %xmm1
vpinsrw $3, %edi, %xmm1, %xmm1
vinserti32x4 $1, %xmm1, %zmm0, %zmm0

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #32 from Vadim Zeitlin  ---
(In reply to Martin Liška from comment #31)
> Created attachment 43781 [details]
> Partially reduced test-case
> 
> I've got 120KB partially reduced test-case. Any further reduction is not
> much possible. I'm able to reproduce that with -O1 -Woverloaded-virtual.
> It's super-weird issue, any ggc parameters adjustments do not make any
> change.
> I would recommend to create Debian-specific issue and somebody will need to
> investigate which patch is responsible for that.

Thanks Martin! I've created
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894302 for it now, pointing
to this bug and your test case.

[Bug c/70924] Wrong position for "warning: missing braces around initializer [-Wmissing-braces]"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c/70618] better error messages for missing/too many arguments

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
I guess it depends on what exactly a normal subreg on lhs means.
The documentation says:
  When used as an lvalue, 'subreg' is a word-based accessor.
  Storing to a 'subreg' modifies all the words of REG that
  overlap the 'subreg', but it leaves the other words of REG
  alone.
but in this case, we really don't have a GPR, but rather a single much larger
(512-bit) register.  Does it still imply that for -m32 (subreg:SI (reg:V32HI)
0)
sets just the low 32 bits of the large register and doesn't modify anything
else,
and for -m64 the same means set low 32 bits, have the 32 bits above it
undefined and the rest of bits unmodified?

Seems store_bit_field treats it that way, but perhaps IRA does not?

[Bug c++/63392] poor error recovery with missing typename

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/85109] Incorrect warning for constexpr lambda with -Wunused-but-set-variable

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Your bug went thru the first time as bug 85108

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

[Bug c++/85108] Incorrect warning for constexpr lambda with -Wunused-but-set-variable

[egallager at gcc dot gnu.org]

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

--- Comment #1 from Eric Gallager  ---
*** Bug 85109 has been marked as a duplicate of this bug. ***

[Bug c++/85109] New: Incorrect warning for constexpr lambda with -Wunused-but-set-variable

[rain.backnet at gmail dot com]

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

Bug ID: 85109
   Summary: Incorrect warning for constexpr lambda with
-Wunused-but-set-variable
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rain.backnet at gmail dot com
  Target Milestone: ---

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

If a lambda is declared constexpr, and then used within another lambda, with
the flag -Wunused-but-set-variable the compiler produces an incorrect warning
that the constexpr lambda is set but not used, when it is.

See attached minimal test case.

[Bug c++/85108] New: Incorrect warning for constexpr lambda with -Wunused-but-set-variable

[rain.backnet at gmail dot com]

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

Bug ID: 85108
   Summary: Incorrect warning for constexpr lambda with
-Wunused-but-set-variable
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rain.backnet at gmail dot com
  Target Milestone: ---

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

If a lambda is declared constexpr, and then used within another lambda, with
the flag -Wunused-but-set-variable the compiler produces an incorrect warning
that the constexpr lambda is set but not used, when it is.

See attached minimal test case.

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
(In reply to Richard Biener from comment #7)
> Thanks for working on this!  Note that there may be multiple ltrans units
> (in theory, not likely in the testsuite), so forcing -flto-partition=one
> when we
> see scan-ltrans-tree-dump would simplify things?

Yeah, I was wondering about that.

I was thinking of this kind of interface:
...
scan-ltrans-tree-dump regex suffix ltrans [{ target/xfail selector }]
...
but I'll try the -flto-partition=one idea, indeed that seems simpler.

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)

[ribasushi at leporine dot io]

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

--- Comment #6 from Peter Rabbitson  ---
Basically I'd simply run the commands as listed in the .travis.yml file one
after the other ;)

The reason I provided this on travis is because the available environment is
"static", and one can install/run whatever without thinking much, as everything
will be blown away after the finish.

So I guess my question is: how can I help you more specifically?

[Bug other/84819] several typos

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I'm closing this as I don't have ambition to backport that.

[Bug other/84819] several typos

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Wed Mar 28 14:51:09 2018
New Revision: 258925

URL: https://gcc.gnu.org/viewcvs?rev=258925=gcc=rev
Log:
Fix typos (PR other/84819).

2018-03-28  Martin Liska  

PR other/84819
* calls.c (initialize_argument_information): Fix trailing space.
* common.opt: Fix typo and provide better explanation for
-fsanitize-coverage option.
* config/i386/i386.opt: Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/common.opt
trunk/gcc/config/i386/i386.opt

[Bug sanitizer/85081] [7 Regression] Sanitizer error with references in vectorized/parallel for-loop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0.1
Summary|[7/8 Regression] Sanitizer  |[7 Regression] Sanitizer
   |error with references in|error with references in
   |vectorized/parallel |vectorized/parallel
   |for-loop|for-loop
  Known to fail|8.0.1   |

--- Comment #4 from Martin Liška  ---
Fixed on trunk.

[Bug sanitizer/85081] [7/8 Regression] Sanitizer error with references in vectorized/parallel for-loop

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Wed Mar 28 14:45:21 2018
New Revision: 258924

URL: https://gcc.gnu.org/viewcvs?rev=258924=gcc=rev
Log:
Fix wrong use-after-scope sanitization for omp variable (PR sanitizer/85081).

2018-03-28  Jakub Jelinek  
Martin Liska  

PR sanitizer/85081
* gimplify.c (asan_poison_variable): Don't do the check for
gimplify_omp_ctxp here.
(gimplify_decl_expr): Do it here.
(gimplify_target_expr): Likewise.
2018-03-28  Jakub Jelinek  
Martin Liska  

PR sanitizer/85081
* g++.dg/asan/pr85081.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr85081.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85094] [8 Regression] -g with any optimization suppresses -Wduplicated-branches

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

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

[Bug c/85094] [8 Regression] -g with any optimization suppresses -Wduplicated-branches

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Thanks for working on this!  Note that there may be multiple ltrans units (in
theory, not likely in the testsuite), so forcing -flto-partition=one when we
see scan-ltrans-tree-dump would simplify things?

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Can you please help me how to reproduce that locally with a travis?

[Bug target/84988] Compiler hang in chkp_type_bounds_count for large arrays

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Wed Mar 28 14:22:27 2018
New Revision: 258923

URL: https://gcc.gnu.org/viewcvs?rev=258923=gcc=rev
Log:
Do not call chkp_type_bounds_count if MPX is not enabled (PR target/84988).

2018-03-28  Martin Liska  

PR target/84988
* config/i386/i386.c (ix86_function_arg_advance): Do not call
chkp_type_bounds_count if MPX is not enabled.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Created attachment 43789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43789=edit
Tentative followup patch that adds scan-offload-rtl-dump

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #43786|0   |1
is obsolete||

--- Comment #5 from Tom de Vries  ---
Created attachment 43788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43788=edit
Updated tentative followup patch that adds scan-offload-tree-dump

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #43785|0   |1
is obsolete||

--- Comment #4 from Tom de Vries  ---
Created attachment 43787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43787=edit
Further updated tentative patch that adds scan-wpa-ipa-dump

[Bug libstdc++/85098] undefined reference to std::regex::extended

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Untested fix:

--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -776,6 +776,37 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _AutomatonPtr_M_automaton;
 };

+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::icase;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::nosubs;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::optimize;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::collate;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::ECMAScript;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::basic;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::extended;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::awk;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::grep;
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::egrep;
+
 #if __cpp_deduction_guides >= 201606
   template
 basic_regex(_ForwardIterator, _ForwardIterator,

[Bug libstdc++/85098] undefined reference to std::regex::extended

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

#include 

void f(const std::regex_constants::syntax_option_type&) { }

int main() {
  f(std::regex::extended);
}

[Bug libstdc++/85098] undefined reference to std::regex::extended

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Wow, I'm amazed nobody's noticed this bug before.

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[brenohl at br dot ibm.com]

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

Breno Leitao  changed:

   What|Removed |Added

 CC||brenohl at br dot ibm.com

--- Comment #7 from Breno Leitao  ---
Hi Alan,

I was not able to read the changelog and understand what are the exact versions
that this bug is fixed. How can I read and get this information?

I am asking this question because mongodb was hitting this issue[1], and the
workaround was disabling optimization[2] during mongodb compilation.

That said, we would like to re-enable the optimized compilation for mongodb[3],
but we need this GCC fix on the distros first, so, I need to know which GCC
version contains this fix and migrating to it prior to the re-enablement of the
Mongodb optimization.

I understand that this fix didn't make the GCC 8 first release, thus, there was
a minor version update on GCC 6, 7 and 8 that contains this fix. Is my
understanding correct?

Thank you,
Breno

[1] https://jira.mongodb.org/browse/SERVER-33395
[2] https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1758116
[3] https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1758118