[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #3 from Janne Blomqvist  ---
I'm seeing a failure in the testcase libgomp.fortran/appendix-a/a.28.5.f90
which looks like it might(?) be caused by this:

$ gfortran a.28.5.f90 
a.28.5.f90:29:20:

   29 |   CALL SUB1(A)
  |1
Error: Rank mismatch in argument ‘x’ at (1) (rank-1 and scalar)

Or is this something else?

[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=

[jb at gcc dot gnu.org]

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

Bug 68401 Summary: improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401

   What|Removed |Added

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

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #14 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist  ---
Author: jb
Date: Sat Aug 17 05:45:37 2019
New Revision: 274599

URL: https://gcc.gnu.org/viewcvs?rev=274599=gcc=rev
Log:
PR fortran/68401 Improve allocation error message

Improve the error message that is printed when a memory allocation
fails, by including the location, and the size of the allocation that
failed.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2019-08-17  Janne Blomqvist  

PR fortran/68401
* trans-decl.c (gfc_build_builtin_function_decls): Replace
os_error with os_error_at decl.
* trans.c (trans_runtime_error_vararg): Modify so the error
function decl is passed directly.
(gfc_trans_runtime_error): Pass correct error function decl.
(gfc_trans_runtime_check): Likewise.
(trans_os_error_at): New function.
(gfc_call_malloc): Use trans_os_error_at.
(gfc_allocate_using_malloc): Likewise.
(gfc_call_realloc): Likewise.
* trans.h (gfor_fndecl_os_error): Replace with gfor_fndecl_os_error_at.

libgfortran/ChangeLog:

2019-08-17  Janne Blomqvist  

PR fortran/68401
* gfortran.map: Add GFORTRAN_10 node, add _gfortran_os_error_at
symbol.
* libgfortran.h (os_error_at): New prototype.
* runtime/error.c (os_error_at): New function.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|9.0 |
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #16 from Jason Merrill  ---
Fixed properly for GCC 10.

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed for GCC 10 and 9.3.

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

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Sat Aug 17 01:34:00 2019
New Revision: 274597

URL: https://gcc.gnu.org/viewcvs?rev=274597=gcc=rev
Log:
PR c++/90393 - ICE with throw in ?:

I fixed the DR 1560 implementation properly for GCC 10, but for GCC 9 feel
that it's better not to change the meaning of well-formed code.  Reverting
the incomplete implementation fixes the ICEs.

* call.c (build_conditional_expr_1): Revert changes from
PR c++/64372 and c++/86205.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond15.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond16.C
Removed:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Sat Aug 17 01:34:00 2019
New Revision: 274597

URL: https://gcc.gnu.org/viewcvs?rev=274597=gcc=rev
Log:
PR c++/90393 - ICE with throw in ?:

I fixed the DR 1560 implementation properly for GCC 10, but for GCC 9 feel
that it's better not to change the meaning of well-formed code.  Reverting
the incomplete implementation fixes the ICEs.

* call.c (build_conditional_expr_1): Revert changes from
PR c++/64372 and c++/86205.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond15.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/expr/cond16.C
Removed:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c

[Bug c++/91477] New: error messages stop including column numbers for large source file

[huili80 at gmail dot com]

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

Bug ID: 91477
   Summary: error messages stop including column numbers for large
source file
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huili80 at gmail dot com
  Target Milestone: ---

At work we have generated headers that can be millions of lines. While
compiling with gcc-8.2.1, I noticed that I'm not getting column numbers in
error messages, only getting filenames and line numbers.

I initially tried adding -fshow-column but that didn't help.

After experimenting a bit, the problem appears to show up when header files are
large, regardless what code is actually in the headers, and regardless of
whether the code in the headers is related to the code that is erroneous.

I didn't try to find the exact file size to produce this problem, but I
observed that when the pre-processed source file had about 690k lines (~26MB in
size), column numbers were no longer shown in errors.

The only other compiler i had was gcc4.8.2 and I don't have the same problem.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #18)
> Created attachment 46723 [details]
> Compiler Diff
> 
> I accidentally attached an old patch, here is the right one :) And thanks
> for helping, Jerry, what will you be working on?

My first step is to get what you have set up here and get some test cases in
place and try some things, then I can look further at trying to understand.
Then go from there. Will let you know seprately from this PR so we dont clutter
it up here. I also need to coordinate with Steve as we look at it.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 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 that detects most cases of a statement function re-using the
name of the containing function.  The only situation that I cannot detect is

function a()
  a() = x
end function

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 35903 Summary: false Warray-bounds warning when passing quoted string to 
function strcmp(arg,"no");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/35903] false Warray-bounds warning when passing quoted string to function strcmp(arg,"no");

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #12 from Martin Sebor  ---
I haven't been able to reproduce the false positive with any of the test cases
here, with -O2 or -O3 and with -funsigned-chars or without.  Since there have
been updates in almost a decade I'm going to close this.  If someone still can
reproduce it please either reopen this bug or open a new one and include a test
case that reproduce the warning and compiles without errors.  Also mention the
target for which you are compiling -- at least one of the attachments looks
like it's from a powerpc system.

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |10.0

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01202.html

[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[matorola at gmail dot com]

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

--- Comment #1 from Anatoly Pugachev  ---
compiling under gcc-8 but without "-O2" in CFLAGS makes it PASS instead of FAIL
(segfault).

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Marek Polacek  ---
Well, patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01196.html

I'm not very optimistic about it being accepted, but so far no one has
submitted anything better.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[david.bolvansky at gmail dot com]

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

--- Comment #20 from Dávid Bolvanský  ---
Clang implemented [0] this diagnostic under -Wxor-used-as-pow.
From user perspective it would be reasonable if GCC follows this naming.

[0] https://reviews.llvm.org/D63423

[Bug c++/91475] Optimization causes infinite loop

[eric_musser at yahoo dot com]

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

--- Comment #2 from Eric Musser  ---
But in this case the undefineness is not directly related to the for loop.
Further the optimizer that changes the loop to maintain and compare j *
0x2001 as opposed to just j could detect certain overflow as the upperbound
for the loop is a constant (j < 9) -- since 9 * 0x2001 > (1<<31). In this
case the optimization could either be disabled or produce a warning. The fact
the end-condition of the for loop is optimized away completely suggests this is
not a runtime issue (the infinite loop is hardcoded into resulting assembly).

In the case the upperbound of the for loop is variable I agree it is not
possible to detect nor may it be worth disabling the optimization if there is
only a chance of overflow.

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[sje at gcc dot gnu.org]

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

--- Comment #16 from Steve Ellcey  ---
I built ggc-page.c with GCC_DEBUG_LEVEL 5 and I see:

Allocating object, requested size=360, actual=360 at 0x8726c210 on
0x10549200
Freeing object, actual size=360, at 0x8726c210 on 0x10549200

But then I wind up calling gt_ggc_mx_symtab_node with x_p of 0x8726c210.
I don't think I should be calling this (via ggc_mark_roots and  ggc_collect) if
it has already been freed.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #46714|0   |1
is obsolete||

--- Comment #18 from Nicolas Koenig  ---
Created attachment 46723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46723=edit
Compiler Diff

I accidentally attached an old patch, here is the right one :) And thanks for
helping, Jerry, what will you be working on?

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug 16 20:40:36 2019
New Revision: 274587

URL: https://gcc.gnu.org/viewcvs?rev=274587=gcc=rev
Log:
PR c++/85827
g++.dg/cpp1z/constexpr-if29.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if29.C
Modified:
trunk/gcc/cp/ChangeLog

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[mpolacek at gcc dot gnu.org]

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

Bug 85827 Summary: false positive for -Wunused-but-set-variable because of 
constexpr-if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827

   What|Removed |Added

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

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
For what it's worth several spec 2000 tests also won't compile any more after
this revision.

I guess -std=legacy all around!

[Bug c++/91475] Optimization causes infinite loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Signed integer overflow is undefined at runtime; this means we cannot error out
when it happens at compile time.  The warning is not done for loops on purpose
since those are normally places where the user wants to take advantage of the
undefineness.

Use -fsanitize=undefined to find it at runtime.
It is hard sometimes to find that the code will run into this code.

[Bug c++/91476] New: const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[abbeyj+gcc at gmail dot com]

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

Bug ID: 91476
   Summary: const reference variables sharing the same name in two
anonymous namespaces cause a multiple definition error
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

There is a problem when having two different variables both of which are const
references and which have the same name but are in different anonymous
namespaces.  You'll need at least two files to reproduce this, say a.cpp and
b.cpp.

a.cpp:
namespace { const int  = 1; }
int main() {}

b.cpp:
namespace { const int  = 2; }


Then compile and link:
$ g++ -c a.cpp b.cpp
$ g++ a.o b.o
b.o:(.rodata+0x0): multiple definition of `_ZGRN12_GLOBAL__N_13fooE_'
a.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status


This works fine in older versions of GCC and in clang.

Looking at the output on https://gcc.godbolt.org/z/A6LxAG shows the following
differences:
- The mangled name for "reference temporary #0 for (anonymous namespace)::foo"
changed from _ZGRN12_GLOBAL__N_13fooE0 to _ZGRN12_GLOBAL__N_13fooE_. 
Interestingly, godbolt.org is unable to demangle the second name.
- There is an additional line `.globl  _ZGRN12_GLOBAL__N_13fooE_`.  This seems
like the part causing the issue.

I originally found this when using objects of class type with user-defined
constructors.  I reduced it down to using `int` for this bug report.  Any
proposed fix should probably be tested with such types in addition to plain
`int`.


gcc version 9.1.0 (GCC)
Target: x86_64-pc-linux-gnu

[Bug c++/91475] New: Optimization causes infinite loop

[eric_musser at yahoo dot com]

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

Bug ID: 91475
   Summary: Optimization causes infinite loop
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric_musser at yahoo dot com
  Target Milestone: ---

The following code on x86-64 9.2.0 compiled with:

gcc -Wall -O2

unexpectedly produces wrong output and an infinite loop:

#include 
#include 

int main(int argc, char** argv) {
char buf[50];
for (int j = 0; j < 9; ++j) {
  std::cout << (j * 0x2001) << " " << j << std::endl;
  sprintf(buf, "%d", j);
}
return 0;
}

Output (truncated) is:
0 0

536870913 1
1073741826 2
1610612739 3
-2147483644 4
-1610612731 5
-1073741818 6
-536870905 7
8 8
536870921 9
1073741834 10
1610612747 11
-2147483636 12
-1610612723 13
...

The sprintf is present only to prevent the loop from being unrolled (and the
issue doesn't occur). The issue appears to because the code is being optimized
roughly as:

int main(int argc, char** argv) {
char buf[50];
for (int j = 0, running_j = 0; running_j != 9 * 0x2001LL ; running_j +=
0x2001, ++j) {
  std::cout << running_j << " " << j << std::endl;
  sprintf(buf, "%d", j);
}
return 0;
}


It loops because running_j is int32 and cannot possibly equal the pre-computed
total. The optimizer actually detects this and removes the end condition of the
for loop completely.

I realize the code is invoking undefined behavior because of signed overflow
with j * 0x2001LL but it seems either the compiler should error/warning
because of this or the for loop optimization should not happen. Without, the
sprintf I do see a warning of undefined behavior (in loop iteration 4).

I see other bugs similar to this but this is the only I see with a hardcoded
constant as the end condition of the for loop.

[Bug c++/85827] false positive for -Wunused-but-set-variable because of constexpr-if

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
This particular problem was fixed in r269433, because the condition is not
dependent.  I'll add the test.  For another problem not fixed by this rev see
PR81676.

[Bug c++/91474] New: Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[joey.dumont at gmail dot com]

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

Bug ID: 91474
   Summary: Internal compiler error when building mabi=32
mips64-elf cross-compiler: segfault in
parallel_settings.cc
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.dumont at gmail dot com
CC: joey.dumont at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: mips64-elf
 Build: x86_64-pc-linux-gnu

Created attachment 46722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46722=edit
Patch to enable the 32-bit ABI

Let me preface this by saying that this is my first bug report, and I could not
find information on what to submit for issues with cross-compilers. Let me know
what information you need and I'll gladly provide it.

When trying to build a gcc-9.2.0 mips64-elf cross-compiler with gcc-9.1.0, I
get an internal compiler error when trying to compile
`libstdc++-v3/src/c++98/parallel_settings.cc`: 

```
libtool: compile: 
/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/./gcc/xgcc
-shared-libgcc
-B/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/./gcc
-nostdinc++
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src/.libs
-L/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/libsupc++/.libs
-B/usr/mips64-elf/bin/ -B/usr/mips64-elf/lib/ -isystem /usr/mips64-elf/include
-isystem /usr/mips64-elf/sys-include -mabi=32
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/../libgcc
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/include/mips64-elf
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/include
-I/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/libsupc++
-std=gnu++98 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=parallel_settings.lo -g -O2 -mabi=32 -D_GLIBCXX_PARALLEL -c
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc
-o parallel_settings.o
during RTL pass: split2
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc:
In function '(static initializers for
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc)':
/home/valandil/software/n64-dev/mips64-elf-gcc/src/gcc-9.2.0/libstdc++-v3/src/c++98/parallel_settings.cc:42:1:
internal compiler error: Segmentation fault
   42 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[9]: *** [Makefile:912: parallel_settings.lo] Error 1
make[9]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src/c++98'
make[8]: *** [Makefile:730: all-recursive] Error 1
make[8]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3/src'
make[7]: *** [Makefile:562: all-recursive] Error 1
make[7]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3'
make[6]: *** [Makefile:487: all] Error 2
make[6]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/32/libstdc++-v3'
make[5]: *** [Makefile:855: multi-do] Error 1
make[5]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[4]: *** [Makefile:823: all-multi] Error 2
make[4]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[3]: *** [Makefile:562: all-recursive] Error 1
make[3]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[2]: *** [Makefile:487: all] Error 2
make[2]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc/mips64-elf/libstdc++-v3'
make[1]: *** [Makefile:11232: all-target-libstdc++-v3] Error 2
make[1]: Leaving directory
'/home/valandil/software/n64-dev/mips64-elf-gcc/src/build-gcc'
make: *** [Makefile:951: all] Error 2
```

Here's the output of `gcc -v`:

```
$ 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

[Bug fortran/91471] f951: internal compiler error: gfc_variable_attr(): Bad array reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-16
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch that prevents the ICE.  Remove ICE-on-valid-code
tag as the code is invalid.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to seurer from comment #0)
> make -k check-target-libgomp
> RUNTESTFLAGS=fortran.exp=libgomp.fortran/appendix-a/a.28.5.f90
> 
> FAIL: libgomp.fortran/appendix-a/a.28.5.f90   -O  (test for excess errors)

Easy enough to "fix" with

Index: testsuite/libgomp.fortran/appendix-a/a.28.5.f90  
=== 
--- testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Revision 274370)   
+++ testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Arbeitskopie)  
@@ -1,5 +1,5 @@ 
 ! { dg-do compile }
-! { dg-options "-w" }  
+! { dg-options "-w -std=legacy" }  
 !  
 ! "-w" added as libgomp/testsuite seemingly cannot parse with  
 ! dg-warning Fortran's output. Fortran warns for "call sub1(a)" 

but the real problem is that this is illegal Fortran. You cannot have
mismatching ranks in an argument, even if it "happens" to work.

Same thing with the SPEC code, I suppose.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger  ---
Hope all is now working again.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  ---
I am getting this at the moment after applying patches to trunk.

../../trunk/gcc/fortran/trans-stmt.c: In function ‘tree_node*
gfc_trans_deallocate(gfc_code*)’:
../../trunk/gcc/fortran/trans-stmt.c:6925:4: error: ‘is_native_coarray’ was not
declared in this scope
 6925 |is_native_coarray = ar_attr.codimension;
  |^
../../trunk/gcc/fortran/trans-stmt.c:6928:45: error: ‘is_native_coarray’ was
not declared in this scope
 6928 |   if (expr->rank || is_coarray_array || is_native_coarray)
  | ^
make[2]: *** [Makefile:1118: fortran/trans-stmt.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:4360: all-gcc] Error 2
make: *** [Makefile:958: all] Error 2

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[edlinger at gcc dot gnu.org]

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

--- Comment #18 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 16:37:04 2019
New Revision: 274578

URL: https://gcc.gnu.org/viewcvs?rev=274578=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

Backport from mainline
2019-08-16  Bernd Edlinger  

PR tree-optimization/91109
* lra-int.h (lra_need_for_scratch_reg_p): Declare.
* lra.c (lra): Use lra_need_for_scratch_reg_p.
* lra-spills.c (lra_need_for_scratch_reg_p): New function.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/lra-int.h
branches/gcc-9-branch/gcc/lra-spills.c
branches/gcc-9-branch/gcc/lra.c

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[edlinger at gcc dot gnu.org]

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

--- Comment #17 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 16:31:13 2019
New Revision: 274577

URL: https://gcc.gnu.org/viewcvs?rev=274577=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

Backport from mainline
2019-08-07  Bernd Edlinger  

PR tree-optimization/91109
* lra-remat.c (update_scratch_ops): Remove assignment of the
hard register.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/lra-remat.c

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-08/msg01172.ht
   ||ml

--- Comment #12 from Janne Blomqvist  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01172.html

With this the test.f90 in the original report prints something like:

In file 'test.f90', around line 5: Error allocating 4294967296 bytes: Cannot
allocate memory

Error termination. Backtrace:
#0  0x400874 in test
at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4
#1  0x4008d3 in main
at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4


(yes, the location is off a little bit)

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #18 from Dávid Bolvanský  ---
a.c

int foo(void) __attribute__((const));


int main(void) {
return foo();
}

b.c

#include 

int foo(void) {
puts("BUM");
return 0;
}

gcc a.c b.c -Wall -Wextra -flto -o bum


It would be nice to get a warning.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  ---
(In reply to Steve Kargl from comment #15)
> On Wed, Aug 14, 2019 at 08:33:04PM +, koenigni at gcc dot gnu.org wrote:
> > 
> > Yes, I'm still working on it (slowly, though, sorry :( ). Here is a diff of 
> > my
> > current trunk. I don't know what exactly changed since the last version, but
> > the biggest two things still missing are actually deallocating coarrays in
> > DEALLOCATE-statements or in types and all the intrinsics like CO_SUM. Locks
> > already work, though.
> 
> Thanks for the update.  No need to apologize.  I assume you
> are off doing work, school, fun stuff, ...
> 
> I'm running out of bugs that I can fix, so thought I would
> venture into coarray territory.  Having a SHM backend might
> be easier to work with than opencoarray and openmpi.

I will be loading up these patches on my new machine here to as well. so we
start to grind away on this.

[Bug preprocessor/77672] wrong rich location in warning: writing a terminating nul past the end

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #9 from Martin Sebor  ---
The output looks good now and has since 7.1 so we can resolve this bug.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Lei YU from comment #7)
> Additional information.
> 
> std::experimental::fundamentals_v1::any has no problem, so the below code
> compiles fine.

The difference is that std::experimental::any doesn't constrain the any(T&&)
constructor on is_copy_constructible, instead it just makes it a hard error
(using a static assert in the constructor body).

std::any has to SFINAE the any(T&&) constructor away if T is not copy
constructible, which leads to a cycle when that constructor is being considered
during instantiation of is_copy_constructible.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I've made the change in r274574.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 16 15:47:25 2019
New Revision: 274574

URL: https://gcc.gnu.org/viewcvs?rev=274574=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/pr19807.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C

[Bug middle-end/90676] default GIMPLE dumps lack information

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 16 15:47:25 2019
New Revision: 274574

URL: https://gcc.gnu.org/viewcvs?rev=274574=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/pr19807.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far, but I'd like to backport this for 9.3 too.

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch, rejects-valid
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01181.html

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
(In reply to Eric Botcazou from comment #6)
> This looks similar to PR target/55023.

Yes.  Looking at how scan_insn() evolved since PR target/55023, it is
clear why this is a regression.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[edlinger at gcc dot gnu.org]

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

--- Comment #16 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Aug 16 15:34:47 2019
New Revision: 274573

URL: https://gcc.gnu.org/viewcvs?rev=274573=gcc=rev
Log:
2019-08-16  Bernd Edlinger  

PR tree-optimization/91109
* lra-int.h (lra_need_for_scratch_reg_p): Declare.
* lra.c (lra): Use lra_need_for_scratch_reg_p.
* lra-spills.c (lra_need_for_scratch_reg_p): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-int.h
trunk/gcc/lra-spills.c
trunk/gcc/lra.c

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Let me fix it.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-16
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I think it's just a mistake in the pattern:

/* { dg-final { scan-tree-dump-times "\\\[\\\(void .\\\) \\\+ 8B\\\]" 3
"optimized" { target { ! store_merge } } } }
   { dg-final { scan-tree-dump-times "  \\\[\\\(void .\\\) \\\+
8B\\\]" 3 "optimized" { target { store_merge } } } } */

No store merging takes place here so the test should use the second pattern
unconditionally.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
It looks like -std=legacy is needed for wrf.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
In case of wrf, there are

  INTEGER  :: Field(*)
  INTEGER  :: FieldType
...
 ELSE IF ( FieldType .EQ. WRF_INTEGER ) THEN

 CALL call_pkg_and_dist_int ( fcn,&
   Hndl , DateStr , VarName , Field , FieldType , Comm , IOComm , &
   DomainDesc , MemoryOrder , Stagger , DimNames ,  &
   DomainStart , DomainEnd ,&
   MemoryStart , MemoryEnd ,&
   PatchStart , PatchEnd ,  &
   Status )

call_pkg_and_dist_int has

  REAL,   INTENT(INOUT):: Field(*)
  INTEGER   ,INTENT(IN):: FieldType

Field is used as some kind of generic pointer.

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
481.wrf in SPEC CPU 2006 also got

Error: Type mismatch in argument 'field' at (1); passed INTEGER(4) to REAL(4)
module_io.fppized.f90:18713:23:

18713 |Status )
  |   1

[Bug sanitizer/91115] stack-buffer-overflow on memset local variable when creating thread on ARM Linux

[fhsueh at roku dot com]

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

--- Comment #6 from Fred Hsueh  ---
Sorry for the long silence ... more on this:

I tracked down where the std::thread() that was causing this issue.

It seems that there are many similar long running tasks that needs to be
completed so we keep a queue of 10x threads. As one finishes, another is kicked
off. But initially, 10x such threads are started in quick succession.

This leads me to believe maybe there's a gap in the locking on the ASAN
metadata side.

I'll see if I can get an example going.

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
The problem seems to be that we're losing DECL_READ_P on the parm_decl v.

[Bug fortran/91473] New: [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[seurer at gcc dot gnu.org]

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

Bug ID: 91473
   Summary: [10 regression] test case
libgomp.fortran/appendix-a/a.28.5.f90 fails starting
with r274551
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make -k check-target-libgomp
RUNTESTFLAGS=fortran.exp=libgomp.fortran/appendix-a/a.28.5.f90

FAIL: libgomp.fortran/appendix-a/a.28.5.f90   -O  (test for excess errors)

# of unexpected failures1


spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.28.5.f90
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-O -w
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp
-S -o a.28.5.s
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.28.5.f90:29:20:
Error: Rank mismatch in argument 'x' at (1) (rank-1 and scalar)
compiler exited with status 1
FAIL: libgomp.fortran/appendix-a/a.28.5.f90   -O  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.28.5.f90:29:20:
Error: Rank mismatch in argument 'x' at (1) (rank-1 and scalar)

[Bug c++/81676] Wrong warning with unused-but-set-parameter within 'if constexpr'

[vittorio.romeo at outlook dot com]

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

Vittorio Romeo  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #3 from Vittorio Romeo  ---
Found this today, still present in gcc trunk (9.2+). Example:

int main()
{
auto f = [](auto a, auto b) {
if constexpr (sizeof(b) == 1) {
return a;
} else {
return b;
}
};

return f(1, 1) + f(1, 'a');
}

https://gcc.godbolt.org/z/SOvLEV

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 16 13:17:04 2019
New Revision: 274570

URL: https://gcc.gnu.org/viewcvs?rev=274570=gcc=rev
Log:
2019-08-16  Richard Biener  

PR target/91469
* config/i386/i386-features.c
(general_scalar_chain::replace_with_subreg): Stop at memory operands.

* gcc.target/i386/pr91469-1.c: New testcase.
* gcc.target/i386/pr91469-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91469-1.c
trunk/gcc/testsuite/gcc.target/i386/pr91469-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[clyon at gcc dot gnu.org]

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

--- Comment #15 from Christophe Lyon  ---
Since r274532 (gcc-9-branch), I am seeing:
FAIL: gcc.c-torture/execute/20040709-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

target arm-none-linux-gnueabi
--with-mode arm
--with-cpu cortex-a9

The same test passes on arm-none-linux-gnueabihf, or using --with-mode thumb

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2019-08-16 5:47 a.m., ebotcazou at gcc dot gnu.org wrote:
> Created attachment 46721
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46721=edit
> Tentative fix
Testing.  Looking at change, it now seems obvious.  Thanks for investigating.

The change fixes compilation of testcase.

[Bug c/91472] New: gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 91472
   Summary: gmp testsuite segfaults with gcc-8 and gcc-9, works
fine with gcc-7
   Product: gcc
   Version: 8.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=gmp
h=sparc64=2%3A6.1.2%2Bdfsg-4=1565898628=
0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
  Target Milestone: ---
  Host: sparc64-*-*

Starting from gcc-8, the testsuite of gmp fails with the test segfaulting:

PASS: t-divis_2exp
PASS: t-cong
PASS: t-cong_2exp
PASS: t-sizeinbase
PASS: t-set_str
PASS: t-aorsmul
../../test-driver: line 107: 227694 Segmentation fault  "$@" > $log_file
2>&1
FAIL: t-cmp_d
PASS: t-cmp_si
PASS: t-hamdist
PASS: t-oddeven
PASS: t-popcount
PASS: t-set_f
PASS: t-io_raw
PASS: t-import
PASS: t-export
PASS: t-pprime_p
PASS: t-nextprime
PASS: t-remove
PASS: t-limbs

Testsuite summary for GNU MP 6.1.99

# TOTAL: 64
# PASS:  63
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/mpz/test-suite.log
Please report to gmp-b...@gmplib.org, see
https://gmplib.org/manual/Reporting-Bugs.html


The same gmp builds and tests fine with gcc-7.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Except -O0, which is what I find surprising.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #15 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #14)
> I can reproduce the link failure. For some reason Clang requires that
> constructor at -O1, but not at any other optimization level.

It will require it at any -O level with fno-inline.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||link-failure
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #14 from Jonathan Wakely  ---
I can reproduce the link failure. For some reason Clang requires that
constructor at -O1, but not at any other optimization level.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #13 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #12)
> I didn't export that because nothing should need it. Nothing in libstdc++
> derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer
> to that type, because it's an implementation detail.
> 
> The explicit instantiation tells Clang not to emit that constructor, but it
> shouldn't cause it to depend on that constructor.

Well, Clang emits call to C2 version somehow. Should it be reported as a but to
Clang?

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
I didn't export that because nothing should need it. Nothing in libstdc++
derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer to
that type, because it's an implementation detail.

The explicit instantiation tells Clang not to emit that constructor, but it
shouldn't cause it to depend on that constructor.

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Created attachment 46721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46721=edit
Tentative fix

Please give it a try on the PA.

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
I have a tentative fix.

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> template

This needs to exclude pointers as well as class types, because ...

>   struct is_referenceable_function : false_type { };
> 
> template
>   struct is_referenceable_function __void_t(std::declval()))>>

This static cast does an explicit conversion, which is allowed from X*& to X**.

The other alternative would be to test for implicit conversion, not explicit.

[Bug fortran/91471] New: f951: internal compiler error: gfc_variable_attr(): Bad array reference

[SameeranJayant.Joshi at amd dot com]

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

Bug ID: 91471
   Summary: f951: internal compiler error: gfc_variable_attr():
Bad array reference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SameeranJayant.Joshi at amd dot com
  Target Milestone: ---

I can again reproduce the bug
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283)
on trunk(checked on godbolt compiler explorer) as well my distro gfortran
version:

*test case:

program dynamic
implicit none
integer,dimension(:), allocatable :: x
allocate(x(1))
stop x(1)
end program dynamic

*compiling commands:

swamimauli$ gfortran dynamic_alloc.f08
f951: internal compiler error: gfc_variable_attr(): Bad array reference
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


*gcc version:


swamimauli@ubuntu:~/workspace/fortran_programs/feature_stop$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.3.0-6ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --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-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 8.3.0 (Ubuntu 8.3.0-6ubuntu1) 
swamimauli@ubuntu:~/workspace/fortran_programs/feature_stop$

[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
This looks similar to PR target/55023.

[Bug other/91255] Can't use define_subst in target that uses set_attr_alternative

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug other/91255] Can't use define_subst in target that uses set_attr_alternative

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Aug 16 09:32:36 2019
New Revision: 274564

URL: https://gcc.gnu.org/viewcvs?rev=274564=gcc=rev
Log:
[gensupport] PR 91255: Do not error out immediately on set_attr_alternative
with define_subst

I'm trying to add a define_subst use in the arm backend but am getting many
build errors complaining about:
`set_attr_alternative' is unsupported by `define_subst'

Looking at the gensupport.c code it iterates over all define_insns and errors
if any of them have set_attr_alternative.

The usecase I'm targetting doesn't involve patterns with set_attr_alternative,
so I would like to make the define_subst handling
more robust to only error out if the define_subst is actually attempted on a
set_attr_alternative.

This patch produces the error only if the set_attr_alternative attr matches the
subst name.
This allows a build of the arm backend with a define_subst usage to succeed.

PR other/91255
* gensupport.c (has_subst_attribute): Error out on set_attr_alternative
only if subst_name matches curr_attr string.

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

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

--- Comment #11 from Viktor Ostashevskyi  ---
I assume that problem comes from explicit instantiation:

extern template class __shared_ptr;

which was added in c8fb3443911413cc88f316305fc6b7bf4861ccaa.

It prevent Clang in emitting "C2" version of constructors on its own.

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, needs-reduction
 CC||law at gcc dot gnu.org
 Blocks||24639
   Target Milestone|--- |10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Created attachment 46720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46720=edit
unreduced testcase

A bit reduced testcase from trans-intrinsic.c (in case it goes latent there due
to changes).  Needs more reduction to capture the meat of things.  The code
basically does

int a, b;
for (int i = 0; i < 2; ++i)
  if (i == 0)
a = 1;
  else
b = 2;

use a/b

and we warn on one of the uses.  It's not that simple of course since this
kind of simple testcase is handled well...

[Bug tree-optimization/91470] New: [10 Regression] bogus uninitialized warning in trans-intrinsic.c

[rguenth at gcc dot gnu.org]

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

Bug ID: 91470
   Summary: [10 Regression] bogus uninitialized warning in
trans-intrinsic.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

r274563 installed

Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c   (revision 274538)
+++ gcc/fortran/trans-intrinsic.c   (working copy)
@@ -5428,7 +5428,7 @@ gfc_conv_intrinsic_findloc (gfc_se *se,
   tree type;
   tree tmp;
   tree found;
-  tree forward_branch;
+  tree forward_branch = NULL_TREE;
   tree back_branch;
   gfc_loopinfo loop;
   gfc_ss *arrayss;

to silence a maybe-uninit warning caused by jump threading things in
a way not recognizable by the uninit warning predicate analysis.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
What about "base object constructors" (mangled with C2)?

For simple case like:

---
#include 
#include 

int main(int argc, char** argv)
{
  for (const auto& dirElem : std::filesystem::directory_iterator(argv[1]))
std::cout << dirElem.path().filename() << '\n';
}
---

When compiling with Clang 8 against libstdc++ from GCC 9.2.0 I got:

in function
`std::filesystem::directory_iterator::directory_iterator(std::filesystem::directory_iterator&&)':
fs.cpp:(.text._ZNSt10filesystem18directory_iteratorC2EOS0_[_ZNSt10filesystem18directory_iteratorC2EOS0_]+0x1):
undefined reference to `std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)'


Checking in libstdc++.so showed that symbols are exported, but only for
complete object constructor:

_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_

Not sure why, but Clang emits call to base object constructor:

_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_


I've checked Clang8 vs libstdc++ from GCC 8.3.0 and see that it emits calls to
same base object ctor, but its definition is also emitted, so no linker error
occur.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[avieira at gcc dot gnu.org]

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

Bug 91460 Summary: gcc -mpreferred-vector-width=256 is slower than 
-mpreferred-vector-width=128 for some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91460

   What|Removed |Added

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

[Bug tree-optimization/88915] Try smaller vectorisation factors in scalar fallback

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||skpgkp2 at gmail dot com

--- Comment #4 from avieira at gcc dot gnu.org ---
*** Bug 91460 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/91460] gcc -mpreferred-vector-width=256 is slower than -mpreferred-vector-width=128 for some loops

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||avieira at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from avieira at gcc dot gnu.org ---
Yes this looks like a duplicate of PR 88915. I'll mark it as such.

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

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|[9/10 regression] All macOS |[9 regression] All macOS
   |asan execution tests FAIL   |asan execution tests FAIL

--- Comment #14 from Iain Sandoe  ---
fixed on trunk.

NOTE: on earlier Darwin platforms (10.7-10.15) it is highly recommended to
build llvm-symbolizer and then:

export ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer

This is because the "atos" implementation for these versions does not seem to
be 100% compatible with the newer sanitisers - the effect is extremely long
timeouts on test fails (so we're talking about hours to run the asan.exp suite
if that happens).  AFAIK, atos is not open-sourced for Darwin, so the best fix
is to use the LLVM version - which is.

---

The following modification is being tested for inclusion in 9.3 (it just makes
the additional check dependent on USING_MAC_INTERPOSE which is fine since the
symbol table for libasan is not affected by this on Darwin/Mac OS).

There is no soname bump needed for this (although, technically, the fault is
not fixed for non-Darwin, in practice the problem has not manifest there
anyway)

diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
index 867240d244..6efbc1df7f 100644
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -5,7 +5,7 @@ gcc_version := $(shell @get_gcc_base_ver@
$(top_srcdir)/../gcc/BASE-VER)

 DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1
-DCAN_SANITIZE_UB=0
 if USING_MAC_INTERPOSE
-DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
+DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
-DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0
 endif
 AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
-fno-ipa-icf
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)

[Bug tree-optimization/91459] Tail-Call Optimization is not performed when return value is assumed.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Part of that might be because of:
  // predicted unlikely by early return (on trees) predictor.

That seems not true, the other side is more unlikely ...

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Elsewhere we have sth with similar effect, but only disqualifying toplevel MEM.

  if (!MEM_P (src))
{
  replace_with_subreg_in_insn (insn, reg, reg);
  bitmap_clear_bit (conv, INSN_UID (insn));
}

and

if (!MEM_P (dst) || !REG_P (src))
  replace_with_subreg_in_insn (insn, reg, reg);

in the end it might be an ordering issue of splitting out memory operands
and converting regs (convert_registers vs. convert_insn).

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The result is correct at least, so testing this patch.

(insn 72 69 14 3 (set (reg:SI 115)
(mem:SI (plus:SI (mult:SI (reg/v:SI 92 [ _23 ])
(const_int 4 [0x4]))
(symbol_ref:SI ("d") [flags 0x2]  ))
[1 d S4 A32])) -1
 (nil))
(insn 14 72 15 3 (set (subreg:V4SI (reg/v:SI 90 [ f ]) 0)
(umax:V4SI (subreg:V4SI (reg:SI 114) 0)
(subreg:V4SI (reg:SI 115) 0))) 3665 {*sse4_1_umaxv4si3}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Index: gcc/config/i386/i386-features.c
===
--- gcc/config/i386/i386-features.c (revision 274536)
+++ gcc/config/i386/i386-features.c (working copy)
@@ -613,6 +613,10 @@ general_scalar_chain::replace_with_subre
   if (x == reg)
 return gen_rtx_SUBREG (vmode, new_reg, 0);

+  /* But not in memory addresses.  */
+  if (GET_CODE (x) == MEM)
+return x;
+
   const char *fmt = GET_RTX_FORMAT (GET_CODE (x));
   int i, j;
   for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)


fixes this, but then the replacement has higher cost in the end(?).

[Bug ipa/91447] [10 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed now.

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> STV converts the register in address:
> 
> (insn 14 56 15 3 (parallel [
> (set (reg/v:SI 90 [ f ])
> (umax:SI (reg/v:SI 92 [ _23 ])
> (mem:SI (plus:SI (mult:SI (reg/v:SI 92 [ _23 ])
> (const_int 4 [0x4]))
> (symbol_ref:SI ("d") [flags 0x2]   0x7f4bf0fcbcf0 d>)) [1 d S4 A32])))
> (clobber (reg:CC 17 flags))
> ]) 973 {*umaxsi3_1}
>  (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
> 
> which is certainly wrong.

Yes, it does that via general_scalar_chain::make_vector_copies when replacing
all uses:

  for (ref = DF_REG_USE_CHAIN (regno); ref; ref = DF_REF_NEXT_REG (ref))
if (bitmap_bit_p (insns, DF_REF_INSN_UID (ref)))
  {
rtx_insn *insn = DF_REF_INSN (ref);
replace_with_subreg_in_insn (insn, reg, vreg);

if (dump_file)
  fprintf (dump_file, "  Replaced r%d with r%d in insn %d\n",
   regno, REGNO (vreg), INSN_UID (insn));
  }

I think we need to disqualify this instruction from being STVed because
of the address-use of the reg.  I've seen code to do that that probably
needs extending to cover {U,S}{MIN,MAX}.  Looking.

[Bug ipa/91447] [10 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Fri Aug 16 08:10:55 2019
New Revision: 274562

URL: https://gcc.gnu.org/viewcvs?rev=274562=gcc=rev
Log:
Add missed to a opt-info dump.

2019-08-16  Martin Liska  

PR ipa/91447
* g++.dg/ipa/ipa-icf-4.C: Add -missed for target that
don't have aliases.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
STV converts the register in address:

(insn 14 56 15 3 (parallel [
(set (reg/v:SI 90 [ f ])
(umax:SI (reg/v:SI 92 [ _23 ])
(mem:SI (plus:SI (mult:SI (reg/v:SI 92 [ _23 ])
(const_int 4 [0x4]))
(symbol_ref:SI ("d") [flags 0x2]  )) [1 d S4 A32])))
(clobber (reg:CC 17 flags))
]) 973 {*umaxsi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

which is certainly wrong.

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug c/91463] missing -Warray-bounds accessing past the end of a statically initialized flexible array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #2 from Richard Biener  ---
I believe the frontend should emit warnings for this kind of statically
determinable cases, VRP only runs at -O2+.  It should be possible to
split out code like maybe_warn_array_bound (tree expr, bool addr_p, void
(*get_value_range) (tree name, wide_int , wide_int )) and use
that from the FE with a NULL get_value_range callback.

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
And one similar issue:

$ cat ice2.i
int a, b, c, d;
int *e;
void fn1() {
  b = c > 0 ? c : 0;
  d += e[b];
  a = d > 0 ? d : 0;
}

$ gcc -Os -m32 --param scev-max-expr-size=0 -mavx512vnni -funroll-all-loops
ice2.i -c
during RTL pass: ira
ice2.i: In function ‘fn1’:
ice2.i:7:1: internal compiler error: in elimination_costs_in_insn, at
reload1.c:3547
7 | }
  | ^
0x6ba890 elimination_costs_in_insn
/home/marxin/Programming/gcc/gcc/reload1.c:3547
0xd4228d calculate_elim_costs_all_insns()
/home/marxin/Programming/gcc/gcc/reload1.c:1609
0xbe715d ira_costs()
/home/marxin/Programming/gcc/gcc/ira-costs.c:2305
0xbe0879 ira_build()
/home/marxin/Programming/gcc/gcc/ira-build.c:3432
0xbd7807 ira
/home/marxin/Programming/gcc/gcc/ira.c:5352
0xbd7807 execute
/home/marxin/Programming/gcc/gcc/ira.c:5663

[Bug middle-end/91462] [8/9/10 Regression] missing -Warray-bounds writing to an empty flexible array member in a ctor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.4

[Bug tree-optimization/91460] gcc -mpreferred-vector-width=256 is slower than -mpreferred-vector-width=128 for some loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|i386|x86_64-*-*, i?86-*-*,
   ||aarch64-*-*
 CC||andre.simoesdiasvieira@arm.
   ||com
  Component|rtl-optimization|tree-optimization
 Blocks||53947

--- Comment #3 from Richard Biener  ---
I believe we have a duplicate PR for exactly this case and Andre is working on
this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/91459] Tail-Call Optimization is not performed when return value is assumed.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-16
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think this has a duplicate somewhere.  The reason is we end up with

foo1 (int a, int b)
{
   [local count: 1073741824]:
  function_returns_only_1_or_doesnt_return (a_2(D), b_3(D));
  return 1;

and thus no obvious tail-call opportunity.  Here it is EVRP replacing
result_5 with 1 in

   :
  result_5 = function_returns_only_1_or_doesnt_return (a_2(D), b_3(D));
  if (result_5 == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  // predicted unlikely by early return (on trees) predictor.
  return result_5;

   :
  __builtin_unreachable ();

where it would be better to transform this idiom to unconditional
return result_5 early.

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |testsuite

--- Comment #1 from Richard Biener  ---
Martin changed the dumping

[Bug target/91469] [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-16
  Known to work||9.1.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug target/91469] New: [10 Regression] ICE in extract_insn, at recog.c:2310 since r274481

[marxin at gcc dot gnu.org]

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

Bug ID: 91469
   Summary: [10 Regression] ICE in extract_insn, at recog.c:2310
since r274481
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, uros at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Yet another fallout from the the patch:

$ cat ice.i
int a, b, e;
long long c;
int d[6];

void fn1() {
  int i;
  unsigned f;
  c = a;
  f = i;
  for (; i < b; i++)
if (d[i] > f)
  f = d[i];
  e = f;
}

$ gcc ice.i -funroll-loops -O2 -fno-gcse -m32 -mavx512vbmi -fno-ivopts
ice.i: In function ‘fn1’:
ice.i:14:1: error: unrecognizable insn:
   14 | }
  | ^
(insn 72 69 14 3 (set (reg:SI 115)
(mem:SI (plus:SI (mult:SI (subreg:V4SI (reg:SI 114) 0)
(const_int 4 [0x4]))
(symbol_ref:SI ("d") [flags 0x2] ))
[1 d S4 A32])) -1
 (nil))
during RTL pass: subreg3
ice.i:14:1: internal compiler error: in extract_insn, at recog.c:2310
0x6bab09 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x6bab25 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x6b8cad extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2310
0x16d1af7 decompose_multiword_subregs
/home/marxin/Programming/gcc/gcc/lower-subreg.c:1540
0x16d2c2d execute
/home/marxin/Programming/gcc/gcc/lower-subreg.c:1808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/91468] Suspicious codes in ipa-prop.c and ipa-cp.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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