[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jbassett271 at gmail dot com]

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

Justin Bassett  changed:

   What|Removed |Added

 CC||jbassett271 at gmail dot com

--- Comment #13 from Justin Bassett  ---
Reconfirmed with GCC 9.1, from this Stack Overflow question:
https://stackoverflow.com/questions/57315054/unable-to-use-ternary-operator-to-conditionally-assign-istream/57315456

Some variants:

https://godbolt.org/z/gcnglB (GCC 9.1)

class Foo
{
public:
Foo(int& i)
: i{i > 0 ? i : throw "invalid"} 
{}

private:
int& i;
};

Error:

: In constructor 'Foo::Foo(int&)':
:6:40: error: cannot bind non-const lvalue reference of type 'int&' to
an rvalue of type 'int'
6 | : i{i > 0 ? i : throw "invalid"}
  |^


This one changed from GCC 8.3 and GCC 9.1, which I'm guessing is due to the
work by Jason Merrill:

https://godbolt.org/z/DfKGg4



struct no_copy {
no_copy(no_copy const&) = delete;

bool valid() const;
};

class Foo
{
public:
Foo(no_copy& it)
: it{it.valid() ? it : throw "invalid"} 
{}

private:
no_copy& it;
};



GCC 9.1:

: In constructor 'Foo::Foo(no_copy&)':
:11:47: error: cannot bind non-const lvalue reference of type
'no_copy&' to an rvalue of type 'no_copy'
   11 | : it{it.valid() ? it : throw "invalid"}
  |   ^


GCC 8.3:

: In constructor 'Foo::Foo(no_copy&)':
:11:38: error: use of deleted function 'no_copy::no_copy(const
no_copy&)'
 : it{it.valid() ? it : throw "invalid"}
  ^
:2:5: note: declared here
 no_copy(no_copy const&) = delete;
 ^~~
:11:47: error: invalid initialization of non-const reference of type
'no_copy&' from an rvalue of type ''
 : it{it.valid() ? it : throw "invalid"}
   ^

[Bug c++/91335] False positive "unused variable" warning with variable initialized in 'if' condition

[zeratul976 at hotmail dot com]

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

--- Comment #1 from Nathan Ridge  ---
(In reply to Nathan Ridge from comment #0)
> As a result, the only way to fix the warning is to lift the variable into
> the outer scope, which can be undesirable from a code style point of view:

(Well, or I could add a "(void) f;" statement in the if body. Equally
undesirable.)

[Bug c++/91335] New: False positive "unused variable" warning with variable initialized in 'if' condition

[zeratul976 at hotmail dot com]

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

Bug ID: 91335
   Summary: False positive "unused variable" warning with variable
initialized in 'if' condition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeratul976 at hotmail dot com
  Target Milestone: ---

In the following code:

int* foo();

int main() {
  if (int* f = foo()) {
return 1;
  }
  return 0;
}

GCC (tested version 9.1.0) issues the following warning with -Wall:

test.cpp: In function ‘int main()’:
test.cpp:4:12: warning: unused variable ‘f’ [-Wunused-variable]
4 |   if (int* f = foo()) {
  |^

I consider this a false positive because testing the variable's value in the
if-condition constitutes a use.

The language does not syntactically permit omitting the variable name here:

int main() {
  if (int* = foo()) {  // error: expected unqualified-id before '=' token
return 1;
  }
  return 0;
}

As a result, the only way to fix the warning is to lift the variable into the
outer scope, which can be undesirable from a code style point of view:

int* foo();

int main() {
  int* f = foo();
  if (f) {
return 1;
  }
  // variable 'f' still in scope here, when I don't want it to be
  return 0;
}

[Bug fortran/89943] Submodule functions are not allowed to have C binding

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug fortran/90985] Wrong error message with variables named "DATA*"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/90985] Wrong error message with variables named "DATA*"

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Aug  2 23:48:36 2019
New Revision: 274033

URL: https://gcc.gnu.org/viewcvs?rev=274033&root=gcc&view=rev
Log:
2019-08-02  Steven G. Kargl  

PR fortran/90985
* decl.c (gfc_match_data): In free-form code, DATA be followed by
whitespace.

2019-08-02  Steven G. Kargl  

PR fortran/90985
* gfortran.dg/pr90985.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr90985.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> Author: kargl
> Date: Fri Aug  2 21:28:58 2019
> New Revision: 274031
> 
> URL: https://gcc.gnu.org/viewcvs?rev=274031&root=gcc&view=rev
> Log:
> 2019-08-02  Steven G. Kargl  
> 
>   PR fortran/90297
>   * match.c (gfc_match_equivalence): Check that EQUIVALENCE is followed
>   by '('.
> 
> 2019-08-02  Steven G. Kargl  
> 
>   PR fortran/90297
>   * gfortran.dg/equiv_10.f90: New test.
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/equiv_10.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/match.c
> trunk/gcc/testsuite/ChangeLog

Whoops.  Wrong PR number in ChangeLog.  Correct PR is fortran/90986.

[Bug fortran/90986] Wrong error message with variables named "EQUIVALENCE*"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #1 from kargl at gcc dot gnu.org ---
Fixed on trunk with r274031.

I had the wrong PR number in the ChangeLog.

[Bug c++/91334] New: [10 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

Bug ID: 91334
   Summary: [10 Regression] internal compiler error: Segmentation
fault
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

On x86-64, when building 483.xalancbmk in SPEC CPU 2006, r273791 caused:

$ g++ -m32  -Ofast -funroll-loops -msse2 -mfpmath=sse -ffast-math
-march=skylake-avx512 -flto ...
ElemNumber.cpp: In member function 'getCountString':
ElemNumber.cpp:458:1: internal compiler error: Segmentation fault
  458 | ElemNumber::getCountString(
  | ^ 
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [Xalan] Error 1

[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Aug  2 21:28:58 2019
New Revision: 274031

URL: https://gcc.gnu.org/viewcvs?rev=274031&root=gcc&view=rev
Log:
2019-08-02  Steven G. Kargl  

PR fortran/90297
* match.c (gfc_match_equivalence): Check that EQUIVALENCE is followed
by '('.

2019-08-02  Steven G. Kargl  

PR fortran/90297
* gfortran.dg/equiv_10.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/equiv_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c/91312] -Wconversion warning with += operator

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Kostas Sotiropoulos from comment #4)
> Any comments on my questions?

Yes go read the c standard about prompting to int here.

[Bug c/91312] -Wconversion warning with += operator

[kosotiro at yahoo dot gr]

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

--- Comment #4 from Kostas Sotiropoulos  ---
Any comments on my questions?

[Bug c++/77712] [DR903] int() is incorrectly treated as a null pointer constant in C++11 and later

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The problem here is that parsing "int()" results in INTEGER_CST 0, created by
build_zero_init, and we have no way to tell that it's not a null pointer
constant anymore :(.

[Bug rtl-optimization/91333] New: [9/10 Regression] suboptimal register allocation for inline asm

[glisse at gcc dot gnu.org]

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

Bug ID: 91333
   Summary: [9/10 Regression] suboptimal register allocation for
inline asm
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

static double g(double x){
  asm volatile("":"+x"(x));
  return x;
}
double f(double a,double b){
  return g(g(a)+g(b));
}

(using -O1, -O2 or -O3)

With gcc-8, I get the sensible

addsd   %xmm1, %xmm0

With gcc-9, I get

movapd  %xmm0, %xmm2
movapd  %xmm1, %xmm0
movapd  %xmm2, %xmm1
addsd   %xmm1, %xmm0

For some reason gcc decided to swap the 2 numbers?

-mavx helps remove all the moves, but on this slightly larger example:

double h(double a,double b){
  return f(f(a,a),f(b,b));
}

-mavx actually increases the number of moves, from 2 to 4... (and at -O1 gcc
does this strange thing where it stores a double in %rax, good thing that
disappears at -O2)

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
If everyone agrees I will do this one. I should have some time in the next few
weeks assuming I get my development systems bcak online. They are in a
maintaenance state at the moment (ie changing some parts)

[Bug lto/91313] [10 regression] r273908 breaks lto on power 7

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Fri, Aug 02, 2019 at 09:30:04AM +, marxin at gcc dot gnu.org wrote:
> 
> --- Comment #8 from Martin Liška  ---
> Should be fixed now.
> 

Thanks!  I can comfirm the issue is fixed on FreeBSD.

[Bug tree-optimization/91326] VRP does not handle array value range

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Associating the minimum and maximum with the declaration of each constant array
object would be a simple way of doing it but I'm not sure how much it would
gain.  Doing better would mean a linear traversal of the array.  That seems to
be what Clang does -- it folds even equalities with values in the range [MIN,
MAX] that aren't in the array.  An only slightly less costly approach would be
to only search the elements between the lower and upper bounds of the index.

I pondered doing this for strcmp and strlen but the linear search felt too
expensive (Clang doesn't do it).  It might be worth getting some data on how
often it would trigger and what it would cost.

[Bug c++/67033] [c++11] template argument invalid for integral constant expression beginning with address-of expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-02
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

Testcase from PR56428:

template  struct Z { };

struct C
{
void f();
Z<&C::f == nullptr> z;
};

[Bug c++/56428] [C++11] "is not a constant expression" when comparing non-type template argument to nullptr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.  Comment 2 is another, still valid, issue, but we have PR67033 for that.

[Bug fortran/91332] New: ICE: Segfault in gfortran when compiling massive function with -O3

[clogged.drainpipe at gmail dot com]

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

Bug ID: 91332
   Summary: ICE: Segfault in gfortran when compiling massive
function with -O3
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clogged.drainpipe at gmail dot com
  Target Milestone: ---

Created attachment 46664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46664&action=edit
gzipped source to reproduce

Hello!

We have run into an ICE when we tried to compile an admittedly pretty massive
subroutine. I am not sure which component is segfaulting, so for lack of better
idea I am filing this under gfortran, please feel free to reassign it as you
see fit. The system is running Ubuntu 18.04 LTS. Gfortran just throws an ICE
segfault after about an hour of wall time. Please note that gfortran also
consumes ~60+ GiB of RAM before finally segfaulting. I tested on a machine that
has 64 GiB of RAM and some swap on an SSD, and apart from the segfault I had no
issues, but with less RAM this might be challenging to reproduce.

The command line that causes the crash is:
gfortran -v -O3 -march=skylake -ffree-line-length-0 -save-temps -c dmono_4.f90

Interestingly, there is no crash with O0,O1 or even O2. I am yet to test other
optimization levels. Not much else can I say about this, but if anyone needs
more info, please do ask.

Complete output of the command line above:

Using built-in specs.
COLLECT_GCC=gfortran
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
COLLECT_GCC_OPTIONS='-v' '-O3' '-march=skylake' '-ffree-line-length-0'
'-save-temps' '-c'
 /usr/lib/gcc/x86_64-linux-gnu/7/f951 dmono_4.f90 -quiet -dumpbase dmono_4.f90
-march=skylake -auxbase dmono_4 -O3 -version -ffree-line-length-0
-fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/7/finclude -o dmono_4.s
GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) version 7.4.0 (x86_64-linux-gnu)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Ubuntu 7.4.0-1ubuntu1~18.04.1) version 7.4.0
(x86_64-linux-gnu)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
dmono_4.f90:19736:0:

   end subroutine devmono_4

internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/56428] [C++11] "is not a constant expression" when comparing non-type template argument to nullptr

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  2 18:17:20 2019
New Revision: 274028

URL: https://gcc.gnu.org/viewcvs?rev=274028&root=gcc&view=rev
Log:
PR c++/56428
* g++.dg/cpp0x/nontype4.C: New test.

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

[Bug c++/56428] [C++11] "is not a constant expression" when comparing non-type template argument to nullptr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed by r215409.  I'll be adding Mr. Wakely's example to our testing suite.

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[jg at jguk dot org]

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

--- Comment #12 from Jonny Grant  ---
If -Wenum-conversion is not enabled automatically, do those GCC build warnings
need to be cleaned up before it is added? It's a bit chicken and egg.

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug fortran/90786] [7/8 Regression] ICE on procedure pointer assignment to function with class pointer result

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Aug  2 17:51:45 2019
New Revision: 274026

URL: https://gcc.gnu.org/viewcvs?rev=274026&root=gcc&view=rev
Log:
2019-08-02  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* trans-expr.c (pointer_assignment_is_proc_pointer) Remove as
it is very simple and only called from one place.
(gfc_trans_pointer_assignment): Rename non_proc_pointer_assign
as non_proc_ptr_assign. Assign to it directly, rather than call
to above, deleted function and use gfc_expr_attr instead of
only checking the reference chain.
* trans-decl.c (sym_identifier): New function.
(mangled_identifier): New function, doing most of the work
of gfc_sym_mangled_identifier.
(gfc_sym_mangled_identifier): Use mangled_identifier.  Add mangled
identifier to global symbol table.
(get_proc_pointer_decl): Use backend decl from global identifier
if present.

2019-08-02  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* gfortran.dg/proc_ptr_51.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  2 17:51:53 2019
New Revision: 274027

URL: https://gcc.gnu.org/viewcvs?rev=274027&root=gcc&view=rev
Log:
PR c++/53009
* g++.dg/cpp0x/nontype3.C: New test.

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

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[tkoenig at gcc dot gnu.org]

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

--- Comment #36 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Aug  2 17:51:45 2019
New Revision: 274026

URL: https://gcc.gnu.org/viewcvs?rev=274026&root=gcc&view=rev
Log:
2019-08-02  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* trans-expr.c (pointer_assignment_is_proc_pointer) Remove as
it is very simple and only called from one place.
(gfc_trans_pointer_assignment): Rename non_proc_pointer_assign
as non_proc_ptr_assign. Assign to it directly, rather than call
to above, deleted function and use gfc_expr_attr instead of
only checking the reference chain.
* trans-decl.c (sym_identifier): New function.
(mangled_identifier): New function, doing most of the work
of gfc_sym_mangled_identifier.
(gfc_sym_mangled_identifier): Use mangled_identifier.  Add mangled
identifier to global symbol table.
(get_proc_pointer_decl): Use backend decl from global identifier
if present.

2019-08-02  Thomas Koenig  
Paul Thomas 

Backport from trunk
PR fortran/90786
PR fortran/90813
* gfortran.dg/proc_ptr_51.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed by r251438.

[Bug c++/77575] Bogus error when alias template yielding a reference type used as template template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/77575] Bogus error when alias template yielding a reference type used as template template argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  2 17:26:02 2019
New Revision: 274024

URL: https://gcc.gnu.org/viewcvs?rev=274024&root=gcc&view=rev
Log:
PR c++/77575
* g++.dg/cpp0x/nontype2.C: New test.

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

[Bug c++/77575] Bogus error when alias template yielding a reference type used as template template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Got fixed in r241425 but the testcase added doesn't contain an alias template.

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
Discussions of the change continued into Aug / Sep 2017.  In particular, 
there were issues with warnings this introduced in the GCC build (of 
target libraries), and questions about whether fixes posted for those 
warnings were correct or not.  Did all the warnings this introduced in the 
GCC build get resolved?  If not, those warnings would need dealing with 
first.

[Bug c++/91329] Unnecessary call to __cxa_throw_bad_array_new_length

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
int is signed.
So closing as invalid.

[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Assuming fixed.

[Bug c/90737] [8 Regression] inconsistent address of a local converted to intptr_t between callee and caller

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[8/9 Regression]|[8 Regression] inconsistent
   |inconsistent address of a   |address of a local
   |local converted to intptr_t |converted to intptr_t
   |between callee and caller   |between callee and caller
  Known to fail|10.0, 9.1.0 |

--- Comment #9 from Martin Sebor  ---
Backported to 9-branch in r274022.

[Bug c/90737] [8/9 Regression] inconsistent address of a local converted to intptr_t between callee and caller

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Fri Aug  2 17:05:34 2019
New Revision: 274022

URL: https://gcc.gnu.org/viewcvs?rev=274022&root=gcc&view=rev
Log:
Backport from mainline

PR c/90737 - [8/9/10 Regression] inconsistent address of a local converted to
intptr_t between callee and caller

gcc/c/ChangeLog:

PR c/90737
* c-typeck.c (c_finish_return): Only consider functions returning
pointers as candidates for -Wreturn-local-addr.

gcc/cp/ChangeLog:

PR c/90737
* typeck.c (maybe_warn_about_returning_address_of_local): Only
consider functions returning pointers as candidates for
-Wreturn-local-addr.

gcc/testsuite/ChangeLog:

PR c/90737
* c-c++-common/Wreturn-local-addr.c: New test.
* g++.dg/warn/Wreturn-local-addr-6.C: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/Wreturn-local-addr.c
branches/gcc-9-branch/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-6.C
Modified:
branches/gcc-9-branch/gcc/c/ChangeLog
branches/gcc-9-branch/gcc/c/c-typeck.c
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/typeck.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/90989] [9 Regression] incorrrect strlen result after second strcpy into the same destination

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Backported to 9-branch in r274021.

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

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

Bug 90989 Summary: [9 Regression] incorrrect strlen result after second strcpy 
into the same destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90989

   What|Removed |Added

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

[Bug tree-optimization/90989] [9 Regression] incorrrect strlen result after second strcpy into the same destination

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Aug  2 16:57:19 2019
New Revision: 274021

URL: https://gcc.gnu.org/viewcvs?rev=274021&root=gcc&view=rev
Log:
Backport from mainline

PR tree-optimization/90989 - incorrrect strlen result after second strcpy
into the same destination

gcc/ChangeLog:

PR tree-optimization/90989
* tree-ssa-strlen.c (handle_char_store): Constrain a single character
optimization to just single character stores.

gcc/testsuite/ChangeLog:

PR tree-optimization/90989
* gcc.dg/strlenopt-26.c: Exit with test result status.
* gcc.dg/strlenopt-67.c: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/strlenopt-67.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.dg/strlenopt-26.c
branches/gcc-9-branch/gcc/tree-ssa-strlen.c

[Bug c/91046] missing warning about empty translation unit

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
There can't be any debug info issues specific to empty translation units, 
given that

_Static_assert (1, "");

is valid as a translation unit in ISO C, and doesn't declare anything that 
would get debug info.

As an extension the support for empty translation units should be 
documented, but it would be entirely inappropriate to warn about them by 
default (it's perfectly natural to have an empty translation unit if e.g. 
it has preprocessor conditionals and is only empty under some conditions).

[Bug testsuite/91331] new test case gcc.dg/torture/pr91323.c from r274005 fails

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Please see PR91323. LTGT should trap on NaN.

[Bug testsuite/91331] New: new test case gcc.dg/torture/pr91323.c from r274005 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 91331
   Summary: new test case gcc.dg/torture/pr91323.c from r274005
fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This fails on all our powerpc64 test machines.

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test2/./pr91323.exe 
Program received signal SIGABRT, Aborted.
0x3fffb7cd247c in .raise () from /lib64/libc.so.6
(gdb) where
#0  0x3fffb7cd247c in .raise () from /lib64/libc.so.6
#1  0x3fffb7cd4688 in .abort () from /lib64/libc.so.6
#2  0x1954 in main () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c:48


Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O0-lm  -o ./pr91323.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O0 -lm -o ./pr91323.exe
PASS: gcc.dg/torture/pr91323.c   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/pr91323.c   -O0  execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O1-lm  -o ./pr91323.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O1 -lm -o ./pr91323.exe
PASS: gcc.dg/torture/pr91323.c   -O1  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/pr91323.c   -O1  execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O2-lm  -o ./pr91323.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr91323.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -lm -o ./pr91323.exe
PASS: gcc.dg/torture/pr91323.c   -O2  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/pr91323.c   -O2  execution test
...etc...

[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array

[uros at gcc dot gnu.org]

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

--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Aug  2 15:46:02 2019
New Revision: 274018

URL: https://gcc.gnu.org/viewcvs?rev=274018&root=gcc&view=rev
Log:
PR target/91201
* config/i386/sse.md (*vec_extractv16qi_zext): New insn pattern.

testsuite/ChangeLog:

PR target/91201
* gcc.target/i386/sse4_1-pr91201.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/sse4_1-pr91201.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/91278] Array arithmetic yields "is not a constant expression" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-02
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Could be a dup; I think I've seen a couple of related PRs.

[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug jit/91330] New: JIT "dir" entry for info is incomplete

[tromey at gcc dot gnu.org]

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

Bug ID: 91330
   Summary: JIT "dir" entry for info is incomplete
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Looking at the "dir" entry for the JIT, I see:

murgatroyd. grep jit install/share/info/dir 
* libgccjit: (libgccjit.info).  One line description of project.


I think the "One line description..." text should be replaced with
something more descriptive.

[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Thanks Helge.  This is not a gcc bug.

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[iains at gcc dot gnu.org]

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

--- Comment #33 from Iain Sandoe  ---
Author: iains
Date: Fri Aug  2 14:54:57 2019
New Revision: 274017

URL: https://gcc.gnu.org/viewcvs?rev=274017&root=gcc&view=rev
Log:
darwin, backport driver fixes.

272260,r272479 - Darwin, Driver - Improve processing of macosx-version-min=

For PR target/63810 some improvements were made in the parsing of
the version string at the point it's used to define the built-in
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. This is fine, but the
specs processing also uses the version, and specs version-compare
doesn't like leading zeros on components. This means that while we
succeed in processing -mmacosx-version-min=010.2.99 on compile
lines, it fails for any other line that uses the value as part of a spec
(in particular, link lines fail).

To fix this, we need to apply a bit of clean-up to the version that's
presented to the driver, and push that back into the command line opts.

The value can come from four places:
1. User-entered on the command line
2. User-entered as MACOSX_DEPLOYMENT_TARGET= environment var.
3. Absent those two
3a For self-hosting systems, look-up from the kernel
3b For cross-compilers, as a default supplied at configure time.

We apply the clean-up to all 4 (although it shouldn't really be needed
for the cases under 3).

We also supply a test-case that adapts to the target-version of the
system, so that the link requirements are met by the SDK in use (if you
try to link i686-darwin9 on an x86-64-darwin18 SDK, it will fail).

gcc/

2019-08-02  Iain Sandoe  

Backport from mainline
2019-06-19  Iain Sandoe  

* config/darwin-driver.c (darwin_driver_init): Fix off-by-one errors
in computing the number of options to be moved.

Backport from mainline
2019-06-13  Iain Sandoe  

* config/darwin-driver.c (validate_macosx_version_min): New.
(darwin_default_min_version): Cleanup and validate supplied version.
(darwin_driver_init): Likewise and push cleaned version into opts.

gcc/testsuite/

2019-08-02  Iain Sandoe  

2019-06-13  Iain Sandoe  

* gcc.dg/darwin-minversion-link.c: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/darwin-minversion-link.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/darwin-driver.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91286] invalid use of incomplete type depends on --enable-checking=release

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The reason for this is:
  /* When checking, try to get a constant value for all non-dependent
 expressions in order to expose bugs in *_dependent_expression_p
 and constexpr.  This can affect code generation, see PR70704, so
 only do this for -fchecking=2.  */
  if (flag_checking > 1
  && cxx_dialect >= cxx11
  /* Don't do this during nsdmi parsing as it can lead to
 unexpected recursive instantiations.  */
  && !parsing_nsdmi ()
  /* Don't do this during concept expansion either and for
 the same reason.  */
  && !expanding_concept ())
fold_non_dependent_expr (expr, tf_none);

but I think this is invalid ([class.derived]) NDR, so not sure if we need to
change anything.

[Bug tree-optimization/90989] [9 Regression] incorrrect strlen result after second strcpy into the same destination

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I will backport it today.  There are no followup fixes to this one.

[Bug c++/91329] Unnecessary call to __cxa_throw_bad_array_new_length

[antoshkka at gmail dot com]

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

--- Comment #1 from Antony Polukhin  ---
Ops, sorry. This is invalild. `i` could be negative.

Please close as invalid

[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-02
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tom at honermann dot net
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Thanks Tom!

[Bug c++/91329] New: Unnecessary call to __cxa_throw_bad_array_new_length

[antoshkka at gmail dot com]

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

Bug ID: 91329
   Summary: Unnecessary call to __cxa_throw_bad_array_new_length
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

For the code

int* test(int i) {
return new int[i];
}

The following assembly is generated:

test(int):
  movsx rdi, edi
  sub rsp, 8
  movabs rax, 2305843009213693950
  cmp rdi, rax
  ja .L2
  sal rdi, 2
  add rsp, 8
  jmp operator new[](unsigned long)
test(int) [clone .cold]:
.L2:
  call __cxa_throw_bad_array_new_length


However the `i * sizeof(int)` can not be greater than `2305843009213693950`. So
the checks should be skipped.

Optimal assembly should look close to:

test(int):
  movsx rdi, edi
  sal rdi, 2
  jmp operator new[](unsigned long)

[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder

[tom at honermann dot net]

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

--- Comment #3 from Tom Honermann  ---
A patch for this issue has been submitted:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00150.html

[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test

[deller at gmx dot de]

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

--- Comment #4 from deller at gmx dot de ---
We do not have a RLIMIT_DATA default limit in the Linux kernel.
I suspect that's added somewhere outside, e.g. before building gcc/gnat.
You may disable the rlimit check by executing:
echo Y > /sys/module/kernel/parameters/ignore_rlimit_data

524288000 is exactly 500MB, maybe that number can grepped somewhere?

[Bug sanitizer/91325] [ASAN] ASAN hangs at throw if called via dlopen

[jensseidel at users dot sf.net]

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

--- Comment #3 from Jens Seidel  ---
(In reply to Martin Liška from comment #1)
> Hm, I can't reproduce that with any version of GCC I have:

Was trying it now also on other computers:

On Debian 9 with g++ 6.3 and libc-2.24.so it works well, on Ubuntu 18.04 with
g++ 7.4.0 (libc-2.27.so) and Ubuntu 16.04 with g++-8, g++-7, g++-6, g++-5
(libc-2.23.so) I get:

$ ./main 
==10179==AddressSanitizer CHECK failed:
../../../../src/libsanitizer/asan/asan_interceptors.cc:384
"((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
#0 0x7f7030b3ac02  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe9c02)
#1 0x7f7030b59595 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0x108595)
#2 0x7f7030a8926c in __interceptor___cxa_throw
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0x3826c)
#3 0x7f702cffdc04 in foo /home/seidel/tmp/shlib.cpp:4
#4 0x7f702cffdc12 in bar /home/seidel/tmp/shlib.cpp:13
#5 0x55eb62962bf9 in main /home/seidel/tmp/main.c:11
#6 0x7f703047db96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#7 0x55eb62962a89 in _start (/home/seidel/tmp/main+0xa89)

On macOS (x86_64-apple-darwin18.6.0) it works, on SLES 12.0 (Suse) with g++
4.8.5 I get:
$ ./main
==7984== ERROR: AddressSanitizer failed to allocate 0xdfff0001000
(15392894357504) bytes at address 0x02008fff7000 (12)
==7984== ReserveShadowMemoryRange failed while trying to map 0xdfff0001000
bytes. Perhaps you're using ulimit -v
Aborted

My affected system I reported initially is a Ubuntu 16.04 (libc-2.23.so). The
other report refers to a Red Hat system.

What can I do?

[Bug sanitizer/91328] New: stack-use-after-scope for in-class initialization of std::vector member using initializer_list

[geert.fan...@auro-technologies.com]

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

Bug ID: 91328
   Summary: stack-use-after-scope for in-class initialization of
std::vector member using initializer_list
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geert.fan...@auro-technologies.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

GCC and system details (`gcc -v`):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.1.0 (GCC) 

Compiler statement: `g++ test.ii -fsanitize=address -O3 -Wall -Wextra`
 => no warnings

Running application: `./a.out`
 => ASAN stack-use-after-scope error
=
==1669==ERROR: AddressSanitizer: stack-use-after-scope on address
0x562395364060 at pc 0x7eff4508aab4 bp 0x7ffd220dfa40 sp 0x7ffd220df1e8
READ of size 12 at 0x562395364060 thread T0
#0 0x7eff4508aab3 in __interceptor_memcpy
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
#1 0x56239536343b in f()
(/home/geertf/tmp/repro-bug-gcc9-asan/a.out+0x143b)
#2 0x56239536317d in main
(/home/geertf/tmp/repro-bug-gcc9-asan/a.out+0x117d)
#3 0x7eff44b09ee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
#4 0x5623953631ed in _start
(/home/geertf/tmp/repro-bug-gcc9-asan/a.out+0x11ed)

0x562395364060 is located 0 bytes inside of global variable 'C.0' defined in
'test.cpp:3:8' (0x562395364060) of size 12
SUMMARY: AddressSanitizer: stack-use-after-scope
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
in __interceptor_memcpy
Shadow bytes around the buggy address:
  0x0ac4f2a647b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a647c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a647d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a647e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a647f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ac4f2a64800: 00 00 00 00 00 00 00 00 00 00 00 00[f8]f8 f9 f9
  0x0ac4f2a64810: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a64820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a64830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a64840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac4f2a64850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==1669==ABORTING

The original source code for this bug can be found here:
https://github.com/gfannes/repro-bug-gcc9-asan

[Bug rtl-optimization/91327] non-reproducible Internal Compiler Error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-02
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
On the one machine where sometimes you get the crash.  Do you have ecc memory? 
Have you ran a memory tester to see if you have issues with the machine itself?

[Bug rtl-optimization/91327] non-reproducible Internal Compiler Error

[j.schleicher at pilz dot de]

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

--- Comment #2 from j.schleicher at pilz dot de ---
Created attachment 46662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46662&action=edit
command line output during another compilation

Note: Free memory was still several hundred megabytes (4GB installed total)

[Bug sanitizer/91325] [ASAN] ASAN hangs at throw if called via dlopen

[jensseidel at users dot sf.net]

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

--- Comment #2 from Jens Seidel  ---
I am using
/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so.

[Bug c++/91230] [9/10 Regression] Template function containing lambda expression that has auto parameter and uses __PRETTY_FUNCTION__ does not compile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/91230] [9/10 Regression] Template function containing lambda expression that has auto parameter and uses __PRETTY_FUNCTION__ does not compile

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  2 13:29:05 2019
New Revision: 274010

URL: https://gcc.gnu.org/viewcvs?rev=274010&root=gcc&view=rev
Log:
PR c++/91230 - wrong error with __PRETTY_FUNCTION__ and generic lambda.
* pt.c (value_dependent_expression_p): Consider __PRETTY_FUNCTION__
inside a template function value-dependent.

* g++.dg/cpp1y/lambda-generic-pretty1.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-pretty1.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/pt.c

[Bug rtl-optimization/91327] non-reproducible Internal Compiler Error

[j.schleicher at pilz dot de]

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

--- Comment #1 from j.schleicher at pilz dot de ---
Created attachment 46661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46661&action=edit
Preprocessed source

[Bug c++/91230] [9/10 Regression] Template function containing lambda expression that has auto parameter and uses __PRETTY_FUNCTION__ does not compile

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  2 13:26:06 2019
New Revision: 274009

URL: https://gcc.gnu.org/viewcvs?rev=274009&root=gcc&view=rev
Log:
PR c++/91230 - wrong error with __PRETTY_FUNCTION__ and generic lambda.
* pt.c (value_dependent_expression_p): Consider __PRETTY_FUNCTION__
inside a template function value-dependent.

* g++.dg/cpp1y/lambda-generic-pretty1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-pretty1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91327] New: non-reproducible Internal Compiler Error

[j.schleicher at pilz dot de]

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

Bug ID: 91327
   Summary: non-reproducible Internal Compiler Error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.schleicher at pilz dot de
  Target Milestone: ---

Created attachment 46660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46660&action=edit
Command line and output including gcc version info

I get different internal compiler errors when compiling the attached source.
The problem is when compiling on a low-end cpu (Intel(R) Celeron(R) CPU N3450 @
1.10GHz) while the code compiles fine on other PCs.

Sometimes compilation succeeds; most of the time it fails with different
backtraces in boost/function or boost/algorithm.

In some run there was a message "during RTL pass: reload" just before the
crash.

[Bug tree-optimization/91326] VRP does not handle array value range

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
For bar, we don't take advantage of the uninitialized variable enough, we still
have "a_3(D) == 0" at expansion time (RTL gets rid of it, but too
conservatively).

For foo, indeed computing the min and max values of the array to get a range
for any access to it would be nice.

[Bug sanitizer/88109] UBSAN can't work with vector operations

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
The same applies for eg. division by zero; doing such vector operation results
in:

$ cat testcase-sanitize.c
int v __attribute__ ((vector_size (8)));
int
main (void)
{
  return (v / v)[0];
}
$ x86_64-pc-linux-gnu-gcc -fsanitize=undefined testcase-sanitize.c
$ ./a.out 
Floating point exception

But the sanitizer does not report the invalid operation.

[Bug tree-optimization/91326] New: VRP does not handle array value range

[zsojka at seznam dot cz]

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

Bug ID: 91326
   Summary: VRP does not handle array value range
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 46659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46659&action=edit
testcase

For the attached code, gcc "10.0.0 20190730" -O3 generates:

foo:
movsx   rdi, edi
mov eax, 1
mov edx, DWORD PTR arr[0+rdi*4]
testedx, edx
je  .L1
xor eax, eax
cmp edx, 10
setgal
add eax, eax
.L1:
ret

bar:
xor eax, eax
cmp edi, 2
setaal
ret

baz:
xor eax, eax
ret


clang "7.1.0" and "8.0.1" -O3 generate the optimal code for all 3 versions:

foo:
xor eax, eax
ret


bar:
xor eax, eax
ret


baz:
xor eax, eax
ret

[Bug target/77952] c++11 and gcc: internal compiler error: in convert_move

[coypu at sdf dot org]

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

coypu  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #2 from coypu  ---
hi, I tested some versions:

6.3.0: fail
7.4.0: OK
trunk (10.x): OK

I suspect this means the bug can be closed as already being fixed in supported
branches.

[Bug tree-optimization/91280] [8/9 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Aug  2 12:07:33 2019
New Revision: 274007

URL: https://gcc.gnu.org/viewcvs?rev=274007&root=gcc&view=rev
Log:
2019-08-02  Richard Biener  

Backport from mainline
2019-07-31  Richard Biener  

PR tree-optimization/91280
* tree-ssa-structalias.c (get_constraint_for_component_ref):
Decompose MEM_REF manually for offset handling.

* g++.dg/torture/pr91280.C: New testcase.

2019-07-31  Richard Biener  

PR tree-optimization/91293
* tree-vect-slp.c (vect_build_slp_tree_2): Do not swap operands
of reduction stmts.

* gcc.dg/vect/pr91293-1.c: New testcase.
* gcc.dg/vect/pr91293-2.c: Likewise.
* gcc.dg/vect/pr91293-3.c: Likewise.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91280.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-1.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-2.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-3.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-structalias.c
branches/gcc-9-branch/gcc/tree-vect-slp.c

[Bug tree-optimization/91293] [8 Regression] Wrong code with -O3 -mavx2

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Aug  2 12:07:33 2019
New Revision: 274007

URL: https://gcc.gnu.org/viewcvs?rev=274007&root=gcc&view=rev
Log:
2019-08-02  Richard Biener  

Backport from mainline
2019-07-31  Richard Biener  

PR tree-optimization/91280
* tree-ssa-structalias.c (get_constraint_for_component_ref):
Decompose MEM_REF manually for offset handling.

* g++.dg/torture/pr91280.C: New testcase.

2019-07-31  Richard Biener  

PR tree-optimization/91293
* tree-vect-slp.c (vect_build_slp_tree_2): Do not swap operands
of reduction stmts.

* gcc.dg/vect/pr91293-1.c: New testcase.
* gcc.dg/vect/pr91293-2.c: Likewise.
* gcc.dg/vect/pr91293-3.c: Likewise.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91280.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-1.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-2.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/vect/pr91293-3.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-structalias.c
branches/gcc-9-branch/gcc/tree-vect-slp.c

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  ---
On Thu, 1 Aug 2019, ubizjak at gmail dot com wrote:

> It also means that __builtin_islessgreater is confusingly named.

No, __builtin_islessgreater corresponds to the ISO C islessgreater 
type-generic macro, which does not raise exceptions for quiet NaN 
arguments.  If anything is confusingly named it's GCC's internal LTGT 
operations, if they don't correspond to islessgreater.

Regarding the confused LTGT (RTL, GENERIC, GIMPLE) semantics, see what I 
said in  (and 
elsewhere in that thread).

Whatever we conclude about whether LTGT is (LT || GT) or (!UNEQ), (a) we 
should document the choice (so that we then have a basis for telling 
whether code involving LTGT is correct or not, based on whether it 
corresponds to the documented semantics) and (b) the choice should be the 
same for all of RTL, GENERIC and GIMPLE.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Richard Biener from comment #4)
> > quoting rtl.def:
> > 
> > /* This is an ordered NE, ie !UNEQ, ie false for NaN.  */
> > DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)
> 
> In gensupport.c, we have:
> 
>   {"ordered_comparison_operator", false, false, {EQ, NE,
>LE, LT, GE, GT,
>LEU, LTU, GEU, GTU}},
>   {"comparison_operator", false, false, {EQ, NE,
>LE, LT, GE, GT,
>LEU, LTU, GEU, GTU,
>UNORDERED, ORDERED,
>UNEQ, UNGE, UNGT,
>UNLE, UNLT, LTGT}}
> 
> And based on the observation that LTGT = LT || GT, should LTGT be a member
> of ordered_comparison_operator?

@defun ordered_comparison_operator
This predicate matches any expression which performs an arithmetic
comparison in @var{mode} and whose expression code is valid for integer
modes; that is, the expression code will be one of @code{eq}, @code{ne},
@code{lt}, @code{ltu}, @code{le}, @code{leu}, @code{gt}, @code{gtu},
@code{ge}, @code{geu}.
@end defun

I don't think we use LTGT for integer modes, so the answer is no.  But
I argue ordered_comparison_operator is named confusingly then.

[Bug sanitizer/91311] __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Martin Liška  ---
Sorry, but I can't reproduce the issue with any of GCC 7,8,9 and clang8.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #4)
> quoting rtl.def:
> 
> /* This is an ordered NE, ie !UNEQ, ie false for NaN.  */
> DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)

In gensupport.c, we have:

  {"ordered_comparison_operator", false, false, {EQ, NE,
 LE, LT, GE, GT,
 LEU, LTU, GEU, GTU}},
  {"comparison_operator", false, false, {EQ, NE,
 LE, LT, GE, GT,
 LEU, LTU, GEU, GTU,
 UNORDERED, ORDERED,
 UNEQ, UNGE, UNGT,
 UNLE, UNLT, LTGT}}

And based on the observation that LTGT = LT || GT, should LTGT be a member of
ordered_comparison_operator?

[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Martin Liška  ---
I can't reproduce that on x86_64-linux-gnu.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #8)
> FWIW, using __float128 also traps on LTGT. The adapted testcase:

Eh, __float128 should trap on LTGT, but currently, it doesn't.

[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
The cp/decl.c change looks weird, it is more readable to use one if with ||
instead of if (cond1) something; else if (cond2) something; where something is
the same in between.

[Bug tree-optimization/90989] [9 Regression] incorrrect strlen result after second strcpy into the same destination

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Weren't there follow-up changes to this change?

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
FWIW, using __float128 also traps on LTGT. The adapted testcase:

--cut here--
/* { dg-do run } */
/* { dg-add-options ieee } */
/* { dg-require-effective-target fenv_exceptions } */

#include 

int
__attribute__ ((noinline, noclone))
f1 (__float128 a, __float128 b)
{
  return __builtin_isless (a, b) || __builtin_isgreater (a, b);
}

int
__attribute__ ((noinline, noclone))
f2 (__float128 a, __float128 b)
{
  return __builtin_islessgreater (a, b);
}

int
__attribute__ ((noinline, noclone))
f3 (__float128 a, __float128 b)
{
  return a < b || a > b;
}

int
main (void)
{
  volatile int r;

  __float128 nanq = __builtin_nanq ("");
  __float128 argq = 1.0q;

  feclearexcept (FE_INVALID);

  r = f1 (nanq, argq);
  if (fetestexcept (FE_INVALID))
__builtin_abort ();

  r = f2 (nanq, argq);
  if (fetestexcept (FE_INVALID))
__builtin_abort ();

  r = f3 (nanq, argq);
  if (!fetestexcept (FE_INVALID))
__builtin_abort ();

  return 0;
}
--cut here--

[Bug target/91142] [9 Regression] Incorrect aligned vector load instruction emitted because of vinserti32x4 elision

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Jakub, can you identify what fixed it on trunk?  Maybe we can backport a simple
fix.

[Bug tree-optimization/90989] [9 Regression] incorrrect strlen result after second strcpy into the same destination

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0

--- Comment #4 from Richard Biener  ---
Please consider backporting for GCC 9.2.

[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0

--- Comment #7 from Richard Biener  ---
Please consider backporting for GCC 9.2.

[Bug c/90737] [8/9 Regression] inconsistent address of a local converted to intptr_t between callee and caller

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Please consider backporting for GCC 9.2.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Aug  2 09:58:04 2019
New Revision: 274005

URL: https://gcc.gnu.org/viewcvs?rev=274005&root=gcc&view=rev
Log:
PR target/91323
* config/i386/i386-expand.c (ix86_unordered_fp_compare) :
Return false.

testsuite/ChangeLog:

PR target/91323
* gcc.dg/torture/pr91323.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr91323.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-expand.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/91325] [ASAN] ASAN hangs at throw if called via dlopen

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-02
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hm, I can't reproduce that with any version of GCC I have:

$ make clean ; make && ./main && echo OK
rm -f libshlib.so main
g++-7 -ggdb3 -fsanitize=address -Wextra -Wall -fPIC -shared -o libshlib.so
shlib.cpp
gcc-7 -ggdb3 -fsanitize=address -Wextra -Wall -o main main.c -ldl
OK

$ make clean ; make && ./main && echo OK
rm -f libshlib.so main
g++-9 -ggdb3 -fsanitize=address -Wextra -Wall -fPIC -shared -o libshlib.so
shlib.cpp
gcc-9 -ggdb3 -fsanitize=address -Wextra -Wall -o main main.c -ldl
OK

Maybe it's related to glibc version:
Name   : glibc 
Version: 2.29-7.3

[Bug lto/91313] [10 regression] r273908 breaks lto on power 7

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Should be fixed now.

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  ---
On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> 
> --- Comment #28 from Xiong Hu XS Luo  ---
> (In reply to Richard Biener from comment #24)
> > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > has
> > 
> >   /* FIXME: Builtins corresponding to real functions probably should have
> >  symbol table entries.  */
> >   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > return false;
> > 
> > we could try to do sth like
> > 
> >   if (TREE_CODE (decl) == FUNCTION_DECL
> >   && (fndecl_built_in_p (decl, BUILT_IN_MD)
> >   || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> >   && !associated_internal_fn (decl
> > return false;
> > 
> > but that would still leave us with too many undefineds I guess
> > (gcc_unreachable for one).
> > 
> > We do not currently track builtins that do have a library implementation
> > (whether that it is used in the end is another thing, but less important).
> > 
> > What we definitely can do is put a whitelist above like via the following
> > which also catches the case of definitions of builtins.
> > 
> > Index: gcc/symtab.c
> > ===
> > --- gcc/symtab.c(revision 273968)
> > +++ gcc/symtab.c(working copy)
> > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> >   first place.  */
> >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> >  return false;
> > +
> >/* FIXME: Builtins corresponding to real functions probably should have
> >   symbol table entries.  */
> > -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > -return false;
> > +  if (TREE_CODE (decl) == FUNCTION_DECL
> > +  && !definition
> > +  && fndecl_built_in_p (decl))
> > +{
> > +  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > +   switch (DECL_FUNCTION_CODE (decl))
> > + {
> > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > + CASE_FLT_FN (BUILT_IN_SIN):
> > +   return true;
> > + default:
> > +   break;
> > + }
> > +  return false;
> > +}
> >  
> >/* We have real symbol that should be in symbol table.  However try to
> > trim
> >   down the refernces to libraries bit more because linker will otherwise
> 
> Hi Richard, no undefineds generated with below code, what's your opinion about
> the updated code, please? Thanks.

It will break code calling __builtin_unreachable for example since
we'll emit an UNDEF that cannot be satisfied.

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[luoxhu at cn dot ibm.com]

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

--- Comment #29 from Xiong Hu XS Luo  ---
(In reply to Xiong Hu XS Luo from comment #28)
> (In reply to Richard Biener from comment #24)
> > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > has
> > 
> >   /* FIXME: Builtins corresponding to real functions probably should have
> >  symbol table entries.  */
> >   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > return false;
> > 
> > we could try to do sth like
> > 
> >   if (TREE_CODE (decl) == FUNCTION_DECL
> >   && (fndecl_built_in_p (decl, BUILT_IN_MD)
> >   || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> >   && !associated_internal_fn (decl
> > return false;
> > 
> > but that would still leave us with too many undefineds I guess
> > (gcc_unreachable for one).
> > 
> > We do not currently track builtins that do have a library implementation
> > (whether that it is used in the end is another thing, but less important).
> > 
> > What we definitely can do is put a whitelist above like via the following
> > which also catches the case of definitions of builtins.
> > 
> > Index: gcc/symtab.c
> > ===
> > --- gcc/symtab.c(revision 273968)
> > +++ gcc/symtab.c(working copy)
> > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> >   first place.  */
> >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> >  return false;
> > +
> >/* FIXME: Builtins corresponding to real functions probably should have
> >   symbol table entries.  */
> > -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > -return false;
> > +  if (TREE_CODE (decl) == FUNCTION_DECL
> > +  && !definition
> > +  && fndecl_built_in_p (decl))
> > +{
> > +  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > +   switch (DECL_FUNCTION_CODE (decl))
> > + {
> > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > + CASE_FLT_FN (BUILT_IN_SIN):
> > +   return true;
> > + default:
> > +   break;
> > + }
> > +  return false;
> > +}
> >  
> >/* We have real symbol that should be in symbol table.  However try to
> > trim
> >   down the refernces to libraries bit more because linker will otherwise
> 
> Hi Richard, no undefineds generated with below code, what's your opinion
> about the updated code, please? Thanks.

I mean "too many undefineds" here. with below modification, symbols will be
output to object file, then linker could link static library as expected.


> 
> diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
> index 47a9143ae26..9d42a57b4b6 100644
> --- a/gcc/lto-streamer-out.c
> +++ b/gcc/lto-streamer-out.c
> @@ -2644,7 +2644,10 @@ write_symbol (struct streamer_tree_cache_d *cache,
> 
>gcc_checking_assert (TREE_PUBLIC (t)
>&& (TREE_CODE (t) != FUNCTION_DECL
> -  || !fndecl_built_in_p (t))
> +  || !fndecl_built_in_p (t, BUILT_IN_MD))
> +  && (TREE_CODE (t) != FUNCTION_DECL
> +  || !fndecl_built_in_p (t, BUILT_IN_NORMAL)
> +  || associated_internal_fn (t) != IFN_LAST)
>&& !DECL_ABSTRACT_P (t)
>&& (!VAR_P (t) || !DECL_HARD_REGISTER (t)));
> 
> diff --git a/gcc/symtab.c b/gcc/symtab.c
> index 63e2820eb93..ce74589b291 100644
> --- a/gcc/symtab.c
> +++ b/gcc/symtab.c
> @@ -2377,7 +2377,10 @@ symtab_node::output_to_lto_symbol_table_p (void)
>  return false;
>/* FIXME: Builtins corresponding to real functions probably should have
>   symbol table entries.  */
> -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> +  if (TREE_CODE (decl) == FUNCTION_DECL
> +  && (fndecl_built_in_p (decl, BUILT_IN_MD)
> + || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> + && IFN_LAST == associated_internal_fn (decl
>  return false;
> 
>/* We have real symbol that should be in symbol table.  However try to
> trim

[Bug sanitizer/91325] New: [ASAN] ASAN hangs at throw if called via dlopen

[jensseidel at users dot sf.net]

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

Bug ID: 91325
   Summary: [ASAN] ASAN hangs at throw if called via dlopen
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jensseidel at users dot sf.net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

I noticed that the following program invoking dlopen hangs forever if the
address sanitizer is used (but works fine without) consuming 100% CPU:

$ g++-9 -ggdb3 -fsanitize=address -Wextra -Wall -fPIC -shared -o libshlib.so
shlib.cpp
$ gcc-9 -ggdb3 -fsanitize=address -Wextra -Wall -o main main.c -ldl

$ gdb ./main
^C
Program received signal SIGINT, Interrupt.
__memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:143
143 ../sysdeps/x86_64/multiarch/memset-avx2.S: No such file or directory.
(gdb) bt
#0  __memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:143
#1  0x772c054a in __asan_handle_no_return () at
../../../../src/libsanitizer/asan/asan_rtl.cc:569
#2  0x771e102d in __interceptor___cxa_throw (a=0x60d00190,
b=0x72def8c0 , c=0x0)
at ../../../../src/libsanitizer/asan/asan_interceptors.cc:328
#3  0x72dfea79 in foo () at shlib.cpp:4
#4  0x72dfea87 in bar () at shlib.cpp:13
#5  0x00400942 in main () at main.c:11

Please note that the triggered exception is catched in the plugin and never
leaves the module boundaries.

main.c:
#include 
#include 

int main()
{
int (*bar)(void);
void *handle = dlopen("./libshlib.so", RTLD_NOW | RTLD_GLOBAL);
assert(handle);
bar = dlsym(handle, "bar");
assert(bar);
return bar();
}

shlib.cpp:
static void foo(void)
{
int i = 0;
throw(i);
}

extern "C" {
int bar(void);
};
int bar(void)
{
try {
foo();
} catch(int i) {
return i;
}
return -1;
}

Makefile:
CC = gcc-9
CXX = g++-9

all: libshlib.so main

libshlib.so: shlib.cpp
$(CXX) -ggdb3 -fsanitize=address -Wextra -Wall -fPIC -shared -o
libshlib.so shlib.cpp

main: main.c
$(CC) -ggdb3 -fsanitize=address -Wextra -Wall -o main main.c -ldl

clean:
rm -f libshlib.so main

PS: This example I found at https://bugzilla.redhat.com/show_bug.cgi?id=1649501
where nobody dealed with it.

[Bug lto/91313] [10 regression] r273908 breaks lto on power 7

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Aug  2 09:23:56 2019
New Revision: 274003

URL: https://gcc.gnu.org/viewcvs?rev=274003&root=gcc&view=rev
Log:
Properly detect working jobserver in gcc driver.

2019-08-02  Martin Liska  

PR lto/91313
* gcc.c (driver::maybe_run_linker): Call detect_jobserver
to detect working job server.
(driver::detect_jobserver): Test whether jobserver
is active from GCC driver. That will prevent situation where
GCC is invoked from a LD plugin and the linker already uses
file descriptors suggested by make.  That leads to a wrong
detection.
* gcc.h (driver): Add detect_jobserver.
* lto-wrapper.c (jobserver_active_p): Simplify sscanf by
not scanning for --jobserver-auth prefix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/gcc.h
trunk/gcc/lto-wrapper.c

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[luoxhu at cn dot ibm.com]

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

--- Comment #28 from Xiong Hu XS Luo  ---
(In reply to Richard Biener from comment #24)
> Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> has
> 
>   /* FIXME: Builtins corresponding to real functions probably should have
>  symbol table entries.  */
>   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> return false;
> 
> we could try to do sth like
> 
>   if (TREE_CODE (decl) == FUNCTION_DECL
>   && (fndecl_built_in_p (decl, BUILT_IN_MD)
>   || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
>   && !associated_internal_fn (decl
> return false;
> 
> but that would still leave us with too many undefineds I guess
> (gcc_unreachable for one).
> 
> We do not currently track builtins that do have a library implementation
> (whether that it is used in the end is another thing, but less important).
> 
> What we definitely can do is put a whitelist above like via the following
> which also catches the case of definitions of builtins.
> 
> Index: gcc/symtab.c
> ===
> --- gcc/symtab.c(revision 273968)
> +++ gcc/symtab.c(working copy)
> @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
>   first place.  */
>if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
>  return false;
> +
>/* FIXME: Builtins corresponding to real functions probably should have
>   symbol table entries.  */
> -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> -return false;
> +  if (TREE_CODE (decl) == FUNCTION_DECL
> +  && !definition
> +  && fndecl_built_in_p (decl))
> +{
> +  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> +   switch (DECL_FUNCTION_CODE (decl))
> + {
> + CASE_FLT_FN (BUILT_IN_ATAN2):
> + CASE_FLT_FN (BUILT_IN_SIN):
> +   return true;
> + default:
> +   break;
> + }
> +  return false;
> +}
>  
>/* We have real symbol that should be in symbol table.  However try to
> trim
>   down the refernces to libraries bit more because linker will otherwise

Hi Richard, no undefineds generated with below code, what's your opinion about
the updated code, please? Thanks.

diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 47a9143ae26..9d42a57b4b6 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2644,7 +2644,10 @@ write_symbol (struct streamer_tree_cache_d *cache,

   gcc_checking_assert (TREE_PUBLIC (t)
   && (TREE_CODE (t) != FUNCTION_DECL
-  || !fndecl_built_in_p (t))
+  || !fndecl_built_in_p (t, BUILT_IN_MD))
+  && (TREE_CODE (t) != FUNCTION_DECL
+  || !fndecl_built_in_p (t, BUILT_IN_NORMAL)
+  || associated_internal_fn (t) != IFN_LAST)
   && !DECL_ABSTRACT_P (t)
   && (!VAR_P (t) || !DECL_HARD_REGISTER (t)));

diff --git a/gcc/symtab.c b/gcc/symtab.c
index 63e2820eb93..ce74589b291 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -2377,7 +2377,10 @@ symtab_node::output_to_lto_symbol_table_p (void)
 return false;
   /* FIXME: Builtins corresponding to real functions probably should have
  symbol table entries.  */
-  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && (fndecl_built_in_p (decl, BUILT_IN_MD)
+ || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
+ && IFN_LAST == associated_internal_fn (decl
 return false;

   /* We have real symbol that should be in symbol table.  However try to trim

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Aug  2 08:40:34 2019
New Revision: 274000

URL: https://gcc.gnu.org/viewcvs?rev=274000&root=gcc&view=rev
Log:
2019-08-02  Richard Biener  

Backport from mainline
2019-07-31  Richard Biener  

PR tree-optimization/91178
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address):
Use tail-recursion.

* gcc.dg/torture/pr91178-2.c: New testcase.

2019-07-17  Richard Biener  

PR tree-optimization/91178
* tree-ssa.c (release_defs_bitset): Iterate from higher to
lower SSA names to avoid quadratic behavior in the common case.
* tree-data-ref.c (split_constant_offset): Add limit argument
and pass it down.  Initialize it from PARAM_SSA_NAME_DEF_CHAIN_LIMIT.
(split_constant_offset_1): Add limit argument and use it to
limit SSA def walking.  Optimize the common plus/minus case.

* gcc.dg/torture/pr91178.c: New testcase.

2019-07-12  Martin Sebor  

* doc/invoke.texi (ssa-name-def-chain-limit): Document new --param.
* params.def (PARAM_SSA_NAME_DEF_CHAIN_LIMIT): Add new --param.
* tree-vrp.c (vrp_prop::check_mem_ref): Use
PARAM_SSA_NAME_DEF_CHAIN_LIMIT.

* gcc.dg/Warray-bounds-43.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/Warray-bounds-43.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91178-2.c
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91178.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/doc/invoke.texi
branches/gcc-9-branch/gcc/params.def
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-data-ref.c
branches/gcc-9-branch/gcc/tree-ssa-sccvn.c
branches/gcc-9-branch/gcc/tree-ssa.c
branches/gcc-9-branch/gcc/tree-vrp.c

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 2 Aug 2019, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
> 
> --- Comment #5 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #3)
> 
> > That means this is a target issue, LTGT isn't an unordered compare.
> 
> So, it should create COMISS then?
> 
> The patch is then simple:
> 
> --cut here--
> Index: config/i386/i386-expand.c
> ===
> --- config/i386/i386-expand.c   (revision 273981)
> +++ config/i386/i386-expand.c   (working copy)
> @@ -2290,12 +2290,12 @@
>  case GE:
>  case LT:
>  case LE:
> +case LTGT:
>return false;
> 
>  case EQ:
>  case NE:
> 
> -case LTGT:
>  case UNORDERED:
>  case ORDERED:
>  case UNLT:
> --cut here--
> 
> (I just want to double-check, this stuff is a bit confusing to me).

That looks consistent with what the rest of the compiler does, yes.
ICC generates comiss as well (but two of them, never combining).
clang generates ucomiss even with -ftrapping-math -fno-finite-math-only
but that looks like a bug similar to this one.

[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Fri Aug  2 08:28:31 2019
New Revision: 273998

URL: https://gcc.gnu.org/viewcvs?rev=273998&root=gcc&view=rev
Log:
PR tree-optimization/91201
* config/i386/i386-expand.c (ix86_expand_vector_extract): For elt == 0
V16QImode extraction without sse4.1 try to use V4SImode lowpart
extraction.

* gcc.target/i386/sse2-pr91201-3.c: New test.
* gcc.target/i386/sse2-pr91201-4.c: New test.
* gcc.target/i386/sse2-pr91201-5.c: New test.
* gcc.target/i386/sse2-pr91201-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-3.c
trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-4.c
trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-5.c
trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-expand.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #3)

> That means this is a target issue, LTGT isn't an unordered compare.

So, it should create COMISS then?

The patch is then simple:

--cut here--
Index: config/i386/i386-expand.c
===
--- config/i386/i386-expand.c   (revision 273981)
+++ config/i386/i386-expand.c   (working copy)
@@ -2290,12 +2290,12 @@
 case GE:
 case LT:
 case LE:
+case LTGT:
   return false;

 case EQ:
 case NE:

-case LTGT:
 case UNORDERED:
 case ORDERED:
 case UNLT:
--cut here--

(I just want to double-check, this stuff is a bit confusing to me).

[Bug c++/79328] Wshadow and lambda captures

[fwyzard at gmail dot com]

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

--- Comment #2 from Andrea Bocci  ---
Created attachment 46658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46658&action=edit
simple test case

Build with

g++-9 test.cc -Wshadow -o test

[Bug c++/79328] Wshadow and lambda captures

[fwyzard at gmail dot com]

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

Andrea Bocci  changed:

   What|Removed |Added

 CC||fwyzard at gmail dot com

--- Comment #1 from Andrea Bocci  ---
If I may, I think at least this case


  // Warning considered erroneous
  // There is no default capture to get at the outer object
  void haveWarningBad (int x) {
[] { int x; };
  }


should be fixed not to produce any warnings.

[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
quoting rtl.def:

/* This is an ordered NE, ie !UNEQ, ie false for NaN.  */
DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)