[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
r265259 FAIL

/home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=release --enable-languages=c,c++,lto --disable-multilib
--with-isl

[Bug fortran/87632] [9 regression] ICE segmentation fault in f951

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

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

--- Comment #5 from Jürgen Reuter  ---
Apparently, Tobias was faster in reducing the reproducer than myself. With the
fix by Tobias (I checked r265248) all of our code including testsuites with
different sets of flags works again. Thanks for the quick fix! Incredible job!

[Bug fortran/87127] External function not recognised from within an associate block

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Hi Tobias,

I have been looking at this one on and off. I think that blocks should
be resolved in the same way as contained procedures; I tried adding
them to the parent contained list (the night before last) and ended up
with segfaults on cleanup. This is easily fixed but I just did not
have time.

Cheers

Paul

On Wed, 17 Oct 2018 at 23:43, burnus at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
>
> Tobias Burnus  changed:
>
>What|Removed |Added
> 
>  CC||burnus at gcc dot gnu.org
>
> --- Comment #3 from Tobias Burnus  ---
> Variant:
>
> program test
>   implicit none
>   integer :: exfunc, i
>   call foo()
> contains
>   subroutine foo()
> write(*,*) exfunc(i)
>   end subroutine foo
> end program
>
>
> In primary.c's gfc_match_rvalue(), we try to parse a symbol in several ways –
> if everything fails:
>
>   /* Give up, assume we have a function.  */
>   gfc_get_sym_tree (name, NULL, &symtree, false);   /* Can't fail */
>   sym = symtree->n.sym;
>   e->expr_type = EXPR_FUNCTION;
>   if (!sym->attr.function
>   && !gfc_add_function (&sym->attr, sym->name, NULL))
>
> This sets both attr.flavor = FL_PROCEDURE and attr.function = 1.
>
> If we call "exfunc" in "program test", everything is fine.
>
> However, if we call "exfunc" in a block (associate) or a contained procedure,
> we are in a different namespace.
>
> In the local namespace, the symbol is FL_PROCEDURE with attr.function.
> In the parent namespace, the symbol has will be to FL_VARIABLE.
>
> In resolve_symbol, one tries to resolve the symbol:
>   if (sym->attr.flavor == FL_UNKNOWN
>   || (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic
>   && !sym->attr.generic && !sym->attr.external
>   && sym->attr.if_source == IFSRC_UNKNOWN
>   && sym->ts.type == BT_UNKNOWN))
> {
>
> Thus, one ends up with a symbol without attr.function.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/87641] New: std::valarray::sum() fails for types where T() is not a neutral element for addition

[frederic.jardon at gmail dot com]

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

Bug ID: 87641
   Summary: std::valarray::sum() fails for types where T() is
not a neutral element for addition
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.jardon at gmail dot com
  Target Milestone: ---

** Compiler version and command-line used are at the end of this message **


The following code:

#include 
#include 

using namespace std;

int main()
{
valarray Y(0xf00d, 1);
valarray> X(Y, 1);
cout << "X[0].size()= " << X[0].size()<< '\n';
cout << "X.sum().size() = " << X.sum().size() << '\n';
}

Should print (expected):

X[0].size()= 1
X.sum().size() = 1

But it prints (actual):

X[0].size()= 1
X.sum().size() = 0

I tracked the issue to this function:

   //
   // Compute the sum of elements in range [__f, __l)
   // This is a naive algorithm.  It suffers from cancelling.
   // In the future try to specialize
   // for _Tp = float, double, long double using a more accurate
   // algorithm.
   //
   template
 inline _Tp
 __valarray_sum(const _Tp* __f, const _Tp* __l)
 {
   _Tp __r = _Tp();
   while (__f != __l)
 __r += *__f++;
   return __r;
 }

The implementation assumes that:

_Tp __r = _Tp();
__r += *__f;

has the same value than *__f, but this is not the case if _Tp() is not a
neutral element for addition. For instance a default constructed
std::valarray has a size of 0, and the end result will have a size of 0 even
though the *__f may be a valarray of size 1.

The same problem could occur if _Tp was a custom floating-point-like type whose
default constructed value was NaN.

Reference to the standard: 26.6.2.8

> This function may only be instantiated for a type T to which operator+= can be
> applied. This function returns the sum of all the elements of the array. If
> the array has length 0, the behavior is undefined. If the array has length 1,
> sum() returns the value of element 0. Otherwise, the returned value is
> calculated by applying operator+= to a copy of an element of the array and all
> other elements of the array in an unspecified order.

The standard clearly state that the initial value of __r should be a **copy of
an element of the array**

If you provide me a link on how to submit a pull-request I can work on
providing a patch.

I have reports that other compilers (clang, cl) doesn't exhibit this behavior.

Thanks for your attention and the good compiler :)

Frederic Jardon

=== compiler / compilation information

$ uname -a
CYGWIN_NT-10.0 DD1K7KF2 2.11.1(0.329/5/3) 2018-09-05 10:24 x86_64 Cygwin

$ LANG="" gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.3.0 (GCC) 

$ g++ valarray-sum.cpp -save-temps -o valarray-sum

$ ./valarray-sum.exe 
X[0].size()= 1
X.sum().size() = 0


I also reproduced the same bug on another system:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.9/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u1'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstd

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[frederic.jardon at gmail dot com]

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

--- Comment #1 from Frederic Jardon  ---
Created attachment 44852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44852&action=edit
Full preprocessed sources (-save-temps) compressed with gzip

[Bug c++/87629] function template parameter deduction succeeds but parameter and deduced arg does not match.

[okannen at gmail dot com]

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

--- Comment #1 from Olivier Kannengieser  ---
This is maybe not a compiler bug, to be confirmed/unconfirmed by an expert of
the standard.

[Bug target/87537] Redundant vmovaps

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Oct 18 08:18:42 2018
New Revision: 265260

URL: https://gcc.gnu.org/viewcvs?rev=265260&root=gcc&view=rev
Log:
Simplify subreg of vec_merge of vec_duplicate

We can simplify

  (subreg (vec_merge (vec_duplicate X)
 (vector)
 (const_int ((1 << N) | M)))
  (N * sizeof (X)))

to X when mode of X is the same as of mode of subreg.

gcc/

PR target/87537
* simplify-rtx.c (simplify_subreg): Simplify subreg of vec_merge
of vec_duplicate.
(test_vector_ops_duplicate): Add test for a scalar subreg of a
VEC_MERGE of a VEC_DUPLICATE.

gcc/testsuite/

PR target/87537
* gcc.target/i386/pr87537-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr87537-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-18
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Confirmed, I have a patch to fix it.

[Bug tree-optimization/87087] [8 Regression] Optimization hangs up and consumes over 15Gb of memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85935] [8 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:287

[rguenth at gcc dot gnu.org]

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

Bug 87087 Summary: [8 Regression] Optimization hangs up and consumes over 15Gb 
of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87087

   What|Removed |Added

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

[Bug tree-optimization/84204] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[rguenth at gcc dot gnu.org]

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

Bug 87087 Summary: [8 Regression] Optimization hangs up and consumes over 15Gb 
of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87087

   What|Removed |Added

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

[Bug tree-optimization/84204] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||xfail
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
   Target Milestone|8.0 |9.0
  Known to fail||8.2.1

--- Comment #7 from Richard Biener  ---
Re-opening.

[Bug c++/86969] [8/9 Regression] ICE (in tsubst_copy) for a generic recursive lambda

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Closely related to PR86740.

[Bug tree-optimization/87087] [8 Regression] Optimization hangs up and consumes over 15Gb of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 18 08:40:54 2018
New Revision: 265261

URL: https://gcc.gnu.org/viewcvs?rev=265261&root=gcc&view=rev
Log:
2018-10-18  Richard Biener  

PR middle-end/87087
Revert
2018-02-07  Richard Biener  

PR tree-optimization/84204
* tree-chrec.c (chrec_fold_plus_1): Remove size limiting in
this place.

* gcc.dg/torture/pr87087.c: New testcase.
* gcc.dg/graphite/pr84204.c: XFAIL.
* gcc.dg/graphite/pr85935.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87087.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/graphite/pr84204.c
trunk/gcc/testsuite/gcc.dg/graphite/pr85935.c
trunk/gcc/tree-chrec.c

[Bug tree-optimization/84204] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 18 08:40:54 2018
New Revision: 265261

URL: https://gcc.gnu.org/viewcvs?rev=265261&root=gcc&view=rev
Log:
2018-10-18  Richard Biener  

PR middle-end/87087
Revert
2018-02-07  Richard Biener  

PR tree-optimization/84204
* tree-chrec.c (chrec_fold_plus_1): Remove size limiting in
this place.

* gcc.dg/torture/pr87087.c: New testcase.
* gcc.dg/graphite/pr84204.c: XFAIL.
* gcc.dg/graphite/pr85935.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87087.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/graphite/pr84204.c
trunk/gcc/testsuite/gcc.dg/graphite/pr85935.c
trunk/gcc/tree-chrec.c

[Bug c++/77655] [6/7 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Just an error-recovery issue, let's close it.

[Bug tree-optimization/84204] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 18 08:51:32 2018
New Revision: 265262

URL: https://gcc.gnu.org/viewcvs?rev=265262&root=gcc&view=rev
Log:
2018-10-18  Richard Biener  

PR middle-end/87087
Revert
2018-02-07  Richard Biener  

PR tree-optimization/84204
* tree-chrec.c (chrec_fold_plus_1): Remove size limiting in
this place.

* gcc.dg/torture/pr87087.c: New testcase.
* gcc.dg/graphite/pr84204.c: XFAIL.
* gcc.dg/graphite/pr85935.c: Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr87087.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr84204.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr85935.c
branches/gcc-8-branch/gcc/tree-chrec.c

[Bug tree-optimization/87087] [8 Regression] Optimization hangs up and consumes over 15Gb of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 18 08:51:32 2018
New Revision: 265262

URL: https://gcc.gnu.org/viewcvs?rev=265262&root=gcc&view=rev
Log:
2018-10-18  Richard Biener  

PR middle-end/87087
Revert
2018-02-07  Richard Biener  

PR tree-optimization/84204
* tree-chrec.c (chrec_fold_plus_1): Remove size limiting in
this place.

* gcc.dg/torture/pr87087.c: New testcase.
* gcc.dg/graphite/pr84204.c: XFAIL.
* gcc.dg/graphite/pr85935.c: Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr87087.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr84204.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/graphite/pr85935.c
branches/gcc-8-branch/gcc/tree-chrec.c

[Bug c++/87637] Unwinding does not destroy constructed subobject of brace-initialized temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
I've updated the summary of PR 57510 and added your testcase, let's close this
one. I'll ping Jason about it too.

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

[Bug c++/57510] subobjects not destroyed when exception thrown during list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|initializer_list memory |subobjects not destroyed
   |leak|when exception thrown
   ||during list-initialization

--- Comment #10 from Jonathan Wakely  ---
Another example provided by Hubert in PR 87637:

In the following program, the initialization of the A subobject of the B
temporary associated with the brace-initializing cast expression is complete
when an exception is thrown during the further initialization of the B
temporary.

When compiled with GCC, stack unwinding for the exception fails to invoke the
destructor of the A subobject.

### SOURCE ():
extern "C" int printf(const char *, ...);

struct A {
  A() { printf("%s\n", __PRETTY_FUNCTION__); }
  A(const A &) = delete;
  ~A() { printf("%s\n", __PRETTY_FUNCTION__); }
};

struct B { A a; int q; };

int foo() { throw 0; }

int main(void) {
  try {
(void) B{{}, foo()};
  }
  catch (...) { }
}


### COMPILER INVOCATION:
g++ -x c++ -std=c++11 -o prog -


### RUN INVOCATION:
./prog


### ACTUAL RUN OUTPUT:
A::A()


### EXPECTED RUN OUTPUT:
A::A()
A::~A()


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20181016 (experimental) (GCC)

--- Comment #11 from Jonathan Wakely  ---
*** Bug 87637 has been marked as a duplicate of this bug. ***

[Bug c++/57510] subobjects not destroyed when exception thrown during list-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|initializer_list memory |subobjects not destroyed
   |leak|when exception thrown
   ||during list-initialization
 CC||hstong at ca dot ibm.com

--- Comment #10 from Jonathan Wakely  ---
Another example provided by Hubert in PR 87637:

In the following program, the initialization of the A subobject of the B
temporary associated with the brace-initializing cast expression is complete
when an exception is thrown during the further initialization of the B
temporary.

When compiled with GCC, stack unwinding for the exception fails to invoke the
destructor of the A subobject.

### SOURCE ():
extern "C" int printf(const char *, ...);

struct A {
  A() { printf("%s\n", __PRETTY_FUNCTION__); }
  A(const A &) = delete;
  ~A() { printf("%s\n", __PRETTY_FUNCTION__); }
};

struct B { A a; int q; };

int foo() { throw 0; }

int main(void) {
  try {
(void) B{{}, foo()};
  }
  catch (...) { }
}


### COMPILER INVOCATION:
g++ -x c++ -std=c++11 -o prog -


### RUN INVOCATION:
./prog


### ACTUAL RUN OUTPUT:
A::A()


### EXPECTED RUN OUTPUT:
A::A()
A::~A()


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20181016 (experimental) (GCC)

--- Comment #11 from Jonathan Wakely  ---
*** Bug 87637 has been marked as a duplicate of this bug. ***

[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it

[xavierb at gmail dot com]

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

--- Comment #15 from Xavier B  ---
hi,

Just a ping for this issue.

Since it's about declarations and it is not possible to disable it,
as soon as you have headers files using the feature you get flooded with
thousands of warnings making it impossible to see the other actually useful
warnings...

[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155

[su at cs dot ucdavis.edu]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #3 from Zhendong Su  ---
Here is a small reproducer: 

$ gcctk -Os small.c
during GIMPLE pass: evrp
small.c: In function ‘main’:
small.c:9:1: internal compiler error: in check, at tree-vrp.c:155
9 | }
  | ^
0xf400ef value_range::check()
../../gcc-source-trunk/gcc/tree-vrp.c:155
0xf45800 value_range::value_range(value_range_kind, tree_node*, tree_node*,
bitmap_head*)
../../gcc-source-trunk/gcc/tree-vrp.c:110
0xf45800 set_value_range_with_overflow
../../gcc-source-trunk/gcc/tree-vrp.c:1422
0xf45800 extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*,
value_range const*, value_range const*)
../../gcc-source-trunk/gcc/tree-vrp.c:1680
0xfcafcd vr_values::extract_range_from_binary_expr(value_range*, tree_code,
tree_node*, tree_node*, tree_node*)
../../gcc-source-trunk/gcc/vr-values.c:734
0xfcd794 vr_values::extract_range_from_assignment(value_range*, gassign*)
../../gcc-source-trunk/gcc/vr-values.c:1392
0x14a5679 evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool)
../../gcc-source-trunk/gcc/gimple-ssa-evrp-analyze.c:285
0x14a33b8 evrp_dom_walker::before_dom_children(basic_block_def*)
../../gcc-source-trunk/gcc/gimple-ssa-evrp.c:139
0x147f92a dom_walker::walk(basic_block_def*)
../../gcc-source-trunk/gcc/domwalk.c:353
0x14a3e31 execute_early_vrp
../../gcc-source-trunk/gcc/gimple-ssa-evrp.c:311
0x14a3e31 execute
../../gcc-source-trunk/gcc/gimple-ssa-evrp.c:348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$
$ cat small.c
int main ()
{ 
  unsigned b = 0;
  int c, d = -8;
  for (; b < 2; b++)
for (c = 1; c; c--)
  d++;
  return 0;
}
$

[Bug c++/87634] CSE for dynamic_cast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
If that is possible then we cannot optimize the dynamic_cast<>.  Certainly
GCC thinks that bar() clobbers what *a points to but it could possibly
thread the case when the dynamic cast fails (but that's too complex for
the threader to figure out as profitable).

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||aldyh at gcc dot gnu.org
  Component|c++ |tree-optimization
Version|8.0 |9.0
   Target Milestone|--- |9.0
Summary|ice in compare_range_wit|[9 Regression] ice in
   |h_value, at |compare_range_wit h_value,
   |vr-values.c:1702|at vr-values.c:1702

[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug rtl-optimization/87639] GCC fails to consider end of automatic object lifetime when determining sibcall eligibility

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  It's going to be "interesting" to support this.  Maybe
shrink-wrapping could help.

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Thu Oct 18 10:33:25 2018
New Revision: 265263

URL: https://gcc.gnu.org/viewcvs?rev=265263&root=gcc&view=rev
Log:
2018-10-18  Paul Thomas  

PR fortran/58618
* trans-decl.c (gfc_get_symbol_decl): Deal correctly with the
initialization with NULL() of a deferred length pointer.

2018-10-18  Paul Thomas  

PR fortran/58618
* gfortran.dg/deferred_character_30.f90 : New test.


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

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Thu Oct 18 10:37:39 2018
New Revision: 265264

URL: https://gcc.gnu.org/viewcvs?rev=265264&root=gcc&view=rev
Log:
2018-10-18  Paul Thomas  

PR fortran/58618
* trans-stmt.c (trans_associate_var): All strings that return
as pointer types can be assigned directly to the associate
name so remove 'attr' and the condition that uses it.

2018-10-18  Paul Thomas  

PR fortran/58618
* gfortran.dg/associate_45.f90 : New test.


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

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
(In reply to Paul Thomas from comment #11)
> Author: pault
> Date: Thu Oct 18 10:33:25 2018
> New Revision: 265263
> 
> URL: https://gcc.gnu.org/viewcvs?rev=265263&root=gcc&view=rev
> Log:
> 2018-10-18  Paul Thomas  
> 
>   PR fortran/58618
>   * trans-decl.c (gfc_get_symbol_decl): Deal correctly with the
>   initialization with NULL() of a deferred length pointer.
> 
> 2018-10-18  Paul Thomas  
> 
>   PR fortran/58618
>   * gfortran.dg/deferred_character_30.f90 : New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/deferred_character_30.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/trans-decl.c
> trunk/gcc/testsuite/ChangeLog

This bug was found during the fix of this PR but is a regression caused by the
fix for PR70149.

Paul

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely  ---
Comment on attachment 44851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44851
patch as per directions

That looks like sufficient variety of types tested.

I would prefer a function template instead of the LF macro e.g.

template
void check()
{
  std::atomic a;
  VERIFY( a.is_lock_free() || !a.is_always_lock_free );
}

and then:

  check< Foo * >();
  check< Bar * >();

etc.

But I'm losing confidence in this change being correct, after asking some
questions of the C++ committee. The intent seems to be that is_lock_free() can
indeed give a runtime answer, based on properties which might not have been
known at compile-time. For example, code compiled with -march=i386 will say
is_always_lock_free is false (correctly) but if at runtime it links to
libatomic compiled for i686 and it runs on i686 then is_lock_free could return
true. So the link failure in comment 30 is right, and I was wrong to say:

> The result should be the same as ax.is_always_lock_free which is a constant.

This is the point Andrew made all the way back in Comment 2. At compile-time we
might not be able to guarantee lock-freedom, but at run-time libatomic might be
able to **and that will be true for all suitably-aligned objects of that
type**.

So the premise that "is_lock_free() is per-type implies it's the same as
always_lock_free" is wrong.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely  ---
std::atomic already meets the "same for all objects of the type" guarantee
by fixing the alignment of its member and by using a fake pointer that has the
same value for all objects of the type.

[Bug c++/83083] c++2a concepts without -fconcepts

[h2+bugs at fsfe dot org]

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

--- Comment #1 from Hannes Hauswedell  ---
*polite ping*

Any chance this will change for gcc9? I know some changes are pending for the
San Diego WG21 meeting, but these are only additions to what is already merged
in the DS. It would be great to have concepts as per the DS in GCC9. Thank you!

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[dmjpp at hotmail dot com]

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

--- Comment #6 from Dimitrij Mijoski  ---
I read the patch couple of times and seems completely OK. Can you push it to
the repository (or to a fork)?

[Bug c++/87629] function template parameter deduction succeeds but parameter and deduced arg does not match.

[okannen at gmail dot com]

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

--- Comment #2 from Olivier Kannengieser  ---
This is not a bug, this bug report should be removed!

The function call is undeduced context so the rule [temp.call.deduct]/4 is
bypassed.

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

[cdenizet at mozilla dot com]

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

--- Comment #6 from calixte  ---
from IRC:
 calixte: I think -fprofile-filter-files
 -fprofile-exclude-files
 as Martin proposes looks OK to me.

[Bug rtl-optimization/87639] GCC fails to consider end of automatic object lifetime when determining sibcall eligibility

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
While I'd love to see it fixed via shrink-wrappping, which would fix lots of
other excessive stack usage issues too, like:

if (last_recursion_level) {
char buf[1000];
/* code that needs buf */
} else {
/* code that doesn't need buf */
}

I don't think this is necessary for a fix. It should be possible to update
whatever predicate checks for sibcall eligibility based on having leaked
address of objects on the stack to exclude those whose block lifetime has
ended, without actually going to the trouble of making gcc explicitly free
their stack allocations.

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #7 from Jonathan Wakely  ---
It has some problems which I've fixed in branch pr85494 at 
https://github.com/jwakely/gcc/tree/pr85494

I'll commit it to the GCC repo at some point.

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
My precious.

[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Aldy Hernandez  ---
All mine baby.

[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Sam, did you get a chance to implement the changes requested on the mailing
list?

[Bug c++/87629] function template parameter deduction succeeds but parameter and deduced arg does not match.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Agreed, the call to x_func(Tfoo) deducing Args as an empty pack, and then
deduces T as int for the argument to the x<>::x(void(*)(int)) constructor.

[Bug rtl-optimization/87639] GCC fails to consider end of automatic object lifetime when determining sibcall eligibility

[bugdal at aerifal dot cx]

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

--- Comment #3 from Rich Felker  ---
Note: presumably that information is already available somewhere for
-fstack-reuse.

[Bug libstdc++/87642] New: Cannot handle fr_FR.UTF8 thousands separator

[rguenth at gcc dot gnu.org]

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

Bug ID: 87642
   Summary: Cannot handle fr_FR.UTF8 thousands separator
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

using namespace std;

int
main()
{
  locale::global(locale(""));
  cout.imbue(locale());
  cout << 1000 << endl;
}

> LANG=fr_FR.UTF8 ./a.out 
1�000
> LANG=fr_FR.UTF8 ./a.out | hexdump -c
000   1 342   0   0   0  \n
006

[Bug libstdc++/87642] Cannot handle fr_FR.UTF8 thousands separator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
 Ever confirmed|0   |1

[Bug c++/87634] CSE for dynamic_cast

[Simon.Richter at hogyros dot de]

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

--- Comment #2 from Simon Richter  ---
Well, I tried really hard to make a case that makes the second dynamic_cast
return null after the first returned non-null.

The most promising candidate uses a direct destructor call and placement new on
a global pointer that happens to be a copy of the pointer passed into the
method.

struct C : A { virtual void foo() {} };

unsigned char *storage = new unsigned char[std::max(sizeof(B), sizeof(C))];
B *global_b = new(storage) B;

later, call

test(global_b);

and implement B::foo() as

global_b->~B();
new(storage) C;

If that is legal C++, then rechecking the dynamic type of the object might make
sense, but I'm not entirely sure about whether aliasing rules would break that
example.

[Bug c++/87643] New: [9 regression] ICE at dbxout.c:508:1: linemap_position_for_line_and_column starting with r264887

[seurer at gcc dot gnu.org]

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

Bug ID: 87643
   Summary: [9 regression] ICE at dbxout.c:508:1:
linemap_position_for_line_and_column starting with
r264887
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This error occurs in compiling the 502.gcc_r and 602.gcc_r parts of SPEC2017. 
I've only tried it on powerpc64le.

seurer@genoa:~/gcc/cpu2017/benchspec/CPU/502.gcc_r/build/build_base_test_64.0001$
/home/seurer/gcc/install/gcc-test/bin/gcc -c -o dbxout.o -DSPEC -DNDEBUG -I.
-I./include -I./spec_qsort -DSPEC_502 -DSPEC_AUTO_SUPPRESS_OPENMP -DIN_GCC
-DHAVE_CONFIG_H  -m64 -O3 -mcpu=power8 -fpeel-loops -funroll-loops -ffast-math
-mpopcntd -mrecip-DSPEC_LP64 -Wno-deprecated-declarations  
-fgnu89-inline  dbxout.c
during GIMPLE pass: printf-return-value
dbxout.c: In function 'dbxout_stab_value_internal_label':
dbxout.c:508:1: internal compiler error: in
linemap_position_for_line_and_column, at libcpp/line-map.c:848
508 | dbxout_stab_value_internal_label (const char *stem, int *counterp)
| ^~~~
0x116070af linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
/home/seurer/gcc/gcc-test/libcpp/line-map.c:848
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Breakpoint 1, linemap_position_for_line_and_column (set=0x3fffb7f7,
ord_map=0x3fffb5c5eb68, line=124, column=23) at
/home/seurer/gcc/gcc-test/libcpp/line-map.c:848
848   linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line);
(gdb) where
#0  linemap_position_for_line_and_column (set=0x3fffb7f7,
ord_map=0x3fffb5c5eb68, line=124, column=23) at
/home/seurer/gcc/gcc-test/libcpp/line-map.c:848
#1  0x115ddafc in get_substring_ranges_for_loc (pfile=0x12003e20,
concats=0x3fffb5cc, strloc=, type=CPP_STRING, ranges=...)
at /home/seurer/gcc/gcc-test/gcc/input.c:1465
#2  0x115de88c in get_source_location_for_substring (pfile=0x12003e20,
concats=0x3fffb5cc, strloc=, type=,
caret_idx=, 
start_idx=, end_idx=, out_loc=0x3fffe2c0)
at /home/seurer/gcc/gcc-test/gcc/input.c:1517
#3  0x102db7ac in c_get_substring_location (substr_loc=...,
out_loc=) at
/home/seurer/gcc/gcc-test/gcc/c-family/c-common.c:867
#4  0x10a1701c in substring_loc::get_location (out_loc=0x3fffe2c0,
this=0x3fffe480) at /home/seurer/gcc/gcc-test/gcc/substring-locations.c:284
#5  format_string_diagnostic_t::emit_warning_n_va (this=0x3fffe360,
opt=, n=0, 
singular_gmsgid=0x11b7ace0 "%<%.*s%> directive writing likely %wu or more
bytes into a region of size %wu", 
plural_gmsgid=0x11b7ace0 "%<%.*s%> directive writing likely %wu or more
bytes into a region of size %wu", ap=0x3fffe388)
at /home/seurer/gcc/gcc-test/gcc/substring-locations.c:156
#6  0x11434bec in (anonymous namespace)::fmtwarn (fmt_loc=...,
param_loc=0, corrected_substring=0x0, opt=, 
gmsgid=0x11b7ace0 "%<%.*s%> directive writing likely %wu or more bytes into
a region of size %wu", corrected_substring=0x0)
at /home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:472
#7  0x11437b2c in (anonymous namespace)::maybe_warn (dir=..., dir=...,
res=..., avail_range=, info=..., argloc=0, dirloc=...)
at /home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:2593
#8  (anonymous namespace)::format_directive (info=..., res=0x3fffe748,
dir=..., vr_values=0x12483fc0) at
/home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:2822
#9  0x1143b654 in (anonymous
namespace)::sprintf_dom_walker::compute_format_length (res=0x3fffe748,
info=..., this=0x3fffea00)
at /home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:3502
#10 (anonymous namespace)::sprintf_dom_walker::handle_gimple_call
(this=0x3fffea00, gsi=0x3fffe930) at
/home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:3988
#11 0x1143cbac in (anonymous
namespace)::sprintf_dom_walker::before_dom_children (this=0x3fffea00,
bb=)
at /home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:4027
#12 0x113e1300 in dom_walker::walk (this=0x3fffea00,
bb=0x3fffb5eb8a88) at /home/seurer/gcc/gcc-test/gcc/domwalk.c:353
#13 0x1143481c in (anonymous namespace)::pass_sprintf_length::execute
(this=, fun=0x3fffadc8a3a0)
at /home/seurer/gcc/gcc-test/gcc/gimple-ssa-sprintf.c:4053
#14 0x108e79f4 in execute_one_pass (pass=0x1202f4d0) at
/home/seurer/gcc/gcc-test/gcc/passes.c:2428
#15 0x108e8b24 in execute_pass_list_1 (pass=0x1202f4d0) at
/home/seurer/gcc/gcc-test/gcc/passes.c:2517
#16 0x108e8b3c in execute_pass

[Bug c++/87643] [9 regression] ICE at dbxout.c:508:1: linemap_position_for_line_and_column starting with r264887

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from David Malcolm  ---
Sorry about this; it's a duplicate of PR 87562.  I'm testing a fix.

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

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #5 from David Malcolm  ---
*** Bug 87643 has been marked as a duplicate of this bug. ***

[Bug c++/87643] [9 regression] ICE at dbxout.c:508:1: linemap_position_for_line_and_column starting with r264887

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry for the duplicate.  I am not having much success with searches lately...

[Bug tree-optimization/65461] -Warray-bounds warnings in the linux kernel (free_area_init_nodes)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||4.5.3
  Known to fail||4.6.0, 5.4.0, 6.3.0, 7.3.0,
   ||8.2.0

--- Comment #4 from Martin Sebor  ---
Looks like the warning first appeared in 4.6 and is still on trunk.

[Bug middle-end/87623] bytes swapped in register when comparing cause fail when compiled with -O1 or higher

[george.thopas at gmail dot com]

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

--- Comment #9 from George Thopas  ---
(In reply to Eric Botcazou from comment #8)
> Thanks for reporting the problem.

And thanks for the swift resolution !

[Bug fortran/87644] New: ICE due to variable named "parameters"

[matthew.thompson at nasa dot gov]

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

Bug ID: 87644
   Summary: ICE due to variable named "parameters"
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.thompson at nasa dot gov
  Target Milestone: ---

This is a weird ICE recently encountered using gfortran 8.2.0 on SLES11, CentOS
7, and macOS High Sierra in a large code, but I managed to whittle it down to a
small reproducer below. The issue sees to be related to the fact that the
variable is named 'parameters'.

module test

  implicit none
  private
  public :: get

contains

  subroutine initialize()
 integer :: parameters
 parameters = get()
  end subroutine initialize

  function get() result(parameters)
 integer :: parameters
 parameters = 1
  end function get

end module test

When it's compiled:

(259) $ gfortran -v -save-temps test.F90
Driving: gfortran -v -save-temps test.F90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/ford1/local/gcc/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure --prefix=/ford1/local/gcc/gcc-8.2.0
--disable-multilib
Thread model: posix
gcc version 8.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /ford1/local/gcc/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/f951 test.F90
-cpp=test.f90 -quiet -v test.F90 -quiet -dumpbase test.F90 -mtune=generic
-march=x86-64 -auxbase test -version -fintrinsic-modules-path
/ford1/local/gcc/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/finclude -o test.s
GNU Fortran (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/ford1/local/gcc/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /ford1/local/gcc/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/finclude
 /ford1/local/gcc/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
 /usr/local/include
 /ford1/local/gcc/gcc-8.2.0/include
 /ford1/local/gcc/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in is_illegal_recursion, at
fortran/resolve.c:1684
0x5c3d20 is_illegal_recursion
../../gcc-8.2.0/gcc/fortran/resolve.c:1684
0x6a3136 resolve_function
../../gcc-8.2.0/gcc/fortran/resolve.c:3262
0x6a006d gfc_resolve_expr(gfc_expr*)
../../gcc-8.2.0/gcc/fortran/resolve.c:6725
0x633cff gfc_reduce_init_expr(gfc_expr*)
../../gcc-8.2.0/gcc/fortran/expr.c:2773
0x636650 gfc_match_init_expr(gfc_expr**)
../../gcc-8.2.0/gcc/fortran/expr.c:2821
0x6203b4 do_parm
../../gcc-8.2.0/gcc/fortran/decl.c:8836
0x6203b4 gfc_match_parameter()
../../gcc-8.2.0/gcc/fortran/decl.c:8890
0x67f239 match_word
../../gcc-8.2.0/gcc/fortran/parse.c:65
0x67fbac decode_statement
../../gcc-8.2.0/gcc/fortran/parse.c:356
0x68357e next_free
../../gcc-8.2.0/gcc/fortran/parse.c:1234
0x68357e next_statement
../../gcc-8.2.0/gcc/fortran/parse.c:1466
0x684c2b parse_spec
../../gcc-8.2.0/gcc/fortran/parse.c:3858
0x687627 parse_progunit
../../gcc-8.2.0/gcc/fortran/parse.c:5671
0x687aaa parse_contained
../../gcc-8.2.0/gcc/fortran/parse.c:5574
0x68871c parse_module
../../gcc-8.2.0/gcc/fortran/parse.c:5944
0x688a0b gfc_parse_file()
../../gcc-8.2.0/gcc/fortran/parse.c:6247
0x6cf25f gfc_be_parse_file
../../gcc-8.2.0/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Note that if the variable 'parameters' is renamed 'p' it works:

(261) $ cat testp.F90
module test

  implicit none
  private
  public :: get

contains

  subroutine initialize()
 integer :: p
 p = get()
  end subroutine initialize

  function get() result(p)
 integer :: p
 p = 1
  end function get

end module test
(262) $ gfortran testp.F90
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

[Bug fortran/87644] ICE due to variable named "parameters"

[matthew.thompson at nasa dot gov]

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

--- Comment #1 from Matt Thompson  ---
Further update from a colleague:

Some observations:

* The function result having the name 'parameters' has no effect. It's from
this line "parameters = get()".

* The 'public :: get' must be present in the module otherwise it compiles

* Appending letters to the word 'parameters', for example 'parametersabc' still
causes a crash

* Prepending letters to the word 'parameters' does not crash

* The 'private' clause at the top is not necessary

Here's a more stripped down reproducer:

module test
  public :: get !this line is necessary for the crash

contains

  subroutine init()
integer :: parameters
 parameters = get()
  end subroutine init

  function get() result(p)
 integer :: p
 p = 1
  end function get

end module test

The bug seems to have been introduced in gfortran 7. I tried GCC 8.2, 8.1, 7.3,
7.2 and 7.1 and the bug is present in all of them. However, it is not present
in GCC 6.3 and previous versions.

Another interesting thing I noticed is that if you just have a variable named
'parameters' and assign it a value you get this warning:

module test

contains

  subroutine init()
integer :: parameters
 parameters = 1
  end subroutine init

end module test

gfortran_reproducer.F90:8:14:

  parameters = 1
  1
Warning: Legacy Extension: PARAMETER without '()' at (1)

This legacy extension seems like it's the culprit, and this patch

 https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00206.html

describes the error we found and roughly coincides with GCC 7 when the bug
appeared, but it says it should only apply to fixed-form code.

> However, note that this would change by default the compiler's
> interpretation of fixed-form variables starting with the string
> "parameter", if any such cases existed in real code. IMO fixed form
> code is isomorphic to legacy code, so I imagine most users writing
> fixed-form/legacy code would intend for a legacy PARAMETER statement,
> rather than assignment to variable PARAMETERPI, when writing such a
> statement.

But our code is obviously not fixed-format and that doesn't explain why "public
:: get" should have any effect.

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 18 15:38:50 2018
New Revision: 265270

URL: https://gcc.gnu.org/viewcvs?rev=265270&root=gcc&view=rev
Log:
PR libstdc++/87641 correctly initialize accumulator in valarray::sum()

Use the value of the first element as the initial value of the
__valarray_sum accumulator. Value-initialization might not create the
additive identity for the value type.

Make a similar change to __valarray_product even though it's only ever
used internally with a value_type of size_t.

PR libstdc++/87641
* include/bits/valarray_array.h (__valarray_sum): Use first element
to initialize accumulator instead of value-initializing it.
(__valarray_product<_Tp>): Move to ...
* src/c++98/valarray.cc (__valarray_product<_Tp>): Here. Use first
element to initialize accumulator.
(__valarray_product(const valarray&)): Remove const_cast made
unnecessary by LWG 389.
* testsuite/26_numerics/valarray/87641.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/87641.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/valarray_array.h
trunk/libstdc++-v3/src/c++98/valarray.cc

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Thu Oct 18 15:44:39 2018
New Revision: 265271

URL: https://gcc.gnu.org/viewcvs?rev=265271&root=gcc&view=rev
Log:
Fix ICE in substring-handling building 502.gcc_r (PR 87562)

In r264887 I broke the build of 502.gcc_r due to an ICE.
The ICE occurs when generating a location for an sprintf warning within
a string literal, where the sprintf call is in a macro.

The root cause is a bug in the original commit of substring locations
(r239175).  get_substring_ranges_for_loc has code to handle the case
where the string literal is in a very long source line that exceeds the
length that the current linemap can represent: the start of the token
is in one line map, but then another line map is started, and the end
of the token is in the new linemap.  get_substring_ranges_for_loc handles
this by using the linemap of the end-point when building location_t
values within the string.  When extracting the linemap for the endpoint
in r239175 I erroneously used LRK_MACRO_EXPANSION_POINT, which should
have instead been LRK_SPELLING_LOCATION.

I believe this bug was dormant due to rejecting macro locations earlier
in the function, but in r264887 I allowed some macro locations in order
to deal with locations coming from the C++ lexer, and this uncovered
the bug: if a string literal was defined in a macro, locations within
the string literal would be looked up using the linemap of the expansion
point of the macro, rather than of the spelling point.  This would lead
to garbage location_t values, and, depending on the precise line numbers
of the two locations, an assertion failure (which was causing the build
failure in 502.gcc_r).

This patch fixes the bug by using LRK_SPELLING_LOCATION, and adds some
bulletproofing to the "two linemaps" case.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
(g++.sum gained 5 PASS results; gcc.sum gained 3 PASS results).
I also verified that this fixes the build of 502.gcc_r.

gcc/ChangeLog:
PR tree-optimization/87562
* input.c (get_substring_ranges_for_loc): Use
LRK_SPELLING_LOCATION rather than LRK_MACRO_EXPANSION_POINT when
getting the linemap for the endpoint.  Verify that it's either
in the same linemap as the start point's spelling location, or
at least in the same file.

gcc/testsuite/ChangeLog:
PR tree-optimization/87562
* c-c++-common/substring-location-PR-87562-1-a.h: New file.
* c-c++-common/substring-location-PR-87562-1-b.h: New file.
* c-c++-common/substring-location-PR-87562-1.c: New test.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Add test for
PR 87562.
* gcc.dg/plugin/pr87562-a.h: New file.
* gcc.dg/plugin/pr87562-b.h: New file.


Added:
trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1-a.h
trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1-b.h
trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1.c
trunk/gcc/testsuite/gcc.dg/plugin/pr87562-a.h
trunk/gcc/testsuite/gcc.dg/plugin/pr87562-b.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed by r265271.  Sorry for the breakage.

[Bug middle-end/81376] unnecessary cast before comparison

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez  ---
Causes PR87633.

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||ygribov at gcc dot gnu.org
   Assignee|aldyh at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Aldy Hernandez  ---
On closer inspection, this isn't my ring at all.

This PR was caused by the following, which was way before I started meddling
here:

commit 91a82d532f1442242b290b1515e87116d6f7acb1
Author: ygribov 
Date:   Fri Oct 12 20:35:20 2018 +

Add pattern to remove useless float casts in comparisons.

PR middle-end/81376

gcc/
* real.c (format_helper::can_represent_integral_type_p): New
function
* real.h (format_helper::can_represent_integral_type_p): Ditto.
* match.pd: New pattern.

gcc/testsuite/
* c-c++-common/pr81376.c: New test.
* gcc.target/i386/387-ficom-2.c: Update test.
* gcc.target/i386/387-ficom-2.c: Ditto.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@265131
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug tree-optimization/87645] New: gcc hangs up on vr_values::vrp_visit_assignment_or_call

[konstantin.vladimirov at gmail dot com]

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

Bug ID: 87645
   Summary: gcc hangs up on
vr_values::vrp_visit_assignment_or_call
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

Reproduction (after creduce, sorry for that code):

typedef unsigned a[8];
a b, g;
int c, d, e, f;
int h() {
  unsigned i = 2;
  for (; i < 8; i++)
b[i] = 0;
  for (; f;) {
d = 1;
for (; d < 14; d += 3) {
  e = 0;
  for (; e < 8; e++) {
i = 2;
for (; i < 8; i++)
  b[i] = 5 - (c - g[e] + b[i]);
  }
}
  }
}

Compiler:

> gcc -v

Reading specs from
/apps/gcc/8.1.0/.bin/../lib64/gcc/x86_64-suse-linux/8.1.0/specs
COLLECT_GCC=/apps/gcc/8.1.0/.bin/gcc
COLLECT_LTO_WRAPPER=/apps/gcc/8.1.0/.bin/../libexec/gcc/x86_64-suse-linux/8.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ./configure --prefix=/apps/gcc/8.1.0
--libdir=/apps/gcc/8.1.0/lib64 --libexecdir=/apps/gcc/8.1.0/libexec
--bindir=/apps/gcc/8.1.0/bin --with-isl=/apps/gcc/8.1.0
--with-libelf=/apps/gcc/8.1.0 --with-mpfr=/apps/gcc/8.1.0
--with-gmp=/apps/gcc/8.1.0 --with-mpc=/apps/gcc/8.1.0
--disable-gnu-unique-object --enable-gold=yes --enable-lto
--enable-languages=c,c++,objc,fortran --build=x86_64-suse-linux
--host=x86_64-suse-linux --target=x86_64-suse-linux --enable-libotm
--disable-multilib --disable-bootstrap --disable-libstdcxx-pch
Thread model: posix
gcc version 8.1.0 (GCC)

Try to compile like this:

gcc -S -O3 test.c

gcc hangs up

gcc -S -O2 test.c

passes ok

This might look similar with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87087
but in this case it doesn't consume too much memory and gdb shows vrp, not
unroll.

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
Build successes for intrate: 502.gcc_r(base)
Build errors for intrate: None

It now works with your fix, thanks!

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 18 17:40:29 2018
New Revision: 265275

URL: https://gcc.gnu.org/viewcvs?rev=265275&root=gcc&view=rev
Log:
PR libstdc++/87641 correctly initialize accumulator in valarray::sum()

Use the value of the first element as the initial value of the
__valarray_sum accumulator. Value-initialization might not create the
additive identity for the value type.

PR libstdc++/87641
* include/bits/valarray_array.h (__valarray_sum): Use first element
to initialize accumulator instead of value-initializing it.
* testsuite/26_numerics/valarray/87641.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/26_numerics/valarray/87641.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug target/86677] popcount builtin detection is breaking some kernel build

[will.deacon at arm dot com]

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

Will Deacon  changed:

   What|Removed |Added

 CC||will.deacon at arm dot com

--- Comment #8 from Will Deacon  ---
I replied to the ticket raised on the kernel.org bugzilla about this change:

https://bugzilla.kernel.org/show_bug.cgi?id=200671#c1

I've also duplicated my response below in case you'd rather respond here.

--->8

Whilst providing an implementation of __popcountsi2 will fix the build, won't
this end up with worse code generation compared to a compiler which doesn't do
this idiom recognition?

If I understand this correctly, an in-line integer popcount implementation in
the code can be spotted by the compiler and replaced  by a branch to an
out-of-line integer popcount implementation.

Please can we have an option to disable this idiom recognition? It really
doesn't seem to make sense in an environment where the SIMD registers aren't
readily accessible.

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #4 from Yury Gribov  ---
Thanks, looking.

[Bug c++/87646] New: Wrong code at -O3 and above (but not at -O2 and below)

[sukhovvl at gmail dot com]

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

Bug ID: 87646
   Summary: Wrong code at -O3 and above (but not at -O2 and below)
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sukhovvl at gmail dot com
  Target Milestone: ---

gcc 4.8.5 20150623 miscompiles the following code with -O3 optimization flag on
x86-64
gcc 4.9 and above doesn't seem to have this bug

Correct output with -O2 flag:
[root@localhost home]# g++ -std=c++11 -O2 test.cpp -otest && ./test
        0

Incorrect output with -O3 flag:
[root@localhost home]# g++ -std=c++11 -O3 test.cpp -otest && ./test
 0 0 0 0 0 0 0 0

[root@localhost home]# hostnamectl
   Static hostname: localhost.localdomain
 Icon name: computer-vm
   Chassis: vm
Machine ID: 
   Boot ID: 
Virtualization: kvm
  Operating System: CentOS Linux 7 (Core)
   CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-862.9.1.el7.x86_64
  Architecture: x86-64



#include 
#include 
#include 

void f(std::size_t N, std::int32_t* dst)
{
if (N % 8)
{
std::int32_t l[8] = {0, 0, 0, 0, 0, 0, 0, 0};
for (unsigned i = 0; i < N % 8; ++i)
l[i] = -1;

std::memcpy((void*)dst, (const void*)l, sizeof(int32_t)*8);
}
}

int main()
{
std::int32_t values[8];
std::size_t N = 7;

f(N, values);

for (int i = 0; i < 8; ++i)
std::cout << std::hex << " " << values[i];
std::cout << std::endl;

return 0;
}

[Bug c++/87646] Wrong code at -O3 and above (but not at -O2 and below)

[sukhovvl at gmail dot com]

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

--- Comment #1 from Vadim Sukhov  ---
Created attachment 44853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44853&action=edit
Test case (compile with -std=c++11 -O3)

[Bug middle-end/87647] New: ICE on valid code in decode_addr_const, at varasm.c:2958

[tavianator at gmail dot com]

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

Bug ID: 87647
   Summary: ICE on valid code in decode_addr_const, at
varasm.c:2958
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com
  Target Milestone: ---

$ cat test.c
struct a {
};
struct a *const b = &(struct a){};
int main() {
  struct {
char *s;
struct a *t;
  } a[] = {"", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "",
   b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b};
}
$ gcc -O1 test.c
test.c: In function ‘main’:
test.c:8:5: internal compiler error: in decode_addr_const, at varasm.c:2958
   } a[] = {"", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "", b,  "",
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ gcc --version
gcc (GCC) 8.2.1 20180831
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.

Reduced from a reddit post:
https://www.reddit.com/r/C_Programming/comments/9p44be/internal_compiler_error/

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[ygribov at gcc dot gnu.org]

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

--- Comment #5 from Yury Gribov  ---
Created attachment 44854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44854&action=edit
Draft fix

So my commit caused unordered comparison to be generated for integer operands
which upsetted vrange pass. It's probly a good idea to get rid of unordereds so
attached patch does that and seems to no longer crash on both attached
reprocases. I'm now running bootstrap/test as usual.

[Bug c++/87646] Wrong code at -O3 and above (but not at -O2 and below)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This got fixed with r204926 and r204929, but there is nothing that can be done
about 4.8, it is not supported upstream since June 2015.

[Bug c++/87646] Wrong code at -O3 and above (but not at -O2 and below)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Testcase without headers in C:
typedef __SIZE_TYPE__ size_t;

__attribute__((noinline, noclone)) void
foo (size_t x, int *y)
{
  if (x % 8)
{
  int l[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }, i;
  for (i = 0; i < x % 8; ++i)
l[i] = -1;
  __builtin_memcpy (y, l, sizeof (int) * 8);
}
}

int
main ()
{
  int v[8], i;
  foo (7, v);
  for (i = 0; i < 7; i++)
if (v[i] != -1)
  __builtin_abort ();
  if (v[i])
__builtin_abort ();  
  return 0;
}

[Bug target/87646] Wrong code at -O3 and above (but not at -O2 and below)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |target
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed in 4.9, can't be fixed on unsupported branch.

[Bug target/87646] Wrong code at -O3 and above (but not at -O2 and below)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #5 from Jakub Jelinek  ---
Actually, with -O3 -mmemset-strategy=libcall:-1:noalign this can be reproduced
much later and got fixed with r233743.

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

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sukhovvl at gmail dot com

--- Comment #20 from Jakub Jelinek  ---
*** Bug 87646 has been marked as a duplicate of this bug. ***

[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Thu Oct 18 19:35:34 2018
New Revision: 265283

URL: https://gcc.gnu.org/viewcvs?rev=265283&root=gcc&view=rev
Log:
Fix (re)alloc of polymorphic arrays

PR fortran/87625
* trans-array.c (gfc_is_reallocatable_lhs): Detect allocatable
polymorphic arrays.

PR fortran/87625
* gfortran.dg/realloc_on_assign_31.f90: New file.


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

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 18 19:38:56 2018
New Revision: 265285

URL: https://gcc.gnu.org/viewcvs?rev=265285&root=gcc&view=rev
Log:
PR libstdc++/87641 correctly initialize accumulator in valarray::sum()

Use the value of the first element as the initial value of the
__valarray_sum accumulator. Value-initialization might not create the
additive identity for the value type.

PR libstdc++/87641
* include/bits/valarray_array.h (__valarray_sum): Use first element
to initialize accumulator instead of value-initializing it.
* testsuite/26_numerics/valarray/87641.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/26_numerics/valarray/87641.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/87642] Cannot handle fr_FR.UTF8 thousands separator

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 18 19:57:25 2018
New Revision: 265286

URL: https://gcc.gnu.org/viewcvs?rev=265286&root=gcc&view=rev
Log:
PR libstdc++/87642 handle multibyte thousands separators from libc

If a locale's THOUSANDS_SEP or MON_THOUSANDS_SEP string is not a
single character we either need to narrow it to a single char or
ignore it (and therefore disable digit grouping for that facet).

PR libstdc++/87642
* config/locale/gnu/monetary_members.cc
(moneypunct::_M_initialize_moneypunct): Use
__narrow_multibyte_chars to convert multibyte thousands separators
to a single char.
* config/locale/gnu/numeric_members.cc
(numpunct::_M_initialize_numpunct): Likewise.
(__narrow_multibyte_chars): New function.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/locale/gnu/monetary_members.cc
trunk/libstdc++-v3/config/locale/gnu/numeric_members.cc

[Bug libstdc++/87642] Cannot handle fr_FR.UTF8 thousands separator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Should be fixed on trunk.

[Bug fortran/87648] New: Clobber some variables on entry to DO CONCURRENT

[tkoenig at gcc dot gnu.org]

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

Bug ID: 87648
   Summary: Clobber some variables on entry to DO CONCURRENT
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For variables which are defined in a DO CONCURRENT loop,
it should be beneficial to clobber them on entry.

This could have two benefits: Catching undefined variables for
constructs like

    do concurrent (i = 1:size(a))
    s = s + (2 * a(i) - 1)
    end do

but not for things like

   do concurrent (i = 1:size(a))
if (i == 42) s = (2 * a(i) - 1)
   end do

and possibly as an aid to optimization.

For some analysis, see

https://groups.google.com/d/msg/comp.lang.fortran/ksGzUPK7GBM/ulfEBGFkBQAJ

[Bug target/72782] AVX512: No support for scalar broadcasts

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Oct 18 20:38:41 2018
New Revision: 265288

URL: https://gcc.gnu.org/viewcvs?rev=265288&root=gcc&view=rev
Log:
i386: Enable AVX512 memory broadcast for FMA

Many AVX512 vector operations can broadcast from a scalar memory source.
This patch enables memory broadcast for FMA operations.

gcc/

PR target/72782
* config/i386/sse.md (VF_AVX512): New.
(avx512bcst): Likewise.
(*fma_fmadd__bcst_1):
Likewise.
(*fma_fmadd__bcst_2):
Likewise.
(*fma_fmadd__bcst_3):
Likewise.

gcc/testsuite/

PR target/72782
* gcc.target/i386/avx512-fma-1.h: New file.
* gcc.target/i386/avx512-fma-2.h: Likewise.
* gcc.target/i386/avx512-fma-3.h: Likewise.
* gcc.target/i386/avx512-fma-4.h: Likewise.
* gcc.target/i386/avx512-fma-5.h: Likewise.
* gcc.target/i386/avx512-fma-6.h: Likewise.
* gcc.target/i386/avx512-fma-7.h: Likewise.
* gcc.target/i386/avx512-fma-8.h: Likewise.
* gcc.target/i386/avx512f-fmadd-df-zmm-1.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-1.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-2.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-3.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-4.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-5.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-6.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-7.c: Likewise.
* gcc.target/i386/avx512f-fmadd-sf-zmm-8.c: Likewise.
* gcc.target/i386/avx512vl-fmadd-sf-xmm-1.c: Likewise.
* gcc.target/i386/avx512vl-fmadd-sf-ymm-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-1.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-2.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-3.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-4.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-5.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-6.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-7.h
trunk/gcc/testsuite/gcc.target/i386/avx512-fma-8.h
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-df-zmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-3.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-4.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-5.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-6.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-7.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-fmadd-sf-zmm-8.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-fmadd-sf-xmm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-fmadd-sf-ymm-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77643] ICE with "character(len=:), pointer :: p => null()"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
It looks like a duplicate of pr70149. It is fixed at revision r265266.

[Bug fortran/71880] pointer to allocatable character

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Dominique d'Humieres  ---
The test in comment 2 looks like a duplicate of pr70149. It is fixed at
revision r265266.

[Bug fortran/70914] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1655

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Dominique d'Humieres  ---
The test z7.f90 looks like a duplicate of pr70149. It is fixed at revision
r265266.

[Bug libgomp/87649] New: ICE in OpenMP doacross (ordered) loop

[omrimor2 at illinois dot edu]

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

Bug ID: 87649
   Summary: ICE in OpenMP doacross (ordered) loop
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: omrimor2 at illinois dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44855&action=edit
Minimal Working Example (C)

An OpenMP loop construct with an ordered clause with a parameter and a nested
ordered construct with no depend clause causes an internal compiler error
during the 'ompexp' GIMPLE pass. This is invalid OpenMP*, but should not cause
an ICE segfault. Clang returns with an error, while ICC compiles (!) the
invalid code but imposes no ordering constraint. Occurs on both macOS
(Homebrew, GCC 8.2.0) and a Linux cluster (GCC 7.2.0).

I haven't confirmed if this is C/C++ frontend-specific or errors with Fortran
as well.

*The loop or loop SIMD region to which an ordered region arising from an
ordered construct without a depend clause binds must have an ordered clause
without the parameter specified on the corresponding loop or loop SIMD
directive. (OpenMP 4.5 Specification, §2.13.8, pp. 168)

#pragma omp parallel for ordered(1)
for (int i = 0; i < 100; i++) {
#pragma omp ordered
array[i] = i;
}

macOS:
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin18.0.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin18.0.0
Configured with: ../configure --build=x86_64-apple-darwin18.0.0
--prefix=/usr/local/Cellar/gcc/8.2.0
--libdir=/usr/local/Cellar/gcc/8.2.0/lib/gcc/8
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
8.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 8.2.0 (Homebrew GCC 8.2.0) 

Linux:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7.2.0/configure --with-gmp=/usr/local/gmp/6.1.0
--with-mpfr=/usr/local/mpfr/3.1.4 --with-mpc=/usr/local/mpc/1.0.3
--with-cloog=/usr/local/cloog/ --with-isl=/usr/local/isl/0.16.1
--enable-cloog-backend=isl --prefix=/usr/local/gcc/7.2.0
Thread model: posix
gcc version 7.2.0 (GCC) 

Command line:
gcc -o test1 -fopenmp test1.c

Compiler output:
test1.c: In function 'main':
test1.c:7:10: internal compiler error: Segmentation fault: 11
  #pragma omp parallel for ordered(1)
  ^~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/87647] [6/7/8/9 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-18
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE on valid code in|[6/7/8/9 Regression] ICE on
   |decode_addr_const, at   |valid code in
   |varasm.c:2958   |decode_addr_const, at
   ||varasm.c:2958
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r159325.

[Bug libgomp/87649] ICE in OpenMP doacross (ordered) loop

[omrimor2 at illinois dot edu]

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

--- Comment #1 from omrimor2 at illinois dot edu ---
Duplicate of #85488, but has more information.

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 18 21:41:01 2018
New Revision: 265291

URL: https://gcc.gnu.org/viewcvs?rev=265291&root=gcc&view=rev
Log:
PR libstdc++/87641 correctly initialize accumulator in valarray::sum()

Use the value of the first element as the initial value of the
__valarray_sum accumulator. Value-initialization might not create the
additive identity for the value type.

PR libstdc++/87641
* include/bits/valarray_array.h (__valarray_sum): Use first element
to initialize accumulator instead of value-initializing it.
* testsuite/26_numerics/valarray/87641.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/26_numerics/valarray/87641.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 6.5, 7.4 and 8.3

Thanks for reporting it.

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

[bugdal at aerifal dot cx]

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

--- Comment #10 from Rich Felker  ---
Since musl 1.1 introduced unconditional setup of thread pointer, the
previously-reported consequence is no longer relevant with modern versions.
However it's still either a missed optimization (emitting useless canary load
despite the fact that there's no code to check the canary) or missed hardening
(checking canary before leaving via a noreturn function) and thus seems
interesting still.

[Bug target/66389] sh2eb-linux-* is not recognized by configure

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

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

--- Comment #1 from Rich Felker  ---
I don't have a reference for the commit, but this bug was fixed somewhere in
6.x.

[Bug target/87650] New: suboptimal codegen for testing low bit

[hoganmeier at gmail dot com]

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

Bug ID: 87650
   Summary: suboptimal codegen for testing low bit
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hoganmeier at gmail dot com
  Target Milestone: ---

int pow(int x, unsigned int n)
{
int y = 1;
while (n > 1)
{
auto m = n%2;
n = n/2;
if (m)
y *= x;
x = x*x;
}
return x*y;
}

produces
mov edx, esi
and edx, 1
test edx, edx

instead of just
test sil, 1

while clang chooses a branchless version:
https://godbolt.org/z/L6VUZ1

Interestingly gcc does use test sil,1 if you get rid of m:
godbolt.org/z/9oL1oc

Assembly analysis:
https://stackoverflow.com/a/52877279/594456

[Bug other/79543] Inappropriate "ld --version" checking

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Thomas Schwinge from comment #1)
> > .
> 
> This link doesn't work for me.

Wait never mind now it does

[Bug target/62273] doc: Invoke.texi -mkernel mentions undocumented option

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net

--- Comment #4 from Eric Gallager  ---
(In reply to Joel Sherrill from comment #0)
> 
> I assume someone responsible for the Darwin configuration knows enough to
> add a line or two of documentation.

cc-ing people responsible for or knowledgeable of the Darwin configuration

[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||geoffk at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Jack Howarth from comment #1)
> Note that weak_import was added by Geoffrey Keating in...
> 
> https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html
> 
> and tweaked in...
> 
> https://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html
> 
> The last time Geoff referenced it in a patch, he claimed it was 'effectively
> deprecated' in gcc...
> 
> https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html
> 

cc-ing him

[Bug c++/87651] New: inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0

[haining.cpp at gmail dot com]

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

Bug ID: 87651
   Summary: inner class with template template friend declaration
of same name fails to compile in gcc 8.1, 8.2, and 9.0
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haining.cpp at gmail dot com
  Target Milestone: ---

Requirements to repro

1) Outer class must be template
2) Inner class must have template template parameter

 Sample program 

template  class Cls;

template 
struct Outer {
  template  class>
  class Failure {
template  class>
friend class Failure; // All Failures should be friends
  };

  using F = Failure;
};

int main() {
  Outer::F var;
}


 Error message #

prog.cc: In instantiation of 'class Outer::Failure':
prog.cc:15:18:   required from here
prog.cc:5:33: error: template parameter 'template template
class'
   template  class>
 ^
prog.cc:8:18: error: redeclared here as 'template
class'
 friend class Failure;
  ^~~

 Additional Info 


wandbox links to errors:

 - [gcc-8.1.0](https://wandbox.org/permlink/vpzvcXcPUwVm4ent)
 - [gcc-8.2.0](https://wandbox.org/permlink/YaD9sml3aPaJExcm)
 - [gcc HEAD 9.0.0 20181017 ](https://wandbox.org/permlink/FXqrijJRqbyNT0ZT)

passing with [gcc-7.3.0](https://wandbox.org/permlink/0HQ9K8PuSJBqRmD1)


This is causing several components of
http://github.com/ryanhaining/cppitertools to fail to compile, and I have no
ideas for a workaround besides making my data members public

[Bug c/60440] Bogus -Wreturn-type warning after error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Liška from comment #5)
> I'm CC'ing some..

cc-ing some (well one) more since no one replied yet

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Blocks||87403

--- Comment #11 from Eric Gallager  ---
ASSIGNED since there's an assignee


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/61579] -Wwrite-strings does not behave as a warning option

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Marek Polacek from comment #4)
> Wow, how has it been 4 years already?  Maybe this time around then.  :)

Hopefully! I keep seeing it come up places...

[Bug c++/87652] New: inner class template of outer class template can't access friend's protected data member

[haining.cpp at gmail dot com]

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

Bug ID: 87652
   Summary: inner class template of outer class template can't
access friend's protected data member
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haining.cpp at gmail dot com
  Target Milestone: ---

 Example program 

template 
struct Outer {
  template 
  class Inner {
template 
friend class Inner; // All Inners should be friends

   public:
 template 
 void use_other_x(const Inner& other) const {
   (void)other.x; // should be fine, we're all friends
 }
   private: // no error if private instead
 int x;
  };
};

int main() {
  Outer::Inner i1;
  Outer::Inner i2;
  i1.use_other_x(i2);
}

 Error message 

prog.cc: In instantiation of 'void Outer<  >::Inner<
 >::use_other_x(const Outer< 
>::Inner&) const [with T = char;  = void;
 = int]':
prog.cc:21:20:   required from here
prog.cc:11:20: error: 'int Outer::Inner::x' is protected within this
context
(void)other.x;
  ~~^
prog.cc:14:10: note: declared protected here
  int x;


 Notes 

No problems observed when using private: instead of protected:

[Bug c++/87652] inner class template of outer class template can't access friend's protected data member

[haining.cpp at gmail dot com]

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

--- Comment #1 from Ryan R Haining  ---
ugh, very sorry, I copied the version with private: instead of protected. The
example program should be:

template 
struct Outer {
  template 
  class Inner {
template 
friend class Inner; // All Inners should be friends

   public:
 template 
 void use_other_x(const Inner& other) const {
   (void)other.x;
 }
   protected: // no error if private instead
 int x;
  };
};

int main() {
  Outer::Inner i1;
  Outer::Inner i2;
  i1.use_other_x(i2);
}