[Bug target/91518] [9/10 Regression] segfault when run CPU2006 465.tonto since r263875

[luoxhu at cn dot ibm.com]

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

--- Comment #3 from Xiong Hu XS Luo  ---
(In reply to Richard Biener from comment #2)
> Not seen on x86_64.  Given you bisected to r263875 it should appear with GCC
> 9 as well - are the actual GCC 9 releases also affected?
> 
> I assume this is ppc64le.
> 
> Unless we know more I assume this is a target issue.  Please build with debug
> info and see where exactly and why it segfaults.

Yes.  It still fails on both power8 and power9 even on GCC 10 (gcc version
10.0.0 20190823 (experimental) (GCC)).  
Reset to r263875, the register content shown as below, Wrong address filled for
lwzx instruction ($r8 is expected to be a valid address value):

140│0x101a5718 <+552>:   ld  r12,888(r31)
141│0x101a571c <+556>:   ld  r0,856(r31)
142│0x101a5720 <+560>:   ld  r17,880(r31)
143│0x101a5724 <+564>:   ld  r8,848(r31)
144│0x101a5728 <+568>:   addir21,r21,1
145│0x101a572c <+572>:   cmpwcr7,r21,r30
146│0x101a5730 <+576>:   mulld   r4,r3,r12
147│0x101a5734 <+580>:   add r18,r4,r0
148│0x101a5738 <+584>:   mulld   r11,r18,r17
149├>   0x101a573c <+588>:   lwzxr3,r8,r11 

44: /x $r3 = 0x1
45: /x $r8 = 0x77
46: /x $r11 = 0x1770
47: /x $r18 = 0x7d
48: /x $r17 = 0x30
49: /x $r4 = 0x1
50: /x $r0 = 0x7c
51: /x $r3 = 0x1
52: /x $r12 = 0x1
53: /x $r21 = 0x2
54: /x $r8 = 0x77
55: /x $r17 = 0x30
56: /x $r0 = 0x7c
57: /x $r12 = 0x1

I am not sure whether this is the debug info you needed? 
function callstack is already pasted in #c0, as source code is not allowed to
be pasted, the segment fault place is in line 9375 of file mol.fppized.f90 of
function make_image_of_shell.  Thanks.

[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #2)
> (In reply to prathamesh3492 from comment #1)
> > Author: prathamesh3492
> > Date: Wed Aug 21 18:34:43 2019
> > New Revision: 274805
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=274805=gcc=rev
> > Log:
> > 2019-08-21  Prathamesh Kulkarni  
> > 
> > PR target/90724
> > * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
> > in reg if it fails aarch64_plus_operand predicate.
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/config/aarch64/aarch64.c
> 
> Did this fix it?

On trunk, yes. Needs to be backported to gcc-9-branch.

Thanks,
Prathamesh

[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to prathamesh3492 from comment #1)
> Author: prathamesh3492
> Date: Wed Aug 21 18:34:43 2019
> New Revision: 274805
> 
> URL: https://gcc.gnu.org/viewcvs?rev=274805=gcc=rev
> Log:
> 2019-08-21  Prathamesh Kulkarni  
> 
>   PR target/90724
>   * config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
>   in reg if it fails aarch64_plus_operand predicate.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/aarch64/aarch64.c

Did this fix it?

[Bug target/90552] attribute((optimize(3))) not overriding -Os

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to uros from comment #5)
> Author: uros
> Date: Thu May 23 19:46:56 2019
> New Revision: 271576
> 
> URL: https://gcc.gnu.org/viewcvs?rev=271576=gcc=rev
> Log:
>   PR target/90552
>   * config/i386/i386.c (gen_rtx_cost):
>   Use ix86_tune_cost instead of ix86_cost.
> 
> testsuite/ChangeLog:
> 
>   PR target/90552
>   * gcc.target/i386/pr90552.c: New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.target/i386/pr90552.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/i386/i386.c
> trunk/gcc/testsuite/ChangeLog

Did this fix it?

[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 91304, which changed state.

Bug 91304 Summary: maybe_unused attribute ignored on variable declared in if 
declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304

   What|Removed |Added

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

[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug 23 00:06:25 2019
New Revision: 274839

URL: https://gcc.gnu.org/viewcvs?rev=274839=gcc=rev
Log:
PR c++/91304 - prefix attributes ignored in condition.
* parser.c (cp_parser_condition): Handle prefix attributes.

* g++.dg/cpp0x/gen-attrs-70.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-70.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/91490] [9 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[9/10 Regression] bogus |[9 Regression] bogus
   |argument missing|argument missing
   |terminating nul warning on  |terminating nul warning on
   |strlen of a flexible array  |strlen of a flexible array
   |member  |member

--- Comment #4 from Martin Sebor  ---
Fixed in r274837.  I'm not sure this should be backported.  It suppresses bogus
warnings but also introduces new warnings for invalid code.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #21 from Martin Sebor  ---
I just noticed the test fail in my test run with -m32 on x86_64:

FAIL: g++.dg/tree-ssa/pr90883.C   scan-tree-dump dse1 "Deleted redundant store:
.*.a = {}"

With -m32 the pattern is dse2 dump but the target matches the dse1 directive:

// { dg-final { scan-tree-dump "Deleted redundant store: .*\.a = {}" "dse1" {
target { ! i?86-*-* } } } }

[Bug middle-end/91490] [9/10 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Aug 22 23:09:26 2019
New Revision: 274837

URL: https://gcc.gnu.org/viewcvs?rev=274837=gcc=rev
Log:
PR middle-end/91490 - bogus argument missing terminating nul warning on strlen
of a flexible array member

gcc/c-family/ChangeLog:

PR middle-end/91490
* c-common.c (braced_list_to_string): Add argument and overload.
Handle flexible length arrays and unions.

gcc/testsuite/ChangeLog:

PR middle-end/91490
* c-c++-common/Warray-bounds-7.c: New test.
* gcc.dg/Warray-bounds-39.c: Expect either -Warray-bounds or
-Wstringop-overflow.
* gcc.dg/strlenopt-78.c: New test.

gcc/ChangeLog:

PR middle-end/91490
* builtins.c (c_strlen): Rename argument and introduce new local.
Set no-warning bit on original argument.
* expr.c (string_constant): Pass argument type to fold_ctor_reference.
Fold empty and zero constructors into empty strings.
* gimple-fold.c (fold_nonarray_ctor_reference): Return a STRING_CST
for missing initializers.
* tree.c (build_string_literal): Handle optional argument.
* tree.h (build_string_literal): Add defaulted argument.
* gimple-ssa-warn-restrict.c (maybe_diag_access_bounds): Check
no-warning bit on original expression.


Added:
trunk/gcc/testsuite/c-c++-common/Warray-bounds-7.c
trunk/gcc/testsuite/gcc.dg/strlenopt-78.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/expr.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-39.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[skpgkp2 at gmail dot com]

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

--- Comment #14 from Sunil Pandey  ---
(In reply to Richard Biener from comment #7)
> (In reply to Sunil Pandey from comment #4)
> > Actually it is spec cpu 2017 521.wrf benchmark getting this problem while
> > compiling. Compilation taking forever, you can see while compiling file
> > module_first_rk_step_part1.fppized.f90 as a representative.
> 
> Note this file contains a single function which (besides USEing quite a
> number
> of modules...) has only function calls involving a lot of parameters
> effectively forwarding parameters from the function.  Thus
> 
> SUBROUTINE foo (psim, ..., ims, ime, jms, jme)
> REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
> call sub1 (PSIM=psim, ...)
> call sub2 (PSIM=psim, ...)
> END SUBROUTINE
> 
> with a _lot_ of arrays being passed through.  A simple testcase like
> 
> SUBROUTINE sub1 (psim, ims, ime, jms, jme)
> REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
> END SUBROUTINE
> SUBROUTINE foo (psim, ims, ime, jms, jme)
> REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
> call sub1 (psim, ims, ime, jms, jme)
> END SUBROUTINE
> 
> doesn't show any extra loops generated though, so I'm not sure what to
> look after.

It seems very hard to create a small test case which reproduce the long compile
time problem. Unfortunately, I'm not allowed to upload spec source file. Also
it's very big with lots of module dependency. Assuming you have spec 2017
sources,

Here is unmodified command line, which show compile time problem.

Spec build dir: 
===

/local/skpandey/gccwork/specx5/cpu2017/benchspec/CPU/521.wrf_r/build/build_base_gcc-10.0.0-x86-64.

Before the commit in question:
==

Take 41 second to compile unmodified file with -O2 -march=skylake

$ time
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release.a4ba5c3ec624008e899a8bcb687359db25140c23/usr/gcc-10.0.0-x86-64/bin/gfortran
 -m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O2 -march=skylake -funroll-loops
-fconvert=big-endian module_first_rk_step_part1.fppized.f90

real0m41.295s
user0m41.031s
sys 0m0.204s

After the commit in question:
=

It take about 12 minute with -O2 -march=skylake

$ time
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release/usr/gcc-10.0.0-x86-64/bin/gfortran
 -m64 -c -o module_first_rk_step_part1.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -O2 -march=skylake -funroll-loops
-fconvert=big-endian module_first_rk_step_part1.fppized.f90

real11m59.498s
user11m53.304s
sys 0m4.835s


With higher optimization like -O3 or -Ofast, it take even longer and I have to
kill it.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Thu Aug 22 19:36:21 2019
New Revision: 274835

URL: https://gcc.gnu.org/viewcvs?rev=274835=gcc=rev
Log:
rs6000: Use unspec_volatile for darn (PR91481)

Every call to darn should deliver a *new* random number; such calls
should not be CSEd together.  So they should be unspec_volatile, not
plain unspec.


PR target/91481
* config/rs6000/rs6000.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32,
and UNSPEC_DARN_RAW.
(unspecv): New enumerator values UNSPECV_DARN, UNSPECV_DARN_32, and
UNSPECV_DARN_RAW.
(darn_32): Use an unspec_volatile, and UNSPECV_DARN_32.
(darn_raw): Use an unspec_volatile, and UNSPECV_DARN_RAW.
(darn): Use an unspec_volatile, and UNSPECV_DARN.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
*** Bug 91524 has been marked as a duplicate of this bug. ***

[Bug fortran/91524] [10 regression] module_comm_dm.fppized.f90 in cpu 2017 ICEs in fortran compiler starting with r274551

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from kargl at gcc dot gnu.org ---
Already known and a fix is pending review.

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

[Bug c++/91525] New: ICE (Segmentation Fault) on a bool conversion operator with concepts

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 91525
   Summary: ICE (Segmentation Fault) on a bool conversion operator
with concepts
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

The following code segfaults on gcc 7 and gcc 8.

It seems to be fixed in gcc 9, but a variant of the following code still
segfault on gcc 9 and 10.

```c++
#include 
#include 
namespace ranges {
struct view_interface {
  template < bool = true > operator bool();
#if 1
  template < bool B = true> requires false operator bool(); // ICE on gcc <= 10
#elif 1
  template < bool B = true> requires false explicit operator bool(); // ICE on
gcc <= 8. This code is working since gcc 9.
#else
  template < bool B = true, std::enable_if_t> explicit operator bool(); // a
possible workaround
#endif
};

template < typename View > struct impl {
  template < typename... Ts, typename V = View >
  static auto bind(Ts... ts) -> decltype(V::bind((ts)...));
};

template < typename > struct view;
template < typename Fun > view< Fun > make_view(Fun);
template < typename View > struct view {
  template < typename Arg, typename Pipe >
  friend auto operator|(Arg, Pipe)
  -> decltype(Pipe::pipe(std::declval< Arg >, std::declval< Pipe >()));
  View view_;
  template < typename Rng, typename Vw > static auto pipe(Rng, Vw v) {
return v.view_(0);
  }
  template < typename... Ts, typename V = View >
  auto operator()(Ts... ts)
  -> decltype(make_view(impl< V >::bind(view_, (ts)...)));
};
struct f {
  template < typename g > static auto bind(f h, g t) {
return std::bind(h, std::placeholders::_1, t);
  }
  template < typename a, typename ValRng >
  auto operator()(a, ValRng) -> view_interface;
};
view< f > join;
} std::string e() {
  std::vector< std::string > extensions;
  std::string i;
  auto o = extensions | ranges::join(i);
  std::cout << o;
}

```

This will produce this error:

```terminal
> g++-9 -std=c++17 -fconcepts -c ice.cpp'
ice.cpp: In function ‘std::string e()’:
ice.cpp:53:16: internal compiler error: Segmentation fault
   53 |   std::cout << o;
  |^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

Tested compiler versions are:

```terminal
> g++-7 --version
g++-7 (GCC) 7.4.1 20181207
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

> g++-9 --version 
g++ (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> g++-git --version
g++-git (GCC) 10.0.0 20190709 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

[Bug libgomp/91473] Test case libgomp.fortran/appendix-a/a.28.5.f90 is invalid

[seurer at gcc dot gnu.org]

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

--- Comment #9 from seurer at gcc dot gnu.org ---
Note pr91524

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
(In reply to kargl from comment #7)

> The function check_externals_expr
> is somewhat odd.  It is declared to return int, but all return
> statements are 'return 0'.  This suggests to me that proper
> declaration for this function is void.

It's a callback function for the expression walker. A non-zero
return value would mean an immediate return. From frontend-passes.c:

#define WALK_SUBEXPR(NODE) \
  do\
{   \
  result = gfc_expr_walker (&(NODE), exprfn, data); \
  if (result)   \
return result;  \
}   \
  while (0)

[Bug fortran/91524] New: [10 regression] module_comm_dm.fppized.f90 in cpu 2017 ICEs in fortran compiler starting with r274551

[seurer at gcc dot gnu.org]

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

Bug ID: 91524
   Summary: [10 regression] module_comm_dm.fppized.f90 in cpu 2017
ICEs in fortran compiler 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: ---

Starting with revision r274551 we began to see the following failure when
building the cpu 2017 test 521.wrf_r.  Note that in order to get this to not
generate fortran compilation errors I had to add -std=legacy as per pr91473.

It was definitely r274551 as 521.wrf_r builds fine with r274550.

/home/seurer/gcc/install/gcc-trunk/bin/gfortran -c -o module_comm_dm.fppized.o
-I. -I./netcdf/include -I./inc -m64 -O3 -mcpu=power8
-Wno-deprecated-declarations -fconvert=big-endian -std=legacy
module_comm_dm.fppized.f90

in gfc_format_decoder, at fortran/error.c:947
0x102697d3 gfc_format_decoder
/home/seurer/gcc/gcc-trunk/gcc/fortran/error.c:947
0x11789f77 pp_format(pretty_printer*, text_info*)
/home/seurer/gcc/gcc-trunk/gcc/pretty-print.c:1390
0x1176e2a7 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/seurer/gcc/gcc-trunk/gcc/diagnostic.c:1025
0x1026939f gfc_warning
/home/seurer/gcc/gcc-trunk/gcc/fortran/error.c:792
0x1026964b gfc_error_opt
/home/seurer/gcc/gcc-trunk/gcc/fortran/error.c:1280
0x1026b44f gfc_error(char const*, ...)
/home/seurer/gcc/gcc-trunk/gcc/fortran/error.c:1342
0x10346093 ambiguous_symbol
/home/seurer/gcc/gcc-trunk/gcc/fortran/symbol.c:3169
0x1034f8eb gfc_find_sym_tree(char const*, gfc_namespace*, int, gfc_symtree**)
/home/seurer/gcc/gcc-trunk/gcc/fortran/symbol.c:3240
0x1034f943 gfc_find_symbol(char const*, gfc_namespace*, int, gfc_symbol**)
/home/seurer/gcc/gcc-trunk/gcc/fortran/symbol.c:3291
0x10448743 check_externals_expr
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5397
0x1044c973 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:4919
0x1044cc4f gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:4926
0x104501cf gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5343
0x10450203 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5345
0x10450203 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5345
0x104517b7 gfc_check_externals(gfc_namespace*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5453
0x10451813 gfc_check_externals(gfc_namespace*)
/home/seurer/gcc/gcc-trunk/gcc/fortran/frontend-passes.c:5458
0x102f50e3 gfc_parse_file()
/home/seurer/gcc/gcc-trunk/gcc/fortran/parse.c:6326
0x1036438f gfc_be_parse_file
/home/seurer/gcc/gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake: *** [/home/seurer/gcc/cpu2017/benchspec/Makefile.defaults:386:
module_comm_dm.fppized.o] Error 1
Error with make.diffwrf_521 'specmake --output-sync -j50 build
TARGET=diffwrf_521':

  
  Please review this file:
   
"/home/seurer/gcc/cpu2017/benchspec/CPU/521.wrf_r/build/build_base_none./make.diffwrf_521.out"
  

  Command returned exit code 2
  Error with make!
*** Error building 521.wrf_r base

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Yes, the treatment of namespaces was dogdgy.

This is fixed in https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01438.html (not
yet reviewed).

HJ, does this patch also fix the original test case?

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Thomas, this is fixed by

% svn diff gcc/fortran/frontend-passes.c 
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c   (revision 274676)
+++ gcc/fortran/frontend-passes.c   (working copy)
@@ -5391,7 +5391,7 @@ check_externals_expr (gfc_expr **ep, int *walk_subtree
 return 0;

   gsym = gfc_find_gsymbol (gfc_gsym_root, sym->name);
-  if (gsym == NULL)
+  if (gsym == NULL || gsym->ns == NULL)
 return 0;

   gfc_find_symbol (sym->name, gsym->ns, 0, _sym);


I don't know if this is correct.  The function check_externals_expr
is somewhat odd.  It is declared to return int, but all return
statements are 'return 0'.  This suggests to me that proper
declaration for this function is void.

[Bug target/91522] [10 Regression] STV is slow

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Uh, all other DF_REG_REG_CHAIN uses need to be updated as well I guess, how
we convert defs and uses seems to be a slight mess :/  I'm going to try
to rewrite this part to

 for insn in insns
   for def in insn
 if def in defs_conv
   replace def in insn with subreg of new pseudo from new defs-map
   emit copy from new def to original scalar def
 else
   replace def with subreg
   for use in insn
 if use in defs_conv & ~defs
   replace use in insn with subreg of new pseudo from new defs-map
   emit copy from old scalar def to new def
 else
   replace use with subreg [of new pseudo from new defs-map]

that should also support chains where not all defs of a pseudo are part
of the chain.  Since we have ud and du chains we can use those more.

[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 #7 from Fred Hsueh  ---
This looks more like an odd interaction with ASAN and fork(). The process
reporting the stack-buffer-overflow is actually a fork() child of the main
process.

Something similar to https://github.com/google/sanitizers/issues/836
"LeakSanitizer and AddressSanitizer detect false leaks after fork() with
threads".

Still working on a working demo, but it might be something like this:

- Create thread #1
- Create thread #2
- thread #1 completes and cleans up.
- fork()

child:
- create thread #3 (uses same spot as #1 ok!)
- create thread #4 (uses same spot as #2 ... ASAN detects it writing memory in
another thread's memory).

[Bug rtl-optimization/91523] New: Register allocation picks sub-optimal alternative with scratch registers

[rearnsha at gcc dot gnu.org]

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

Bug ID: 91523
   Summary: Register allocation picks sub-optimal alternative with
scratch registers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: vmakarov at redhat dot com, wdijkstr at arm dot com
  Target Milestone: ---
Target: arm-none-eabi

consider this simple testcase:
_Bool f (unsigned a, unsigned b) { return a | b; }

when compiled for arm-eabi with options -O2 -march=armv7-a -mthumb, the
compiler generates the following code sequence:

orrsr3, r0, r1  @ 8 [c=4 l=4]  *iorsi3_compare0_scratch/2
ite ne
movne   r0, #1  @ 24[c=8 l=6]  *p *thumb2_movsi_insn/1
moveq   r0, #0  @ 25[c=8 l=6]  *p *thumb2_movsi_insn/1
bx  lr  @ 28[c=8 l=4]  *thumb2_return

which is correct, but sub-optimal.  The pattern selected for the orrs has
picked a sub-optimal alternative.

The pattern being matched is

(define_insn "*iorsi3_compare0_scratch"
  [(set (reg:CC_NOOV CC_REGNUM)
(compare:CC_NOOV
 (ior:SI (match_operand:SI 1 "s_register_operand" "%r,0,r")
 (match_operand:SI 2 "arm_rhs_operand" "I,l,r"))
 (const_int 0)))
   (clobber (match_scratch:SI 0 "=r,l,r"))]
  "TARGET_32BIT"
  "orrs%?\\t%0, %1, %2"
  [(set_attr "conds" "set")
   (set_attr "arch" "*,t2,*")
   (set_attr "length" "4,2,4")
   (set_attr "type" "logics_imm,logics_reg,logics_reg")]
)

and the insn matching it is

(insn 7 21 22 2 (parallel [
(set (reg:CC_NOOV 100 cc)
(compare:CC_NOOV (ior:SI (reg:SI 119)
(reg:SI 120))
(const_int 0 [0])))
(clobber (scratch:SI))
]) "/home/rearnsha/work/pdtools/gcc-tests/cmpdi.c":3:35 96
{*iorsi3_compare0_scratch}
 (expr_list:REG_DEAD (reg:SI 120)
(expr_list:REG_DEAD (reg:SI 119)
(nil

Given that both input operands are dead, there is no reason why the compiler
can't pick alternative 1 from the insn and use a scratch that clobbers one of
the inputs (either directly, or via a commutative swap).  However it insists on
allocating a different register (r3) and then using alternative 2 which is more
expensive (32-bit insn instead of 16-bit insn).

Note the pattern shown above is updated in r274822 to add the thumb2
alternative that we want to match here.

[Bug target/91522] [10 Regression] STV is slow

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So in particular

  for (ref = DF_INSN_UID_DEFS (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
if (!HARD_REGISTER_P (DF_REF_REG (ref)))
  for (def = DF_REG_DEF_CHAIN (DF_REF_REGNO (ref));
   def;
   def = DF_REF_NEXT_REG (def))
analyze_register_chain (candidates, ref);

looks odd since that iterates over all defs in insn_uid, then over
all defs of that register everywhere else in the function and
analyze_register_chain then iterating over the corresponding def->use
chain.  I'd say the iteration over all defs everywhere else is
not necessary and it should be simply

Index: config/i386/i386-features.c
===
--- config/i386/i386-features.c (revision 274764)
+++ config/i386/i386-features.c (working copy)
@@ -419,10 +419,7 @@ scalar_chain::add_insn (bitmap candidate
   df_ref def;
   for (ref = DF_INSN_UID_DEFS (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
 if (!HARD_REGISTER_P (DF_REF_REG (ref)))
-  for (def = DF_REG_DEF_CHAIN (DF_REF_REGNO (ref));
-  def;
-  def = DF_REF_NEXT_REG (def))
-   analyze_register_chain (candidates, def);
+  analyze_register_chain (candidates, ref);
   for (ref = DF_INSN_UID_USES (insn_uid); ref; ref = DF_REF_NEXT_LOC (ref))
 if (!DF_REF_REG_MEM_P (ref))
   analyze_register_chain (candidates, ref);

which fixes the slowness.  I'm going to test that.

[Bug c++/91521] [9/10 Regression] expression incorrectly evaluated as function with trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Started with r263836 so mine :(.

[Bug target/91522] [10 Regression] STV is slow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Target||x86_64-*-* i?86-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug target/91522] New: [10 Regression] STV is slow

[rguenth at gcc dot gnu.org]

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

Bug ID: 91522
   Summary: [10 Regression] STV is slow
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Compiling module_domain.fppized.f90 from 521.wrf with -Ofast -march=haswell
reveals

 machine dep reorg  :  89.07 ( 95%)   0.02 ( 18%)  89.10 ( 95%)
 54 kB (  0%)
 TOTAL  :  95.13  0.13 95.32   
 103803 kB

perf reports (checking is enabled but -fno-checking supplied):

  83.74%  f951  f951 [.] (anonymous
namespace)::scalar_chain::analyze_register_chain
   5.80%  f951  f951 [.] bitmap_bit_p   
   5.13%  f951  f951 [.] (anonymous
namespace)::general_scalar_chain::mark_dual_mode_def

which is exactly what I noticed when reviewing the pass functionality:

  /* ???  The following is quadratic since analyze_register_chain
 iterates over all refs to look for dual-mode regs.  Instead this
 should be done separately for all regs mentioned in the chain once.  */

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Btw, for me module_configure.fppized.f90 is much more problematic, compiling
longest and using most memory.  IIRC that one has long series of initialization
expressions.  And

 load CSE after reload  : 143.49 ( 41%)   0.02 (  3%) 143.52 ( 41%)
   1001 kB (  0%)

(known issue I think)

Then there's module_alloc_space_0.fppized.f90 with similar

 load CSE after reload  :  55.97 ( 61%)   0.00 (  0%)  55.97 ( 60%)
341 kB (  0%)

and more of these... :/

And module_domain.fppized.f90 with

 machine dep reorg  :  89.07 ( 95%)   0.02 ( 18%)  89.10 ( 95%)
 54 kB (  0%)

that's probably STV ... same for module_dm.fppized.f90

module_first_rk_step_part1.fppized.f90 compile is also slow with

 callgraph ipa passes   :  21.30 ( 14%)   0.13 (  9%)  21.44 ( 14%)
  95303 kB ( 11%)
 alias stmt walking :  17.93 ( 12%)   0.12 (  8%)  18.16 ( 12%)
136 kB (  0%)
 tree FRE   :  14.19 (  9%)   0.03 (  2%)  14.32 (  9%)
   2744 kB (  0%)
 complete unrolling :   6.07 (  4%)   0.02 (  1%)   6.08 (  4%)
  95401 kB ( 11%)
 load CSE after reload  :  33.62 ( 22%)   0.01 (  1%)  33.63 ( 22%)
174 kB (  0%)

and solve_em.fppized.f90 might be similar.

Looking at .original of module_first_rk_step_part1.fppized.f90 it is
the decomposed "grid" that gets passed along causing all the re-packs.
So the caller has

  SUBROUTINE first_rk_step_part1 (   grid , ...
TYPE ( domain ), INTENT(INOUT) :: grid
...
CALL phy_prep ( config_flags,&
grid%mut, grid%muu, grid%muv, grid%u_2,  &
grid%v_2, grid%p, grid%pb, grid%alt, &
grid%ph_2, grid%phb, grid%t_2, grid%tsk, moist,
num_moist,   &
grid%rho,th_phy, p_phy, pi_phy, grid%u_phy, grid%v_phy,
 &
p8w, t_phy, t8w, grid%z, grid%z_at_w, dz8w,  &
grid%p_hyd, grid%p_hyd_w, grid%dnw,  &
grid%fnm, grid%fnp, grid%znw, grid%p_top,&
grid%rthraten,   &
grid%rthblten, grid%rublten, grid%rvblten,   &
grid%rqvblten, grid%rqcblten, grid%rqiblten, &
grid%rucuten,  grid%rvcuten,  grid%rthcuten, &
grid%rqvcuten, grid%rqccuten, grid%rqrcuten, &
grid%rqicuten, grid%rqscuten,&
grid%rushten,  grid%rvshten,  grid%rthshten, &
grid%rqvshten, grid%rqcshten, grid%rqrshten, &
grid%rqishten, grid%rqsshten, grid%rqgshten, &
grid%rthften,  grid%rqvften, &
grid%RUNDGDTEN, grid%RVNDGDTEN, grid%RTHNDGDTEN, &
grid%RPHNDGDTEN,grid%RQVNDGDTEN, grid%RMUNDGDTEN,&
!jdf
grid%landmask,grid%xland, &
!jdf
ids, ide, jds, jde, kds, kde,&
ims, ime, jms, jme, kms, kme,&
grid%i_start(ij), grid%i_end(ij),&
grid%j_start(ij), grid%j_end(ij),&
k_start, k_end   )

and more of that while TYPE (domain) having

real  ,DIMENSION(:,:,:)   ,POINTER   :: rucuten
real  ,DIMENSION(:,:) ,POINTER   :: mut
...

so here are the assumed-shaped arrays.  Note the packing is done
conditional like

contiguous.11171 = (D.83839.dim[0].stride == 1 && D.83839.dim[1].stride ==
D.83839.dim[0].stride * ((D.83839.dim[0].ubound - D.83839.dim[0].lbound) + 1))
&& D.83839.dim[2].stride == D.83839.dim[1].stride * ((D.83839.dim[1].ubound -
D.83839.dim[1].lbound) + 1);
if (__builtin_expect ((integer(kind=8)) contiguous.11171, 1, 50))
  { 
arg_ptr.11170 = (real(kind=4)[0:] * restrict) grid->u_phy.data;
  }
else
  { 
D.83779 = (real(kind=4)[0:] *) grid->u_phy.data;
... repack ...
  }

so this simply exposes quite a number of loop nests in this file while
there were no loops but only calls before (repack + the actual calls).

Given calls might be inlined it seems to be worth expanding the repacking
inline.  IIRC the original motivation of adding the inline expansion
was exactly such a case, correct?

So a testcase for the "regression" would be a function with a single
call stmt with a _lot_ of arguments all in need of repacking.

[Bug c++/91521] [9/10 Regression] expression incorrectly evaluated as function with trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I guess -> is confusing us.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #11)

> > One or two dimensional?
> 
> Two or three dimensional.  I didn't review all callees and
> arguments but there seems to be a 1:1 match, so both
> callers and callees have matching argument specifications
> dimension(ims:ime,jms:jme).

Can you isolate an example where packing or unpacking occurs, but
should not? Maybe the analysis of what is contiguous and what
is not could be improved to fix this.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[ma...@linux-mips.org]

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

--- Comment #35 from Maciej W. Rozycki  ---
So presumably the actual solution for n32 would be the same as with x32
and SIB, which IIUC cannot rely on hardware wrapping around the address
space either.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[ma...@linux-mips.org]

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

--- Comment #34 from Maciej W. Rozycki  ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX control bit forces address calculations i.e. base + imm or base + reg to
> be performed with 32-bit rules but allows 64 instruction usage. Since there
> is a processor mode that is perfectly capable of meeting the requirements of
> a program with 64bit data and 32bit pointers then the solution is to set PX
> for N32 rather than UX.

This is impractical because as I say Linux has to support processors that
have no CP0.Status.PX bit and do have to rely on CP0.Status.UX instead.

NB Richard, n32 is 64-bit mode, pretty much like x86's x32, except that
invented some 20 years earlier.  So regs are already DImode as are stack
slots, etc.

[Bug c++/91521] [9/10 Regression] expression incorrectly evaluated as function with trailing return type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||8.3.0
   Target Milestone|--- |9.3

[Bug debug/91507] wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Note that lldb has

(lldb) p zzz
(char *[2]) $0 = ([0] = "abc", [1] = "cde")

for the proposed variant with an extra DW_AT_type in the specification DIE and

(lldb) p zzz
error: incomplete type 'char *[]' where a complete type is required

for the variant GCC currently generates.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 22 Aug 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
> 
> --- Comment #10 from Thomas Koenig  ---
> 
> > Yes, but in the WRF file I see no assumed-shape arrays but all
> > appear to be of dimension(low:high,...) style.
> 
> One or two dimensional?

Two or three dimensional.  I didn't review all callees and
arguments but there seems to be a 1:1 match, so both
callers and callees have matching argument specifications
dimension(ims:ime,jms:jme).  OTOH "matching" is probably
known only losely because those ims,ime,jms and jme are
arguments to both caller and callee and passed on from caller
to callee.  Not sure if the FE knows they are not modified,
but then still no repacking should be required?

> Code like
> 
>   subroutine foo(a)
>   real, intent(in), dimension(*) :: a
>   end subroutine foo
> 
>   real, dimension(n,m) :: a
>   call foo(a(low:high,low2,high2))
> 
> will also trigger a repack, because foo expects
> a contiguous memory argument.
> 
> Code like
> 
>   real, dimension(10) :: a
>   call foo(a(from:to))
> 
> should not repack, because the memory is contiguous.
> 
>

[Bug c++/91521] New: [9/10 Regression] expression incorrectly evaluated as function with trailing return type

[aron.ujvary at nng dot com]

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

Bug ID: 91521
   Summary: [9/10 Regression] expression incorrectly evaluated as
function with trailing return type
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aron.ujvary at nng dot com
  Target Milestone: ---

As of g++ 8.3, the following code is well-formed:

struct foo {
int bar() { return 0; }
foo* operator->() { return this; }
};

int main()
{
int pt(foo()->bar());
return pt;
}

With g++ 9.1.0, 9.2.0, 10.0.0 20190822 (experimental), compilation fails with
"error: ‘parameter’ function with trailing return type not declared with ‘auto’
type specifier"
error message when compiling with c++11 or above, and with
"error: trailing return type only available with ‘-std=c++11’ or
‘-std=gnu++11’"
error message when compiling with c++03.

clang++ 8.0.1 also compiles this snippet just fine.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[patrickdepinguin at gmail dot com]

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

--- Comment #33 from Thomas De Schampheleire  ---
(In reply to Andrew Pinski from comment #32)
> >I'm currently using -march=octeon3   or -march=octeon2  as appropriate.
> 
> Can you report this to Marvell (Cavium)?  O32 was not used much on Octeon.


Yes, I will.
However, please note that I am using N32, not O32.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[pinskia at gcc dot gnu.org]

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

--- Comment #32 from Andrew Pinski  ---
>I'm currently using -march=octeon3   or -march=octeon2  as appropriate.

Can you report this to Marvell (Cavium)?  O32 was not used much on Octeon.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[patrickdepinguin at gmail dot com]

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

--- Comment #31 from Thomas De Schampheleire  ---
(In reply to Maciej W. Rozycki from comment #27)
> Yes, it is the same problem, the same address calculation occurs here,
> and the lack of 32-bit address space wraparound is a part of the n32
> Linux ABI, which implies support for processors that do not support such
> a wraparound in hardware (no CP0.Status.PX bit).
> 
> You may try experimenting with ISA/ASE selection options, so that LWX is
> not considered a valid instruction by GCC.  Otherwise I can't help with
> finding a workaround as I don't know one offhand and I'm not involved
> with MIPS development anymore, sorry.  And neither is Doug BTW.
> 
> This really ought to be fixed properly in GCC.

I'm currently using -march=octeon3   or -march=octeon2  as appropriate.
I'm not really confident in changing this, as there will be other impact too.

As a quick workaround/test, I will try letting the '-mno-lxc1-sxc1' flag also
control the use of the lwx and similar instructions, as follows:

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 23e1672b586..5dee3fbe29f 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1194,17 +1194,17 @@ struct mips_cpu_info {

 /* ISA has lwxs instruction (load w/scaled index address.  */
 #define ISA_HAS_LWXS   ((TARGET_SMARTMIPS || TARGET_MICROMIPS) \
-&& !TARGET_MIPS16)
+&& !TARGET_MIPS16 && mips_lxc1_sxc1)

 /* ISA has lbx, lbux, lhx, lhx, lhux, lwx, lwux, or ldx instruction. */
-#define ISA_HAS_LBX(TARGET_OCTEON2)
-#define ISA_HAS_LBUX   (ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LHX(ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LHUX   (TARGET_OCTEON2)
-#define ISA_HAS_LWX(ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LWUX   (TARGET_OCTEON2 && TARGET_64BIT)
+#define ISA_HAS_LBX(TARGET_OCTEON2 && mips_lxc1_sxc1)
+#define ISA_HAS_LBUX   ((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LHX((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LHUX   (TARGET_OCTEON2 && mips_lxc1_sxc1)
+#define ISA_HAS_LWX((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LWUX   (TARGET_OCTEON2 && TARGET_64BIT &&
mips_lxc1_sxc1)
 #define ISA_HAS_LDX((ISA_HAS_DSP || TARGET_OCTEON2) \
-&& TARGET_64BIT)
+&& TARGET_64BIT && mips_lxc1_sxc1)

 /* The DSP ASE is available.  */
 #define ISA_HAS_DSP(TARGET_DSP && !TARGET_MIPS16)

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---

> Yes, but in the WRF file I see no assumed-shape arrays but all
> appear to be of dimension(low:high,...) style.

One or two dimensional?

Code like

  subroutine foo(a)
  real, intent(in), dimension(*) :: a
  end subroutine foo

  real, dimension(n,m) :: a
  call foo(a(low:high,low2,high2))

will also trigger a repack, because foo expects
a contiguous memory argument.

Code like

  real, dimension(10) :: a
  call foo(a(from:to))

should not repack, because the memory is contiguous.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[patrickdepinguin at gmail dot com]

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

--- Comment #30 from Thomas De Schampheleire  ---
(In reply to mpf from comment #29)
> I don't remember the detail of this issue but I believe I was convinced that
> it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The
> PX control bit forces address calculations i.e. base + imm or base + reg to
> be performed with 32-bit rules but allows 64 instruction usage. Since there
> is a processor mode that is perfectly capable of meeting the requirements of
> a program with 64bit data and 32bit pointers then the solution is to set PX
> for N32 rather than UX.

This would have to be done by the kernel when switching to an application,
correct? And then only for n32 applications, not for n64 or others.

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #10)
 .L31:
leaq(%rdx), %rsi
negq%rsi
vpermps (%r9,%rsi), %zmm8, %zmm0
--> vmovaps %zmm0, %zmm1
vmaxps  (%r11,%rdx), %zmm3, %zmm0
vfnmadd132ps(%r14,%rdx), %zmm7, %zmm1
vmaxps  %zmm1, %zmm0, %zmm0
vmovups %zmm0, 0(%r13,%rdx)
leaq64(%rdx), %rdx
cmpq%r8, %rdx
jne .L31

> %zmm0 is killed in (insn 860) and thus dead in (insn 1743). (insn 856) could
> simply use %zmm0 as its destination.
_%zmm1_ as its destination.

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #10 from Uroš Bizjak  ---
Actually, the issue is not fixed. As mentioned in the description, the issue is
best visible without -funrol-loops.

(GCC) 10.0.0 20190821 (experimental) compiles (-Ofast -fopenmp -march=knl) to:

.L31:
leaq(%rdx), %rsi
negq%rsi
vpermps (%r9,%rsi), %zmm8, %zmm0
vmovaps %zmm0, %zmm1
vmaxps  (%r11,%rdx), %zmm3, %zmm0
vfnmadd132ps(%r14,%rdx), %zmm7, %zmm1
vmaxps  %zmm1, %zmm0, %zmm0
vmovups %zmm0, 0(%r13,%rdx)
leaq64(%rdx), %rdx
cmpq%r8, %rdx
jne .L31

As seen in the detailed dump,

#(insn:TI 856 852 1743 71 (set (reg:V16SF 20 xmm0 [orig:885 vect__72.36 ]
[885])
#(unspec:V16SF [
#(mem:V16SF (plus:DI (reg/f:DI 37 r9 [orig:198 vectp.34 ]
[198])
#(reg:DI 4 si [883])) [3 MEM[base: vectp.34_256, index:
_1006, offset: 0B]+0 S64 A32])
#(reg:V16SI 44 xmm8 [919])
#] UNSPEC_VPERMVAR))
"/hdd/uros/git/gcc/gcc/testsuite/g++.dg/pr80481.C":59:28 4754
{avx512f_permvarv16sf}
# (expr_list:REG_DEAD (reg:DI 4 si [883])
#(nil)))
vpermps (%r9,%rsi), %zmm8, %zmm0# 856   [c=68 l=7] 
avx512f_permvarv16sf
#(insn:TI 1743 856 860 71 (set (reg:V16SF 21 xmm1 [orig:885 vect__72.36 ]
[885])
#(reg:V16SF 20 xmm0 [orig:885 vect__72.36 ] [885]))
"/hdd/uros/git/gcc/gcc/testsuite/g++.dg/pr80481.C":60:20 1255
{movv16sf_internal}
# (expr_list:REG_DEAD (reg:V16SF 20 xmm0 [orig:885 vect__72.36 ] [885])
#(nil)))
vmovaps %zmm0, %zmm1# 1743  [c=4 l=6]  movv16sf_internal/2
#(insn 860 1743 857 71 (set (reg:V16SF 20 xmm0 [orig:888 vect__13.45 ] [888])
#(smax:V16SF (reg:V16SF 23 xmm3 [890])
#(mem:V16SF (plus:DI (reg/f:DI 39 r11 [orig:187 vectp.43 ] [187])
#(reg:DI 1 dx [orig:478 ivtmp.111 ] [478])) [3 MEM[base:
vectp.43_238, index: ivtmp.111_997, offset: 0B]+0 S64 A32])))
"/hdd/uros/git/gcc/gcc/testsuite/g++.dg/pr80481.C":61:15 1631 {*smaxv16sf3}
# (nil))
vmaxps  (%r11,%rdx), %zmm3, %zmm0   # 860   [c=68 l=6] 
*smaxv16sf3/1

%zmm0 is killed in (insn 860) and thus dead in (insn 1743). (insn 856) could
simply use %zmm0 as its destination.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Thu, 22 Aug 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
> 
> --- Comment #8 from Thomas Koenig  ---
> This should be exposed by
> 
> module y
> contains
>   subroutine bar(a,n)
> real, dimension(n), intent(inout) :: a
> a = a + 1.0
>   end subroutine bar
> end module y
> 
> module x
>   use y
> contains
>   subroutine foo(a)
> real, dimension(:), intent(inout) :: a
> call bar (a,size(a))
>   end subroutine foo
> end module x
> 
> The subroutine foo takes a descriptor, and it needs to repack
> the data for passing it as a reference to bar.  The reason is
> that somebody may call foo with a non-uniform stride, as in

Yes, but in the WRF file I see no assumed-shape arrays but all
appear to be of dimension(low:high,...) style.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
This should be exposed by

module y
contains
  subroutine bar(a,n)
real, dimension(n), intent(inout) :: a
a = a + 1.0
  end subroutine bar
end module y

module x
  use y
contains
  subroutine foo(a)
real, dimension(:), intent(inout) :: a
call bar (a,size(a))
  end subroutine foo
end module x

The subroutine foo takes a descriptor, and it needs to repack
the data for passing it as a reference to bar.  The reason is
that somebody may call foo with a non-uniform stride, as in

program main
  use x
  real, dimension(10) :: a
  call random_number(a)
  call foo(a(1:10:2))
  print *,a
end program main

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[mpf at gcc dot gnu.org]

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

--- Comment #29 from mpf at gcc dot gnu.org ---
I don't remember the detail of this issue but I believe I was convinced that it
is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The PX
control bit forces address calculations i.e. base + imm or base + reg to be
performed with 32-bit rules but allows 64 instruction usage. Since there is a
processor mode that is perfectly capable of meeting the requirements of a
program with 64bit data and 32bit pointers then the solution is to set PX for
N32 rather than UX.

[Bug debug/91507] wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-22
 CC||tromey at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
So we're now handling the definition via

static void
gen_variable_die (tree decl, tree origin, dw_die_ref context_die)
{ 
...
  else if (decl_will_get_specification_p (old_die, decl, declaration))
{
  /* This is a definition of a C++ class level static.  */
  add_AT_specification (var_die, old_die);
...

earlier in gen_decl_die we already do

26451   gen_type_die (TREE_TYPE (decl_or_origin), context_die);

unconditionally, creating a dangling type DIE, so it seems reasonable
to attach that if it doesn't match what is already there in the specification.
Now the question is how often this triggers.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 274816)
+++ gcc/dwarf2out.c (working copy)
@@ -23928,6 +23928,10 @@ gen_variable_die (tree decl, tree origin
  if (old_die->die_tag == DW_TAG_member)
add_linkage_name (var_die, decl);
}
+  dw_die_ref type_die = lookup_type_die (TREE_TYPE (decl));
+  dw_attr_node *a = get_AT (var_die, DW_AT_type);
+  if (type_die && (!a || AT_ref (a) != type_die))
+   add_AT_die_ref (var_die, DW_AT_type, type_die);
 }
   else
 add_name_and_src_coords_attributes (var_die, decl, no_linkage_name);

The alternative is to try fixing this in the FE by delaying finalization
of the declaration.  The question is whether that declared variable can
end up being referenced in things we throw at dwarf2out and thus whether
a DIE for it might end up created anyways.  Like

extern char *zzz[];
const char **p = zzz;
char *zzz[] = {
"abc",
"cde"
};

but we're not creating a DIE ref for the constant initializer (yet).

Anyhow, with the patch we create

 <1><1d>: Abbrev Number: 2 (DW_TAG_array_type)
<1e>   DW_AT_type: <0x28>
<22>   DW_AT_sibling : <0x28>
 <2><26>: Abbrev Number: 3 (DW_TAG_subrange_type)
 <2><27>: Abbrev Number: 0
...
 <1><35>: Abbrev Number: 6 (DW_TAG_variable)
<36>   DW_AT_name: zzz
<3a>   DW_AT_decl_file   : 1
<3b>   DW_AT_decl_line   : 1
<3c>   DW_AT_decl_column : 14
<3d>   DW_AT_type: <0x1d>
<41>   DW_AT_external: 1
<41>   DW_AT_declaration : 1
 <1><41>: Abbrev Number: 2 (DW_TAG_array_type)
<42>   DW_AT_type: <0x28>
<46>   DW_AT_sibling : <0x51>
 <2><4a>: Abbrev Number: 7 (DW_TAG_subrange_type)
<4b>   DW_AT_type: <0x51>
<4f>   DW_AT_upper_bound : 1
...
 <1><58>: Abbrev Number: 8 (DW_TAG_variable)
<59>   DW_AT_specification: <0x35>
<5d>   DW_AT_decl_line   : 2
<5e>   DW_AT_decl_column : 7
<5f>   DW_AT_type: <0x41>
<63>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

but I guess it isn't of much additional value to the debug info consumer
to have both the declaration and the specification...?  Still for C++
class level statics it was deemed to be useful and this C variant really
looks similar enough.

Btw, the C++ FE behaves exactly the same as the C FE on the testcase in this
bug.

gdb isn't impressed by the above improved debug and still prints

(gdb) ptype zzz
type = char *[]

compared to the following when omitting the declaration.

(gdb) ptype zzz
type = char *[2]

so it seems to ignore the seemingly redundant DW_AT_type in the
specification DIE.  The DWARF spec isn't entirely clear what is
to be taken from the specification and what from the declaration DIE
and how to handle this situation.  But the wording suggests that
"completing" something is exactly the use-case for a specification
(whether that applies to completing a referenced DIE as in this case
remains an open question).

gdb folks?

[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||assemble-failure
 Target||x86_64-apple-darwin1(345678
   ||)
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-22
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/91520] New: AVX512 target assembler fails for x86_64 Darwin

[iains at gcc dot gnu.org]

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

Bug ID: 91520
   Summary: AVX512 target assembler fails for x86_64 Darwin
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

The following tests have failed since their introduction on Darwin targets that
have vector instruction support.

-m32
FAIL: gcc.target/i386/avx512vl-vcvtpd2dq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtpd2ps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtpd2udq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtqq2ps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvttpd2dq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvttpd2udq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtuqq2ps-2.c (test for excess errors)

-m64
FAIL: gcc.target/i386/avx512vl-vcvtpd2dq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtpd2udq-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vfpclasspd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vfpclassps-2.c (test for excess errors)

The reason is that the assembler (where it supports AVX) is based on the LLVM
backend, which did not support the use of the 'x', 'y' and 'z' markers on
instructions when the inns do not require them letters to disambiguate.

[ when the instruction includes a memory access, then it *is* necessary to use
the letter to disambiguate ].

GAS allows the markers on all the insn variants and GCC emits them.

As of LLVM 9.x the LLVM backend has been changed to match what GAS does - but
clearly (a) that will take some time to appear in Xcode (which most Darwin
folks are using as their 'binutils').  It will also never be made
retrospectively available to existing earlier Darwin versions.

There are two potential solutions:

1) Arrange that GCC doesn't emit this variant;
(either unilaterally, or under some configure-determined flag that determines
the required support).  I have a prototype patch that can do the change, at
least.

2) require that folks on Darwin use patched "binutils" (such as the 'xtools' I
maintain).

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Sunil Pandey from comment #4)
> Actually it is spec cpu 2017 521.wrf benchmark getting this problem while
> compiling. Compilation taking forever, you can see while compiling file
> module_first_rk_step_part1.fppized.f90 as a representative.

Note this file contains a single function which (besides USEing quite a number
of modules...) has only function calls involving a lot of parameters
effectively forwarding parameters from the function.  Thus

SUBROUTINE foo (psim, ..., ims, ime, jms, jme)
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
call sub1 (PSIM=psim, ...)
call sub2 (PSIM=psim, ...)
END SUBROUTINE

with a _lot_ of arrays being passed through.  A simple testcase like

SUBROUTINE sub1 (psim, ims, ime, jms, jme)
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
END SUBROUTINE
SUBROUTINE foo (psim, ims, ime, jms, jme)
REAL,DIMENSION(ims:ime,jms:jme), INTENT(INOUT) :: psim
call sub1 (psim, ims, ime, jms, jme)
END SUBROUTINE

doesn't show any extra loops generated though, so I'm not sure what to
look after.

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #6 from Hongtao.liu  ---
Created attachment 46744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46744=edit
Fortran source code

Command line to reproduce this issue.

gfortran -m64 -c -o module_comm_dm_3.fppized.o -O2 module_comm_dm_3.fppized.f90
gfortran -m64 -c -o module_comm_dm_4.fppized.o -O2 module_comm_dm_4.fppized.f90
gfortran -m64 -c -o module_comm_dm.fppized.o -O2 module_comm_dm.fppized.f90

[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  ---
Created attachment 46743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46743=edit
Make sure we process the PRAGMA_GCC_PCH_PREPROCESS first

We need to make sure that we've acted on the PRAGMA_GCC_PCH_PREPROCESS before
calling c_common_no_more_pch (), since that's allowed to deallocate resources
that are set aside for PCH.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Sounds similar to PR91509.  The rev. in question can end up exposing a lot more
loops which I think is not necessarily bad but may uncover issues in the
compiler.  For PR91509 it is the prefetching pass going wild so I wonder
what your -march=native maps to?

Note your time-reports indicate that you build the compiler with checking
enabled, you can get better figures when building with -fno-checking
or configuring GCC with --enable-checking=release.

[Bug tree-optimization/91514] optimization needs ficktive memory allocation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, openmp
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-22
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So what's the variant w/o the fictive allocation?  It would be nice to
see source with the variants controlled by a #define so one can compare
both compiling with -DFICTIVE or -UFICTIVE?


Referenced Bugs:

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

[Bug target/91518] [9/10 Regression] segfault when run CPU2006 465.tonto since r263875

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64le
 Status|UNCONFIRMED |WAITING
   Keywords||lto, wrong-code
   Last reconfirmed||2019-08-22
  Component|lto |target
 Blocks||26163
 Ever confirmed|0   |1
Summary|segfault when run CPU2006   |[9/10 Regression] segfault
   |465.tonto since r263875 |when run CPU2006 465.tonto
   ||since r263875
   Target Milestone|--- |9.3

--- Comment #2 from Richard Biener  ---
Not seen on x86_64.  Given you bisected to r263875 it should appear with GCC 9
as well - are the actual GCC 9 releases also affected?

I assume this is ppc64le.

Unless we know more I assume this is a target issue.  Please build with debug
info and see where exactly and why it segfaults.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/91510] r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 46742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46742=edit
original testcase

Original testcase.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
(In reply to James Cowgill from comment #0)
> Before the ldxc1 instruction is executed, gdb reports that the values in v0
> and s0 are both large integers (above 0x8000):
> (gdb) print/x $v0
> $1 = 0xfffee7f8
> (gdb) print/x $s0
> $2 = 0x80008b50
> 
> When added together, the lower 32-bits contains the correct pointer (in this
> case on the stack). On a 32-bit processor this is fine.
> 
> On a 64-bit processor, we know that v0 and s0 are sign extended as the last
> instructions to touch them were the addu at 924 and the subu at 8e0. So the
> values in the registers are actually:
> v0 = 0xfffee7f8
> s0 = 0x80008b50
> 
> Adding these together (modulo 64-bit) gives the final pointer of
> 0x7fff7348 which is outside the user address space and thus results
> in a SIGBUS.
> 
> I think GCC is assuming that the address calculated by the ldxc1 instruction
> is modulo 32-bit when compiled for a 32-bit processor. However, this is not
> true if the code is later run on a 64-bit processor.

Given the above GCC has to consider pointers (even integer regs!?) being
64bit even in 32bit mode since obviously semantics between 32bit and 64bit
hardware differs.  Thus as Eric says Pmode needs to be DImode and
ptr_mode SImode for 32bit and DImode for 64bit.  Everything else is going
to lead to issues like the ones observed.

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to kargl from comment #4)
> We need the Fortran source not the *.mod file.

You can use samp.f90.