[Bug c++/50169] [DR 2141] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[egallager at gcc dot gnu.org]

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

--- Comment #7 from Eric Gallager  ---
(In reply to Nathan Ridge from comment #6)
> Here is another test case that MSVC accepts but GCC rejects:
> 
> struct A {};
> struct A* b = (1 == 1) ? new struct A : new struct A;

Is this really the same thing though?

[Bug rtl-optimization/87639] New: 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

Bug ID: 87639
   Summary: GCC fails to consider end of automatic object lifetime
when determining sibcall eligibility
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Test case:

void bar();
void bah(void *);
void foo2()
{
{
char buf[1000];
bah(buf);
}
bar();
}

Since buf's address leaked to bah, gcc concludes that it cannot generate a
sibcall to bar. However, at the end of the block in which its declaration is
contained, buf's lifetime has ended.

The above test case is mildly artificial, but the same thing happens with
inlining, and results in long-lived large stack frames (and possibly stack
overflow if tail-recursion was desired), when a function comparable to the
block containing buf gets inlined into the function that should end with a
sibcall. This imposes the need for manual barriers against inlining or unnatual
splitting of functions when the stack usage is a problem.

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

[hp at gcc dot gnu.org]

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

--- Comment #31 from Hans-Peter Nilsson  ---
Created attachment 44851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44851=edit
patch as per directions

Thanks.  I also adjusted include/std/atomic, without which the struct X
test-case would not be impacted; only "base integral types".  I hope 54005.cc
contains sufficient variety, please advise if not.

Will post this to lists after testing.

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

[burnus at gcc dot gnu.org]

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, , false);   /* Can't fail */
  sym = symtree->n.sym;
  e->expr_type = EXPR_FUNCTION;
  if (!sym->attr.function
  && !gfc_add_function (>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.

[Bug c++/87638] New: [C++14] lambda init-capture fails for const references still

[hstong at ca dot ibm.com]

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

Bug ID: 87638
   Summary: [C++14] lambda init-capture fails for const references
still
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

The issue reported by PR 66735 still exists. GCC would not bind const-reference
init-captures to prvalues or xvalues.

### SOURCE ():
const int &();
void g() { [ = f()] { }(); }


### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -x c++ -std=c++14 -


### ACTUAL COMPILER OUTPUT:
: In function 'void g()':
:2:20: error: cannot capture 'f()' by reference


### EXPECTED COMPILER OUTPUT:
(Clean compile).


### 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)

[Bug fortran/85534] allocation of array with source give shifted index

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
I believe it has been FIXED by the patch for PR 67125.

[Bug tree-optimization/80155] [7/8/9 regression] Performance regression with code hoisting enabled

[law at redhat dot com]

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

--- Comment #44 from Jeffrey A. Law  ---
I'd be very hesitant to make the cost model target specific.  It goes against
core design goals of gimple.

Conceptually I believe we should be optimizing as much as possible on gimple
and that issues such as register pressure should be addressed at the
gimple->rtl border and later, not by throttling the gimple optimizers.

You could potentially look at Cliff Click's work from '95.  It could probably
be repurposed as a general lifetime shrinking pass through statement scheduling
within blocks and across blocks.

You could also look at reviving Bernd's work which tries to do statement
scheduling near the gimple->rtl border.

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

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong  ---
(In reply to Jonathan Wakely from comment #1)
> Dup of PR 57510 ?

Looks like this could be the same as the return statement in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510#c9. The scope of PR 57510
looks a bit 
unwieldy. I can't say that the summary of PR 57510 is indicative of the issue
either.

[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

--- Comment #1 from Jonathan Wakely  ---
Dup of PR 57510 ?

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

[hstong at ca dot ibm.com]

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

Bug ID: 87637
   Summary: Unwinding does not destroy constructed subobject of
brace-initialized temporary
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

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)

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

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Author: burnus
Date: Wed Oct 17 19:58:58 2018
New Revision: 265248

URL: https://gcc.gnu.org/viewcvs?rev=265248=gcc=rev
Log:
Fix select-type regression

PR fortran/87632
* resolve.c (resolve_select_type): Use correct variable.

PR fortran/87632
* gfortran.dg/select_type_47.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/select_type_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87622] coarray does not run in parallel

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Andreas Klein from comment #5)


> Adding initialzation removes the effect.
> There is still a 20% decresed performance, but that are plausible cache 
> effects.

OK, I'll close this bug then.

> Sorry my minimal example was to minimal. I derived the mini example from a 
> big parallel linear algebra package. Now I must go throgh all 
> minimalization steps, but its possible that the original error has nothing 
> to do with coarrays.

If you find anything that we could fix, please open a new PR.

And thanks for the PR anyway - it is better to open something that
later turns out to be invalid (I've submitted a few PRs like that) than
to miss something.

[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)

[wcventure at 126 dot com]

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

--- Comment #2 from Cheng Wen  ---
This bug was discovered by NTU Cyber-Security-Lab, for fuzzing research work.
If you have any questions, please let me know.

[Bug libstdc++/87635] backport of cmath patches to gcc 48 for Darwin incomplete cmath

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Riccardo from comment #0)
> The support for this is very useful for compiling larger software which
> still needs gcc 48, as is the case of TenFourFox!

GCC 4.8 is no longer supported or maintained, so nothing is going to be
backported to that branch here (downstream vendors might still support it and
make changes to their versions).

> Compared to the referenced bug, the issue is not PPC only, but also x86!

Those fields were set incorrectly, I've changed them now.

> I would also plan backporting to gcc6.

The gcc-6 branch is going to close in the next week or two, so I doubt this
will get backported to that branch either, unless it fixes a regression in GCC
6.4 when compared to previous releases.

[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)

[wcventure at 126 dot com]

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

--- Comment #1 from Cheng Wen  ---
I have summarized the different recursive stack frames problem in c++filt.

> This issue (In cp-demangle.c.c)
> recursive stack frames: cplus_demangle_type, d_bare_function_type, 
> d_function_type

I find that many people have reported similar problem, but it has not been
completely fixed. For example:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9138
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9996
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12641

> [CVE-2018-9138] (In cplus-dem.c)
> recursive stack frames: demangle_nested_args, demangle_args, do_arg, and 
> do_type
> [CVE-2018-9996] (In cplus-dem.c)
> recursive stack frames: demangle_template_value_parm, 
> demangle_integral_value, and demangle_expression
> [CVE-2018-12641] (In cplus-dem.c)
> recursive stack frames: demangle_arm_hp_template, demangle_class_name, 
> demangle_fund_type, do_type, do_arg, demangle_args, and demangle_nested_args.

In addition, there are still some practical problems that have not been
successfully reproduced. For example:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333


I tried to reproduce above problem on different machines. That may be your
compilation options mismatch. You can try to use the compiler options that I
provided.

> CC=clang LDFLAGS="-ldl" CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all 
> -fsanitize=undefined,address -fno-omit-frame-pointer -g -O0 -Wno-error" 
> ./configure --disable-shared --disable-gdb --disable-libdecnumber 
> --disable-sim --prefix=$PWD/build/
> CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address 
> -ggdb" CXXFLAGS="-fsanitize=address -fsanitize-recover=address -ggdb" 
> LDFLAGS="-fsanitize=address" ./configure --prefix=$PWD/build/

Many of these problems have not been completely fixed. I think this problem may
need attention.

[Bug c++/87636] New: Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)

[wcventure at 126 dot com]

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

Bug ID: 87636
   Summary: Infinite Recursive Stack Frames in cp-demangle.c in
libiberty(function cplus_demangle_type,
d_bare_function_type, d_function_type)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcventure at 126 dot com
  Target Milestone: ---

Created attachment 44850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44850=edit
POC

Dear all,

The following new binutils Stack-Overflow in libiberty was found by a modified
version of the AFL fuzzer(MemFuzz). I have attached the crashing input and an
ASAN report. I have confirmed them with address sanitizer too.

In this issue, Stack Exhaustion occurs in the C++ demangling functions provided
by libiberty, and there are recursive stack frames in cp-demangle:
cplus_demangle_type, d_bare_function_type, d_function_type. This can occur
during the execution of "c++filt -t". I have also collected the different Stack
Overflow problem recently appeared in c++filt, which I will list later. There
may be some problems that need attention.

Please use the “./c++filt < $POC -t” to reproduce the bug. (Remember to add
"-t" option and "<" Symbol)


Here is my compile Option. 

CC=clang LDFLAGS="-ldl" CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all
-fsanitize=undefined,address -fno-omit-frame-pointer -g -O0 -Wno-error"
./configure --disable-shared --disable-gdb --disable-libdecnumber --disable-sim
--prefix=$PWD/build/

> ASAN:DEADLYSIGNAL
> =
> ==28168==ERROR: AddressSanitizer: stack-overflow on address 0x7ffdfcdedf28 
> (pc 0x02081a20 bp 0x7ffdfcdee0f0 sp 0x7ffdfcdedf28 T0)
> #0 0x2081a1f in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2367
> #1 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #2 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> #3 0x2086c1b in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2443:13
> #4 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #5 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> #6 0x2086c1b in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2443:13
> #7 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #8 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> #9 0x2086c1b in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2443:13
> #10 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #11 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> #12 0x2086c1b in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2443:13
> #13 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #14 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> #15 0x2086c1b in cplus_demangle_type 
> binutils-gdb/libiberty/./cp-demangle.c:2443:13
> #16 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #17 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> ...
> #250 0x20c622b in d_bare_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2932:21
> #251 0x209f2df in d_function_type 
> binutils-gdb/libiberty/./cp-demangle.c:2856:9
> 
> SUMMARY: AddressSanitizer: stack-overflow 
> binutils-gdb/libiberty/./cp-demangle.c:2367 in cplus_demangle_type

We do fuzz testing on the 15th OCT commit verison of
binutils(dc86962bf15e7b8dfdcebc17d83b9b48be0bd9cb). And we have also confirmed
this in the release version 2.31.
Please use the “./c++filt < $POC -t” to reproduce the bug. (Remember to add
"-t" option and "<" Symbol)

[Bug libstdc++/87619] sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX

[ville at gcc dot gnu.org]

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

--- Comment #1 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Oct 17 19:08:51 2018
New Revision: 265247

URL: https://gcc.gnu.org/viewcvs?rev=265247=gcc=rev
Log:
PR libstdc++/87619

* include/std/variant (__select_index): Fix an off-by-one.
* testsuite/20_util/variant/87619.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/variant/87619.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug libstdc++/87619] sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |FIXED

--- Comment #2 from Ville Voutilainen  ---
Fixed.

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I think Jakub's patch does only allow __gnu__, using the same canonicalization
for attribute-namespaces as for attributes.

[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||rguenth at gcc dot gnu.org

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

[Bug preprocessor/87630] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Duplicate of 87562.

*** 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

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

--- Comment #3 from David Malcolm  ---
(In reply to Renlin Li from comment #2)
> I checked that, the ICE starts from r264887.

Thanks.

I'm now able to reproduce this; am attempting to reduce the reproducer.

[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Doesn't seem like a bug in the compiler.

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
If both __gnu__ and __gnu are accepted, should both __aligned__ and __aligned
also be?  If not, then should only __gnu__ be accepted?

[Bug libstdc++/87635] New: backport of cmath patches to gcc 48 for Darwin incomplete cmath

[rm at gnu dot org]

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

Bug ID: 87635
   Summary: backport of cmath patches to gcc 48 for Darwin
incomplete cmath
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rm at gnu dot org
  Target Milestone: ---

Created attachment 44849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44849=edit
set of patches (configure, header) without ChangeLog patch

I backported the patches of this commit:

https://gcc.gnu.org/viewcvs/gcc?view=revision=244231

which references this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017

The support for this is very useful for compiling larger software which still
needs gcc 48, as is the case of TenFourFox!
Compared to the referenced bug, the issue is not PPC only, but also x86!

I would also plan backporting to gcc6.

The backport has been applied and tested and solves the issue.
I did run the test suite before and after and there are no changes (no
regressions, no fixes).

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rogerio.souza at gmail dot com]

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

--- Comment #50 from Rogério de Souza Moraes  
---
Created attachment 44848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44848=edit
GCC 6.3.0 consolidated patch based on Richard's patches

The patch attached is a backport based on Richard's patches to GCC v6.3.0. If
any issues, please let me know.

Regards,
--
Rogerio

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Thanks for reporting the problem.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Oct 17 17:54:26 2018
New Revision: 265245

URL: https://gcc.gnu.org/viewcvs?rev=265245=gcc=rev
Log:
PR middle-end/87623
* fold-const.c (fold_truth_andor_1): If the right side is not constant,
bail out if both sides do not have the same storage order.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr87623.c
  - copied unchanged from r265242,
trunk/gcc/testsuite/gcc.c-torture/execute/pr87623.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Oct 17 17:53:02 2018
New Revision: 265244

URL: https://gcc.gnu.org/viewcvs?rev=265244=gcc=rev
Log:
PR middle-end/87623
* fold-const.c (fold_truth_andor_1): If the right side is not constant,
bail out if both sides do not have the same storage order.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/pr87623.c
  - copied unchanged from r265242,
trunk/gcc/testsuite/gcc.c-torture/execute/pr87623.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Oct 17 17:52:10 2018
New Revision: 265243

URL: https://gcc.gnu.org/viewcvs?rev=265243=gcc=rev
Log:
PR middle-end/87623
* fold-const.c (fold_truth_andor_1): If the right side is not constant,
bail out if both sides do not have the same storage order.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr87623.c
  - copied unchanged from r265242,
trunk/gcc/testsuite/gcc.c-torture/execute/pr87623.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Oct 17 17:49:28 2018
New Revision: 265242

URL: https://gcc.gnu.org/viewcvs?rev=265242=gcc=rev
Log:
PR middle-end/87623
* fold-const.c (fold_truth_andor_1): If the right side is not constant,
bail out if both sides do not have the same storage order.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr87623.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

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

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Untested patch:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8914,7 +8914,7 @@ resolve_select_type (gfc_code *code, gfc_namespace
*old_ns)
   if (ref2)
{
  if (code->expr1->symtree->n.sym->attr.untyped)
-   code->expr1->symtree->n.sym->ts = ref->u.c.component->ts;
+   code->expr1->symtree->n.sym->ts = ref2->u.c.component->ts;
  selector_type = CLASS_DATA (ref2->u.c.component)->ts.u.derived;
}
   else

[Bug c++/87634] New: CSE for dynamic_cast

[Simon.Richter at hogyros dot de]

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

Bug ID: 87634
   Summary: CSE for dynamic_cast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

With the code

struct A { virtual void foo() = 0; };

struct B : A { virtual void foo() {} void bar() const; };

void test(A *a)
{
if(auto b = dynamic_cast(a))
b->bar();
if(auto b = dynamic_cast(a))
b->bar();
}

I'd expect the type of the object to be unchanged between the two
`dynamic_cast` invocations, so the second type check would be unnecessary. The
generated code does two checks, however.

It is in theory possible to replace the object in-place with one of different
type if it is also accessible through a global pointer from within `B::bar()`,
but is this a good enough reason to repeat the type check, or would it be
possible to optimize out the second dynamic_cast<> here?

[Bug rtl-optimization/78127] [6 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Wilco from comment #6)
> (In reply to Vladimir Makarov from comment #3)
> > Author: vmakarov
> > Date: Thu Feb 16 19:47:15 2017
> > New Revision: 245514
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=245514=gcc=rev
> > Log:
> > 2017-02-16  Vladimir Makarov  
> > 
> > PR rtl-optimization/78127
> > * lra.c (lra): Call lra_eliminate before finish the loop after
> > lra_constraint.
> > 
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/lra.c
> 
> Vlad, would it be safe to backport this?

Yes, I think it is safe.

[Bug libstdc++/87619] sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-17
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86

[bugdal at aerifal dot cx]

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

--- Comment #4 from Rich Felker  ---
Thanks, that's helpful!

For 64-bit what I mean is that it emits:

  pushq %r12
  movl %edx, %r12d
  pushq %rbp
  movl %esi, %ebp
  pushq %rbx
  movl %edi, %ebx
  call bar
  movl %r12d, %edx
  movl %ebp, %esi
  movl %ebx, %edi
  popq %rbx
  popq %rbp
  popq %r12
  jmp bah

whereas it would be much more efficient to do:

  pushq %rdx
  pushq %rsi
  pushq %rdi
  call bar
  popq %rdi
  popq %rsi
  popq %rdx
  jmp bah

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

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
(In reply to Jürgen Reuter from comment #0)
> There is a new ICE, most likely introduced by r265232, r265134 was still
> working. I will add a reproducer after lunch.

Why most likely :-) ?

There is also: r265171 & r265175

50:50 me and Tobias - I look forward to your reduction.

Thanks

Paul

[Bug tree-optimization/80155] [7/8/9 regression] Performance regression with code hoisting enabled

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #43 from prathamesh3492 at gcc dot gnu.org ---
Sorry for duplications / formatting errors in previous comment. Is there a way
to edit posted comments ?

Thanks,
Prathamesh

[Bug tree-optimization/80155] [7/8/9 regression] Performance regression with code hoisting enabled

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #42 from prathamesh3492 at gcc dot gnu.org ---
Hi,
This is another simpler approach I tried to apply "cost-model" on hoisting
before approaching a more general solution:
http://people.linaro.org/~prathamesh.kulkarni/hoist-change-order.diff
In this prototype patch, I changed order of hoisting such that instead hoisting
an expression in first candidate block, it hoists expression one dominator at a
time.

For pr77445-2.c test-case, str_225 + 1 gets hoisted in block 10 because it's
the first candidate block found from the top-down dom-tree walk, which leaves
little room for controlling hoisting.
The patch forces expressions to be inserted in immediate dominator at a time
instead of the first candidate block. With this change, the following series of
hoistings take place for str_225 + 1:

Inserting expression in block 15 for code
hoisting:{pointer_plus_expr,str_225,1} (0079)
Inserting expression in block 14 for code hoisting:
{pointer_plus_expr,str_225,1} (0079)
Inserting expression in block 11 for code hoisting:
{pointer_plus_expr,str_225,1} (0079)
Inserting expression in block 10 for code hoisting:
{pointer_plus_expr,str_225,1} (0079)
Inserting expression in block 53 for code hoisting:
{pointer_plus_expr,str_225,1} (0079)

str_225 + 1 originally appears in blocks 16 and 17. It is then first hoisted
into their predecessor block 15, then into block 14 and so on. The advantage I
see with this order of hoisting is, we can control hoisting after each
insertion in it's immediate dominator. So for instance if according to our cost
model, we reach "hoisting threshold" after say block 14, we can then prevent
further hoistings of str_225 + 1. Whereas with the current approach it gets
hoisted right up to block 10 initially. Alternatively we could try to "sink"
the expression down to dominated blocks. I didn't explore this option yet.

* Cost model for hoisting
The cost model would be entirely target specific defined by a target hook and
shouldn't affect other architectures that don't wish to use it. I suppose a
very simple cost model for hoisting could take following two factors:
a) Number of hoistings of a particular expression measured in terms of
dominator depth - This is recorded by expr_hoist_map which is map the former representing value number of pre_expr and latter
represents the count.
b) Number of insertions in basic block - This is recorded by map, the former representing block index and latter represents the count.

I didn't attempt to define the cost-model in the patch. I was wondering what
could be other potential factors that we can consider ?

* Issues with changing hoisting order
I am not entirely sure if the result of changing hoisting order can result in
correctness issues or missed optimizations ? For some confidence, I validated
the patch with bootstrap+test on x86_64, which worked.

There are two problems I see:
(1) Interference with statistics of hoisting, which is easy to fix.
(2) Does not honor the "expression should be available in at least one
successor" constraint, which leads to more aggressive hoisting for
architectures that will not use cost model. In example above, str_225 + 1 got
hoisted one block further upto block-53, while with current-order it's
restricted to block-10. I suppose we could fix this by recording which
expressions were originally available at end of block ?

The patch passes bootstrap+test on x86_64.

* Hoistings crossing loop boundary - One "peculiarity" I see with FMS function
in pr77445-2.c is that all the hoistings cross loop boundaries at one point,
while other tests have significantly lesser.
I did a quick test with SPEC2006 to collect some data:
(number-of-hoistings vs number-of-functions)
{2: 89, 1: 166, 3: 37, 4: 14, 5: 8, 6: 10, 7: 11, 8: 2, 13: 3, 10: 1, 11: 5, 9:
4, 17: 1, 15: 2, 27: 1, 12: 2, 18: 1, 21: 1, 26: 1}

It seems most of the functions have cross loop hoistings less than 5 with 166
functions having one hoisting inside loop and 89 functions having two hoistings
across loops. I was wondering if a hoisting into a block from it's successor
should have "extra penalty" if it crosses a loop boundary ? Or does hoisting
inside a loop have no effect on register pressure ?

Thanks,
Prathamesh

[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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 44847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44847=edit
First (long) reproducer

This is a first "complete" reproducer. I will boil it down now.

[Bug c++/87633] ice in compare_range_wit h_value, at vr-values.c:1702

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code seems to be:

class a {
public:
  double b() const;
};
class c {
public:
  int m_fn2() const;
};
double a::b() const {
  return 0 == 0 ? reinterpret_cast(this)->m_fn2() : 0;
}
bool d;
void e() {
  a f;
  double g = f.b();
  d = __builtin_isnan(g);
}

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 44846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44846=edit
gcc9-pr86288.patch

Untested patch with implementation for this enhancement request as well as fix
for the above mentioned ICE (the latter should be backported I guess).

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Unrelated note, we even ICE on
int f [[using gnu : __aligned__(alignof(int))]];

[Bug c++/87469] [9 Regression] ice in record_estimate, at tree-ssa-loop-niter.c:3271

[kugan at gcc dot gnu.org]

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

--- Comment #4 from kugan at gcc dot gnu.org ---
In the loop here, the value defined in the loop (e) is used outside the loop
hence this should not be detected as popcount (AFIK). I will have a look at
fixing this.

[Bug c++/87631] new attribute for passing structures with multiple SIMD data members in registers

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  ---
My (current) use case is structures (nested) of builtin types and vector types.
These structures have a trivial copy constructor.


Generalization
---

I believe generalization of this approach should be possible, but I'm not sure
how useful it would be. E.g.

  struct [[gnu::pass_via_register]] A {
int a;
std::vector b;
  };

  void f(A);

could call f by "unpacking" A and call f'(int, std::vector). I believe the
effort of supporting types with non-trivial copy ctor is not worth the effort
(such types are typically passed via const-ref anyway).


What I believe is worthwhile
-

pass_via_register (max_registers)
  This attribute, attached to a struct type definition, specifies that function
arguments and function return values are passed via up to max_registers
registers, thus potentially using a different calling convention.

  If the number of registers required for passing a value exceeds
max_registers, the default calling convention is used instead. Specifically,
`struct S { int a, b, c; } __attribute__((pass_via_register(1)));` may still
pass via two registers  if it would do so without the attribute.

  If a structure has a single non-static data member of a type declared with
the pass_via_register attribute, the attribute is also applied to the outer
structure:

struct S { ... } __attribute__((pass_via_register(4)));
struct inherited { S x; };  // implicit pass_via_register(4)

If a structure has two or more non-static data members the resulting type does
not inherit the pass_via_register attribute.

  You may only specify this attribute on the definition of a struct, not on a
typedef that does not also define the structure.


Example from std::experimental::simd
-

using V = simd>;

This essentially asks for { __m128[2] }, similar to `float
attribute((vector_size(32)))` when AVX is not available, except that I'd like
to pass arguments and return values via registers:

V f(V x, V y);

Function f reads x from %xmm0 and %xmm1, y from %xmm2 and %xmm3, and returns
via %xmm0 and %xmm1.

The simd class would be defined like this (note that `simd` itself would not
have the attribute):

template  class member_type;
template 
class [[gnu::pass_via_register(4)]] member_type> {
  using V [[gnu::vector_size(16)]] = float;
  V data[N];
};

template  class simd {
  member_type data;
};

simd inherits the pass_via_register(4) attribute from its data member because
it has only one data member.


ill-formed
---

I'd make the following ill-formed:

struct [[gnu::pass_via_register]] A {
  A(const A &);
};

The non-trivial copy ctor clashes with pass_via_register.


dropping the attribute
---

Example:

struct X {
  simd> a;
  int b;
};

a is pass_via_register, b in principle is pass_via_register (on x86_64), but X
is not (two or more non-static data members). The default calling convention
applies.


implementation strategy


I don't see how the frontend could reliably implement the attribute. Does the
frontend know whether a certain type is passed via register (and how many)?
E.g. `void f(int)` passes via the stack on i686. `struct S { int a, b; };`
passes via a single register on x86_64, unpacking `f(S)` to `f(int, int)` would
be suboptimal.

[Bug fortran/87622] coarray does not run in parallel

[klein at cage dot ugent.be]

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

--- Comment #5 from Andreas Klein  ---
On Wed, 17 Oct 2018, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87622
>
> --- Comment #2 from Thomas Koenig  ---
> Some more remarks: In a benchmark, it is best to actually fill the values of
> all read variables to something defined, for example with a call to
> random_number. Also, if you generate values which you do not use later, the
> compilet may decide to remove the calculation altogether. What works well for
> this somethinh like
>
> read (*,*) i,j
> print *, a(i,j)
>
Adding initialzation removes the effect.
There is still a 20% decresed performance, but that are plausible cache 
effects.

Sorry my minimal example was to minimal. I derived the mini example from a 
big parallel linear algebra package. Now I must go throgh all 
minimalization steps, but its possible that the original error has nothing 
to do with coarrays.

This Week’s Fuel Prices

[MEDCO sal]

This Week’s Fuel Prices
if you can’t see the image below you can find it here 
(https://gfcmedia.com/medco/)

https://gfcmedia.com/medco/

Energetically Yours, MEDCO

To Stop Receiving our Emails, Please Reply with: REMOVE

( Some emails are scheduled in advanced, remove may take up some time )

Sent by GFC.media (https://gfcmedia.com/medco)   |  Unsubscribe 
(https://gfcmedia.com/register/)   |  Report Spam 
(https://gfcmedia.com/register/)

http://gfcmedia.com/
Send your emails with GFC and reach more audience
Beirut (+961) 71 629 666  Dubai (+971) 5  5 338

Disclaimer: GFC is not responsible for any contents linked to this email, as 
they are only related to the advertiser and do not represent GFC in any way.

This email was sent to gcc-bugs@gcc.gnu.org (mailto:gcc-bugs@gcc.gnu.org)
why did I get this? 
(https://battleparkae.us19.list-manage.com/about?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120=d024c643c8)
 unsubscribe from this list 
(https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120=d024c643c8)
 update subscription preferences 
(https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120)
BP AE . UAE . Dubai  . United Arab Emirates

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/65174] noexcept() returns true when operator delete with the object that has a throwing destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-17
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Hmm, interesting. When the operand of the delete expression is null the
> destructor is not invoked, so it can't throw.

That's C++11 [expr.delete] p6

  If the value of the operand of the delete-expression is not a null pointer
  value, the delete-expression will invoke the destructor (if any) for the
  object or the elements of the array being deleted.

> It's not obvious to me whether
> GCC's result is allowed by the standard or not.

The question is whether GCC is correct to determine that the unevaluated
operand of the noexcept operator will not invoke a destructor. Although it's
true that it won't throw, deciding that seems to involve some evaluation of the
unevaluated operand.

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  ---
(In reply to Jürgen Reuter from comment #10)
> Paul, I think this "bugfix" introduced an ICE in our code. I will open a new
> PR.

Seemingly, it's PR 87632

[Bug c++/87633] New: ice in compare_range_wit h_value, at vr-values.c:1702

[dcb314 at hotmail dot com]

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

Bug ID: 87633
   Summary: ice in compare_range_wit h_value, at vr-values.c:1702
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 44845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44845=edit
gzipped C++ source code

For the attached C++ code, compiled by recent gcc trunk
and compiler flag -O2, does this:

during GIMPLE pass: evrp
../deps/v8/src/builtins.cc: In function ‘v8::internal::Object*
v8::internal::{an
onymous}::Slow_ArrayConcat(v8::internal::Arguments*,
v8::internal::Handle, v8::internal::Isolate*)’:
../deps/v8/src/builtins.cc:4956:1: internal compiler error: in
compare_range_wit
h_value, at vr-values.c:1702
0xe9aae1 compare_range_with_value(tree_code, value_range*, tree_node*, bool*)
../../trunk/gcc/vr-values.c:1702
0xe9a518 vr_values::compare_name_with_value(tree_code, tree_node*, tree_node*,
b
ool*, bool)
../../trunk/gcc/vr-values.c:2106

The problem seems to occur between revisions 265077 and 265139.

I'll have my usual go at reducing the code.

[Bug c++/29164] Overloaded operator delete[] doesn't get called

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
  Known to fail||

--- Comment #11 from Jonathan Wakely  ---
C++03 [expr.delete] p2:

> In either alternative, if the value of the operand of delete is the null
> pointer the operation has no effect.

That wording was changed by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#348

C++11 [expr.delete] p7:

> If the value of the operand of the delete-expression is not a null pointer
> value, the delete-expression will call a deallocation function (3.7.4.2).
> Otherwise, it is unspecified whether the deallocation function will be
> called.

So in C++03 the delete expressions "have no effect" but that was clarified to
mean that the deallocation functions might not be called, which makes GCC's
behaviour correct.

Prior to r259772 ("PR c++/61982 - dead stores to destroyed objects") GCC was
inconsistent, calling the operator for "delete[] p" but not "delete[] p". Now
it matches Clang's behaviour and neither calls the operator when p is null.

I don't think there's any bug here anyway.

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #12 from asmwarrior  ---
Hi, (In reply to Jonathan Wakely from comment #11)
> Does this code still get miscompiled with GCC 6 and newer?

Hi, I'm now using mingw-build i686-7.2.0-release-posix-dwarf-rt_v5-rev1, which
was downloaded from:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/dwarf/i686-7.2.0-release-posix-dwarf-rt_v5-rev1.7z/download

I don't see such crash bug since 2018-02-09. (See this post in C::B forum:
http://forums.codeblocks.org/index.php/topic,22198.msg152596.html#msg152596)

[Bug rtl-optimization/78127] [6 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
(In reply to Vladimir Makarov from comment #3)
> Author: vmakarov
> Date: Thu Feb 16 19:47:15 2017
> New Revision: 245514
> 
> URL: https://gcc.gnu.org/viewcvs?rev=245514=gcc=rev
> Log:
> 2017-02-16  Vladimir Makarov  
> 
>   PR rtl-optimization/78127
>   * lra.c (lra): Call lra_eliminate before finish the loop after
>   lra_constraint.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/lra.c

Vlad, would it be safe to backport this?

[Bug rtl-optimization/71779] [6 regression] isl miscompiled with -mabi=ilp32

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #27 from Wilco  ---
(In reply to Eric Gallager from comment #26)
> (In reply to Steve Ellcey from comment #24)
> > So should the patch be backported to the 5/6 branches?
> 
> (In reply to Jakub Jelinek from comment #25)
> > GCC 5 branch is being closed
> 
> Well, okay, so not 5, but what about 6 though? Last chance for that...

Yes this should be backported.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|[9.0 regression] ICE|[9 regression] ICE
   |segmentation fault in f951  |segmentation fault in f951

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #7 from Wilco  ---
(In reply to Bernd Edlinger from comment #6)
> Author: edlinger
> Date: Thu Aug  4 13:20:57 2016
> New Revision: 239122
> 
> URL: https://gcc.gnu.org/viewcvs?rev=239122=gcc=rev
> Log:
> 2016-08-04  Bernd Edlinger  
> 
> PR rtl-optimization/70903
> * cse.c (cse_insn): If DEST is a paradoxical SUBREG, don't record
> DEST.
> 
> testsuite:
> 2016-08-04  Bernd Edlinger  
> 
> PR rtl-optimization/70903
> * gcc.c-torture/execute/pr70903.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.c-torture/execute/pr70903.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/cse.c
> trunk/gcc/testsuite/ChangeLog

This should be backported to GCC6/7.

[Bug c++/87631] new attribute for passing structures with multiple SIMD data members in registers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|other   |c++
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
Note this will need target adjustments unless we go the
targetm.split_complex_arg
way of this (which is esp. ugly and should have been done in the regular ABI
handling way).

The other possibility would be of course to have the FEs handle this
attribute by adjusting calls and prototypes to this argument passing
convention accordingly.

Please specify how that attribute would work semantically and how you'd
name it and where you'd use it?  Sth like

struct X1 { V a, b; } __attribute__((pass_by_value_as_two_vector_args));

struct X2 { V a, b; int x } __attribute__((pass_by_value_as_two_vector_args));
// invalid

?  Or more general

struct X { ... } __attribute__((pass_by_value_as_pieces));

where individual fields are passed instead of the aggregate?  Does that
then mean individual copy-ctors need to be available for the members for
example?

[Bug fortran/87632] New: [9.0 regression] ICE segmentation fault in f951

[juergen.reuter at desy dot de]

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

Bug ID: 87632
   Summary: [9.0 regression] ICE segmentation fault in f951
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

There is a new ICE, most likely introduced by r265232, r265134 was still
working. I will add a reproducer after lunch.

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[juergen.reuter at desy dot de]

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

--- Comment #10 from Jürgen Reuter  ---
Paul, I think this "bugfix" introduced an ICE in our code. I will open a new
PR.

[Bug other/87631] New: new attribute for passing structures with multiple SIMD data members in registers

[kretz at kde dot org]

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

Bug ID: 87631
   Summary: new attribute for passing structures with multiple
SIMD data members in registers
   Product: gcc
   Version: 9.0
   URL: https://godbolt.org/z/M-zEpR
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Consider:

using V [[gnu::vector_size(16)]] = float;

struct X1 { V a; };
struct X2 { V a, b; };

X1 f1(X1 x) { return x; }
X2 f2(X2 x) { return x; }

f1 is typically more efficient at the call site and in the function itself,
since it doesn't have to do the stores to & loads from the stack. The user
still has a choice: Using const-ref, the function arguments can still be passed
via memory.

f2 leaves the user no choice, every object of X2 is unconditionally passed via
memory. If the vector_size attribute is removed, however, objects of X2 are
still passed via registers. I propose a new attribute (e.g.
"pass_via_register"), potentially with an argument that limits the number of
registers it may use (useful for generic types), that would modify the ABI of
such types to have them passed via registers. Consequently, f2 could also
compile to a single "ret".

Note, I would like to use this feature in the implementation of
std::experimental::simd.

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
> I would guess optimize_bit_field_compare or friends in fold-const.c wreck
> this.

It's the coaslescing done in fold_truth_andor_1.

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|jason at gcc dot gnu.org   |

--- Comment #12 from Paolo Carlini  ---
Can we close this?

[Bug fortran/87622] coarray does not run in parallel

[klein at cage dot ugent.be]

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

--- Comment #4 from Andreas Klein  ---
On Wed, 17 Oct 2018, burnus at gcc dot gnu.org wrote:
>
> If "b" (and "a") are allocated in some slower memory part, it matters how one
> sums over the variables in the matmul loop.

I know that there are difference in speed. But a factor 2 is realy large 
and should not happen. I created the example as a minimal 
example. I observerd similar problems in almost every coarray program I 
have tried. The result is always that the use coarrays of brings not the 
desired speed up and is just a wast of resouces.

[Bug preprocessor/87630] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug preprocessor/87630] New: [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[rguenth at gcc dot gnu.org]

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

Bug ID: 87630
   Summary: [9 Regression] ICE in
linemap_position_for_line_and_column, at
libcpp/line-map.c:842
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44844=edit
unreduced testcase

Recently 502.gcc started to fail with

> gcc -std=gnu99 -m64 -c -o dbxout.o -DSPEC -DNDEBUG -I. -I./include 
> -I./spec_qsort -DSPEC_502 -DSPEC_AUTO_SUPPRESS_OPENMP -DIN_GCC 
> -DHAVE_CONFIG_H  -Ofast -g -march=native -mtune=native 
> -mprefer-vector-width=128-fgnu89-inline   -DSPEC_LP64  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:842
  508 | dbxout_stab_value_internal_label (const char *stem, int *counterp)
  | ^~~~
0x15d3cdb linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
../../trunk/libcpp/line-map.c:842
0x15d3cdb linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
../../trunk/libcpp/line-map.c:837
0x15b6eaa get_substring_ranges_for_loc
../../trunk/gcc/input.c:1464
0x15b7684 get_source_location_for_substring(cpp_reader*, string_concat_db*,
unsigned int, cpp_ttype, int, int, int, unsigned int*)
../../trunk/gcc/input.c:1517
0x80c22f c_get_substring_location(substring_loc const&, unsigned int*)
../../trunk/gcc/c-family/c-common.c:861
0xccc7a4 substring_loc::get_location(unsigned int*) const
../../trunk/gcc/substring-locations.c:284
0xccc7a4 format_string_diagnostic_t::emit_warning_n_va(int, unsigned long, char
const*, char const*, __va_list_tag (*) [1]) const
../../trunk/gcc/substring-locations.c:156
0x14966f8 fmtwarn
../../trunk/gcc/gimple-ssa-sprintf.c:472
0x1497b5e maybe_warn
../../trunk/gcc/gimple-ssa-sprintf.c:2706
0x1497b5e format_directive
../../trunk/gcc/gimple-ssa-sprintf.c:2822
0x149b89c compute_format_length
../../trunk/gcc/gimple-ssa-sprintf.c:3502
0x149b89c handle_gimple_call
../../trunk/gcc/gimple-ssa-sprintf.c:3988
0x149cd5d before_dom_children
../../trunk/gcc/gimple-ssa-sprintf.c:4027
0x145a4c2 dom_walker::walk(basic_block_def*)
../../trunk/gcc/domwalk.c:353
0x14963cb execute
../../trunk/gcc/gimple-ssa-sprintf.c:4053
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Does this code still get miscompiled with GCC 6 and newer?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #37 from Eric Botcazou  ---
> Would this be a better approach?

Probably not much.  So let's go with your kludge from comment #19 but with a
comment giving the rationale for putting it in.

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-17
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.3.1, 8.2.1, 9.0

--- Comment #2 from Eric Botcazou  ---
Confirmed with all tested compilers.

[Bug c++/81055] [6/7 Regression] ICE with invalid initializer for array new

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[vinay.m.engg at gmail dot com]

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

Vinay Kumar  changed:

   What|Removed |Added

 CC||vinay.m.engg at gmail dot com

--- Comment #1 from Vinay Kumar  ---
Hi,

The current exists in latest trunk sources also. Please let me know is there
any progress on this.

Regards,
Vinay

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #16 from Paolo Carlini  ---
Just an error-recovery issue, too invasive for the branch.

[Bug fortran/87622] coarray does not run in parallel

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
On the coarray library interaction, we have:
* On startup:
  - the coarray library is initialized
  - both coarrays are registed with the library
i.e. the library allocates the memory for the program
* At the end: the coarray library is told to finish


Otherwise, the program itself just calls _gfortran_matmul_r4.

The memory for variable "c" is in static memory while "a" and "b" are allocated
by the coarray run-time library.

If "b" (and "a") are allocated in some slower memory part, it matters how one
sums over the variables in the matmul loop.

For instance, for A = BC, one can calculate it as:
   a(i,j) = sum_k b(i,k)c(k,j)
in that case, b(i,:) is contiguous in memory (which is faster) and c(:,j) is
not (which is slower).  [I have not checked in which order _gfortran_matmul_r4
calculates that the loop.]

In the simplest case, the memory of "B" is slower because part of the page is
accessed by two processors and it keeps getting kicked out of the level 1 or
level 2 cache - and, hence, needs to be loaded from the the L3/L4 cache or the
normal RAM.

Besides those reasons, there is also an overhead of generating multiple jobs
and synchronizing them - i.e. waiting until all processes have called "init"
and all processes have called "finished" in the library. - With many processes,
this overall barrier (all waiting for all) might take a very sizable amount of
the total run time.

For 1 vs. 2 jobs, it should be negligible but still some libraries have an
explicit short cut for 1 job.

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #49 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 17 08:49:00 2018
New Revision: 265235

URL: https://gcc.gnu.org/viewcvs?rev=265235=gcc=rev
Log:
2018-10-16  Richard Biener  

Backport from mainline
2018-10-08  Richard Biener  

PR tree-optimization/63155
* tree-ssa-propagate.c (add_ssa_edge): Do cheap check first.
(ssa_propagation_engine::ssa_propagate): Remove redundant
bitmap bit clearing.

2018-10-05  Richard Biener  

PR tree-optimization/63155
* tree-ssa-ccp.c (ccp_propagate::visit_phi): Avoid excess
vertical space in dumpfiles.
* tree-ssa-propagate.h
(ssa_propagation_engine::process_ssa_edge_worklist): Remove.
* tree-ssa-propagate.c (cfg_blocks_back): New global.
(ssa_edge_worklist_back): Likewise.
(curr_order): Likewise.
(cfg_blocks_get): Remove abstraction.
(cfg_blocks_add): Likewise.
(cfg_blocks_empty_p): Likewise.
(add_ssa_edge): Add to current or next worklist based on
RPO index.
(add_control_edge): Likewise.
(ssa_propagation_engine::process_ssa_edge_worklist): Fold
into ...
(ssa_propagation_engine::ssa_propagate): ... here.  Unify
iteration from CFG and SSA edge worklist so we process
everything in RPO order, prioritizing forward progress
over iteration.
(ssa_prop_init): Allocate new worklists, do not dump
immediate uses.
(ssa_prop_fini): Free new worklists.

2018-09-24  Richard Biener  

PR tree-optimization/63155
* tree-ssa-propagate.c (add_ssa_edge): Avoid adding PHIs to
the worklist when the edge of the respective argument isn't
executable.

Modified:
branches/gcc-8-branch/gcc/tree-ssa-ccp.c
branches/gcc-8-branch/gcc/tree-ssa-propagate.h

[Bug c++/87629] New: 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

Bug ID: 87629
   Summary: function template parameter deduction succeeds but
parameter and deduced arg does not match.
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

This bug is present in all gcc versions.

Consider the following code:

template
struct x{
x(void(*)(int));
};

void foo(int);

template
void Tfoo(T);

template
void x_func(x a);

void test(){
  x_func(foo);   //does not compile => standard compliant
  x_func(Tfoo); //compile! template deduction + conversion => not standard
compliant
  }

`x_func(Tfoo)` compiles, but this violate this standard rule
[\[temp.deduct.call\]/4](http://eel.is/c++draft/temp.deduct#call-4) which
states that the deduced function argument type shall match (almost) the type of
the argument:

In general, the deduction process attempts to find template argument values
that will make the deduced A identical to A (after the type A is transformed as
described above).
However, there are three cases that allow a difference:

>  - If the original P is a reference type, the deduced A (i.e., the type 
> referred to by the reference) can be more cv-qualified than the transformed A.

>  - The transformed A can be another pointer or pointer-to-member type that 
> can be converted to the deduced A via a function pointer conversion and/or 
> qualification conversion.

>  - If P is a class and P has the form simple-template-id, then the 
> transformed A can be a derived class of the deduced A. Likewise, if P is a 
> pointer to a class of the form simple-template-id, the transformed A can be a 
> pointer to a derived class pointed to by the deduced A.

See also this stackoverflow
question:https://stackoverflow.com/q/52845621/5632316

[Bug fortran/87622] coarray does not run in parallel

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Some more remarks: In a benchmark, it is best to actually fill the values of
all read variables to something defined, for example with a call to
random_number. Also, if you generate values which you do not use later, the
compilet may decide to remove the calculation altogether. What works well for
this somethinh like

read (*,*) i,j
print *, a(i,j)

at the end and then invoke the progtam with

echo 1 1 | ./a.out

And, of course, please supply the timings.

[Bug c++/87469] [9 Regression] ice in record_estimate, at tree-ssa-loop-niter.c:3271

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
It seems that kugan wrote the revision that broke it, but the bug is
unassigned.

I'd be interested to find the process to re-assign.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ebotcazou at gcc dot gnu.org
  Component|tree-optimization   |middle-end
  Build|gcc version 8.2.0 (Gentoo   |
   |8.2.0-r3 p1.4)  |

--- Comment #1 from Richard Biener  ---
I would guess optimize_bit_field_compare or friends in fold-const.c wreck this.

[Bug c++/84705] [6/7/8 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Note, the cp/ change in fact is in tree.c:
https://gcc.gnu.org/viewcvs/gcc?view=revision=265234

[Bug ipa/87624] improve interprocedural clean up of null pointer checks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
IIRC IPA-VRP simply looks at the SSA name range info rather than being a
true (non-iterating) "propagation" that would come up with context sensitive
info.

[Bug fortran/87622] coarray does not run in parallel

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
There could be interaction from cache interaction, or from something regarding
coarrays and the matmul library funczions.

Can you supply some more details such as compiler options, compiler version,
CPU type, MPI version etc? And do you have the possibility of monitoring cache
misses?

[Bug c++/84705] [6/7/8 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
Summary|[6/7/8/9 Regression]|[6/7/8 Regression] internal
   |internal compiler error: in |compiler error: in
   |add_stmt, at|add_stmt, at
   |cp/semantics.c:390  |cp/semantics.c:390

--- Comment #6 from Paolo Carlini  ---
Done.

[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-17
Version|unknown |9.0
 Ever confirmed|0   |1

[Bug c++/87628] Redundant check of pointer when operator delete is called

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  IIRC there are duplicates of this bug.

[Bug c++/84705] [6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 17 07:32:15 2018
New Revision: 265233

URL: https://gcc.gnu.org/viewcvs?rev=265233=gcc=rev
Log:
/cp
2018-10-17  Paolo Carlini  

PR c++/84705
* init.c (build_cplus_new): Avoid duplicate diagnostic about
incomplete type, early return error_mark_node if the second
argument is error_mark_node.

/testsuite
2018-10-17  Paolo Carlini  

PR c++/84705
* g++.dg/cpp0x/pr84705.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr84705.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev
Log:
2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_44.f90
trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev
Log:
2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_44.f90
trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev
Log:
2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_44.f90
trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev
Log:
2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_44.f90
trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Wed Oct 17 07:16:16 2018
New Revision: 265232

URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev
Log:
2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.

2018-10-17  Paul Thomas  

PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_44.f90
trunk/gcc/testsuite/gfortran.dg/select_type_45.f90
trunk/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #48 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 17 07:01:28 2018
New Revision: 265231

URL: https://gcc.gnu.org/viewcvs?rev=265231=gcc=rev
Log:
2018-10-17  Richard Biener  

Backport from mainline
2018-10-08  Richard Sandiford  

PR middle-end/63155
* gimple-ssa-backprop.c (backprop::intersect_uses): Use
FOR_EACH_IMM_USE_FAST instead of FOR_EACH_IMM_USE_STMT.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-backprop.c

[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
Noticed this back when working on -fno-plt patches:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00229.html

Emitting a tailcall on RTL drops REG_EQUIV notes (perhaps because in the
general case equivalences might not hold just before the sibcall when the new
arguments are being prepared), and this penalizes code generation for the whole
function.

I'm not sure why you say "Results are similarly bad for 64-bit", there's
nothing to improve in this example with three arguments all of which are on
registers and thus need to be somehow saved/restored anyway?