[Bug target/71235] march=silvermont turns on aes by default

[m.vorobyov at cs dot msu.ru]

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

Mikhail Vorobyov  changed:

   What|Removed |Added

 CC||m.vorobyov at cs dot msu.ru

--- Comment #1 from Mikhail Vorobyov  ---
There is the same problem with Sandybridge. All Sandybridge i3 mobile cores
doesn't support aes accordingly to https://ark.intel.com/. E.g.
https://ark.intel.com/products/54624/.
But -march=sandybridge enables __AES__.
I thought -march=X should be valid for all of X too.

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[krzysio.kurek at wp dot pl]

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

krzysio.kurek at wp dot pl changed:

   What|Removed |Added

Version|7.1.0   |7.2.0

--- Comment #17 from krzysio.kurek at wp dot pl ---
I've been trying to create a minimal testcase but I've not been able to.
Seemingly random actions like changing the directory from the build dir back
into it prevents the bug from manifesting.
Looking at results of Valgrind's tool, Callgrind, I've managed to find the hog
being Random::get() calls not being optimized as aggressively on GCC7 as on
GCC6.
On GCC6, std::mersenne_twister_engine is being called directly from the main
world simulation loop, whereas on GCC7, Random::get() is called every time
calculations on random numbers are made. Random::get() in turn calls
std::uniform_int_distribution which then calls the mersenne engine.

[Bug target/85293] ICE in output_1257, at config/rs6000/vsx.md:3252

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Fixed.

[Bug target/85293] ICE in output_1257, at config/rs6000/vsx.md:3252

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Sat Apr 14 21:13:20 2018
New Revision: 259386

URL: https://gcc.gnu.org/viewcvs?rev=259386=gcc=rev
Log:
rs6000: Disable -m[no-]direct-move (PR85293)

The -mno-direct-move option causes a lot of problems, since it forces
us to be able to generate code for p8 and up with some crucial
instructions missing.  This patch removes the -m[no-]direct-move
options so that the user cannot put us into this unexpected situation
anymore.  Internally we still have all the same flags, and they are
automatically set based on -mcpu; getting rid of that is a lot more
work and will have to wait for GCC 9 (in some places the flag is used
to see if we are compiling for a p8 _at all_).


PR target/85293
* config/rs6000/rs6000.opt (mdirect-move): Make deprecated.
* doc/invoke.texi (RS/6000 and PowerPC Options): Remove -mdirect-move
and -mno-direct-move.

gcc/testsuite/
PR target/85293
* gcc.target/powerpc/pr80098-2.c: Remove -mdirect-move.  Remove the
corresponding dg-error clause.
* gcc.target/powerpc/pr80098-3.c: Ditto.
* gcc.target/powerpc/pr80103-1.c: Delete.

Removed:
trunk/gcc/testsuite/gcc.target/powerpc/pr80103-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-3.c

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
This is shown as a regression on 6 and 7 are you going to backport this?  Is it
even back-portable?

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[vehre at gcc dot gnu.org]

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

Bug 81773 Summary: [Coarray] Get with vector index on lhs leads to incorrect 
caf_get_by_ref() call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81773

   What|Removed |Added

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

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Fxied by r259385.

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Fixed by r259385.

[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
*** Bug 85399 has been marked as a duplicate of this bug. ***

[Bug target/85399] Redundant SSP clearing before rdssp

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
This will be fixed by PR 85397.

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

[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs

[hjl.tools at gmail dot com]

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

Bug 85399 Summary: Redundant SSP clearing before rdssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85399

   What|Removed |Added

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

[Bug target/85404] -fcf-protection -mcet doesn't work with -fleading-underscore

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-14
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Please take a look at hjl/cet/master branch at

https://github.com/hjl-tools/gcc/tree/hjl/cet/master

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 14 14:45:59 2018
New Revision: 259385

URL: https://gcc.gnu.org/viewcvs?rev=259385=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-14  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-14  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
trunk/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Sat Apr 14 14:45:59 2018
New Revision: 259385

URL: https://gcc.gnu.org/viewcvs?rev=259385=gcc=rev
Log:
gcc/fortran/ChangeLog:

2018-04-14  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-14  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/get_to_indexed_array_1.f90
trunk/gcc/testsuite/gfortran.dg/coarray/get_to_indirect_array.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85404] New: -fcf-protection -mcet doesn't work with -fleading-underscore

[hjl.tools at gmail dot com]

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

Bug ID: 85404
   Summary: -fcf-protection -mcet doesn't work with
-fleading-underscore
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---

[hjl@gnu-cfl-1 gcc]$ cat x.c
void func(void) __asm("_func");
void _func(int x) {}
void func(void) {}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -c -fcf-protection -mcet -fleading-underscore
x.c
/tmp/ccPfHME2.s: Assembler messages:
/tmp/ccPfHME2.s:37: Error: can't resolve `.L11' {*UND* section} - `.L1' {*UND*
section}
/tmp/ccPfHME2.s:38: Error: can't resolve `.L41' {*UND* section} - `.L11' {*UND*
section}
/tmp/ccPfHME2.s:45: Error: can't resolve `.L31' {*UND* section} - `.L21' {*UND*
section}
/tmp/ccPfHME2.s: Error: local label `"1" (instance number 1 of a fb label)' is
not defined
/tmp/ccPfHME2.s: Error: local label `"0" (instance number 1 of a fb label)' is
not defined
/tmp/ccPfHME2.s: Error: local label `"4" (instance number 1 of a fb label)' is
not defined
/tmp/ccPfHME2.s: Error: local label `"3" (instance number 1 of a fb label)' is
not defined
/tmp/ccPfHME2.s: Error: local label `"2" (instance number 1 of a fb label)' is
not defined
[hjl@gnu-cfl-1 gcc]$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug fortran/85364] -fopenmp should not put array in program on the stack

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Jakub Jelinek from comment #3)
> If it is about variables in MAIN__ and not say variables inside of BLOCK
> inside of MAIN__, then perhaps.  For BLOCK, I wonder about stuff like:
>   !$omp parallel
>   block
> integer :: i
> i = ...
> use (i)
>   end block
>   !$omp end parallel
> end
> and similar, where the implicit SAVE would be undesirable.

As far as I understand the Fortran standard, variables inside BLOCKs
are not affected.

Definition:

1.3.124
scoping unit
BLOCK construct, derived-type definition, interface body, program unit, or
subprogram, excluding all nested
scoping units in it

5.3.16 says

A variable, common block, or procedure pointer declared in the scoping unit of
a main program, module, or
submodule implicitly has the SAVE attribute, which may be confirmed by explicit
specification.

So, in your example, the variable i is unsaved.

[Bug fortran/85387] [8 Regression] incorrect output with optimization /= 0

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed, closing.

Thanks for the bug report!

[Bug fortran/85387] [8 Regression] incorrect output with optimization /= 0

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Apr 14 13:38:41 2018
New Revision: 259384

URL: https://gcc.gnu.org/viewcvs?rev=259384=gcc=rev
Log:
2018-04-14  Thomas Koenig  

PR fortran/85387
* frontend-passes.c (traverse_io_block): Check for start, end or
stride being defined by an outer implied DO loop.

2018-04-14  Thomas Koenig  

PR fortran/85387
* gfortran.dg/implied_do_io_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_io_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/85403] New: internal compiler error: ... config/i386/i386.c:32347

[hjl.tools at gmail dot com]

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

Bug ID: 85403
   Summary: internal compiler error: ... config/i386/i386.c:32347
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 gcc]$ /export/build/gnu/gcc-cet-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-cet-test/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c 
-fcf-protection -mcet   -fno-diagnostics-show-caret -fdiagnostics-color=never  
 -ansi -pedantic-errors  -lm  -o ./mvc1.exe
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c: In
function \u2018foo.resolver\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c:27:1:
error: \u2018-fcf-protection=full\u2019 requires Intel CET support. Use -mcet
or both of -mibt and -mshstk options to enable CET
during IPA pass: targetclone
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c:27:1:
internal compiler error: tree check: expected target_option_node, have
error_mark in get_builtin_code_for_version, at config/i386/i386.c:32347
0x13624ff tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/export/gnu/import/git/sources/gcc/gcc/tree.c:9327
0x7ddca8 tree_check(tree_node*, char const*, int, char const*, tree_code)
/export/gnu/import/git/sources/gcc/gcc/tree.h:3135
0x146134e get_builtin_code_for_version
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:32347
0x1461b43 dispatch_function_versions
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:32631
0x14629ab ix86_generate_version_dispatcher_body
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:32967
0x1c16fcd create_dispatcher_calls
/export/gnu/import/git/sources/gcc/gcc/multiple_target.c:97
0x1c18098 ipa_target_clone
/export/gnu/import/git/sources/gcc/gcc/multiple_target.c:437
0x1c18104 execute
/export/gnu/import/git/sources/gcc/gcc/multiple_target.c:466
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-cfl-1 gcc]$ 

Since CET is applied to the whole program, it is correct to disallow
-fcf-protection=full without -mcet.  But compiler shouldn't crash.

[Bug target/42947] multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib

[slyfox at inbox dot ru]

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

--- Comment #6 from Sergei Trofimovich  ---
Created attachment 43931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43931=edit
0001-gcc-config.gcc-sh-Disable-sysroot-suffix-PR42947.patch

0001-gcc-config.gcc-sh-Disable-sysroot-suffix-PR42947.patch implements "- drop
SYSROOT_SUFFIX_SPEC support for sh* targets" above. Tested as:

cc="${HOME}/dev/git/gcc-sh4-installed/bin/sh4-unknown-linux-gnu-gcc
-B/usr/libexec/gcc/sh4-unknown-linux-gnu/"

$ cc="${built}/sh4-unknown-linux-gnu-gcc"
$ echo 'int main(){}' > 'a.c'
$ $cc a.c -o a
$ $cc a.c -o a.m4 -m4
$ $cc a.c -o a.m4 -m4-100

All 3 work now.

[Bug target/42947] multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich  ---
I have looked at it a bit and I think the bug here is in interaction between
MULTILIB_DEFAULTS
and
SYSROOT_SUFFIX_SPEC

AFAIU normally gcc ignores spec overrides for MULTILIB_DEFAULTS.

In our case values are:
// from sh/sh.h expansion
#define MULTILIB_DEFAULTS { "ml", "m4" }

// from autogenerated multilib.h
static const char *const multilib_raw[] = {
". !m4;",
"m4 m4;",
NULL
};

// from autogenerated sysroot-suffix.h
#define SYSROOT_SUFFIX_SPEC "" \
"%{m4:/m4;" \
":}"

Note even when we pass option -m4 we never append 'm4' suffix in library search
path (because it's a MULTILIB_DEFAULTS).

Looks like sh is one of 2 rare targets that touch t-sysroot-suffix:

sh-*-elf* | sh[12346l]*-*-elf* | \
  sh-*-linux* | sh[2346lbe]*-*-linux* | \
  sh-*-netbsdelf* | shl*-*-netbsdelf*)

  tmake_file="... t-sysroot-suffix"

tic6x-*-uclinux)
  tmake_file="t-sysroot-suffix ..."

I think a few possible solutions here are:
- drop SYSROOT_SUFFIX_SPEC support for sh* targets (or some of sh targets)
- fix SYSROOT_SUFFIX_SPEC parsing to respect MULTILIB_DEFAULTS

Does the above sound about right?

I know nothing about SYSROOT_SUFFIX_SPEC.
What uses it? It feels like a competing mechanism to multilib.

[Bug fortran/85387] [8 Regression] incorrect output with optimization /= 0

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay  ---
(In reply to Eric Gallager from comment #9)
> There have been a bunch of commits for this bug; is it fixed yet?

Dunno, back then I focused only on two targets, namely ARM and V850.  Neither
did I perform a global review, nor do I know whether in the meantime (4 years
now) more headers and files slipped in.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Sorry for overlooking the PR83983, I can help you with that next week.
> Now I've got reduced 1/6 of preprocessed files. Hope that having a
> reasonable small test-case would allow you do debug that and fix?

No, sorry, I'm giving up, just revert my couple of changes instead.

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

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

--- Comment #1 from coypu  ---
Threw computing resources at the problem, so now I have an "offending" commit.
Before this commit, it doesn't segfault.
After, it does.

commit bbb9b536dd58015b5712a867954d34aae9d9dae5 (HEAD, refs/bisect/bad)
Author: thopre01 
Date:   Tue Jan 6 11:51:16 2015 +

2015-01-06  Thomas Preud'homme  

gcc/
PR tree-optimization/63259
* tree-ssa-math-opts.c (pass_optimize_bswap::execute): Stop checking
if optab exists for 16bit byteswap.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219256
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c/85402] New: excessive compile time with -Wmissing-braces

[dcb314 at hotmail dot com]

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

Bug ID: 85402
   Summary: excessive compile time with -Wmissing-braces
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code - when compiled by -Wmissing-braces -  can cause 
compile times of over 100 minutes on gcc trunk. -O2 doesn't seem
to be required.

-Wmissing-braces seems to want to print out all parts of a very long
data structure in the user's source code.

Maybe this should be constrained to the first 100 or 1000 elements or so.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Eric Botcazou from comment #4)
> Let's just back out my couple of patches to ipa-devirt.c.  Nobody seems to
> care about PR ipa/83983 so I guess I no longer do either.

Sorry for overlooking the PR83983, I can help you with that next week.
Now I've got reduced 1/6 of preprocessed files. Hope that having a reasonable
small test-case would allow you do debug that and fix?