[Bug tree-optimization/85597] [6 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mattwi at fysik dot dtu.dk

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

[Bug tree-optimization/87458] fma and -O3 wrong result

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
I suspect this has been fixed already and is a duplicate of bug 85597.

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

[Bug fortran/70863] [F03] Finalization of array of derived type causes segfault

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
Is this code posted October 28 on c.l.f. another incarnation of the same
problem?
module third_party_library
  type foo
integer, pointer :: f(:) => null()
  contains
final :: foo_destroy
  end type
contains
  impure elemental subroutine foo_destroy(this)
type(foo), intent(inout) :: this
print *, "foo"
if (associated(this%f)) deallocate(this%f)
  end subroutine
end module

module my_code
  use third_party_library
  type bar
type(foo) :: b(2)
  end type
end module

program main
  use my_code
  type(bar) :: x
  call sub(x)
contains
  subroutine sub(x)
type(bar), intent(out) :: x
  end subroutine
end program

[Bug fortran/65347] [F03] Final subroutine not called for function result

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Also still present in trunk.

[Bug fortran/71798] [OOP] failure to finalise temporary

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
Still present in actual trunk.

[Bug fortran/87459] New: -Wunused-variable: False positive for associated variables

[m.diehl at mpie dot de]

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

Bug ID: 87459
   Summary: -Wunused-variable: False positive for associated
variables
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Warning messages about unused variables (-Wunused-variable) appear wrongly when
associate is used (false positive):

pprogram test

  implicit none
  real :: a = 5
  real :: b

  associate(b => a)
write(6,*) b
  end associate

end program


gives

Warning: Unused variable ‘b’ declared at (1) [-Wunused-variable]

when complied with -Wunused-variable

[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #14 from Segher Boessenkool  ---
I'm closing this as fixed.  Please reopen if you want a backport (of the
#c13 part).  Thanks!

[Bug target/87195] ICE in simplify_binary_operation_1, at simplify-rtx.c:3637

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Segher Boessenkool  ---
Fixed with r264584.

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

[Bug target/86987] ICE in simplify_binary_operation_1, at simplify-rtx.c:3515 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
*** Bug 87195 has been marked as a duplicate of this bug. ***

[Bug target/87033] The compiler does not generate the LWAX instruction

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #7 from Michael Meissner  ---
Fixed in the trunk, gcc 8, and gcc 7 branches.

[Bug target/87033] The compiler does not generate the LWAX instruction

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Author: meissner
Date: Fri Sep 28 00:32:46 2018
New Revision: 264686

URL: https://gcc.gnu.org/viewcvs?rev=264686&root=gcc&view=rev
Log:
Backport pr 87033 to gcc 7

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr87033.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/87447] Missing -Wconversion warning in implicit conversion of unsigned long long to double

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
C++ warns:

:5:3: warning: conversion from 'long long unsigned int' to 'double'
changes value from '9223372036854775809' to '9.2233720368547758e+18'
[-Wfloat-conversion]

[Bug c/70477] -Wtautological-compare too aggressive?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
A cast suppresses the warning so that might be a solution (or a workaround) in
the _Static_assert case:

   _Static_assert ((void*)&a == (void*)A, "&a must be A");

[Bug c++/87364] Pretty print of enumerator never prints the id, always falls back to C-style cast output

[wjwray at gmail dot com]

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

--- Comment #5 from Will Wray  ---
re: https://gcc.gnu.org/ml/gcc/2018-02/msg9.html
discussion on removing literal suffixes from Integral constants
(part a bigger conversation I'll pick up on below).

That change brought GCC into line with clang and MSVC which both
currently output plain digits with no distinguishing type info.
Unfortunately, plain digits output fails to distinguish non-type
template Args with same values but different Integral types.

To see how this discussion relates to enumeration constants
we must distinguish non-enumerated from enumerated values.

For non-enumerated values clang and MSVC output plain digits
while GCC outputs a C-style cast* (unchanged by this patch). 

For enumerated values the patch here brings GCC into line with
current clang and MSVC - all three now output enumerator ids*
(current MSVC outputs duplicate-value ids as-if non-enumerated).

(*ids and cast type are output with nested-specifier sequence.)

Clang & MSVC discussion
---
I started a thread with Clang devs about adding type info to enums:
__PRETTY_FUNCTION__ output loses enum type info for non-enumerated values
http://lists.llvm.org/pipermail/cfe-dev/2018-September/059229.html
(I also submitted a broader request to MSVC
https://developercommunity.visualstudio.com/content/problem/339663/improve-pretty-print-of-integral-non-type-template.html)

Richard Smith is open to the idea of Clang adding type info where needed.
He points out that the type info is only needed for deduced arguments,
which I interpret to mean 'auto' in C++17 but can be concept in C++20.
He singles out enum printing as a case where it may be OK to always print
the type, arguing that implicit conversion from integer is not allowed.

Mr Smith expanded the thread to cover -

General non-type template arguments: Integral constants and more
---
Picking up here on the bigger conversation, which really belongs elsewhere.
In the linked thread https://gcc.gnu.org/ml/gcc/2018-02/msg00030.html

Martin Sebor: 
  For auto, since it's new, a viable alternative might be to
  standardize the debug info format so that eventually all
  producers will converge on it. But even that approach won't
  help users of existing compilers.

C++20 generalises template non-type arguments to include LiteralType
https://en.cppreference.com/w/cpp/language/template_parameters
I doubt anyone considered yet what this means for debug info.
How do you pretty-print a general non-scalar non-type Arg constant?
Implementations will have to deal with this somehow (or ignore it).

Without consensus we'll get greater divergence.
This provides motivation NOW to discuss a general standard format.

While this is outside the remit of the C++ standards process
requirements for debug info / pretty-print should feed back to it.

For instance, it'd be useful for non-type Args to have a unique,
canonical constructor, akin to aggregate initialization perhaps.

Where best to pick up this discussion towards standard debug info?

[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
This should be fixed on trunk now.  Martin, can you please check that?

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Should be fixed on trunk now.

[Bug c/70477] -Wtautological-compare too aggressive?

[petr at vandrovec dot name]

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

Petr Vandrovec  changed:

   What|Removed |Added

 CC||petr at vandrovec dot name

--- Comment #7 from Petr Vandrovec  ---
Would it be possible to special-case parameter for _Static_assert, as whole
purpose of _Static_assert is to have constant value that is non-zero?

We have in our code base code that ends up calling _Static_assert() with really
complicated constant expression.

When regular gcc is used, code compiles fine with all optimization levels, as
gcc recognizes there are complicated macros involved, and backs off.  When
ccache is used, it preprocesses source in separate step, and gcc will complain
about tautological compare inside _Static_assert :-(

Would it be possible to either suppress warning when used as parameter for
_Static_assert, or remove tautological-compare warnings if -fpreprocessed is
passed to the compiler, as macro heuristics are subverted by doing
preprocessing in separate step?

Example (our code is more complicated, this is simplest example I came up
with):

$ cat test.c
#define A &a
int a;

void test(void) {
   _Static_assert(&a == A, "&a must be A");
}
$ gcc -c -Wall -Werror test.c
$ gcc -c -Wall -Werror test.c -no-integrated-cpp
x.c: In function 'test':
x.c.:5:22: error: self-comparison always evaluates to true
[-Werror=tautological-compare]
   _Static_assert(&a == A, "&a must be A");

cc1: all warnings being treated as errors

It happens with 8.2.0, as well as with 6.4.0.

$ gcc --version
gcc (Debian 8.2.0-6) 8.2.0

[Bug target/87033] The compiler does not generate the LWAX instruction

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/86465] C++17 triggers: ‘’ may be used uninitialized in this function

[proski at gnu dot org]

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

--- Comment #2 from Pavel Roskin  ---
Created attachment 44761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44761&action=edit
Heavily simplified example, g++-5 compatible

I'm attaching a dumbed down version of the previous example, which compiles
with gcc 5.5.0 and newer.

gcc 5.5.0 and gcc 6.4.0 don't produce any warning. gcc 7.3.0, 8.1.0 and the
today's gcc from the git master branch all produce the warning.

That suggests that the issue is indeed related to the one described in bug
#86485.

The implementation of optional in libstdc++ 7 doesn't trigger a warning, it's
the changes in libstdc++ 8 that started triggering it. However, gcc 7 appears
to have the same compiler issue.

[Bug target/87033] The compiler does not generate the LWAX instruction

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Thu Sep 27 21:31:04 2018
New Revision: 264679

URL: https://gcc.gnu.org/viewcvs?rev=264679&root=gcc&view=rev
Log:
Backport PR 87033

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87033.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/87458] fma and -O3 wrong result

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
-  u._M_elems[0] = 7.0e+0;
-  u._M_elems[1] = 7.0e+0;
+  MEM[(double *)&u] = { 7.0e+0, 7.0e+0 };
   D.41349 = create (1.0e+2);
-  _9 = MEM[(value_type &)&u];
-  tmp_10 = -_9;
   _11 = MEM[(const value_type &)&D.41349];
-  _12 = _11 * 1.0e+0 + tmp_10;
-  MEM[(value_type &)&u] = _12;
-  _13 = MEM[(value_type &)&u + 8];
-  tmp_14 = -_13;
+  vect__11.38_25 = MEM[(const value_type &)&D.41349];
   _15 = MEM[(const value_type &)&D.41349 + 8];
-  _16 = _15 * 1.0e+0 + tmp_14;
-  MEM[(value_type &)&u + 8] = _16;
+  vect_cst__29 = {_11, _15};
+  vect__12.43_30 = vect__11.38_25 * { 1.0e+0, 1.0e+0 } + vect_cst__29;
+  MEM[(value_type &)&u] = vect__12.43_30;

It is worse, notice how _11 * 1.0e+0 + tmp_10; and _15 * 1.0e+0 + tmp_14; are
combined into:
vect_cst__29 = {_11, _15};
vect__11.38_25 * { 1.0e+0, 1.0e+0 } + vect_cst__29;
But vect_cst__29 is not {tmp_10, tmp_14} or -{_9, _13} or rather
-MEM[(value_type &)&u];

Looks like the SLP vectorizer is using operand 0 for the operand 2 which is
incorrect.

[Bug tree-optimization/87458] fma and -O3 wrong result

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||aarch64-linux-gnu
   ||x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
A negate has gone missing ...

Confirmed happens on aarch64-linux-gnu also.

[Bug c++/87458] New: fma and -O3 wrong result

[mattwi at fysik dot dtu.dk]

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

Bug ID: 87458
   Summary: fma and -O3 wrong result
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattwi at fysik dot dtu.dk
  Target Milestone: ---

Created attachment 44760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44760&action=edit
preprocessed source

Dear developers, 

I have an issue when I combine std::fma with -O3. It leads to wrong output.
I apologize if this has already been addressed somewhere. 

Best regards
Matthias

COMMAND LIND
g++-7 -O3 -Wall -Wextra -mfma  test.cpp -o test

OUTPUT
Need to output x to reproduce error 100
In dot u is 200 (Correct value is 93)
8 (Correct value is 17298)

OUTPUT COMPILED WITH -O2 INSTEAD OF -O3
Need to output x to reproduce error 100
In dot u is 93 (Correct value is 93)
17298 (Correct value is 17298)

GCC INFO:

Using built-in specs.
COLLECT_GCC=g++-7
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.3.0-21ubuntu1~16.04' --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 --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.3.0 (Ubuntu 7.3.0-21ubuntu1~16.04) 

PROGRAM: test.cpp

#include 
#include 
#include 


std::array create(double x)
{
std::cout << "Need to output x to reproduce error ";
std::cout << x << std::endl;
return {x,x};
}

void axpby( double alpha, const std::array& x, double beta,
std::array& y)
{
double tmp = beta*y[0];
y[0] = std::fma( alpha,x[0],tmp);
tmp = beta*y[1];
y[1] = std::fma( alpha,x[1],tmp);
}
double dot( const std::array& u)
{
//we also need this output to reproduce error
std::cout << "In dot u is "< u = {{7,7}};
axpby( 1., create(100), -1., u); //100 - 7 , 100 - 7
std::cout << dot( u)<<" (Correct value is 17298)" << std::endl;

return 0;
}

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Author: segher
Date: Thu Sep 27 19:54:09 2018
New Revision: 264675

URL: https://gcc.gnu.org/viewcvs?rev=264675&root=gcc&view=rev
Log:
rs6000: Delete many HAVE_AS_* (PR87149)

This deletes most HAVE_AS_* that determine if the assembler supports
some ISA level (and also HAVE_AS_MFPGPR and HAVE_AS_DFP).

These are not useful: we will only generate an instruction that requires
some newer ISA if the user specifically asked for it (with -mcpu=, say).
If the assembler cannot handle that, it is fine if it gives an error.

They also hurt: it increases the number of possible situations that all
need handling and all need testing.  We do not handle all cases, and
obviously do not test all either.

This patch removes:

HAVE_AS_POPCNTB (power5,  2.02)
HAVE_AS_FPRND   (power5+, 2.04)
HAVE_AS_CMPB(power6,  2.05)
HAVE_AS_POPCNTD (power7,  2.06)
HAVE_AS_POWER8  (power8,  2.07)
HAVE_AS_POWER9  (power9,  3.0)

HAVE_AS_DFP (power6,  2.05, server)
HAVE_AS_MFPGPR  (power6x but not later, not arch)


PR target/87149
* config.in (HAVE_AS_CMPB, HAVE_AS_DFP, HAVE_AS_FPRND, HAVE_AS_MFPGPR,
HAVE_AS_POPCNTB, HAVE_AS_POPCNTD, HAVE_AS_POWER8, HAVE_AS_POWER9):
Delete, always treat as true.
* config/powerpcspe/powerpcspe.c (rs6000_option_override_internal):
Ditto.  Simplify remaining code.
* config/powerpcspe/powerpcspe.h: Ditto.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Ditto.
Simplify remaining code.
(rs6000_expand_builtin): Ditto.
* config/rs6000/rs6000.h: Ditto.
* configure.ac: Ditto.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/powerpcspe/powerpcspe.c
trunk/gcc/config/powerpcspe/powerpcspe.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug c++/84423] [6/7/8/9 Regression] [concepts] ICE with invalid using declaration

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/87457] thread sanitizer false positive on virtual destructor

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I think the problem is that the std::thread code in libstdc++.so isn't built
with ThreadSanitizer.

[Bug c++/87456] Attributes on a global empty statement

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Ever confirmed|0   |1

[Bug c++/87457] New: thread sanitizer false positive on virtual destructor

[SebastiansPublicAddress at googlemail dot com]

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

Bug ID: 87457
   Summary: thread sanitizer false positive on virtual destructor
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SebastiansPublicAddress at googlemail dot com
  Target Milestone: ---

Created attachment 44759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44759&action=edit
source code to reproduce the bug

reproduce like this:

$ g++ -g -fno-omit-frame-pointer -fsanitize=undefined -fsanitize=thread -o
tsan_reproduce tsan_reproduce.cpp

$ ./tsan_reproduce
==
WARNING: ThreadSanitizer: data race (pid=19509)
  Write of size 8 at 0x7b040800 by thread T2:
#0 pipe  (libtsan.so.0+0x2f079)
#1   (libubsan.so.1+0x1aaed)
#2 void std::__invoke_impl(std::__invoke_other, void
(*&&)()) /usr/include/c++/8/bits/invoke.h:60 (tsan_reproduce+0x3efc)
#3 std::__invoke_result::type std::__invoke(void
(*&&)()) /usr/include/c++/8/bits/invoke.h:95 (tsan_reproduce+0x38e4)
#4 decltype (__invoke((_S_declval<0ul>)()))
std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>) /usr/include/c++/8/thread:244
(tsan_reproduce+0x569f)
#5 std::thread::_Invoker >::operator()()
/usr/include/c++/8/thread:253 (tsan_reproduce+0x55b7)
#6 std::thread::_State_impl >
>::_M_run() /usr/include/c++/8/thread:196 (tsan_reproduce+0x554c)
#7   (libstdc++.so.6+0xbbafe)

  Previous write of size 8 at 0x7b040800 by thread T1:
#0 pipe  (libtsan.so.0+0x2f079)
#1   (libubsan.so.1+0x1aaed)
#2 std::thread::_State_impl >
>::~_State_impl() /usr/include/c++/8/thread:188 (tsan_reproduce+0x54a3)
#3   (libstdc++.so.6+0xbbb07)

  Thread T2 (tid=19512, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x2be2b)
#1 std::thread::_M_start_thread(std::unique_ptr >, void (*)()) 
(libstdc++.so.6+0xbbd84)
#2 main
/home/sebastian/projects/photoalbum/lib/sqdbcpp/tsan_reproduce.cpp:18
(tsan_reproduce+0x346f)

  Thread T1 (tid=19511, finished) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x2be2b)
#1 std::thread::_M_start_thread(std::unique_ptr >, void (*)()) 
(libstdc++.so.6+0xbbd84)
#2 main
/home/sebastian/projects/photoalbum/lib/sqdbcpp/tsan_reproduce.cpp:17
(tsan_reproduce+0x345c)

SUMMARY: ThreadSanitizer: data race
(/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x2f079) in pipe
==
ThreadSanitizer: reported 1 warnings




My system:

$ uname -a
Linux roc-lin 4.18.0-1-amd64 #1 SMP Debian 4.18.8-1 (2018-09-18) x86_64
GNU/Linux

$ g++ --version
g++ (Debian 8.2.0-7) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c/87435] "Duplicate const" warning NOT emitted from typedef in -std=c90

[ndesaulniers at google dot com]

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

Nick Desaulniers  changed:

   What|Removed |Added

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

--- Comment #2 from Nick Desaulniers  ---
Ok, looks like this can be a -pedantic warning.

[Bug c++/87456] New: Attributes on a global empty statement

[aaron.ballman+gcc at gmail dot com]

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

Bug ID: 87456
   Summary: Attributes on a global empty statement
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron.ballman+gcc at gmail dot com
  Target Milestone: ---

GCC rejects the following valid program:
```
[[]];

int main() {}
```
with the error "declaration does not declare anything" on the attribute.
However, this is a valid attribute-declaration and should be accepted.

https://godbolt.org/z/I_7mIg

[Bug c/87390] [x86 32bit only] GCC does not honor FLT_EVAL_METHOD on implicit conversion of integer to floating point

[vincent-gcc at vinc17 dot net]

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

--- Comment #27 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #26)
> The general explanation of the choices made in the cases where C99 was 
> less than optimally clear is in 
> , the original 
> addition of support for -fexcess-precision=standard.

This is not visible by the end user. The decision made for -std=c99 should
really be documented in the GCC manual (in Section 4.6 Floating Point), in
particular as this is the only exception and yields different results for
similar code (e.g. the last two cases in my example). This is made worse by the
fact that -Wfloat-conversion does not warn (bug 87447).

[Bug target/87455] sse_packed_single_insn_optimal is suboptimal on Zen

[fanael4 at gmail dot com]

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

--- Comment #1 from Fanael  ---
Assembly diff between the two:

--- /dev/fd/63  2018-09-27 17:59:06.120507763 +0200
+++ /dev/fd/62  2018-09-27 17:59:06.120507763 +0200
@@ -7,21 +7,21 @@
 main:
 .LFB5179:
.cfi_startproc
-   movaps  .LC0(%rip), %xmm0
-   movaps  .LC1(%rip), %xmm1
+   movdqa  .LC0(%rip), %xmm0
+   movdqa  .LC1(%rip), %xmm1
movl$10, %eax
-   movaps  .LC2(%rip), %xmm2
+   movdqa  .LC2(%rip), %xmm2
.p2align 4,,15
 .L2:
paddd   %xmm2, %xmm1
-   xorps   %xmm0, %xmm2
+   pxor%xmm0, %xmm2
decl%eax
paddd   %xmm1, %xmm0
-   movaps  %xmm2, %xmm3
-   xorps   %xmm2, %xmm1
+   movdqa  %xmm2, %xmm3
+   pxor%xmm2, %xmm1
paddd   %xmm0, %xmm3
-   xorps   %xmm1, %xmm0
-   movaps  %xmm3, %xmm2
+   pxor%xmm1, %xmm0
+   movdqa  %xmm3, %xmm2
jne .L2
movaps  %xmm3, -40(%rsp)
movaps  %xmm1, -56(%rsp)

[Bug c++/86946] ice: canonical types differ for identical types

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Problem seems to exist sometime before revision 247000,
dated 2017-04-19.

[Bug target/87455] New: sse_packed_single_insn_optimal is suboptimal on Zen

[fanael4 at gmail dot com]

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

Bug ID: 87455
   Summary: sse_packed_single_insn_optimal is suboptimal on Zen
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fanael4 at gmail dot com
  Target Milestone: ---

GCC by default enables -mtune-ctrl=sse_packed_single_insn_optimal on
-mtune=znver1, even though that microarchitecture doesn't like it for the same
reason Intel's microarchitectures don't: there's additional latency for domain
crossing operations, using e.g. xorps for integer data costs one cycle more
than using pxor.

Example code:

#include 

int main() {
auto x = _mm_setr_epi32(1, 2, 3, 4);
auto y = _mm_setr_epi32(5, 6, 7, 8);
auto z = _mm_setr_epi32(9, 10, 11, 12);

for(int i = 0; i < 10; ++i) {
x = _mm_add_epi32(x, y);
y = _mm_xor_si128(y, z);
z = _mm_add_epi32(z, x);
x = _mm_xor_si128(x, y);
y = _mm_add_epi32(y, z);
z = _mm_xor_si128(z, x);
}

asm volatile("" :: "m"(x), "m"(y), "m"(z));
}

Compiled with GCC 8.2, with -O3 -mtune=znver1 running it yields the following
perf counters:

$ perf stat -e task-clock,cycles,instructions ./a.out

 Performance counter stats for './a.out':

  1 193,69 msec task-clock:u  #0,989 CPUs utilized  
 4 040 330 384  cycles:u  # 3386697,723 GHz 
10 002 005 027  instructions:u#2,48  insn per cycle 

   1,206801245 seconds time elapsed

   1,190625000 seconds user
   0,003995000 seconds sys

However, the code compiled with -O3 -mtune=znver1
-mtune-ctrl=^sse_packed_single_insn_optimal is significantly faster:

$ perf stat -e task-clock,cycles,instructions ./a.out

 Performance counter stats for './a.out':

894,08 msec task-clock:u  #0,998 CPUs utilized  
 3 012 492 242  cycles:u  # 3369678,123 GHz 
10 002 004 492  instructions:u#3,32  insn per cycle 

   0,895728255 seconds time elapsed

   0,894688000 seconds user
   0,0 seconds sys

This is on a Ryzen 5 2500U.

[Bug c/87390] [x86 32bit only] GCC does not honor FLT_EVAL_METHOD on implicit conversion of integer to floating point

[joseph at codesourcery dot com]

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

--- Comment #26 from joseph at codesourcery dot com  ---
On Thu, 27 Sep 2018, vincent-gcc at vinc17 dot net wrote:

> > The interpretation of C99 rules for excess precision used in GCC has been
> > explained at length from 2008 onwards.
> 
> Could you cite where this bug is documented in GCC?

The general explanation of the choices made in the cases where C99 was 
less than optimally clear is in 
, the original 
addition of support for -fexcess-precision=standard.

The part of this issue that I consider a bug (i.e. the case of C11 and 
later modes, the default being -std=gnu17, so if someone just uses 
-fexcess-precision=standard in the default mode they'll get the C11 
semantics) is fixed for GCC 9.

[Bug sanitizer/87453] Maybe implement -fsanitize=float-cast-overflow and -fsanitize=float-divide-by-zero

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
These two seem a bit too specific. They are also not undefined behavior (just
like unsigned integer overflow is not).

I imagine what people would rather want is a way to detect floating point
operations resulting in a NaN or infinity, i.e.

 - -fsanitize=float-nan-result
 - -fsanitize=float-nonfinite-result

Doing that via instrumentation would have some overhead though. Today people
can partially achieve that with zero overhead by enabling FPU exceptions, but
it's not so trivial when some exceptions are produced in third-party code (but
you don't want to trap on them).

Is there information on why Clang implemented those two options, was there
significant demand for those kinds specifically?

[Bug debug/87440] GCC creates debug that confuses gdb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 27 14:17:52 2018
New Revision: 264668

URL: https://gcc.gnu.org/viewcvs?rev=264668&root=gcc&view=rev
Log:
2018-09-27  Richard Biener  

PR testsuite/87451
* gcc.dg/debug/dwarf2/inline5.c: Deal with different comment
characters.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 27 14:10:45 2018
New Revision: 264667

URL: https://gcc.gnu.org/viewcvs?rev=264667&root=gcc&view=rev
Log:
2018-09-27  Richard Biener  

PR debug/37801
PR debug/87440
* dwarf2out.c (set_block_origin_self): Do not mark outermost
block as we do not output that.
(gen_inlined_subroutine_die): Elide the originally outermost
block, matching what we do for concrete instances.
(decls_for_scope): Add parameter specifying whether to recurse
to subblocks.

* gcc.dg/debug/dwarf2/inline2.c: Adjust.
* gcc.dg/debug/dwarf2/inline4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c

[Bug debug/87440] GCC creates debug that confuses gdb

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 27 14:10:45 2018
New Revision: 264667

URL: https://gcc.gnu.org/viewcvs?rev=264667&root=gcc&view=rev
Log:
2018-09-27  Richard Biener  

PR debug/37801
PR debug/87440
* dwarf2out.c (set_block_origin_self): Do not mark outermost
block as we do not output that.
(gen_inlined_subroutine_die): Elide the originally outermost
block, matching what we do for concrete instances.
(decls_for_scope): Add parameter specifying whether to recurse
to subblocks.

* gcc.dg/debug/dwarf2/inline2.c: Adjust.
* gcc.dg/debug/dwarf2/inline4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|aarch64, arm|aarch64,
   ||arm,sparc-sun-solaris2.*,i3
   ||86-pc-solaris2.*
 CC||ro at gcc dot gnu.org
Summary|FAIL:   |FAIL:
   |gcc.dg/debug/dwarf2/inline5 |gcc.dg/debug/dwarf2/inline5
   |.c on aarch64 and arm   |.c

--- Comment #3 from Rainer Orth  ---
The test also FAILs on Solaris/SPARC and x86 with /bin/as, which have different
comment signs:

  x86:

.byte   0x6 / uleb128 0x6; (DIE (0x160) DW_TAG_lexical_block)
.byte   0xc / uleb128 0xc; (DIE (0x19f) DW_TAG_lexical_block)
.byte   0x6 / uleb128 0x6; (DIE (0x1c3) DW_TAG_lexical_block)
.byte   0xb / uleb128 0xb; (TAG: DW_TAG_lexical_block)
.byte   0xb / uleb128 0xb; (TAG: DW_TAG_lexical_block)

  sparc:

.byte   0x6 ! uleb128 0x6; (DIE (0x14c) DW_TAG_lexical_block)
.byte   0xc ! uleb128 0xc; (DIE (0x18b) DW_TAG_lexical_block)
.byte   0x6 ! uleb128 0x6; (DIE (0x1b0) DW_TAG_lexical_block)
.byte   0xb ! uleb128 0xb; (TAG: DW_TAG_lexical_block)
.byte   0xb ! uleb128 0xb; (TAG: DW_TAG_lexical_block)

[Bug c++/87452] decltype ignores namespace in trailing return type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Reduced a bit more:

struct vector { };

namespace N {

void operator+(const vector&) { }

template
auto
f(const T& t)
-> decltype(operator+(t)) // OK
{
  return (+t);
}

template
auto
g(const T& t)
-> decltype(+t) // fails to find operator defined in N::
{
  return (+t);
}

} // namespace N

int main()
{
  vector vec;
  N::f(vec);
  N::g(vec);
}

It works if struct vector and the operator+ overload are in the same namespace,
suggesting the operator can found via ADL, but normal lookup seems to not
consider namespace N.

[Bug c++/87452] decltype ignores namespace in trailing return type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Ever confirmed|0   |1

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

extern "C" int puts(const char*);

struct vector { };

namespace N {

/**
 * Write range of random access iterators to output stream.
 */
void
operator+(const vector&)
{
  puts("pass");
}

template
auto
f(const T& t)
-> decltype(operator+(t)) // OK
{
  return (+t);
}

template
auto
g(const T& t)
-> decltype(+t) // fails to find operator defined in N::
{
  return (+t);
}

} // namespace N

int main()
{
  vector vec;
  N::f(vec);
  N::g(vec);
}


87452.cc: In function 'int main()':
87452.cc:38:11: error: no matching function for call to 'g(vector&)'
38 |   N::g(vec);
   |   ^
87452.cc:26:1: note: candidate: 'template decltype (+ t) N::g(const
T&)'
26 | g(const T& t)
   | ^
87452.cc:26:1: note:   template argument deduction/substitution failed:
87452.cc: In substitution of 'template decltype (+ t) N::g(const T&)
[with T = vector]':
87452.cc:38:11:   required from here
87452.cc:27:13: error: no match for 'operator+' (operand type is 'const
vector')
27 | -> decltype(+t) // fails to find operator defined in N::
   | ^~


As the call to N::f(t) shows, the decltype in the trailing-return-type works OK
if using function call syntax (to call either a named function or the
operator-function-id). It only fails to find the overloaded operator in the
enclosing namespace for operator syntax, i.e. decltype(+t).

[Bug sanitizer/87454] New: Maybe implement -fsanitize=implicit-integer-truncation

[marxin at gcc dot gnu.org]

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

Bug ID: 87454
   Summary: Maybe implement -fsanitize=implicit-integer-truncation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, mpolacek at gcc dot gnu.org
  Target Milestone: ---

It's new in LLVM 7.0.0:

  -  ``-fsanitize=implicit-integer-truncation``: Implicit conversion from
 integer of larger bit width to smaller bit width, if that results in data
 loss. That is, if the demoted value, after casting back to the original
 width, is not equal to the original value before the downcast.
 Issues caught by this sanitizer are not undefined behavior,
 but are often unintentional.

Example:

unsigned char store = 0;

bool consume(unsigned int val);

void test(unsigned long val) {
  if (consume(val)) // the value may have been silently truncated.
store = store + 768; // before addition, 'store' was promoted to int.
  (void)consume((unsigned int)val); // OK, the truncation is explicit.
}

[Bug sanitizer/87453] Maybe implement -fsanitize=float-cast-overflow and -fsanitize=float-divide-by-zero

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Martin Liška  ---
Explanation of the options.

  -  ``-fsanitize=float-cast-overflow``: Conversion to, from, or
 between floating-point types which would overflow the
 destination.
  -  ``-fsanitize=float-divide-by-zero``: Floating point division by
 zero.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Jakub, can we close this?

[Bug sanitizer/87453] New: Maybe implement -fsanitize=float-cast-overflow and -fsanitize=float-divide-by-zero

[marxin at gcc dot gnu.org]

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

Bug ID: 87453
   Summary: Maybe implement -fsanitize=float-cast-overflow and
-fsanitize=float-divide-by-zero
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, mpolacek at gcc dot gnu.org
  Target Milestone: ---

That are UBSAN features that LLVM can instrument.
What do you think about it?

[Bug c++/87452] New: decltype ignores namespace in trailing return type

[schuchart at hlrs dot de]

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

Bug ID: 87452
   Summary: decltype ignores namespace in trailing return type
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schuchart at hlrs dot de
  Target Milestone: ---

Created attachment 44758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44758&action=edit
Test case

It appears that GCC does not include the namespace in the evaluations of
expressions passed to decltype() in trailing return type definitions. 

The attached test-case compiled with GCC 8.2.0 produces the following output:


$ g++-8 gcc_decltype_ret.cc
$ ./a.out 
10
fall-back
$ g++-8 --version
g++-8 (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0
]]

Compiling with Clang 6.0.1 on the other hand gives the following output:

$ clang++-6.0 gcc_decltype_ret.cc
$ ./a.out 
10
0 0 0 0 0 0 0 0 0 0 

In other parts of the code, the same decltype() statement that is used in the
trailing return type definition yields the expected type (line 26).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #70 from Jonathan Wakely  ---
Drat, that is one of the symlinked files.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

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

--- Comment #69 from Chris Johns  ---
(In reply to Jonathan Wakely from comment #68)
> (In reply to Chris Johns from comment #67)
> > (In reply to Jonathan Wakely from comment #66)
> > > Yes, I was afraid the RTEMS failures might be a different problem.
> > > 
> > > Are the symptoms the same? i.e. missing C++ standard library headers?
> > > 
> > 
> > Yes it seems to be the same issue I was seeing when we first looked into the
> > problem.
> 
> So not failing on "bits/gthr.h" then? I'm still not clear exactly what part
> fails for you now.
> 
> > > Comment 17 suggests you're seeing missing libgcc headers, which is created
> > > by a different makefile. Maybe a similar kluge is needed in 
> > > libgcc/Makefile
> > > for build=*darwin*
> > 
> > Is it? I think that file is being installed in the same way. Could it be the
> > RTEMS target config has a different list?
> 
> Ah yes, my mistake, libstdc++ creates
> $target/include/x86_64-pc-linux-gnu/bits/gthr.h
> 
> I thought we found that in $target/libgcc/ instead, but in fact we process
> the libgcc/gthr.h header using sed and create our own version.
> 
> That means it's definitely *not* the same way as the other headers, because
> the others are symlinks into the source tree.
> 
> Please clarify exactly what your current failure is.

This is the current failure, it varies on the file that it fails on:

In file included from
/Users/chris/development/rtems/rsb/rtems-source-builder.git/rtems/build/sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-apple-darwin18.0.0-1/gcc-7.3.0/libstdc++-v3/libsupc++/exception:143:0,
 from ../../../../gcc-7.3.0/libstdc++-v3/libsupc++/new:40,
 from
../../../../gcc-7.3.0/libstdc++-v3/libsupc++/bad_alloc.cc:26:
/Users/chris/development/rtems/rsb/rtems-source-builder.git/rtems/build/sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-apple-darwin18.0.0-1/build/sparc-rtems5/libstdc++-v3/include/bits/nested_exception.h:40:10:
fatal error: bits/move.h: No such file or directory
 #include 
  ^

[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1

[ams at gcc dot gnu.org]

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

Andrew Stubbs  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Stubbs  ---
Patch committed. This is now fixed on the trunk.

[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1

[ams at gcc dot gnu.org]

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

--- Comment #7 from Andrew Stubbs  ---
Author: ams
Date: Thu Sep 27 11:15:48 2018
New Revision: 264666

URL: https://gcc.gnu.org/viewcvs?rev=264666&root=gcc&view=rev
Log:
[pr82089] Don't sign-extend SFV 1 in BImode

This is an update of the patch posted to PR82089 long ago.  We ran into the
same bug on GCN, so we need this fixed as part of this series.

2018-09-27  Andrew Stubbs  
Tom de Vries  

PR 82089

gcc/
* expmed.c (emit_cstore): Fix handling of result_mode == BImode and
STORE_FLAG_VALUE == 1.

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

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c on aarch64 and arm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-27
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Hmm, looks like the test depends on the fix for PR87440 to go in.  So let's
just wait until Jason approves that.  As you can see the testcase is named
inline5.c
and the mentioned adds inline4.c which means I expected to install them in the
other way around ...

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #68 from Jonathan Wakely  ---
(In reply to Chris Johns from comment #67)
> (In reply to Jonathan Wakely from comment #66)
> > Yes, I was afraid the RTEMS failures might be a different problem.
> > 
> > Are the symptoms the same? i.e. missing C++ standard library headers?
> > 
> 
> Yes it seems to be the same issue I was seeing when we first looked into the
> problem.

So not failing on "bits/gthr.h" then? I'm still not clear exactly what part
fails for you now.

> > Comment 17 suggests you're seeing missing libgcc headers, which is created
> > by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile
> > for build=*darwin*
> 
> Is it? I think that file is being installed in the same way. Could it be the
> RTEMS target config has a different list?

Ah yes, my mistake, libstdc++ creates
$target/include/x86_64-pc-linux-gnu/bits/gthr.h

I thought we found that in $target/libgcc/ instead, but in fact we process the
libgcc/gthr.h header using sed and create our own version.

That means it's definitely *not* the same way as the other headers, because the
others are symlinks into the source tree.

Please clarify exactly what your current failure is.

[Bug c++/67544] ICE: SIGSEGV in tree_check3 (tree.h:2896) with -fconcepts

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Fixed long time ago.

[Bug c++/67491] [meta-bug] concepts issues

[paolo.carlini at oracle dot com]

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

Bug 67544 Summary: ICE: SIGSEGV in tree_check3 (tree.h:2896) with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67544

   What|Removed |Added

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

[Bug c++/67544] ICE: SIGSEGV in tree_check3 (tree.h:2896) with -fconcepts

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Sep 27 09:53:08 2018
New Revision: 264665

URL: https://gcc.gnu.org/viewcvs?rev=264665&root=gcc&view=rev
Log:
2018-09-27  Paolo Carlini  

PR c++/67544
* g++.dg/concepts/pr67544.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr67544.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c on aarch64 and arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|[9 Regression] FAIL:|FAIL:
   |gcc.dg/debug/dwarf2/inline5 |gcc.dg/debug/dwarf2/inline5
   |.c on aarch64 and arm   |.c on aarch64 and arm
  Known to fail||9.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Not a regression I guess since it's a new test.

[Bug debug/87451] New: [9 Regression] FAIL: gcc.dg/debug/dwarf2/inline5.c on aarch64 and arm

[ktkachov at gcc dot gnu.org]

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

Bug ID: 87451
   Summary: [9 Regression] FAIL: gcc.dg/debug/dwarf2/inline5.c on
aarch64 and arm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64, arm

The new test fails on aarch64 and arm:
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
DW_TAG_lexical_block\\)[^#]*# DW_AT_abstract_origin 2
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
DW_TAG_lexical_block\\)[^#]*# \\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1

[Bug c++/86269] [concepts] ICE with intermediate concepts notation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/86000] ICE with requires statement in a non constexpr if

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/84810] [concepts][c++20] constraints of lambdas with explicit template parameters are not checked

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Blocks||67491
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/85229] .[concepts] ICE with local class in lambda

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 Ever confirmed|0   |1

[Bug c++/85241] Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Blocks||67491

--- Comment #3 from Paolo Carlini  ---
Closely related to PR68812


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/85908] Internal error with concepts and polymorphic lambdas

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
I can't reproduce the issue with the released 8.1.0

[Bug rtl-optimization/87446] [7/8/9 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2431

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

--- Comment #2 from Richard Biener  ---
OK, so the issue is that there's a missed CFG cleanup run somewhere (eventually
done by one of the passes you disable).  We have


  # j = PHI<1>
 if (j == 0)
   loop!
 else
   loop exit

and we happily if-convert single-argument PHIs (boo).  if-conversion then
will do the CFG cleanup and that scraps the fallback loop while the
if-converted loop now looks like

  j = 1;
  if (j == 0)


which CFG cleanup doesn't "handle".

-> Kaboom.

I'd say "doctor it hurts", but of course we should cleanup the CFG properly.
This time the offender is VRP which performs jump-threading and then
CFG cleanup but with SSA not updated.  This then runs into

gimple_can_merge_blocks_p (a=, 
b=) at /tmp/trunk/gcc/tree-cfg.c:1883
1939  for (gphi_iterator gsi = gsi_start_phis (b); !gsi_end_p (gsi);
1940   gsi_next (&gsi))
1941{
1942  gphi *phi = gsi.phi ();
1943  /* Technically only new names matter.  */
1944  if (name_registered_for_update_p (PHI_RESULT (phi)))
1945return false;
1946}

and so not merging two blocks which would propagate out the single-arg PHI.
I also believe the comment is wrong and we cannot propagate the PHI out.
But we could in theory simply create a copy (which of course wouldn't solve
the issue at hand).

So one solution might be to force a phi-only-cprop pass before
tree-if-conversion but then if you disable that manually you're screwed again
;)

Or try re-organizing TODO processing to "interleave" update-SSA and
cleanup-CFG.  We basically need cleanup_control_flow_pre () be performed
first, then update-SSA if required and then continue.

static void
execute_function_todo (function *fn, void *data)
{
  bool from_ipa_pass = (cfun == NULL);
  unsigned int flags = (size_t)data;
  flags &= ~fn->last_verified;
  if (!flags)
return;

  push_cfun (fn);

  /* Always cleanup the CFG before trying to update SSA.  */
  if (flags & TODO_cleanup_cfg)
{
  cleanup_tree_cfg ();

...

  if (flags & TODO_update_ssa_any)
{
  unsigned update_flags = flags & TODO_update_ssa_any;
  update_ssa (update_flags);


anyhow this seems low-priority and certainly I don't think CFG cleanup
(or loop fixup) should in any way be forced to kill LOOP_VECTORIZED IFN calls.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

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

--- Comment #67 from Chris Johns  ---
(In reply to Jonathan Wakely from comment #66)
> Yes, I was afraid the RTEMS failures might be a different problem.
> 
> Are the symptoms the same? i.e. missing C++ standard library headers?
> 

Yes it seems to be the same issue I was seeing when we first looked into the
problem.

> Comment 17 suggests you're seeing missing libgcc headers, which is created
> by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile
> for build=*darwin*

Is it? I think that file is being installed in the same way. Could it be the
RTEMS target config has a different list?

> What are your build, host and target triplets?

They are:

 --build=x86_64-apple-darwin18.0.0
 --target=sparc-rtems5
 --host=x86_64-apple-darwin18.0.0

The configure command line is ...

../gcc-7.3.0/configure --prefix=/Users/chris/development/rtems/5
--bindir=/Users/chris/development/rtems/5/bin
--exec_prefix=/Users/chris/development/rtems/5
--includedir=/Users/chris/development/rtems/5/include
--libdir=/Users/chris/development/rtems/5/lib
--libexecdir=/Users/chris/development/rt
ems/5/libexec --mandir=/Users/chris/development/rtems/5/share/man
--infodir=/Users/chris/development/rtems/5/share/info
--datadir=/Users/chris/development/rtems/5/share
--build=x86_64-apple-darwin18.0.0 --host=x86_64-apple-darwin18.0.0
--target=sparc-rtems5 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--verbose --with-newlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_88
59_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16
le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++

[Bug c++/84940] [7/8/9 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:465

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Sep 27 08:33:41 2018
New Revision: 264664

URL: https://gcc.gnu.org/viewcvs?rev=264664&root=gcc&view=rev
Log:
/cp
2018-09-27  Paolo Carlini  

PR c++/84940
* semantics.c (finish_unary_op_expr): Check return value of
build_x_unary_op for error_mark_node.

/testsuite
2018-09-27  Paolo Carlini  

PR c++/84940
* g++.dg/expr/unary4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/expr/unary4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87450] New: -Wunused-variable: false positive for associate

[m.diehl at mpie dot de]

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

Bug ID: 87450
   Summary: -Wunused-variable: false positive for associate
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Warning messages about unused variables (-Wunused-variable) appear wrongly when
associate is used (false positive):

pprogram test

  implicit none
  real :: a = 5
  real :: b

  associate(b => a)
write(6,*) b
  end associate

end program


gives

Warning: Unused variable ‘b’ declared at (1) [-Wunused-variable]

when complied with -Wunused-variable

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

[mscfd at gmx dot net]

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

--- Comment #2 from martin  ---
Originally I came across this problem in a large module with a slightly more
complex function with gfortran-7.3.0 (standard version from ubuntu 18.4). I got
the same bogus error, which Janus has seen for this reduced testcase with
gfortran-5.5. Taking out the function and related class I got the ICE, but was
not able to reproduce this error.

In short: I think that the bogus error is still present in recent gfortran
versions (or is just another symptom of this problem).

[Bug fortran/87449] New: -Wunused-variable and associate

[m.diehl at mpie dot de]

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

Bug ID: 87449
   Summary: -Wunused-variable and associate
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Warning messages about unused variables (-Wunused-variable) appear wrongly when
associate is used (false positive):

pprogram test

  implicit none
  real :: a = 5
  real :: b

  associate(b => a)
write(6,*) b
  end associate

end program


gives

Warning: Unused variable ‘b’ declared at (1) [-Wunused-variable]

when complied with -Wunused-variable

[Bug target/87444] 'gcc -marc=native' sets L2 cache size equal to L3 cache size on i7 and i5 CPU

[studio at anchev dot net]

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

--- Comment #6 from George  ---
Thanks!

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. The ICE is present since version 6. gfortran 5.5 rejects the example
with this bogus error:

associate(l => len(cs))
 1
Error: Symbol ‘l’ at (1) has no IMPLICIT type

[Bug target/87444] 'gcc -marc=native' sets L2 cache size equal to L3 cache size on i7 and i5 CPU

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to George from comment #4)
> Richard Biener,
> 
> Thanks for the reply. Unfortunately I don't understand what it means -
> whether I should set explicitly the correct l2-cache-size or if that has any
> effect on the final binary.
> 
> But I realise this may not be the place for questions. In which particular
> mailing list may I get reply to my question please?

For prefetching (the only thing that uses the L2 numbers) the L3 size (last
level cache) is more appropriate here.  As said that could be probably better
reflected in the code.

IIRC there's even CPUs with L4 cache.  And with CPUs with SMT even L1 isn't
exclusive to a thread.  Modeling the memory subsystem with main memory, L2 and
L1 isn't really state of the art any more.

You can ask on gcc-h...@gcc.gnu.org

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #66 from Jonathan Wakely  ---
Yes, I was afraid the RTEMS failures might be a different problem.

Are the symptoms the same? i.e. missing C++ standard library headers?

Comment 17 suggests you're seeing missing libgcc headers, which is created by a
different makefile. Maybe a similar kluge is needed in libgcc/Makefile for
build=*darwin*

What are your build, host and target triplets?

[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Maybe the other way around:
-fprofile-filter-files
-fprofile-exclude-files

[Bug rtl-optimization/87446] [7/8/9 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2431

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-27
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r242550, but maybe it just exposed a latent bug?