[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++

2019-10-27 Thread boite.pour.spam at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170

X Ryl  changed:

   What|Removed |Added

 CC||boite.pour.spam at gmail dot 
com

--- Comment #8 from X Ryl  ---
Is there a reason why -fstack-usage doesn't output mangled name ?
It's very easy to run the output through c++filt.

Wouldn't it better if it was consistent with other tools and as such could be
compared ?

Typically, there is a tool (https://www.dlbeer.co.nz/oss/avstack.html) that's
used to compute the minimum stack size required for a program, and the fact
that -fstack-usage breaks for C++ (either with wrong names, or it outputs non
mangled name), it's not possible to link the reported stack usage with the
functions in the produced binary (for example, with objdump)

Even when the C++ item does not contain fancy dot, this is still a real pain
because if you demangle objdump's output, you'll get:

unsigned char * MyClass::foo(unsigned long)

while fstack-usage will return (with typedef):

uint8_t * MyClass::foo(uint64_t)



The patch is very simple, just bypass any demangling here since I don't think
it's the role of this method to demangle for you.






Index: gcc-7.3.0/gcc/toplev.c
===
--- gcc-7.3.0.orig/gcc/toplev.c
+++ gcc-7.3.0/gcc/toplev.c
@@ -996,28 +996,8 @@ output_stack_usage (void)
 {
   expanded_location loc
= expand_location (DECL_SOURCE_LOCATION (current_function_decl));
-  /* We don't want to print the full qualified name because it can be
long,
-so we strip the scope prefix, but we may need to deal with the suffix
-created by the compiler.  */
-  const char *suffix
-   = strchr (IDENTIFIER_POINTER (DECL_NAME (current_function_decl)), '.');
-  const char *name
-   = lang_hooks.decl_printable_name (current_function_decl, 2);
-  if (suffix)
-   {
- const char *dot = strchr (name, '.');
- while (dot && strcasecmp (dot, suffix) != 0)
-   {
- name = dot + 1;
- dot = strchr (name, '.');
-   }
-   }
-  else
-   {
- const char *dot = strrchr (name, '.');
- if (dot)
-   name = dot + 1;
-   }
+  const char *name = IDENTIFIER_POINTER
+   (DECL_ASSEMBLER_NAME (current_function_decl));

   fprintf (stack_usage_file,
   "%s:%d:%d:%s\t" HOST_WIDE_INT_PRINT_DEC"\t%s\n",

[Bug tree-optimization/88760] GCC unrolling is suboptimal

2019-10-27 Thread guojiufu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760

--- Comment #42 from Jiu Fu Guo  ---
Author: guojiufu
Date: Mon Oct 28 05:23:24 2019
New Revision: 277501

URL: https://gcc.gnu.org/viewcvs?rev=277501&root=gcc&view=rev
Log:
rs6000: Enable limited unrolling at -O2

In PR88760, there are a few disscussion about improve or tune unroller for
targets. And we would agree to enable unroller for small loops at O2 first.
And we could see performance improvement(~10%) for below code:
```
  subroutine foo (i, i1, block)
integer :: i, i1
integer :: block(9, 9, 9)
block(i:9,1,i1) = block(i:9,1,i1) - 10
  end subroutine foo

```
This kind of code occurs a few times in exchange2 benchmark.

Similar C code:
```
  for (i = 0; i < n; i++)
arr[i] = arr[i] - 10;
```

On powerpcle, for O2 , enable -funroll-loops and limit
PARAM_MAX_UNROLL_TIMES=2 and PARAM_MAX_UNROLLED_INSNS=20, we can see >2%
overall improvement for SPEC2017.

This patch is only for rs6000 in which we see visible performance improvement.

gcc/
2019-10-25  Jiufu Guo   

PR tree-optimization/88760
* config/rs6000/rs6000-common.c (rs6000_option_optimization_table):
Enable -funroll-loops for -O2 and above.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Set
PARAM_MAX_UNROLL_TIMES to 2 and PARAM_MAX_UNROLLED_INSNS to 20, and
do not turn on web and rngreg implicitly, if the unroller is not
explicitly enabled.

gcc.testsuite/
2019-10-25  Jiufu Guo  

PR tree-optimization/88760
* gcc.target/powerpc/small-loop-unroll.c: New test.
* c-c++-common/tsan/thread_leak2.c: Update test.
* gcc.dg/pr59643.c: Update test.
* gcc.target/powerpc/loop_align.c: Update test.
* gcc.target/powerpc/ppc-fma-1.c: Update test.
* gcc.target/powerpc/ppc-fma-2.c: Update test.
* gcc.target/powerpc/ppc-fma-3.c: Update test.
* gcc.target/powerpc/ppc-fma-4.c: Update test.
* gcc.target/powerpc/pr78604.c: Update test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/small-loop-unroll.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/rs6000/rs6000-common.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/tsan/thread_leak2.c
trunk/gcc/testsuite/gcc.dg/pr59643.c
trunk/gcc/testsuite/gcc.target/powerpc/loop_align.c
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fma-1.c
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fma-2.c
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fma-3.c
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fma-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78604.c

[Bug ipa/92242] [10 regression] LTO ICE in ipa_get_cs_argument_count ipa-prop.h:598

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92242

--- Comment #2 from Dmitry G. Dyachenko  ---
correctly reduced testcase

$ cat x.i
unsigned foo(int a) {
  if (a)
return 0;
  return 1;
}

$ cat y.i
unsigned foo(int);
int bar() {
  foo(0);
  return 0;
}

$ cat libso.ver
{ global:
bar;
local: *; };

$ gcc -O2 -flto -Wall -c x.i y.i

$ gcc -flto -fPIC -DPIC -shared x.o y.o -Wl,-version-script -Wl,./libso.ver -o
libso.so
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xdd4bdf crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0x64e28d ipa_get_cs_argument_count
/home/dimhen/src/gcc_current/gcc/ipa-prop.h:598
0x64e28d ipa_merge_fn_summary_after_inlining(cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/ipa-fnsummary.c:3318
0x16f66db inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:484
0x16f0682 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x16f0682 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x16f0682 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ gcc -flto -fPIC -DPIC -shared x.o y.o -Wl,-version-script -Wl,./libso.ver -o
libso.so
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xdd4bdf crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0x64e28d ipa_get_cs_argument_count
/home/dimhen/src/gcc_current/gcc/ipa-prop.h:598
0x64e28d ipa_merge_fn_summary_after_inlining(cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/ipa-fnsummary.c:3318
0x16f66db inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:484
0x16f0682 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x16f0682 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x16f0682 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/92249] New: ICE in c_parser_gimple_compound_statement w/ GIMPLE testcases

2019-10-27 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92249

Bug ID: 92249
   Summary: ICE in c_parser_gimple_compound_statement w/ GIMPLE
testcases
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20191027 snapshot (r277495) and 9.2 ICE when compiling the
following testcase reduced from testsuite/gcc.dg/vect/slp-reduc-10[abcde].c
(added in r277406) w/ -fgimple:

void __GIMPLE (ssa)
foo (void)
{
  return;
}

% gcc-10.0.0-alpha20191027 -fgimple -c tvbra2u4.c
tvbra2u4.c: In function 'foo':
tvbra2u4.c:4:3: internal compiler error: Segmentation fault
4 |   return;
  |   ^~
0xc71516 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/toplev.c:326
0x7b6a21 c_parser_gimple_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:444
0x7b6a21 c_parser_gimple_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:380
0x7b7ede c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:252
0x7a8ed7 c_parser_declaration_or_fndef
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:2385
0x7b0035 c_parser_external_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:1658
0x7b0852 c_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:1539
0x7b0852 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:20804
0x8075f5 c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c-family/c-opts.c:1179

gcc fails on the original testcases w/ -fno-gimple:

% gcc-10.0.0-alpha20191027 -fno-gimple -c
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:5:5: error: '__GIMPLE' only valid
with '-fgimple'
5 | int __GIMPLE (ssa,guessed_local(118111600),startwith("dce3"))
  | ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c: In function 'foo':
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:15:3: error: unknown type name
'__SIZETYPE__'
   15 |   __SIZETYPE__ _7;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:16:3: error: unknown type name
'__SIZETYPE__'
   16 |   __SIZETYPE__ _8;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:19:3: error: unknown type name
'__SIZETYPE__'
   19 |   __SIZETYPE__ _11;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:20:3: error: unknown type name
'__SIZETYPE__'
   20 |   __SIZETYPE__ _12;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:23:3: error: unknown type name
'__SIZETYPE__'
   23 |   __SIZETYPE__ _15;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:24:3: error: unknown type name
'__SIZETYPE__'
   24 |   __SIZETYPE__ _16;
  |   ^~~~
gcc/testsuite/gcc.dg/vect/slp-reduc-10a.c:48:3: internal compiler error: in
build2, at tree.c:4766
   48 |   _9 = x_23(D) + _8;
  |   ^~
0x6c3725 build2(tree_code, tree_node*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree.c:4766
0x7b504c build2_loc
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/tree.h:4322
0x7b504c c_parser_gimple_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:1002
0x7b60d7 c_parser_gimple_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:857
0x7b60d7 c_parser_gimple_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:648
0x7b60d7 c_parser_gimple_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:380
0x7b7ede c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/gimple-parser.c:252
0x7a8ed7 c_parser_declaration_or_fndef
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:2385
0x7b0035 c_parser_external_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191027/work/gcc-10-20191027/gcc/c/c-parser.c:1658
0x7b0852 c_parser_tran

[Bug lto/41526] gimple bytecode streams are not portable between different hosts

2019-10-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41526

--- Comment #4 from Eric Gallager  ---
(In reply to Joseph S. Myers from comment #3)
> The handling of target options (the patch for bug 45475) is another
> host-dependency in the bytecode stream.

That has been closed as fixed... which parts of this issue still remain?

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

2019-10-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Gallager  ---
cc-ing objc[++] maintainers

[Bug libobjc/67455] Inheriting from Object (with GNU runtime) doesn't provide alloc, init, or new, rendering methods useless

2019-10-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67455

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Eric Gallager from comment #4)
> > 67455.m:21:2: warning: (Messages without a matching method signature
> > 67455.m:21:2: warning: will be assumed to return ‘id’ and accept
> > 67455.m:21:2: warning: ‘...’ as arguments.)
> 
> Also this message should probably be a single note rather than warnings, so
> I guess this is a diagnostics issue too.

actually that should probably be split off into a separate issue instead of
including it as part of this one, but I don't feel like doing that now...

[Bug c/45821] Missed -Wreturn-local-addr when local variable address comes from within a statement expression

2019-10-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821

Eric Gallager  changed:

   What|Removed |Added

 Blocks||90556
Summary|no warning when returning a |Missed -Wreturn-local-addr
   |local variable address  |when local variable address
   |within a statement  |comes from within a
   |expression  |statement expression

--- Comment #6 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Andrew Gaul from comment #3)
> > int *function_return_local(void)
> > {
> > int x = 0;
> > return &x;
> > }
> > 
> > int *statement_expression_return_local(void)
> > {
> > int *y = ({
> > int x = 0;
> > &x;
> > });
> > return y;
> > }
> 
> We now warn at -O2:
> 
> test.c:14:10: warning: function returns address of local variable
> [-Wreturn-local-addr]
>return y;
>   ^
> test.c:11:11: note: declared here
>int x = 0;
>^
> 
> but only because we return y. For this testcase,
> 
> int statement_expression_return_local(void)
> {
> int *y = ({
> int x = 0;
> &x;
> });
> return *y;
> }
> 
> we get: 
> 
> test.c:14:10: warning: ‘x’ is used uninitialized in this function
> [-Wuninitialized]
>return *y;
>   ^
> 
> which is a bit confusing (and not the same warning).

It'd be good to get it from the same warning, so I'm making this block the
-Wreturn-local-addr meta-bug

> 
> Possibly related to 60517.
> it would be good to add the testcase


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr

[Bug ipa/92242] [10 regression] LTO ICE in ipa_get_cs_argument_count ipa-prop.h:598

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92242

--- Comment #1 from Dmitry G. Dyachenko  ---
over reduced but still ICE

$ cat x.i
unsigned foo(int a)
{
  if (a)
return 0;
}

$ cat y.i
unsigned foo();
void bar() { foo(); }

$ cat libso.ver 
{ global:
bar;
local: *; };


$ gcc -O2 -flto -c x.i y.i
$ gcc -flto -fPIC -DPIC -shared x.o y.o -Wl,-version-script -Wl,./libso.ver -o
libso.so
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xdd4bdf crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0x64e28d ipa_get_cs_argument_count
/home/dimhen/src/gcc_current/gcc/ipa-prop.h:598
0x64e28d ipa_merge_fn_summary_after_inlining(cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/ipa-fnsummary.c:3318
0x16f66db inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:484
0x16f0682 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x16f0682 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x16f0682 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/local/binutils_current/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug target/92246] Byte or short array reverse loop auto-vectorized with 3-uop vpermt2w instead of 1 or 2-uop vpermw (AVX512)

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92246

--- Comment #1 from Peter Cordes  ---
And BTW, GCC *does* use vpermd (not vpermt2d) for swapt = int or long.  This
problem only applies to char and short.  Possibly because AVX2 includes vpermd
ymm.



Apparently CannonLake has 1 uop vpermb but 2 uop vpermw, according to real
testing on real hardware by https://uops.info/.  Their automated test methods
are generally reliable.

That seems to be true for Ice Lake, too, so when AVX512VBMI is available we
should be using vpermb any time we might have used vpermw with a
compile-time-constant control vector.


(verpmw requires AVX512BW, e.g. SKX and Cascade Lake.  vpermb requires
AVX512VBMI, only Ice Lake and the mostly aborted CannonLake.)

Instlat provides some confirmation:
https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIntel00706E5_IceLakeY_InstLatX64.txt
 shows vpermb at 3 cycle latency, but vpermw at 4 cycle latency (presumably a
chain of 2 uops, 1c and 3c being the standard latencies that exist in recent
Intel CPUs).  InstLat doesn't document which input the dep chain goes through,
so it's not 100% confirmation of only 1 uop.  But it's likely that ICL has 1
uop vpermb given that CNL definitely does.

uops.info lists latencies separately from each input to the result, sometimes
letting us figure out that e.g. one of the inputs isn't needed until the 2nd
uop.  Seems to be the case for CannonLake vpermw: latency from one of the
inputs is only 3 cycles, the other is 4. 
https://www.uops.info/html-lat/CNL/VPERMW_YMM_YMM_YMM-Measurements.html

[Bug c++/92248] New: ‘__NR_open’ was not declared in this scope compilation failed on ubuntu 18.04 WSL2

2019-10-27 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92248

Bug ID: 92248
   Summary: ‘__NR_open’ was not declared in this scope compilation
failed on ubuntu 18.04 WSL2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:162:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_open(const char*, int)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_open’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:200:27: note:
in expansion of macro ‘SYSCALL’
  200 |   return internal_syscall(SYSCALL(open), (uptr)filename, flags);
  |   ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_open(const char*, int,
__sanitizer::u32)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_open’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:209:27: note:
in expansion of macro ‘SYSCALL’
  209 |   return internal_syscall(SYSCALL(open), (uptr)filename, flags, mode);
  |   ^~~
In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_flags.h:16,
 from
../../../.././libsanitizer/sanitizer_common/sanitizer_common.h:18,
 from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:19:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_ftruncate(__sanitizer::fd_t,
__sanitizer::uptr)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_ftruncate’ was not declared in this scope; did you mean
‘ftruncate’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:408:14:
note: in definition of macro ‘HANDLE_EINTR’
  408 |   res = (f);   \
  |  ^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:229:44: note:
in expansion of macro ‘SYSCALL’
  229 |   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
  |^~~
In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:162:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_stat64’ was not declared in this scope; did you mean ‘__lxstat64’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:319:30: note:
in expansion of macro ‘SYSCALL’
  319 |   int res = internal_syscall(SYSCALL(stat64), path, &buf64);
  |  ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_lstat64’ was not declared in this scope; did you mean
‘__lxstat64’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:344:30: note:
in expansion of macro ‘SYSCALL’
  344 |   int res = internal_syscall(SYSCALL(lstat64), path, &buf64);
  |  ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_dup2(int, int)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_dup2’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:385:27: note:
in expansion of macro ‘SYSCALL’
  385 |   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
  |   ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_readlink(const char*, char*,
__sanitizer::uptr)’:
../../../.././libsanitizer/sanitizer_common/saniti

[Bug c++/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2

2019-10-27 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247

--- Comment #1 from fdlbxtqi  ---
*** Bug 92248 has been marked as a duplicate of this bug. ***

[Bug c++/92248] ‘__NR_open’ was not declared in this scope compilation failed on ubuntu 18.04 WSL2

2019-10-27 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92248

fdlbxtqi  changed:

   What|Removed |Added

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

--- Comment #1 from fdlbxtqi  ---
Duplicate of 92247 due to slow browser

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

[Bug c++/92247] New: ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2

2019-10-27 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247

Bug ID: 92247
   Summary: ‘__NR_open’ was not declared in this scope
libsanitizer/sanitizer_common/sanitizer_linux
compilation failed on ubuntu 18.04 WSL2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:162:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_open(const char*, int)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_open’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:200:27: note:
in expansion of macro ‘SYSCALL’
  200 |   return internal_syscall(SYSCALL(open), (uptr)filename, flags);
  |   ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_open(const char*, int,
__sanitizer::u32)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_open’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:209:27: note:
in expansion of macro ‘SYSCALL’
  209 |   return internal_syscall(SYSCALL(open), (uptr)filename, flags, mode);
  |   ^~~
In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_flags.h:16,
 from
../../../.././libsanitizer/sanitizer_common/sanitizer_common.h:18,
 from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:19:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_ftruncate(__sanitizer::fd_t,
__sanitizer::uptr)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_ftruncate’ was not declared in this scope; did you mean
‘ftruncate’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:408:14:
note: in definition of macro ‘HANDLE_EINTR’
  408 |   res = (f);   \
  |  ^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:229:44: note:
in expansion of macro ‘SYSCALL’
  229 |   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
  |^~~
In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:162:
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_stat64’ was not declared in this scope; did you mean ‘__lxstat64’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:319:30: note:
in expansion of macro ‘SYSCALL’
  319 |   int res = internal_syscall(SYSCALL(stat64), path, &buf64);
  |  ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_lstat64’ was not declared in this scope; did you mean
‘__lxstat64’?
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:344:30: note:
in expansion of macro ‘SYSCALL’
  344 |   int res = internal_syscall(SYSCALL(lstat64), path, &buf64);
  |  ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_dup2(int, int)’:
../../../.././libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:19:24:
error: ‘__NR_dup2’ was not declared in this scope
   19 | # define SYSCALL(name) __NR_ ## name
  |^
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:385:27: note:
in expansion of macro ‘SYSCALL’
  385 |   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
  |   ^~~
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp: In function
‘__sanitizer::uptr __sanitizer::internal_readlink(const char*, char*,
__san

[Bug fortran/92114] equivalence in module causes ICE

2019-10-27 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114

--- Comment #3 from urbanjost at comcast dot net ---
I could not get the code to compile at all with 7.4.0 trying a variety of
compiler switches with 7.4.0. This was in a Cygwin environment. I reinstalled
the Cygwin environment and still got the error. 7.4.0-1 is the highest standard
version on the Cygwin site; but 8.3.0 was available as a test version. The
problem went away with 8.3.0.

[Bug target/65342] [7/8 Regression] powerpc-darwin9 m64 code-gen error exposed by r210201

2019-10-27 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[7/8/9/10 Regression] FAIL: |[7/8 Regression]
   |gfortran.dg/intrinsic_(un)? |powerpc-darwin9 m64
   |pack_1.f90   -O1  execution |code-gen error  exposed by
   |test on |r210201
   |powerpc-apple-darwin9/10|
   |after r210201   |

--- Comment #32 from Iain Sandoe  ---
fixed for trunk and 9 so far.

[Bug tree-optimization/92244] vectorized loop updating 2 copies of the same pointer (for in-place reversal cross in the middle)

2019-10-27 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92244

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
(In reply to Peter Cordes from comment #1)
> On AArch64 (with gcc8.2), we see a similar effect, more instructions in the
> loop.  And an indexed addressing mode.

With the trunk (with generic tuning):
.L4:
ldr q1, [x3, x2]
ldr q0, [x4]
tbl v1.16b, {v1.16b}, v2.16b
tbl v0.16b, {v0.16b}, v2.16b
str q1, [x4], 16
str q0, [x3, x2]
sub x2, x2, #16
cmp x2, x1

With -mcpu=octeontx:
.L6:
ldr q1, [x0, x2]
ldr q0, [x3, x1]
tbl v1.16b, {v1.16b}, v2.16b
tbl v0.16b, {v0.16b}, v2.16b
str q1, [x3, x1]
add x1, x1, 16
str q0, [x0, x2]
sub x2, x2, #16
cmp x1, x5
bne .L6

With -mcpu=thunderx2t99:
.L4:
ldr q1, [x3], -16
ldr q0, [x2]
tbl v1.16b, {v1.16b}, v2.16b
tbl v0.16b, {v0.16b}, v2.16b
str q1, [x2], 16
str q0, [x1], -16
cmp x2, x5
bne .L4

I am not shocked that IV-OPTS can chose these widly differences.
I have not looked at the cost differences to understand why -mcpu=thunderx2t99
chose what close might be the best (we could use one less IV by replacing the
first ldr by using the same IV as the last str).

[Bug target/92246] New: Byte or short array reverse loop auto-vectorized with 3-uop vpermt2w instead of 1 or 2-uop vpermw (AVX512)

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92246

Bug ID: 92246
   Summary: Byte or short array reverse loop auto-vectorized with
3-uop vpermt2w instead of 1 or 2-uop vpermw (AVX512)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

typedef short swapt;
void strrev_explicit(swapt *head, long len)
{
  swapt *tail = head + len - 1;
  for( ; head < tail; ++head, --tail) {
  swapt h = *head, t = *tail;
  *head = t;
  *tail = h;
  }
}

g++ -O3 -march=skylake-avx512
  (Compiler-Explorer-Build) 10.0.0 20191022 (experimental)

https://godbolt.org/z/LS34w9

...
.L4:
vmovdqu16   (%rdx), %ymm1
vmovdqu16   (%rax), %ymm0
vmovdqa64   %ymm1, %ymm3# useless copy
vpermt2w%ymm1, %ymm2, %ymm3
vmovdqu16   %ymm3, (%rax)
vpermt2w%ymm0, %ymm2, %ymm0
addq$32, %rax
vmovdqu16   %ymm0, (%rcx)
subq$32, %rdx
subq$32, %rcx   # two tail pointers, PR 92244 is unrelated to
this
cmpq%rsi, %rax
jne .L4

vpermt2w ymm is 3 uops on SKX and CannonLake:  2p5 + p015
(https://www.uops.info/table.html)

Obviously better would be  vpermw (%rax), %ymm2, %ymm0.

vpermw apparently can't micro-micro-fuse a load, but it's only 2 ALU uops plus
a load if we use a memory source.  SKX still bottlenecks on 2p5 for vpermw,
losing only the p015 uop, but in general fewer uops is better.

But on CannonLake it runs on p01 + p5 (plus p23 with a memory source).

uops.info doesn't have IceLake-client data yet but vpermw throughput on IceLake
is 1/clock, vs 1 / 2 clocks for vpermt2w, so this could double throughput on
CNL and ICL.

We have exactly the same problem with AVX512VBMI vpermt2b over vpermb with ICL
g++ -O3 -march=icelake-client -mprefer-vector-width=512

[Bug tree-optimization/92245] New: strncpy followed by nul store not folded into memcpy

2019-10-27 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92245

Bug ID: 92245
   Summary: strncpy followed by nul store not folded into memcpy
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Because the strlen pass has no support for strncpy beyond warnings, GCC emits
suboptimal code for all functions below except f0.  In f1(), the strncpy call
and nul store can be merged into a single memcpy.  The same can happen in f2(),
f3(), and f4().  In addition, the strlen calls can then be folded into
constants.  Since strncpy followed by a nul store to terminate the string is a
common idiom this could would not only lead to better code but also help expose
buffer overflows when inappropriately using the result.

With the strlen calls removed, Clang emits the same optimal code for f0() and
f1(), but does just as poorly on the rest of the functions.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
extern char a[8];

void f0 (void)   // optimal
{
  __builtin_memcpy (a, "123", 4);
  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}

void f1 (void)
{
  __builtin_strncpy (a, "123", 3);
  a[3] = 0;  // can be merged with the above

  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}

void f2 (void)
{
  const char s[] = "123";

  __builtin_strncpy (a, s, 3);
  a[3] = 0;  // can be merged with the above

  if (__builtin_strlen (a) != 3) // can be folded to false
__builtin_abort ();
}

void f3 (const char *s)
{
  if (__builtin_strlen (s) != 3)
return;

  __builtin_strncpy (a, s, 3);
  a[3] = 0;  // can be merged with the above

  if (__builtin_strlen (a) != 3) // can be folded to false
__builtin_abort ();
}

void f4 (const char *s)
{
  if (__builtin_strlen (s) < 3)
return;

  __builtin_strncpy (a, s, 3);
  a[3] = 0;  // can be merged with the above

  if (__builtin_strlen (a) != 3) // can be folded to false
__builtin_abort ();
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)

f0 ()
{
   [local count: 1073741824]:
  __builtin_memcpy (&a, "123", 4); [tail call]
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=1)

f1 ()
{
   [local count: 1073741824]:
  __builtin_memcpy (&a, "123", 3);
  a[3] = 0;
  return;

}



;; Function f2 (f2, funcdef_no=2, decl_uid=1937, cgraph_uid=3, symbol_order=2)

f2 ()
{
  const char s[4];
  long unsigned int _1;

   [local count: 1073741824]:
  s = "123";
  __builtin_strncpy (&a, &s, 3);
  a[3] = 0;
  _1 = __builtin_strlen (&a);
  if (_1 != 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  s ={v} {CLOBBER};
  return;

}



;; Function f3 (f3, funcdef_no=3, decl_uid=1941, cgraph_uid=4, symbol_order=3)

Removing basic block 6
Removing basic block 7
f3 (const char * s)
{
  long unsigned int _1;
  long unsigned int _2;

   [local count: 1073741824]:
  _1 = __builtin_strlen (s_5(D));
  if (_1 != 3)
goto ; [67.00%]
  else
goto ; [33.00%]

   [local count: 354334802]:
  __builtin_strncpy (&a, s_5(D), 3);
  a[3] = 0;
  _2 = __builtin_strlen (&a);
  if (_2 != 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741826]:
  return;

}



;; Function f4 (f4, funcdef_no=4, decl_uid=1944, cgraph_uid=5, symbol_order=4)

Removing basic block 6
Removing basic block 7
f4 (const char * s)
{
  long unsigned int _1;
  long unsigned int _2;

   [local count: 1073741824]:
  _1 = __builtin_strlen (s_5(D));
  if (_1 <= 2)
goto ; [51.12%]
  else
goto ; [48.88%]

   [local count: 524845004]:
  __builtin_strncpy (&a, s_5(D), 3);
  a[3] = 0;
  _2 = __builtin_strlen (&a);
  if (_2 != 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741828]:
  return;

}

[Bug tree-optimization/92244] vectorized loop updating 2 copies of the same pointer (for in-place reversal cross in the middle)

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92244

Peter Cordes  changed:

   What|Removed |Added

Summary|extra sub inside vectorized |vectorized loop updating 2
   |loop instead of calculating |copies of the same pointer
   |end-pointer |(for in-place reversal
   ||cross in the middle)

--- Comment #2 from Peter Cordes  ---
Forgot to update title after looking more carefully at the asm.

[Bug tree-optimization/92244] extra sub inside vectorized loop instead of calculating end-pointer

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92244

--- Comment #1 from Peter Cordes  ---
On AArch64 (with gcc8.2), we see a similar effect, more instructions in the
loop.  And an indexed addressing mode.

https://godbolt.org/z/6ZVWY_


# strrev_explicit   -O3 -mcpu=cortex-a53
   ...
.L4:
ldr q1, [x4, x2]# tail
ldr q0, [x3]# head
tbl v1.16b, {v1.16b}, v2.16b# byte shuffle
tbl v0.16b, {v0.16b}, v2.16b
str q1, [x3], 16# post-increment store to head
cmp x3, x1
str q0, [x4, x2]
sub x2, x2, #16   # doesn't update flags, not SUBS
bne .L4 # }while( head != end_head )



# strrev_implicit   -O3 -mcpu=cortex-a53
...
.L19:
ldr q1, [x3]
ldr q0, [x2]
tbl v1.16b, {v1.16b}, v2.16b
tbl v0.16b, {v0.16b}, v2.16b
str q1, [x2], 16   # post-increment addressing mode 
cmp x2, x4
str q0, [x3], -16  # post-decrement addressing mode 
bne .L19   # }while( head != end_head )

[Bug tree-optimization/92244] New: extra sub inside vectorized loop instead of calculating end-pointer

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92244

Bug ID: 92244
   Summary: extra sub inside vectorized loop instead of
calculating end-pointer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

We get a redundant instruction inside the vectorized loop here.  But it's not a
separate *counter*, it's a duplicate of the tail pointer.

It goes away if we find tail with while(*tail++); instead of calculating it
from head+length.

Only happens with vectorization, not pure scalar (bug 92243 is about the fact
that -O3 fails to use bswap as a GP-integer shuffle to auto-vectorize without
x86 SSSE3).

typedef char swapt;
void strrev_explicit(swapt *head, long len)
{
  swapt *tail = head + len - 1;
  for( ; head < tail; ++head, --tail) {
  swapt h = *head, t = *tail;
  *head = t;
  *tail = h;
  }
}
https://godbolt.org/z/wdGv4S

compiled with g++ -O3 -march=sandybridge gives us a main loop of

...
movq%rcx, %rsi # RSI = RCX before entering the loop
addq%rdi, %r8
.L4:
vmovdqu (%rcx), %xmm3   # tail load from RCX
addq$16, %rax# head
subq$16, %rcx# tail
subq$16, %rsi# 2nd tail?
vmovdqu -16(%rax), %xmm0
vpshufb %xmm2, %xmm3, %xmm1
vmovups %xmm1, -16(%rax)
vpshufb %xmm2, %xmm0, %xmm0
vmovups %xmm0, 16(%rsi) # tail store to RSI
cmpq%r8, %rax   # } while(head != end_head)
jne .L4

RSI = RCX before and after the loop.  This is obviously pointless.
head uses the same register for loads and stores.

 Then we have bloated fully-unrolled scalar cleanup, instead of using the
shuffle control for 8-byte vectors -> movhps.  Or scalar bswap.  Ideally we'd
do something clever at the overlap like one load + shuffle + store, but we
might have to load the next vector before storing the current to make this work
at the overlap.  That would presumably require more special-casing this kind of
meet-in-the-middle loop.




The implicit-length version doesn't have this extra sub in the main loop.

void strrev_implicit(swapt *head)
{
  swapt *tail = head;
  while(*tail) ++tail;// find the 0 terminator, like head+strlen
  --tail; // tail points to the last real char
  for( ; head < tail; ++head, --tail) {
  swapt h = *head, t = *tail;
  *head = t;
  *tail = h;
  }
}

.L22:
vmovdqu (%rcx), %xmm3
addq$16, %rdx   # head
subq$16, %rcx   # tail
vmovdqu -16(%rdx), %xmm0
vpshufb %xmm2, %xmm3, %xmm1
vmovups %xmm1, -16(%rdx)
vpshufb %xmm2, %xmm0, %xmm0
vmovups %xmm0, 16(%rcx)
cmpq%rsi, %rdx  # } while(head != end_head)
jne .L22

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

2019-10-27 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Hi Bill,

The bug is fixed on 7-branch through trunk. 6-branch is closed, otherwise I
would have done that as well.

Thanks for the report.

Paul

[Bug tree-optimization/92243] Missing "auto-vectorization" of char array reversal using x86 scalar bswap when SIMD pshufb isn't available

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92243

--- Comment #1 from Peter Cordes  ---
Forgot to mention, this probably applies to other ISAs with GP-integer
byte-reverse instructions and efficient unaligned loads.

[Bug tree-optimization/92243] New: Missing "auto-vectorization" of char array reversal using x86 scalar bswap when SIMD pshufb isn't available

2019-10-27 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92243

Bug ID: 92243
   Summary: Missing "auto-vectorization" of char array reversal
using x86 scalar bswap when SIMD pshufb isn't
available
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

We could use integer bswap to speed up an in-place byte-reverse loop by a
factor of probably 8, the same way we uses SIMD shuffles.

Consider this loop which reverses an explicit-length char array:
https://godbolt.org/z/ujXq_J

typedef char swapt; // int can auto-vectorize with just SSE2
void strrev_explicit(swapt *head, long len)
{
  swapt *tail = head + len - 1;
  for( ; head < tail; ++head, --tail) {
  swapt h = *head, t = *tail;
  *head = t;
  *tail = h;
  }
}

gcc -O3 (including current trunk) targeting x86-64 makes naive scalar
byte-at-a-time code, even though bswap r64 is available to byte-reverse a
uint64 in 1 or 2 uops (AMD and Intel, respectively).

With -mssse3, we do see auto-vectorization using SIMD pshufb (after checking
lengths and calculating how many 16-byte chunks can be done before bloated
fully-unrolled cleanup).  Doing the same thing with 64-bit integer registers
would be very much worth it (for code where a loop like this was a bottleneck).



With `swapt = short`, vectorizing with SSE2 pshuflw / pshufhw / pshufd is
probably worth it, but GCC chooses not to do that either.  Or working in 8-byte
chunks just using movq + pshuflw, so we only have 1 shuffle per 8-byte
load/store instead of 3 per 16-byte store.  That's a good balance for modern
Intel (Haswell, Skylake, and I think IceLake), although some AMD and earlier
Intel with more integer shuffle throughput (e.g. Sandybridge) might do better
with 3x shuffles per 16-byte load/store.

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

2019-10-27 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #31 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 27 21:25:57 2019
New Revision: 277495

URL: https://gcc.gnu.org/viewcvs?rev=277495&root=gcc&view=rev
Log:
[Darwin, PPC] Fix PR 65342.

The current Darwin load/store lo_sum patterns have neither predicate nor
constraint. This means that most parts of the backend, which rely on
recog() to validate the rtx, can produce invalid combinations/selections.

For 32bit cases this isn't a problem since we can load/store to unaligned
addresses using D-mode insns.

Conversely, for 64bit instructions that use DS mode, this can manifest as
assemble errors (for an assembler that checks the LO14 relocations), or as
crashes caused by wrong offsets (or worse, wrong content for the two LSBs).

What we want to check for Y on Darwin is:
- that the alignment of the Symbols' target is sufficient for DS mode
- that the offset is suitable for DS mode.
(while looking through the Mach-O PIC unspecs).

So, the patch removes the Darwin-specific lo_sum patterns (we begin using
the movdi_internal64 patterns). We also we need to extend the handling of the
mem_operand_gpr constraint to allow looking through Mach-O PIC UNSPECs in
the lo_sum cases.

2019-10-27  Iain Sandoe  

Backport from mainline
2019-10-17  Iain Sandoe  

PR target/65342
* config/rs6000/darwin.md (movdi_low, movsi_low_st): Delete.
(movdi_low_st): Delete.
* config/rs6000/rs6000.c
(darwin_rs6000_legitimate_lo_sum_const_p): New.
(mem_operand_gpr): Validate Mach-O LO_SUM cases separately.
* config/rs6000/rs6000.md (movsi_low): Delete.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/rs6000/darwin.md
branches/gcc-9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-9-branch/gcc/config/rs6000/rs6000.md

[Bug target/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

2019-10-27 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183

--- Comment #6 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 27 21:21:49 2019
New Revision: 277494

URL: https://gcc.gnu.org/viewcvs?rev=277494&root=gcc&view=rev
Log:
[Darwin, machopic] Fix for 67183

When we're using the LLVM-based assembler (the default on modern Darwin)
the ordering of stubs and non-lazy symbol pointers is important.

Interleaving the output (current GCC behaviour) leads to crashes which
prevents us from building code with symbol stubs.

To resolve this, we order the output of stubs and symbol indirections:

1. Any indirections in the data section
2. Symbol stubs.
3. Non-lazy symbol pointers.

At present, we still emit LTO sections after these.

2019-10-27  Iain Sandoe  

Backport from mainline
2019-10-12  Iain Sandoe  

PR target/67183
* config/darwin.c (machopic_indirection): New field to flag
non-lazy-symbol-pointers in the data section.
(machopic_indirection_name): Compute if an indirection should
appear in the data section.
(machopic_output_data_section_indirection): New callback split
from machopic_output_indirection.
(machopic_output_stub_indirection): Likewise.
(machopic_output_indirection): Retain the code for non-lazy
symbol pointers in their regular section.
(machopic_finish): Use the new callbacks to order the indirection
output.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/darwin.c

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

2019-10-27 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #30 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 27 21:17:33 2019
New Revision: 277493

URL: https://gcc.gnu.org/viewcvs?rev=277493&root=gcc&view=rev
Log:
[Darwin, machopic] Preparatory patches.

This is a combined set of 5 patches that allows us to fix
PR 65342 and 67183.

276924 Make machopic_finish() static.

276767 Set a SYMBOL flag for indirections.

We are able to treat these specially where needed in legitimate address
tests (specifically, they are guaranteed to be pointer-aligned).

276708 Compute and cache indirection rules.

This caches a check for the requirement to indirect a symbol in the Darwin
ABI, and uses it where needed.  We also ensure that we place the indirection
pointers into the non-lazy symbol pointers section.  Other placements have
occurred with various platform toolchains - but these seem to have been
unintentional so we match current platform toolchains.

276675 Consider visibility in indirections.

For weak, hidden vars the indirection should just be as normal, that
is that the indirections for such symbols should appear in the non-lazy
symbol pointers table, not in the .data section.

276674 Initial tidy of Mach-O symbol handling.

We want to improve the detection and caching of symbol-properties
so that (a) we can make the compiler's output match the platform
norms (b) we can improve efficiency by checking flags instead of
inspecting strings. (c) The fix for PR71767 was a largish hammer
and we want to reduce the number of symbols that are made linker-
visible.

This first patch is largely typographical changes with no functional
difference intended:

- Tries to ensure that there's no overlap between the symbols used in
the Mach-O case and those declared in the i386 or rs6000 port trees.

 - Some improvement to comments.

- Makes the naming of the symbol flags consistent with other uses.

 - Provides a predicate macro for each use.

2019-10-27  Iain Sandoe  

Backport from mainline
2019-10-12  Iain Sandoe  

* config/darwin-protos.h (machopic_finish): Delete.
* config/darwin.c (machopic_finish): Make static.

Backport from mainline
2019-10-09  Iain Sandoe  

* config/darwin.c (machopic_indirect_data_reference): Set flag to
indicate that the new symbol is an indirection.
(machopic_indirect_call_target): Likewise.
* config/darwin.h (MACHO_SYMBOL_FLAG_INDIRECTION): New.
(MACHO_SYMBOL_INDIRECTION_P): New.
(MACHO_SYMBOL_FLAG_STATIC): Adjust bit number.

Backport from mainline
2019-10-08  Iain Sandoe  

* config/darwin.c (machopic_indirect_data_reference): Check for
required indirections before making direct access to defined
values.
(machopic_output_indirection): Place the indirected pointes for
required indirections into the non-lazy symbol pointers section.
(darwin_encode_section_info):
* config/darwin.h (MACHO_SYMBOL_FLAG_MUST_INDIRECT): New.
(MACHO_SYMBOL_MUST_INDIRECT_P): New.

Backport from mainline
2019-10-07  Iain Sandoe  

* config/darwin.c (machopic_output_indirection): Don't put
hidden symbol indirections into the .data section, use the
non-lazy symbol pointers section as normal.
(darwin_encode_section_info): Record if a symbol is hidden.
* config/darwin.h (MACHO_SYMBOL_FLAG_HIDDEN_VIS): New.
(MACHO_SYMBOL_HIDDEN_VIS_P): New.

Backport from mainline
2019-10-07  Iain Sandoe  

* config/darwin.c (machopic_symbol_defined_p): Use symbol flag
predicates instead of accessing bits directly.
(machopic_indirect_call_target): Likewise.
(machopic_output_indirection): Likewise.
(darwin_encode_section_info): Improve description.  Use renamed
symbol flags.  Use predicate macros for variables and functions.
* config/darwin.h:
Rename MACHO_SYMBOL_VARIABLE to MACHO_SYMBOL_FLAG_VARIABLE.
Rename MACHO_SYMBOL_DEFINED to MACHO_SYMBOL_FLAG_DEFINED.
Rename MACHO_SYMBOL_STATIC to MACHO_SYMBOL_FLAG_STATIC.
(MACHO_SYMBOL_VARIABLE_P): New.
(MACHO_SYMBOL_DEFINED_P):New.
(MACHO_SYMBOL_STATIC_P): New.
* config/i386/darwin.h (MACHO_SYMBOL_FLAG_VARIABLE): Delete.
(SYMBOL_FLAG_SUBT_DEP): New.
* config/rs6000/darwin.h (SYMBOL_FLAG_SUBT_DEP): New.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/darwin-protos.h
branches/gcc-9-branch/gcc/config/darwin.c
branches/gcc-9-branch/gcc/config/darwin.h
branches/gcc-9-branch/gcc/config/i386/darwin.h
branches/gcc-9-branch/gcc/config/rs6000/darwin.h

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

2019-10-27 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Sun Oct 27 18:28:52 2019
New Revision: 277490

URL: https://gcc.gnu.org/viewcvs?rev=277490&root=gcc&view=rev
Log:
2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* resolve.c (flag_fn_result_spec): Correct a typo before the
function declaration.
* trans-decl.c (gfc_sym_identifier): Boost the length of 'name'
to allow for all variants. Simplify the code by using a pointer
to the symbol's proc_name and taking the return out of each of
the conditional branches. Allow symbols with fn_result_spec set
that do not come from a procedure namespace and have a module
name to go through the non-fn_result_spec branch.

2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* gfortran.dg/char_result_19.f90 : New test.
* gfortran.dg/char_result_mod_19.f90 : Module for the new test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/char_result_19.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/char_result_mod_19.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/resolve.c
branches/gcc-9-branch/gcc/fortran/trans-decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/92113] [8/9/10 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

2019-10-27 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113

Thomas Koenig  changed:

   What|Removed |Added

  Component|fortran |middle-end
Summary|[8 regression] r276673  |[8/9/10 regression] r276673
   |causes segfault in  |causes segfault in
   |gfortran.dg/pr51434.f90 |gfortran.dg/pr51434.f90

--- Comment #6 from Thomas Koenig  ---
I have bisected up to current trunk (r277486), and I now find that
the test case fails at -O2 on gcc135 when compiled by hand:

[tkoenig@gcc135 ~]$ gfortran  -O2 pr51434.f90 
[tkoenig@gcc135 ~]$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fff863304d7 in ???
#1  0x1634 in ???
#2  0x7fff85db527f in ???
Speicherzugriffsfehler

It does _not_ fail within the testsuite (which is why we do not see
this in the test results):

[tkoenig@gcc135 gcc]$ make check-gfortran RUNTESTFLAGS="dg.exp=pr51434.f90"
rm -rf testsuite/gfortran-parallel
make[1]: Entering directory `/home/tkoenig/trunk-bin/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../trunk/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gfortran-parallel/finished ]; then \
  rm -rf testsuite/gfortran; \
else \
  cd testsuite/gfortran; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gfortran|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gfortran
dg.exp=pr51434.f90; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gfortran-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test Run By tkoenig on Sun Oct 27 18:10:53 2019
Native configuration is powerpc64le-unknown-linux-gnu

=== gfortran tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/tkoenig/trunk/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/tkoenig/trunk/gcc/testsuite/gfortran.dg/dg.exp ...

=== gfortran Summary ===

# of expected passes    12
/home/tkoenig/trunk-bin/gcc/testsuite/gfortran/../../gfortran  version 10.0.0
20191027 (experimental) (GCC) 

The log file shows:

Executing on host:
/home/tkoenig/trunk-bin/gcc/testsuite/gfortran/../../gfortran
-B/home/tkoenig/trunk-bin/gcc/testsuite/gfortran/../../
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/tkoenig/trunk/gcc/testsuite/gfortran.dg/pr51434.f90 
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O2   -pedantic-errors 
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libquadmath/.libs 
-lm-o ./pr51434.exe(timeout = 300)
spawn -ignore SIGHUP
/home/tkoenig/trunk-bin/gcc/testsuite/gfortran/../../gfortran
-B/home/tkoenig/trunk-bin/gcc/testsuite/gfortran/../../
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/tkoenig/trunk/gcc/testsuite/gfortran.dg/pr51434.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -pedantic-errors
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/tkoenig/trunk-bin/powerpc64le-unknown-linu

[Bug ipa/92242] New: [10 regression] LTO ICE in ipa_get_cs_argument_count ipa-prop.h:598

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92242

Bug ID: 92242
   Summary: [10 regression] LTO ICE in ipa_get_cs_argument_count
ipa-prop.h:598
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r277460 PASS
r277486 FAIL

I'll try creduce it / proprietary codebase, 50+ files LTO linked into .so dylib

Fedora 31 x86_64

/home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native

make dylib [LTO with high optimization]

during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xdd4bdf crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0x64e28d ipa_get_cs_argument_count
/home/dimhen/src/gcc_current/gcc/ipa-prop.h:598
0x64e28d ipa_merge_fn_summary_after_inlining(cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/ipa-fnsummary.c:3318
0x16f66db inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:484
0x16f0682 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x16f0682 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x16f0682 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

2019-10-27 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sun Oct 27 17:06:38 2019
New Revision: 277489

URL: https://gcc.gnu.org/viewcvs?rev=277489&root=gcc&view=rev
Log:
2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* resolve.c (flag_fn_result_spec): Correct a typo before the
function declaration.
* trans-decl.c (gfc_sym_identifier): Boost the length of 'name'
to allow for all variants. Simplify the code by using a pointer
to the symbol's proc_name and taking the return out of each of
the conditional branches. Allow symbols with fn_result_spec set
that do not come from a procedure namespace and have a module
name to go through the non-fn_result_spec branch.

2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* gfortran.dg/char_result_19.f90 : New test.
* gfortran.dg/char_result_mod_19.f90 : Module for the new test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/char_result_19.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/char_result_mod_19.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/92095] ICE on sparc-gcc -O1 -mcpu=niagara2 -fPIE: validize_mem(rtx_def*): gcc/gcc/explow.c:521

2019-10-27 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095

Eric Botcazou  changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu.org,  |
   |ebotcazou at libertysurf dot fr|
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #4 from Eric Botcazou  ---
Investigating.

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

2019-10-27 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Sun Oct 27 16:21:36 2019
New Revision: 277488

URL: https://gcc.gnu.org/viewcvs?rev=277488&root=gcc&view=rev
Log:
2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* resolve.c (flag_fn_result_spec): Correct a typo before the
function declaration.
* trans-decl.c (gfc_sym_identifier): Boost the length of 'name'
to allow for all variants. Simplify the code by using a pointer
to the symbol's proc_name and taking the return out of each of
the conditional branches. Allow symbols with fn_result_spec set
that do not come from a procedure namespace and have a module
name to go through the non-fn_result_spec branch.

2019-10-27  Paul Thomas  

Backport from mainline
PR fortran/86248
* gfortran.dg/char_result_19.f90 : New test.
* gfortran.dg/char_result_mod_19.f90 : Module for the new test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/char_result_19.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/char_result_mod_19.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/92095] ICE on sparc-gcc -O1 -mcpu=niagara2 -fPIE: validize_mem(rtx_def*): gcc/gcc/explow.c:521

2019-10-27 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-27
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
I can reproduce.

[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

2019-10-27 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sun Oct 27 15:00:54 2019
New Revision: 277487

URL: https://gcc.gnu.org/viewcvs?rev=277487&root=gcc&view=rev
Log:
2019-10-27  Paul Thomas  

PR fortran/86248
* resolve.c (flag_fn_result_spec): Correct a typo before the
function declaration.
* trans-decl.c (gfc_sym_identifier): Boost the length of 'name'
to allow for all variants. Simplify the code by using a pointer
to the symbol's proc_name and taking the return out of each of
the conditional branches. Allow symbols with fn_result_spec set
that do not come from a procedure namespace and have a module
name to go through the non-fn_result_spec branch.

2019-10-27  Paul Thomas  

PR fortran/86248
* gfortran.dg/char_result_19.f90 : New test.
* gfortran.dg/char_result_mod_19.f90 : Module for the new test.

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

[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array

2019-10-27 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548

Marek Polacek  changed:

   What|Removed |Added

 CC||euloanty at live dot com

--- Comment #9 from Marek Polacek  ---
*** Bug 92238 has been marked as a duplicate of this bug. ***

[Bug c++/92238] constexpr fails to compile 2d std::array in gcc 10 master

2019-10-27 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92238

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Going to be fixed by
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01685.html

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

[Bug fortran/92113] [8 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

2019-10-27 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113

--- Comment #5 from Thomas Koenig  ---
Still having no luck trying to find out which patch made this
error not appear on trunk.  I think this may actually depend
on the version of the bootstrapping compiler :-(

In the meantime, here is the first difference in the dump files
for gcc 8:

diff -u Decl-artificial/pr51434.f90.088t.fixup_cfg4
Tree-readonly/pr51434.f90.088t.fixup_cfg4
--- Decl-artificial/pr51434.f90.088t.fixup_cfg4 2019-10-27 12:28:21.315599467
+
+++ Tree-readonly/pr51434.f90.088t.fixup_cfg4   2019-10-27 12:28:44.184983294
+
@@ -16,7 +16,7 @@
 __attribute__((externally_visible))
 main (integer(kind=4) argc, character(kind=1) * * argv)
 {
-  static struct a c = {.m=5, .t={"a", "b", "c", "d", "e", " ", " ", " ", " ",
" ", " ", " ", " ", " ", " ", " ", " ", " "}};
+  static struct a c;
   static integer(kind=4) options.3[7] = {68, 8191, 0, 1, 1, 0, 31};
   integer(kind=4) _6;
   integer(kind=8) S.2_7

[Bug lto/92234] [10 Regression] ICE verify_gimple failed (profiled lto) on s390x-linux-gnu

2019-10-27 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92234

Matthias Klose  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target|s390x-linux-gnu |s390x-linux-gnu,
   ||i686-linux-gnu

--- Comment #1 from Matthias Klose  ---
also seen on i686-linux-gnu, but not aarch64-linux-gnu and arm-linux-gnueabihf

[Bug target/91851] [m68k] Convert the backend to MODE_CC so it can be kept in future releases

2019-10-27 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #1) 
> > https://wiki.debian.org/M68k/QemuSystemM68k
> 
> The guide is not complete yet, I will finish it throughout next week.

The code has been completed now after a regression in the serial emulation in
qemu-system-m68k was fixed. Following through the guide now yields a fully
usable Debian/m68k system running on an emulated Macintosh Quadra 800.

> The bounty on BountySource.com can be found at:
> 
> > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

The bounty is now at $5000 with 43 backers.

[Bug c/92241] ice in vect_mark_pattern_st mts, at tree-vect-patterns.c:5175

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92241

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||dimhen at gmail dot com

--- Comment #1 from Dmitry G. Dyachenko  ---
r277434 PASS for me

$ ./gcc_277434/bin/gcc  -O3 -c x.i
x.i: In function ‘d’:
x.i:8:13: warning: iteration 2 invokes undefined behavior
[-Waggressive-loop-optimizations]
8 |   a &= c[b + e] && 1;
  |~^~~
x.i:7:5: note: within this loop
7 | for (; e <= 8; e++)
  | ^~~
$

[Bug c/92241] New: ice in vect_mark_pattern_st mts, at tree-vect-patterns.c:5175

2019-10-27 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92241

Bug ID: 92241
   Summary: ice in vect_mark_pattern_st mts, at
tree-vect-patterns.c:5175
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C code:

int a, b;
char c[2];
void d() {
  char e;
  for (; b; b--) {
e = 0;
for (; e <= 8; e++)
  a &= c[b + e] && 1;
  }
}

when compiled by recent gcc trunk and compiler flag -O3, does this:

during GIMPLE pass: vect
destDir/testFile.7849.c: In function ‘func_16.isra’:
destDir/testFile.7849.c:651:17: internal compiler error: in
vect_mark_pattern_st
mts, at tree-vect-patterns.c:5175
  651 | static int8_t * func_16(uint32_t  p_17)
  | ^~~
0x7e7446 vect_mark_pattern_stmts
../../trunk/gcc/tree-vect-patterns.c:5175
0x7e7446 vect_pattern_recog_1
../../trunk/gcc/tree-vect-patterns.c:5249
0x18defde vect_pattern_recog(vec_info*)
../../trunk/gcc/tree-vect-patterns.c:5369
0x1109078 vect_analyze_loop_2
../../trunk/gcc/tree-vect-loop.c:1925

The bug first seems to appear sometime between revision 277400 and 277450.

[Bug bootstrap/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92240

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Dmitry G. Dyachenko  ---
r277486 PASS for me

[Bug bootstrap/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92240

--- Comment #1 from Dmitry G. Dyachenko  ---
simplified configure' call

configure --enable-checking=yes --enable-languages=c,c++ --disable-multilib
--with-isl

make

/home/dimhen/build/gcc_current/./prev-gcc/xgcc
-B/home/dimhen/build/gcc_current/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H -I.
-I/home/dimhen/src/gcc_current/isl -I/home/dimhen/src/gcc_current/isl/include
-Iinclude/ -I/home/dimhen/src/gcc_current/gmp
-I/home/dimhen/build/gcc_current/./gmp -g -O2 -fno-checking -gtoggle -MT
isl_fold.lo -MD -MP -MF .deps/isl_fold.Tpo -c
/home/dimhen/src/gcc_current/isl/isl_fold.c -o isl_fold.o
during IPA pass: inline
/home/dimhen/src/gcc_current/isl/isl_fold.c:1777:1: internal compiler error: in
duplicate, at ipa-prop.c:3883
 1777 | }
  | ^
0xe820f8 ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
/home/dimhen/src/gcc_current/gcc/ipa-prop.c:3883
0xe8a7df call_summary::symtab_duplication(cgraph_edge*,
cgraph_edge*, void*)
/home/dimhen/src/gcc_current/gcc/symbol-summary.h:771
0xae6b11 symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/cgraph.c:453
0xb04f3f cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
/home/dimhen/src/gcc_current/gcc/cgraphclones.c:141
0xb05f80 cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/dimhen/src/gcc_current/gcc/cgraphclones.c:390
0x2060f11 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:217
0x2060fc6 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:236
0x2060fc6 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:236
0x2061c4b inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:479
0x2052e40 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x20548e9 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x205578e execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/92240] New: [10 regression] ICE in duplicate, at ipa-prop.c:3883

2019-10-27 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92240

Bug ID: 92240
   Summary: [10 regression] ICE in duplicate, at ipa-prop.c:3883
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r277460 PASS
r277485 FAIL

gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native

make
...
/home/dimhen/build/gcc_current/./prev-gcc/xgcc
-B/home/dimhen/build/gcc_current/./prev-gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/sys-include -fno-checking
-DHAVE_CONFIG_H -I. -I/home/dimhen/src/gcc_current/isl
-I/home/dimhen/src/gcc_current/isl/include -Iinclude/
-I/home/dimhen/src/gcc_current/gmp -I/home/dimhen/build/gcc_current/./gmp -g
-O2 -fno-checking -gtoggle -MT isl_fold.lo -MD -MP -MF .deps/isl_fold.Tpo -c
/home/dimhen/src/gcc_current/isl/isl_fold.c -o isl_fold.o
during IPA pass: inline
/home/dimhen/src/gcc_current/isl/isl_fold.c:1777:1: internal compiler error: in
duplicate, at ipa-prop.c:3883
 1777 | }
  | ^
0xeeab70 ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
/home/dimhen/src/gcc_current/gcc/ipa-prop.c:3883
0xef3257 call_summary::symtab_duplication(cgraph_edge*,
cgraph_edge*, void*)
/home/dimhen/src/gcc_current/gcc/symbol-summary.h:771
0xafb841 symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
/home/dimhen/src/gcc_current/gcc/cgraph.c:453
0xb19c79 cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
/home/dimhen/src/gcc_current/gcc/cgraphclones.c:141
0xb1acba cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/dimhen/src/gcc_current/gcc/cgraphclones.c:390
0x26ccd59 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:217
0x26cce0e clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:236
0x26cce0e clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:236
0x26cda93 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/ipa-inline-transform.c:479
0x26bec88 inline_small_functions
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2151
0x26c0731 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2615
0x26c15d6 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

2019-10-27 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77918

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #13 from Arseny Solokha  ---
Should this PR be closed now?

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

2019-10-27 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #11 from Arseny Solokha  ---
Is the backport to GCC 8 still pending?

[Bug ipa/92239] New: [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877

2019-10-27 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92239

Bug ID: 92239
   Summary: [10 Regression] ICE in insert_vi_for_tree, at
tree-ssa-structalias.c:2877
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openacc
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-10.0.0-alpha20191020 snapshot (r277217) ICEs when compiling
gcc/testsuite/g++.dg/torture/pr83619.C:

1) w/ -O3 -fopenacc --param ipa-cp-eval-threshold=1 --param
uninlined-thunk-insns=1000:

% g++-10.0.0-alpha20191020 -O3 -fopenacc --param ipa-cp-eval-threshold=1
--param uninlined-thunk-insns=1000 -c gcc/testsuite/g++.dg/torture/pr83619.C
during IPA pass: pta
gcc/testsuite/g++.dg/torture/pr83619.C:64:1: internal compiler error: in
insert_vi_for_tree, at tree-ssa-structalias.c:2877
   64 | }
  | ^
0x1018c3b insert_vi_for_tree
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-ssa-structalias.c:2877
0x10212db create_function_info_for
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-ssa-structalias.c:5975
0x10212db ipa_pta_execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-ssa-structalias.c:8150
0x10212db execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/tree-ssa-structalias.c:8550

2) w/ -O3 --param ipa-cp-eval-threshold=1 --param uninlined-thunk-insns=1000:

% g++-10.0.0-alpha20191020 -O3 --param ipa-cp-eval-threshold=1 --param
uninlined-thunk-insns=1000 -c gcc/testsuite/g++.dg/torture/pr83619.C
during RTL pass: expand
gcc/testsuite/g++.dg/torture/pr83619.C: In member function 'int
H::_ZThn8_N1H1oEP1e.artificial_thunk.0(e*)':
gcc/testsuite/g++.dg/torture/pr83619.C:49:7: internal compiler error: in
set_parm_rtl, at cfgexpand.c:1311
   49 |   int o (e *);
  |   ^
0x68684e set_parm_rtl(tree_node*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/cfgexpand.c:1311
0xbd51cc assign_parm_setup_reg
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/function.c:3369
0xbd6010 assign_parms
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/function.c:3663
0xbd7abb expand_function_start(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/function.c:5097
0xa87150 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/cfgexpand.c:6442

3) w/ -O3 --param ipa-cp-eval-threshold=1 --param uninlined-thunk-insns=10:

% x86_64-unknown-linux-gnu-g++-10.0.0-alpha20191020 -O3 --param
ipa-cp-eval-threshold=1 --param uninlined-thunk-insns=10 -c
gcc/testsuite/g++.dg/torture/pr83619.C
during RTL pass: expand 
gcc/testsuite/g++.dg/torture/pr83619.C: In member function 'int
H::_ZThn8_N1H1oEP1e.artificial_thunk.0(e*)':
gcc/testsuite/g++.dg/torture/pr83619.C:62:5: internal compiler error: in
expand_expr_real_1, at expr.c:10092
   62 |   n = p;
  |   ~~^~~
0x6a53c5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:10092
0xb88629 expand_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.h:282
0xb88629 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:7920
0xb7828e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:8816
0xb7dd59 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:11389
0xb88982 expand_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.h:282
0xb88982 expand_expr_addr_expr_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:7979
0xb88c14 expand_expr_addr_expr_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:8079
0xb7d5b0 expand_expr_addr_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:8154
0xb7d5b0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191020/work/gcc-10-20191020/gcc/expr.c:11332
0xb8a114 store_expr(tree_node*, rtx_de