[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
I am testing this patch:

diff --git a/gcc/config/i386/cet.h b/gcc/config/i386/cet.h
index 9dca41bad2d..309d90ec87c 100644
--- a/gcc/config/i386/cet.h
+++ b/gcc/config/i386/cet.h
@@ -33,12 +33,14 @@
 #ifdef __ASSEMBLER__

 # ifdef __IBT__
+#  define _CET_NOTRACK notrack
 #  ifdef __x86_64__
 #   define _CET_ENDBR endbr64
 #  else
 #   define _CET_ENDBR endbr32
 #  endif
 # else
+#  define _CET_NOTRACK
 #  define _CET_ENDBR
 # endif

diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S
index 99e65eaaff4..c0cda479806 100644
--- a/libgcc/config/i386/morestack.S
+++ b/libgcc/config/i386/morestack.S
@@ -543,7 +543,7 @@ __morestack:

movq-16(%rbp),%rax  # Restore caller's %rax.

-   call*%r10   # Call our caller!
+   _CET_NOTRACK call *%r10 # Call our caller!

# The caller will return here, as predicted.

[Bug libgcc/85388] New: config/i386/morestack.S is incompatible with CET

[hjl.tools at gmail dot com]

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

Bug ID: 85388
   Summary: config/i386/morestack.S is incompatible with CET
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

config/i386/morestack.S has

movq-16(%rbp),%rax  # Restore caller's %rax.

call*%r10   # Call our caller!
 Missing notrack prefix.


Referenced Bugs:

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

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
The sanitizers insert a lot of instrumentation, and some of it interferes with
GCC warnings.  The usual recommendation is to use either sanitization or
middle-end warnings but not both.  (This is obviously suboptimal and it would
be ideal to have both, but it's not always possible.)

Much of the instrumentation the sanitizers insert is, of course, necessary to
detect bugs and runtime, but some is not (e.g., some of those in bug 79265) and
could be removed to avoid some of the false positives with no loss of efficacy
(and make the code run faster).

The output of the sanitizer for the first function shows a couple of these
unnecessary tests (I don't know if avoiding the would prevent the warning; it's
issued while running the VRP pass):

t1 (char * g)
{
  int c.1_1;
  char * _2;
  char * _3;
  long unsigned int _4;
  int _5;
  char[] * iftmp.0_6;
  char[] * iftmp.0_8;
  char[] * iftmp.0_9;

   :
  c.1_1 = c;
  if (c.1_1 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  iftmp.0_8 = 
  goto ; [INV]

   :
  iftmp.0_9 = 

   :
  # iftmp.0_6 = PHI 
  UBSAN_PTR (g_10(D), 4);
  _2 = g_10(D) + 4;
  if (_2 == 0B)
goto ; [0.05%]
  else
goto ; [99.95%]

   :
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0);

   :
  if (iftmp.0_6 == 0B)<<< unnecessary (neither  nor  can be null)
goto ; [0.05%]
  else
goto ; [99.95%]

   :
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1);

   :
  strcpy (_2, iftmp.0_6);
  UBSAN_PTR (g_10(D), 4);
  _3 = g_10(D) + 4;
  if (_3 == 0B)<<< redundant (already checked in bb 5
goto ; [0.05%]
  else
goto ; [99.95%]

   :
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);

   :
  _4 = strlen (_3);
  _5 = (int) _4;
  e = _5;
  return;

}

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Looking into it.

[Bug middle-end/85369] no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00649.html

[Bug c++/85385] [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by r259360.

[Bug c++/85385] [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Author: dmalcolm
Date: Thu Apr 12 23:44:09 2018
New Revision: 259360

URL: https://gcc.gnu.org/viewcvs?rev=259360=gcc=rev
Log:
Prevent erroneous "macro had not yet been defined" messages (PR c++/85385)

PR c++/85385 reports an issue where we emit bogus "macro had not yet been
defined" notes when a macro is mis-used:

  $ cat test.c
  #define MACRO(X,Y)

  void test ()
  {
MACRO(42);
  }

  $ ./xg++ -B. -c test.c
  test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given
 MACRO(42);
 ^
  test.c: In function ‘void test()’:
  test.c:5:3: error: ‘MACRO’ was not declared in this scope
 MACRO(42);
 ^
  test.c:5:3: note:
  test.c:1: note: it was later defined here
   #define MACRO(X,Y)

The macro *had* been defined, it was merely misused.

This patch fixes the issue by only issuing the note if the use location
is before the definition location (using linemap_location_before_p).

gcc/cp/ChangeLog:
PR c++/85385
* name-lookup.c (macro_use_before_def::maybe_make): New function,
checking that the use is indeed before the definition.
(macro_use_before_def::macro_use_before_def): Make private.
(macro_use_before_def::~macro_use_before_def): Make private.  Move
check for UNKNOWN_LOCATION to macro_use_before_def::maybe_make.
(lookup_name_fuzzy): Call macro_use_before_def::maybe_make rather
than using new directly.

gcc/testsuite/ChangeLog:
PR c++/85385
* g++.dg/diagnostic/macro-arg-count.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/diagnostic/macro-arg-count.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85387] New: incorrect output with optimization /= 0

[zeccav at gmail dot com]

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

Bug ID: 85387
   Summary: incorrect output with optimization /= 0
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

! incorrect output with optimization /= 0
! on trunk 259205
real efg_pw(2,2)
efg_pw(1,1)=1
efg_pw(2,1)=2
efg_pw(1,2)=3
efg_pw(2,2)=4
! with optimization /= 0 displays nothing
print *,((efg_pw(i, j), i=1, j), j=1, 2) !should display 1.  3.
   4.
end

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Fixed, closing.

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Apr 12 21:58:54 2018
New Revision: 259359

URL: https://gcc.gnu.org/viewcvs?rev=259359=gcc=rev
Log:
2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind
for annotation and remove dependence on -ftree-parallelize-loops.

2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* gfortran.dg/do_concurrent_5.f90: Dynamically allocate main work
array and move test to libgomp/testsuite/libgomp.fortran.
* gfortran.dg/do_concurrent_6.f90: New test.

2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* testsuite/libgomp.fortran/do_concurrent_5.f90: Move modified
test from gfortran.dg to here.


Added:
trunk/gcc/testsuite/gfortran.dg/do_concurrent_6.f90
trunk/libgomp/testsuite/libgomp.fortran/do_concurrent_5.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog

[Bug fortran/83064] DO CONCURRENT and auto-parallelization

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Apr 12 21:58:54 2018
New Revision: 259359

URL: https://gcc.gnu.org/viewcvs?rev=259359=gcc=rev
Log:
2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind
for annotation and remove dependence on -ftree-parallelize-loops.

2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* gfortran.dg/do_concurrent_5.f90: Dynamically allocate main work
array and move test to libgomp/testsuite/libgomp.fortran.
* gfortran.dg/do_concurrent_6.f90: New test.

2018-04-12  Thomas Koenig  

PR fortran/83064
PR testsuite/85346
* testsuite/libgomp.fortran/do_concurrent_5.f90: Move modified
test from gfortran.dg to here.


Added:
trunk/gcc/testsuite/gfortran.dg/do_concurrent_6.f90
trunk/libgomp/testsuite/libgomp.fortran/do_concurrent_5.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #11 from acsawdey at gcc dot gnu.org ---
Looking at the dump of an analogous test case for vec_insert:

#include 

typedef __vector unsigned int  uvec32_t  __attribute__((__aligned__(16)));

uvec32_t get_word(uvec32_t v)
{ 
  return({const unsigned _B1 = 32;
  vec_insert(10, (uvec32_t)v, 2);});
}

It seems that we do get an additional cleanup_point like you are proposing to
add for vec_extract, which is maybe why that does not get into trouble:

;; Function __vector(4) unsigned int get_word(__vector(4) unsigned int) (null)
;; enabled by -tree-original


{
  < = {
const unsigned int _B1 = 32;

<>;
<> + 8) = 10;, D.3231>>;
  }>>;
}

I've gotten as far as seeing that something is calling
fold_build_cleanup_point_expr an additional time compared to the vec_extract
example.

[Bug fortran/85364] -fopenmp should not put array in program on the stack

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
(In reply to Jakub Jelinek from comment #3)
> If it is about variables in MAIN__ and not say variables inside of BLOCK
> inside of MAIN__, then perhaps.  For BLOCK, I wonder about stuff like:
>   !$omp parallel
>   block
> integer :: i
> i = ...
> use (i)
>   end block
>   !$omp end parallel
> end
> and similar, where the implicit SAVE would be undesirable.

The OpenMP data sharing rules are quite clear about this, even if they do
not mention Fortran BLOCK explicitly:

E.g. TR6, 2.20.1.2:

  Local variables declared in called routines in the region and that have the
  save attribute, or that are data initialized, are shared unless they appear
  in a threadprivate directive.

[Bug fortran/85364] -fopenmp should not put array in program on the stack

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
If it is about variables in MAIN__ and not say variables inside of BLOCK inside
of MAIN__, then perhaps.  For BLOCK, I wonder about stuff like:
  !$omp parallel
  block
integer :: i
i = ...
use (i)
  end block
  !$omp end parallel
end
and similar, where the implicit SAVE would be undesirable.

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r180965.

[Bug fortran/85364] -fopenmp should not put array in program on the stack

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Thomas Koenig  ---
(In reply to Jakub Jelinek from comment #1)
> -fopenmp just implies -frecursive and has to, because the OpenMP semantics
> requires it.
> Does fortran guarantee that MAIN__ can't be invoked more than once?

Yes, it is not possible (from the language) to call a main program.

> If so,
> perhaps MAIN__ could be special-cased for -frecursive, you'd need to update
> the docs too.  There would be no way to force automatic variables in MAIN__
> though if the user wants it for some reason (you can't mark MAIN__
> RECURSIVE).

Since F2008, all variables in the main program have the SAVE
attribute anyway (F2008, 5.3.16, para 4).

Earlier versions left this unspecified; in F2003, the standard says
"The SAVE attribute may appear in declarations in a main program and has no
effect."

which makes sense because there is no way the user can tell
the difference except by using valgrind on allocatable arrays.
So (methinks) we should be safe making those SAVEd as well.

[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00639.html

[Bug c++/85386] ICE when applying noexcept operator to default constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed by r257713.

[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00638.html

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We warn because we see
strcpy (0B, 0B);
created by jump threading (in a BB that is not reachable).

[Bug c++/85386] ICE when applying noexcept operator to default constructor

[andysem at mail dot ru]

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

--- Comment #1 from andysem at mail dot ru ---
Apparently, the is_nothrow_default_constructible workaround doesn't work
reliably either, at least not in the full code base from which this testcase
was reduced.

[Bug c++/85386] New: ICE when applying noexcept operator to default constructor

[andysem at mail dot ru]

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

Bug ID: 85386
   Summary: ICE when applying noexcept operator to default
constructor
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Created attachment 43923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43923=edit
A testcase that shows the problem.

The following testcase causes ICE:

template< typename T >
class allocator
{
};

template< typename T >
struct is_ebo_possible
{
static constexpr bool value = true;
};

template< typename Char, typename Allocator, bool = is_ebo_possible< Allocator
>::value >
struct ebo
{
typedef Allocator allocator_type;

allocator_type m_allocator;

//  ebo() noexcept(std::is_nothrow_default_constructible< allocator_type
>::value) = default;
ebo() noexcept(noexcept(allocator_type())) = default;
};

template< typename Char, typename Allocator >
struct ebo< Char, Allocator, true > :
public Allocator
{
typedef Allocator allocator_type;

ebo() noexcept(noexcept(allocator_type())) = default;
};

int main()
{
ebo< char, allocator< char > > m;
return 0;
}

$ g++ -o noexcept_def_ctor_test noexcept_def_ctor_test.cpp  
noexcept_def_ctor_test.cpp: In instantiation of ‘ebo::ebo() [with Char = char; Allocator = allocator]’:
noexcept_def_ctor_test.cpp:24:8:   required from ‘struct ebo’
noexcept_def_ctor_test.cpp:34:36:   required from here
noexcept_def_ctor_test.cpp:20:29: internal compiler error: Segmentation fault
 ebo() noexcept(noexcept(allocator_type())) = default;
 ^~~~

This happens with gcc 7.2 but not 6.4. If I replace the noexcept operator with
the is_nothrow_default_constructible trait as in the commented line, ICE
doesn't happen.

$ g++ -v
Using built-in specs.   
COLLECT_GCC=g++ 
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/85356] [7 Regression] ICE with operator=

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Apr 12 20:03:33 2018
New Revision: 259356

URL: https://gcc.gnu.org/viewcvs?rev=259356=gcc=rev
Log:
PR c++/85356 - ICE with pointer to member function.

* pt.c (maybe_instantiate_noexcept): Do instantiate in templates if
flag_noexcept_type.  Build the new spec within the function context.
* except.c (build_noexcept_spec): Do get constant value in templates
if flag_noexcept_type.
* decl.c (check_redeclaration_exception_specification): Don't
instantiate noexcept on a dependent declaration.

Added:
trunk/gcc/testsuite/g++.dg/template/mem_func_ptr2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/except.c
trunk/gcc/cp/pt.c

[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Apr 12 20:02:47 2018
New Revision: 259355

URL: https://gcc.gnu.org/viewcvs?rev=259355=gcc=rev
Log:
PR c++/85258
* constexpr.c (reduced_constant_expression_p): Return false for null
trees.

* g++.dg/parse/error61.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/error61.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85291] ICE in extract_insn, at recog.c:2304

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Thu Apr 12 20:01:37 2018
New Revision: 259354

URL: https://gcc.gnu.org/viewcvs?rev=259354=gcc=rev
Log:
rs6000: Fix an ICE with -mno-direct-move (PR85291)


PR target/85291
* config/rs6000/rs6000.md (fix_truncsi2): Use legacy code if
asked to not generate direct moves.
(fix_truncsi2_stfiwx): Similar.
(fix_truncsi2_internal): Similar.

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

[Bug target/85291] ICE in extract_insn, at recog.c:2304

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #7 from Segher Boessenkool  ---
Fixed.

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||cesar at gcc dot gnu.org

--- Comment #1 from cesar at gcc dot gnu.org ---
Strange. It passes for me using my GeForce 1070 running Nvidia driver 390.48.

[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0

--- Comment #19 from Jakub Jelinek  ---
Fixed for 8+, not going to backport.

[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 12 19:30:00 2018
New Revision: 259353

URL: https://gcc.gnu.org/viewcvs?rev=259353=gcc=rev
Log:
PR debug/83157
* var-tracking.c (add_stores): Handle STRICT_LOW_PART SET_DEST.
* cselib.c (cselib_record_sets): For STRICT_LOW_PART dest,
lookup if dest in some wider mode is known to be const0_rtx and
if so, record permanent equivalence for it to be ZERO_EXTEND of
the narrower mode destination.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cselib.c
trunk/gcc/var-tracking.c

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Bug 85222 Summary: [7 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222

   What|Removed |Added

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

[Bug libstdc++/85222] [7 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #23 from Jonathan Wakely  ---
Fixed for 7.4 and 8.1

[Bug libstdc++/85222] [7 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
Author: redi
Date: Thu Apr 12 19:06:50 2018
New Revision: 259352

URL: https://gcc.gnu.org/viewcvs?rev=259352=gcc=rev
Log:
PR libstdc++/85222 allow catching iostream errors as gcc4-compatible
ios::failure

Define a new exception type derived from std::ios::failure[abi:cxx11]
which also aggregates an object of the gcc4-compatible ios::failure
type. Make __throw_ios_failure throw this new type for iostream errors
that raise exceptions. Provide custom type info for the new type so that
it can be caught by handlers for the gcc4-compatible ios::failure type
as well as handlers for ios::failure[abi:cxx11] and its bases.

Backport from mainline
2018-04-10  Jonathan Wakely  

PR libstdc++/85222
* src/c++11/Makefile.am [ENABLE_DUAL_ABI]: Add special rules for
cxx11-ios_failure.cc to rewrite type info for __ios_failure.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cxx11-ios_failure.cc (__ios_failure, __iosfail_type_info):
New types.
[_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here.
* src/c++11/ios.cc (__throw_ios_failure): Remove definition.
(_GLIBCXX_USE_CXX11_ABI): Don't define here.
* src/c++98/ios_failure.cc (__construct_ios_failure)
(__destroy_ios_failure, is_ios_failure_handler): New functions.
[!_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here.
* testsuite/27_io/ios_base/failure/dual_abi.cc: New.
* testsuite/27_io/basic_ios/copyfmt/char/1.cc: Revert changes to
handler types, to always catch std::ios_base::failure.
* testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/ios_base/storage/2.cc: Likewise.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.am
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-7-branch/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
branches/gcc-7-branch/libstdc++-v3/src/c++11/ios.cc
branches/gcc-7-branch/libstdc++-v3/src/c++98/ios_failure.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc

[Bug c++/85385] New: [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 85385
   Summary: [8 Regression] Bogus "macro had not yet been defined"
message when macro used with wrong arg count
   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: ---

$ cat test.c
#define MACRO(X,Y)

void test ()
{
  MACRO(42);
}

$ ./xg++ -B. -c test.c
test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given
   MACRO(42);
   ^
test.c: In function ‘void test()’:
test.c:5:3: error: ‘MACRO’ was not declared in this scope
   MACRO(42);
   ^
test.c:5:3: note: 
test.c:1: note: it was later defined here
 #define MACRO(X,Y)

We shouldn't emit the note "the macro ‘MACRO’ had not yet been defined" for
cases like these: the macro *had* been defined.

[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-12
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85369
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I'm testing a fix for this.

See also bug 85369 for a related problem.

[Bug middle-end/85369] no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  A small standalone test case is below shwoing that an x86_64 GCC
issues the expected warning but the s360-linux one doesn't.

$ (set -x && cat pr85369.c && /ssd/build/gcc-git/gcc/xgcc -B
/ssd/build/gcc-git/gcc -O2 -S -Wall pr85369.c &&
/ssd/build/s390-linux/gcc-git/gcc/xgcc -B /ssd/build/s390-linux/gcc-git/gcc -O2
-S -Wall pr85369.c)
+ cat pr85369.c
char* g (char *d, __attribute__ ((nonstring)) const char *s)
{
  return __builtin_stpcpy (d, s);
}

+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S -Wall pr85369.c
pr85369.c: In function ‘g’:
pr85369.c:3:10: warning: ‘__builtin_stpcpy’ argument 2 declared attribute
‘nonstring’ [-Wstringop-overflow=]
   return __builtin_stpcpy (d, s);
  ^~~
pr85369.c:1:59: note: argument ‘s’ declared here
 char* g (char *d, __attribute__ ((nonstring)) const char *s)
   ^
+ /ssd/build/s390-linux/gcc-git/gcc/xgcc -B /ssd/build/s390-linux/gcc-git/gcc
-O2 -S -Wall pr85369.c

[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion

[cesar at gcc dot gnu.org]

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

--- Comment #6 from cesar at gcc dot gnu.org ---
I reverted that patch from trunk, and will revisit this issue during stage1.

It should be noted that GCC also chokes with any empty OpenACC loop in general.

[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

[cesar at gcc dot gnu.org]

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

--- Comment #3 from cesar at gcc dot gnu.org ---
I ended up reverting the patch in r259351. It should be working now.

[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #2 from Steve Ellcey  ---
This looks like the same bug I am seeing on Aarch64 with the SPEC 2017
510.parest_r benchmark.  I am compiling it with -Ofast -flto=32 -mcpu=native
on a T99.

[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
gcc_get_base_ver is meant for uses in Makefiles (which is why it uses $$), so
it can't be easily used in a shell script.

[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-12
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

[Bug jit/85384] New: libgccjit does not work if --with-gcc-major-version is used

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 85384
   Summary: libgccjit does not work if --with-gcc-major-version is
used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As noted in this downstream bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=1566178
libgccjit does not honor --with-gcc-major-version.

Specifically, gcc/configure.ac does not use get_gcc_base_ver when generating
gcc-driver-name.h, hence GCC_DRIVER_NAME contains the wrong value when
--with-gcc-major-version is used.

This leads to link errors as reported in that bug, when using the default
embedded driver, and to the driver not being found when using:

  gcc_jit_context_set_bool_use_external_driver (ctxt, 1);

Affects trunk and gcc-7-branch.

I'm about to submit a candidate fix.

[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

[cesar at gcc dot gnu.org]

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

--- Comment #1 from cesar at gcc dot gnu.org ---
I'm building a power8 toolchain right now. If the fix isn't immediately
obvious, I'll revert that patch for pr84955. After all, empty loops are
uninteresting in OpenACC.

[Bug middle-end/85383] New: [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

[seurer at gcc dot gnu.org]

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

Bug ID: 85383
   Summary: [8 regression] many ICE failures at gcc/toplev.c:325
starting with r259346
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

See this on powerpc64 both LE and BE.

One example:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/covariant-1.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-flto -fno-use-linker-plugin -flto-partition=none
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./covariant-1.exe
during IPA pass: pure-const
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/covariant-1.C:33:1:
internal compiler error: Segmentation fault
0x10c0b7cb crash_signal
/home/seurer/gcc/gcc-test2/gcc/toplev.c:325
0x10a00288 loop_optimizer_init(unsigned int)
/home/seurer/gcc/gcc-test2/gcc/loop-init.c:88
0x10a6408f output_function
/home/seurer/gcc/gcc-test2/gcc/lto-streamer-out.c:2088
0x10a6408f lto_output()
/home/seurer/gcc/gcc-test2/gcc/lto-streamer-out.c:2423
0x10aee8b3 write_lto
/home/seurer/gcc/gcc-test2/gcc/passes.c:2610
0x10af4117 ipa_write_summaries_1
/home/seurer/gcc/gcc-test2/gcc/passes.c:2674
0x10af4117 ipa_write_summaries()
/home/seurer/gcc/gcc-test2/gcc/passes.c:2734
0x106b785b ipa_passes
/home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2468
0x106b785b symbol_table::compile()
/home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2558
0x106ba78f symbol_table::compile()
/home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2537
0x106ba78f symbol_table::finalize_compilation_unit()
/home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2717

List of failures:

> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++11 (internal compiler error)
> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++14 (internal compiler error)
> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++98 (internal compiler error)
> FAIL: g++.dg/ipa/pr46984.C  -std=gnu++98 (test for excess errors)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto 
> -flto-partition=1to1 -fno-use-linker-plugin  (internal compiler error)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto 
> -flto-partition=none -fuse-linker-plugin (internal compiler error)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto 
> -flto-partition=1to1 -fno-use-linker-plugin  (internal compiler error)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto 
> -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects  (internal 
> compiler error)
> FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto 
> -fuse-linker-plugin (internal compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto 
> -flto-partition=1to1 -fno-use-linker-plugin  (internal compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto 
> -flto-partition=none -fuse-linker-plugin (internal compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto 
> -flto-partition=1to1 -fno-use-linker-plugin  (internal compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto 
> -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects  (internal 
> compiler error)
> FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto 
> -fuse-linker-plugin (internal compiler error)
> FAIL: g++.dg/lto/20081219 

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Are you configuring gcc against binutils 2.30+ and then assembling stuff with
older binutils?
You can always use -gno-as-locview-support even in that case, but the general
assumption is if you configure against some gas/ld version then you use that or
newer version when using the compiler.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #19 from Dmitry Vyukov  ---
When I am trying to build anything with -g on a machine with binutils 2.26.1 I
am getting:

/tmp/ccTFsPnM.s: Assembler messages:
/tmp/ccTFsPnM.s:11: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:11: Error: junk at end of line, first unrecognized character is
`-'
/tmp/ccTFsPnM.s:13: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:13: Error: unknown pseudo-op: `.lvu1'
/tmp/ccTFsPnM.s:14: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:14: Error: unknown pseudo-op: `.lvu2'
/tmp/ccTFsPnM.s:18: Error: unknown .loc sub-directive `view'

But this works on machine with binutils 2.30.
The previous version of gcc 8 that I built a month ago worked on the machine
with binutils 2.26.1.
Am I doing something wrong? Is there a workaround?

[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
Patch committed to trunk.

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> My patch doesn't fix g++.dg/eh/sighandle.C compiled with
> 
> -O2 -fcf-protection -mcet

It is because

(gdb) bt
#0  _Unwind_RaiseException (exc=exc@entry=0x416ed0)
at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:141
#1  0x77d983db in __cxxabiv1::__cxa_throw (obj=obj@entry=0x416ef0, 
tinfo=0x403dd0 , dest=dest@entry=0x0)
at /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90
#2  0x004010cf in sighandler (signo=, 
si=, uc=)
#3  
#4  dosegv () at x.cc:36  <  This is inlined and isn't on shadow stack.
#5  main () at x.cc:36
#6  0x77990433 in __libc_start_main () from /lib64/libc.so.6
#7  0x004011be in _start () at x.cc:36

[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
gfortran 4.8.2 gives

...
Error: Non-polymorphic passed-object dummy argument of 'summation' at (1)

[Bug middle-end/85382] New: code compiled with fno-builtin uses builtin

[konstantin.vladimirov at gmail dot com]

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

Bug ID: 85382
   Summary: code compiled with fno-builtin uses builtin
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

Minimized reproduction:

double a, b;

void f() {
  a = b * b * (628972 + b - 628972);
}

Compile with:

gcc -msse4 -ffast-math -Os -S minimize.c -fno-builtin -ffreestanding

Remove fast-math to kill reproduction.

Assembler:

f:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$3, %edi
movsd   b(%rip), %xmm0
call__powidf2
movsd   %xmm0, a(%rip)
popq%rax
.cfi_def_cfa_offset 8
ret

Compiler version:

Target: x86_64-suse-linux
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least gcc 4.8.5 up to trunk (8.0).

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Peter Bergner  ---
Confirmed.  Looking at the rtl dumps, the only difference coming into SMS, is
the following (due to combine):

-(insn 25 23 26 4 (set (reg:DI 150 [ iD.2875+-4 ])
-(sign_extend:DI (subreg/v:SI (reg/v:DI 137 [ iD.2875+-4 ]) 4)))
"/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33
38 {extendsidi2}
- (nil))
+(note 25 23 26 4 NOTE_INSN_DELETED)
 (insn 26 25 28 4 (set (reg:DI 151)
-(ashift:DI (reg:DI 150 [ iD.2875+-4 ])
-(const_int 3 [0x3])))
"/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33
270 {ashldi3}
- (expr_list:REG_DEAD (reg:DI 150 [ iD.2875+-4 ])
-(nil)))
+(ashift:DI (sign_extend:DI (subreg:SI (reg/v:DI 137 [ iD.2880+-4 ])
4))
+(const_int 3 [0x3])))
"/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33
276 {ashdi3_extswsli}
+ (nil))

...and the ashdi3_extswsli pattern is only enabled with power9.  Not sure yet
why the above disables SMS, but will keep looking.

[Bug testsuite/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Jakub Jelinek  ---
Should be fixed now.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
I've reproduced one test bug on my machine by using:

./cc1 -I. ../../gcc/gcc/testsuite/gcc.dg/dfp/pr41049.c
-fno-expensive-optimizations --param ira-max-conflict-table-size=0 -mpopcntd
-O3

I think the fix can be probably in rs6000 machine-dependent code related to LRA
and fixing it needs to know LRA very well.  So I'll be working on it.

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

The problem is that cse.c (fold_rtx) uses simplify_unary_operation and that
contains stuff like:
  else if (! CLZ_DEFINED_VALUE_AT_ZERO (imode, int_value))
int_value = GET_MODE_PRECISION (imode);
That is fine in some optimization passes, where we just want some value for the
expression, but not in cse, where we want to record that some register has this
constant value and then optimize other uses of the same constant,
canonicalizing to that register.  Of course, when the value is not defined for
zero, the register contains some random value, not the constant we've computed.

So, either we can do what the patch does, or punt instead of returning
GET_MODE_PRECISION in simplify-rtx.c.

[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Thu Apr 12 16:16:08 2018
New Revision: 259350

URL: https://gcc.gnu.org/viewcvs?rev=259350=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2018-04-12  Kelvin Nilsen  

PR target/85347
* gcc.target/powerpc/vec-ldl-1.c: Change dejagnu directives to
specify -mvsx on gcc command line.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/vec-ldl-1.c

[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding

[c...@mnet-mail.de]

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

c...@mnet-mail.de changed:

   What|Removed |Added

Summary|Regression: gfortran|gfortran versions
   |versions 7.2.0/8.0.1 reject |7.2.0/8.0.1 reject F03
   |F03 procedure overriding|procedure overriding

--- Comment #1 from c...@mnet-mail.de ---
Can't actually vouch for gfortran 7.1 being able to compile this, as I no 
longer have access to that gfortran version, so I changed the title (might 
still be a regression, though).

Also, when replacing the line:

   use base

by

   use base, only: base_type

the code compiles with both gfortran 7.2.0 and 8.0.1.

[Bug rtl-optimization/84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling

[amonakov at gcc dot gnu.org]

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

Bug 85354 Summary: [8 regression] ICE with gcc.dg/graphite/pr84872.c starting 
with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354

   What|Removed |Added

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

[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Blocks||84659
 Resolution|--- |FIXED

--- Comment #5 from Alexander Monakov  ---
Fixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659
[Bug 84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in
bb_note) w/ selective scheduling

[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Author: amonakov
Date: Thu Apr 12 15:40:44 2018
New Revision: 259348

URL: https://gcc.gnu.org/viewcvs?rev=259348=gcc=rev
Log:
sel-sched: move cleanup_cfg before calculate_dominance_info (PR 85354)

PR rtl-optimization/85354
* sel-sched-ir.c (sel_init_pipelining): Move cfg_cleanup call...
* sel-sched.c (sel_global_init): ... here.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/sel-sched.c

[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

 CC||paolo.carlini at oracle dot com

--- Comment #7 from Paolo Carlini  ---
For the remaining error-recovery issue, loosening a bit the assertion would be
enough - see below - I don't know if we want to dig deeper... Opinions?

Index: name-lookup.c
===
--- name-lookup.c   (revision 259340)
+++ name-lookup.c   (working copy)
@@ -2052,7 +2052,7 @@ pop_local_binding (tree id, tree decl)
 binding->value = NULL_TREE;
   else
 {
-  gcc_assert (binding->type == decl);
+  gcc_assert (!binding->type || binding->type == decl);
   binding->type = NULL_TREE;
 }

[Bug target/85381] New: [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

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

Bug ID: 85381
   Summary: [og7, nvptx, openacc] parallel-loop-1.c fails with
default vector length 128
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When running parallel-loop-1.c with this patch, it hangs:
...
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
index 4bc71415688..5e7adcb4340 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-additional-options "-fopenacc-dim=::128" } */

 #include 
...

[Bug fortran/83064] DO CONCURRENT and auto-parallelization

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #28 from Christophe Lyon  ---
(In reply to Thomas Koenig from comment #27)

> 
> 2018-04-09  Thomas Koenig  
> 
>   PR fortran/83064
>   * gfortran.dg/do_concurrent_5.f90: New test.

Hi,
I think the testcase is probably missing a require-effective-target, because I
see it failing on aarch64/arm with this error message:
gfortran: error: libgomp.spec: No such file or directory

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|ktietz at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #26 from Eric Botcazou  ---
This should work now.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Apr 12 14:18:17 2018
New Revision: 259347

URL: https://gcc.gnu.org/viewcvs?rev=259347=gcc=rev
Log:
PR target/85238
* lto-wrapper.c (debug_objcopy): Open the files in binary mode.
* dwarf2out.c (dwarf2out_early_finish): Do not generate assembly in LTO
mode for PE-COFF targets.
* config/i386/i386-protos.h (i386_pe_asm_lto_start): Declare.
(i386_pe_asm_lto_end): Likewise.
* config/i386/cygming.h (TARGET_ASM_LTO_START): Define.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/winnt.c (saved_debug_info_level): New static variable.
(i386_pe_asm_lto_start): New function.
(i386_pe_asm_lto_end): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cygming.h
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/winnt.c
trunk/gcc/dwarf2out.c
trunk/gcc/lto-wrapper.c

[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Tom de Vries  ---
Patch committed, marking resolved-fixed

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
I will, once I bootstrap/regtest it fully on a couple of targets.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[chefmax at gcc dot gnu.org]

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

--- Comment #17 from chefmax at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to chefmax from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > or introduce a new virtual pseudo register that vregs pass would map 
> > > directly to dynamic_offset.
> > 
> > Yeah, that's what I though about (LLVM does pretty the same thing). But
> > (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an
> > appropriate solution too. I'll cover the testing for both approaches.
> 
> The above patch passed
> make -j16 -k check-gcc check-g++
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp=alloca*'
> on x86_64-linux and powerpc64-linux and without the -m32, part also on
> powerpc64le-linux.

Nice! Jakub, would you post the patch in ML?

[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450

[seurer at gcc dot gnu.org]

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

--- Comment #11 from seurer at gcc dot gnu.org ---
I dug through my logs and the last failures I saw for phi-opt-11.c and
pr21643.c on powerpc64 were in mid January immediately before Eric's patch.

[Bug ada/85380] New: gnatbind fails with small executable & restricted runtime

[simon at pushface dot org]

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

Bug ID: 85380
   Summary: gnatbind fails with small executable & restricted
runtime
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: arm-eabi
 Build: x86_64-apple-darwin15

After following the change suggested in PR ada/66205 comment 14,
System.Suppress_Standard_Library set to False, I attempted to build a small
program and got the error

b__generate_hard_fault.adb:62:44: "Parameters" not declared in "System"
gprbind: compilation of binder generated file failed

This line is

  Default_Secondary_Stack_Size : System.Parameters.Size_Type;
  pragma Import (C, Default_Secondary_Stack_Size,
"__gnat_default_ss_size");

and in successful builds of other programs System.Parameters is withed (in the
spec; why not in the body?).

On investigating, I find that none of the units in the closure required the
secondary stack (the P lines didn’t contain 'SS'); this means that
Opt.Sec_Stack_Used is False.

The 'with System.Parameters;' line is generated at bindgen.adb:2286 if
Opt.Sec_Stack_Used is True.

If Suppress_Standard_Library_On_Target is False, the
'Default_Secondary_Stack_Size' line is generated unconditionally at
bindgen.adb:748.

Proposed solution: make generation of the 'with System.Parameters;' line
conditional on (Opt.Sec_Stack_Used or not Suppress_Standard_Library_On_Target).

Proposed alternative solution: make generation of the
'Default_Secondary_Stack_Size' and related lines at bindgen.adb:748 conditional
on Opt.Sec_Stack_Used. I think this would need a lot more thought to make sure
it was OK in all circumstances.

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The bug seems to be introduced during cse_local, before that we have:
(insn 28 26 31 2 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 188)
(const_int 0 [0])))
(set (reg:SI 93 [ _13 ])
(ctz:SI (reg:SI 188)))
]) "pr85376.c":12 735 {*bsfsi_1}
 (expr_list:REG_DEAD (reg:SI 188)
(expr_list:REG_UNUSED (reg:SI 93 [ _13 ])
(expr_list:REG_UNUSED (reg:CCZ 17 flags)
(nil)
...
(insn 55 54 56 2 (set (reg:SI 194 [ o ])
(const_int 32 [0x20])) "pr85376.c":14 86 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:HI 91 [ o ])
(nil)))
(insn 56 55 57 2 (set (reg:QI 108 [ _26+1 ])
(const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal}
 (nil))
(insn 57 56 58 2 (parallel [
(set (reg:CC 17 flags)
(compare:CC (subreg:QI (reg:SI 194 [ o ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
(set (reg:QI 195)
(minus:QI (subreg:QI (reg:SI 194 [ o ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
]) "pr85376.c":14 294 {*subqi_3}
 (expr_list:REG_DEAD (reg:SI 194 [ o ])
(expr_list:REG_DEAD (reg:SI 104 [ _23 ])
(nil

But cse_local changes that to:
(insn 56 54 57 2 (set (reg:QI 108 [ _26+1 ])
(const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal}
 (nil))
(insn 57 56 58 2 (parallel [
(set (reg:CC 17 flags)
(compare:CC (subreg:QI (reg:SI 93 [ _13 ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
(set (reg:QI 195)
(minus:QI (subreg:QI (reg:SI 93 [ _13 ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
]) "pr85376.c":14 294 {*subqi_3}
 (expr_list:REG_DEAD (reg:SI 194 [ o ])
(expr_list:REG_DEAD (reg:SI 104 [ _23 ])
(nil
but pseudo 93 certainly isn't known to contain (const_int 32).  I don't think
cse pass uses cselib though.

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
There is nothing weird about what cprop1 does, __builtin_ffs (0) is known to be
0, with so many disabled optimizations we just don't optimize it away nor
simplify earlier.  So the
mov eax, 0  # tmp201,
bsf edx, eax# _28, tmp201
mov ecx, -16# tmp204,
add eax, ecx# tmp203, tmp204
part is just fine, we replaced the edx in the addition with eax which is known
to hold the same value, and because DCE is disabled nothing removes the dead
bsf.

[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug gcov-profile/85377] [GCOV] Wrong coverage with label and if(cond) break in while(1)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-12
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion

[cesar at gcc dot gnu.org]

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

--- Comment #5 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Thu Apr 12 13:15:45 2018
New Revision: 259346

URL: https://gcc.gnu.org/viewcvs?rev=259346=gcc=rev
Log:
PR middle-end/84955

gcc/
* lto-streamer-out.c (output_function): Fix CFG loop state before
streaming out.
* omp-expand.c (expand_oacc_for): Handle calls to internal
functions like regular functions.

libgomp/
* testsuite/libgomp.oacc-c-c++-common/pr84955.c: New test.
* testsuite/libgomp.oacc-fortran/pr84955.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/omp-expand.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/85379] New: Missing ENDBR in __stack_split_initialize

[hjl.tools at gmail dot com]

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

Bug ID: 85379
   Summary: Missing ENDBR in __stack_split_initialize
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Program received signal SIGSEGV, Segmentation fault.
__stack_split_initialize ()
at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751
751 leaq-16000(%rsp),%rax   # We should have at least 16K.
Missing separate debuginfos, use: dnf debuginfo-install
libgcc-8.0.1-0.21.0.fc28.x86_64
(gdb) disass
Dump of assembler code for function __stack_split_initialize:
=> 0x00402858 <+0>: lea-0x3e80(%rsp),%rax
   0x00402860 <+8>: mov%rax,%fs:0x70
   0x00402869 <+17>:sub$0x8,%rsp
   0x0040286d <+21>:mov%rsp,%rdi
   0x00402870 <+24>:mov$0x3e80,%esi
   0x00402875 <+29>:callq  0x401810
<__generic_morestack_set_initial_sp>
   0x0040287a <+34>:add$0x8,%rsp
   0x0040287e <+38>:retq   
End of assembler dump.
(gdb) 

This

diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S
index eca441a2867..99e65eaaff4 100644
--- a/libgcc/config/i386/morestack.S
+++ b/libgcc/config/i386/morestack.S
@@ -730,6 +730,7 @@ __morestack_large_model:
 #endif

 __stack_split_initialize:
+  _CET_ENDBR

 #ifndef __x86_64__

fixes it.


Referenced Bugs:

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #16 from Dmitry Vyukov  ---
Here is disasm of the function with the patch:

https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt

And the epilogue:

8305fe5f:   48 8d 75 d8 lea-0x28(%rbp),%rsi
8305fe63:   48 89 e7mov%rsp,%rdi
8305fe66:   e8 35 a9 ac fe  callq  81b2a7a0
<__asan_allocas_unpoison>
8305fe6b:   44 89 f0mov%r14d,%eax
8305fe6e:   48 8b 4d d0 mov-0x30(%rbp),%rcx
8305fe72:   65 48 33 0c 25 28 00xor%gs:0x28,%rcx
8305fe79:   00 00 
8305fe7b:   0f 85 5f 01 00 00   jne8305ffe0

8305fe81:   48 8d 65 d8 lea-0x28(%rbp),%rsp
8305fe85:   5b  pop%rbx
8305fe86:   41 5c   pop%r12
8305fe88:   41 5d   pop%r13
8305fe8a:   41 5e   pop%r14
8305fe8c:   41 5f   pop%r15
8305fe8e:   5d  pop%rbp
8305fe8f:   c3  retq   

Kernel boots.

So far I don't see these alloca-related false positives. If I see something
suspicious I will post here, but otherwise consider that everything is good.

Thanks!

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Thus looks like a cselib issue to me.

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
-fdisable-rtl-cprop2 -fdisable-rtl-cprop1 fixes it, likewise
-fdisable-rtl-cse_local:

> diff -u t.c.245r.cprop2 t.c.247r.cse_local
...
-   41: r194:SI=0x20
-  REG_DEAD r91:HI
42: r108:QI=0
-   43: {flags:CC=cmp(r194:SI#0,r104:SI#0);r195:QI=r194:SI#0-r104:SI#0;}
+   43: {flags:CC=cmp(r93:SI#0,r104:SI#0);r195:QI=r93:SI#0-r104:SI#0;}

huh.

[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs

[jakub at gcc dot gnu.org]

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

Bug 85378 Summary: -fsplit-stack is incompatible with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378

   What|Removed |Added

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

[Bug target/85378] -fsplit-stack is incompatible with -fcf-protection -mcet

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
-fsplit-stack doesn't require gold linker, only if you want to build parts with
-fsplit-stack and other parts without it and rely on the linker to fix it up,
you need gold.  So, emitting an error is just incorrect.

[Bug tree-optimization/85360] FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2018-04-12 3:43 AM, rguenth at gcc dot gnu.org wrote:
> Any special
> configury required?
No.

[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Created attachment 43921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43921=edit
0002-nvptx-Fix-propagation-of-branch-cond-in-vw-neutered-code.patch

Tentative fix.

[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 43920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43920=edit
0001-nvptx-Simplifly-logic-in-nvptx_single.patch

NFC patch to make fix easier

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

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

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
  Known to work||7.3.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Should be fixed now.

[Bug target/85378] New: -fsplit-stack is incompatible with -fcf-protection -mcet

[hjl.tools at gmail dot com]

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

Bug ID: 85378
   Summary: -fsplit-stack is incompatible with -fcf-protection
-mcet
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---

-fsplit-stack requires gold linker, which doesn't support GNU property
required by Intel CET:

https://sourceware.org/bugzilla/show_bug.cgi?id=22914
https://sourceware.org/bugzilla/show_bug.cgi?id=22915

It should be an error to use -fsplit-stack with -fcf-protection -mcet.


Referenced Bugs:

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

[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> I went through a couple of cycles of minimizing the failure, seeing
> something suspicious, modifying by hand or writing a tentative patch, but
> every time I went back to the original non-minimized example I got the
> failure again.
> 
> Anyway, things that may be causing this fail:

> 2.
> 
> The bar.sync instruction may not be sufficiently understood.
> 
> In the documentation for bar.sync it says:
> ...
> bar.sync and bar.red also guarantee memory ordering among threads identical
> to
> membar.cta . Thus, threads within a CTA that wish to communicate via memory
> can
> store to memory, execute a bar.sync or bar.red instruction, and then safely
> read
> values stored by other threads prior to the barrier.
> ...
> 
> The question is what happens when you specify a thread count. Does the
> memory ordering still apply to the whole CTA, or only to the threads
> participating in the barrier?
> 
> So if we store something in vector id 0, worker id 0, and load it in worker
> id 1, we may have to use a bar.sync 0 instead to synchronize (or keep the
> same barrier but add a membar.cta).

I misanalyzed why the test was failing, it was not a barrier problem.

There are two situations in which there is state propagation:
1. when transitioning from single to partition mode, for either worker
   or vector (so, when entering a partitioned loop)
2. when propagating branch conditions. [ We implement worker-single and
   vector-single by branch around, but do not branch around branches, so
   the branch condition is calculated in either W0V0 or WAV0 code, and
   then used in WAVA code.

To go from worker single to worker partitioned (W0V0 -> WAV0), we use a generic
broadcast buffer.

To go from vector single to vector partitioned (WAV0 -> WAVA), we use a
worker-specific broadcast buffer.

To propagate the branch condition, we use the worker-specific broadcast buffer,
but that only works for WAV0 -> WAVA. For the W0V0 -> WAVA propagation, we need
to use the generic broadcast buffer.

[Bug target/85328] [8 Regression] accessing ymm16 with non-avx512 instruction form

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 12 12:27:14 2018
New Revision: 259345

URL: https://gcc.gnu.org/viewcvs?rev=259345=gcc=rev
Log:
2018-04-12  Richard Biener  

PR lto/85371
* dwarf2out.c (init_sections_and_labels): Use
debug_line_section[_label]
for the early LTO debug to properly generate references to it
during DIE emission.  Do not re-use that for the skeleton for
split-dwarf.
(dwarf2out_early_finish): Likewise.

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

[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> I went through a couple of cycles of minimizing the failure, seeing
> something suspicious, modifying by hand or writing a tentative patch, but
> every time I went back to the original non-minimized example I got the
> failure again.
> 
> Anyway, things that may be causing this fail:
> 
> 1.
> 
> The og7 fix for PR85204 introduces a unified jump (bra.uni) for a jump
> conditional consisting of a test for vector id == 0 && worker id == 0. The
> fact that we're going a different direction in worker id 0 for vector id 0
> and vector id 1 means the branch diverges, and is _not_ unified. It seems
> prudent to fix this by reverting the og7 fix and backporting the trunk fix.

Fixed here: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00525.html

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to chefmax from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > or introduce a new virtual pseudo register that vregs pass would map 
> > directly to dynamic_offset.
> 
> Yeah, that's what I though about (LLVM does pretty the same thing). But
> (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an
> appropriate solution too. I'll cover the testing for both approaches.

The above patch passed
make -j16 -k check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp=alloca*'
on x86_64-linux and powerpc64-linux and without the -m32, part also on
powerpc64le-linux.

[Bug tree-optimization/85375] possible missed optimisation / regression from 6.3 with while (__builtin_ffs(x) && x)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-12
 Blocks||85316
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
.optimized shows

   [local count: 114863532]:
  _8 = __builtin_ffs (x_4(D));
  if (_8 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 108546038]:
  if (x_4(D) != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

missed jump-threading.

   [local count: 958878293]:
  # x_10 = PHI 
  x_6 = x_10 - a.0_1;
  _2 = __builtin_ffs (x_6);
  if (_2 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 906139986]:
  if (x_6 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

likewise.  VRP needs to derive a range for x_6 from _2 != 0.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[chefmax at gcc dot gnu.org]

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

--- Comment #14 from chefmax at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #13)
> or introduce a new virtual pseudo register that vregs pass would map directly 
> to dynamic_offset.

Yeah, that's what I though about (LLVM does pretty the same thing). But (new_sp
+ virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an appropriate
solution too. I'll cover the testing for both approaches.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

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

So, if you want to add STACK_DYNAMIC_OFFSET to new_sp for the second argument,
then we could do either what this patch does (i.e. pass new_sp +
(virtual_stack_dynamic_rtx - stack_pointer_rtx) as second argument) and rely on
cse/forwprop/combine to optimize it into new_sp (if STACK_DYNAMIC_OFFSET is 0)
or to just addition of some constant, or introduce a new virtual pseudo
register that vregs pass would map directly to dynamic_offset.

[Bug gcov-profile/85377] New: [GCOV] Wrong coverage with label and if(cond) break in while(1)

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85377
   Summary: [GCOV] Wrong coverage with label and if(cond) break in
while(1)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc pv
gcc: error: pv: No such file or directory
gcc: fatal error: no input files
compilation terminated.
root@localhost:~/ccv# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
int g = 0;

int main ()
{
  while (1)
  {
int i = 2;
L1:
if (g < 1)
  break;
  }

  while (1)
  {
int i = 2;
L2:
// if (g < 1)
  break;
  }
  return 0;
}

$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:90.00% of 10
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int g = 0;
-:2:
1:3:int main ()
-:4:{
-:5:  while (1)
#:6:  {
1:7:int i = 2;
1:8:L1:
1:9:if (g < 1)
1:   10:  break;
-:   11:  }
-:   12:
-:   13:  while (1)
-:   14:  {
1:   15:int i = 2;
1:   16:L2:
-:   17:// if (g < 1)
1:   18:  break;
-:   19:  }
1:   20:  return 0;
-:   21:}

Line #6 is wrongly marked as not executed with "#".
For the second while statement, coverage of Line #14 is correct.