[Bug fortran/83864] ICE in gfc_apply_init, at fortran/expr.c:4271

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jan 18 07:54:17 2018
New Revision: 256837

URL: https://gcc.gnu.org/viewcvs?rev=256837=gcc=rev
Log:
2018-01-17  Harald Anlauf  

PR fortran/83864
* expr.c (add_init_expr_to_sym): Do not dereference NULL pointer.

2018-01-17  Harald Anlauf  

PR fortran/83864
* gfortran.dg/pr83864.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr83864.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #11 from Joshua Kinard  ---
(In reply to Joshua Kinard from comment #10)
> Created attachment 43166 [details]
> genrecog.ii temp data from failing build command

Forgot to add, this is generated from a checkout of commit id 1998c023a3ed,
which was the last "bad" build, per git bisect.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #10 from Joshua Kinard  ---
Created attachment 43166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43166=edit
genrecog.ii temp data from failing build command

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #9 from Joshua Kinard  ---
(In reply to Eric Botcazou from comment #8)
> > FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
> > compiles cleanly, which is the first time that's happened on this machine
> > under N32.  Successful builds on this machine take about 8 hours.  Fail
> > builds~3-4 hours.  It's during stage2-bubble when compiling genrecog.c
> > will bail out, claiming no more virtual memory (2GB RAM + 3GB of swap).
> 
> Can you invoke the problematic command manually and add -save-temps to it? 
> This will give you a .i file, then gzip it and attach it to the PR.

Yup, I'll attach that in a moment.  I also have the 'genrecog.s' file, if
needed.  I'll also add that it takes the command about 20-25mins to fail, which
is very abnormal.  This machine might be old, but the CPUs are 600MHz, and they
can still chew through some of the largest C/C++ source files in under a minute
in most cases.  So it seems like something in the stage2-bubble xgcc/xg++ gets
stuck in a loop and consumes additional memory with each iteration until it
hits some kind of boundary and bails.

[Bug go/83787] [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL after Go1.10beta1 update

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/83787] [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL after Go1.10beta1 update

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Jan 18 04:24:48 2018
New Revision: 256835

URL: https://gcc.gnu.org/viewcvs?rev=256835=gcc=rev
Log:
PR go/83787
compiler: pass int to makechan, call makechan64 when appropriate

The update to 1.10beta1 changed makechan to take int instead of int64,
and added a makechan64 call for large values.  Since the size is the
last argument to makechan, the old compiler which always passed a
64-bit int worked fine on 64-bit systems and little-endian 32-bit
systems, but broke on big-endian 32-bit systems.  This CL fixes the
compiler to use the appropriate types.

This fixes GCC PR 83787.

Reviewed-on: https://go-review.googlesource.com/88077

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/escape.cc
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/runtime.def
trunk/libgo/go/runtime/chan.go

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[law at redhat dot com]

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

--- Comment #16 from Jeffrey A. Law  ---
Well, my understanding of how other compilers have handled bitfields would
indicate that deferring optimization of them until later is advisable.

Essentially they pretended bitfields had word precision though most of the
early optimization passes, then lowered things to their actual size later.

I'm not entirely sure how to interpret Richi's c#7.  He could be saying that
optimize_bit_field is premature optimization and if so, deferring it until a
suitable point in gimple would be a good thing.

Or he could be saying that he doesn't think that's the real issue, just a red
herring.  Though your experiments tend to indicate that it is a real issue
here.

ISTM that either we defer bitfield optimization (which may have fallout) or we
try to teach FRE to recognize that the COMPONENT_REF and the BIT_FIELD_REF are
the same.

I'd say experiment with the former and see how bad the fallout looks.

I wonder if this BZ argues that we ought to have a canonical form when a
COMPONENT_REF and BIT_FIELD_REF express the same thing -- and if so, which
ought to be the canonical form?

[Bug testsuite/83883] FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #9 from Jeffrey A. Law  ---
Between David changing the ABI and tightening the expected output of the test I
think we can declare this as fixed.

[Bug testsuite/83883] FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times)

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Thu Jan 18 04:05:27 2018
New Revision: 256833

URL: https://gcc.gnu.org/viewcvs?rev=256833=gcc=rev
Log:
PR testsuite/83883
* gcc.dg/tree-ssa/ssa-dse-26.c: Tighten expected output.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[aldyh at gcc dot gnu.org]

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

--- Comment #15 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #14)
> I think the easiest fix is move optimize_bit_field_compare from where it is
> currently done and do it only in some late gimple pass, around
> pass_fold_builtins/store merging or so?  Dunno which exact one though.

Delaying optimize_bit_field_compare, would definitely do the trick.  For that
matter, disabling it, at least in this particular case, causes FRE to sensibly
realize the nonsense in:

   :
  _1 = tp_10(D)->chrono_type;
  _2 = (int) _1;
  if (_1 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = tp_10(D)->chrono_type;
  if (_3 != 0)
goto ; [INV]
  else
goto ; [INV]

...and clean things up.  By VRP we no longer have a problematic store, and the
warning is gone.

However, wouldn't optimizing bit field compares so late inhibit other
optimizations that come before store merging???  Though come to think of it,
optimizing bit fields so early (in the FE currently) seems mighty early.

I don't know whether Richard was frowning upon optimize_bit_field_compare
twiddling in comment 7.

Also, doing it in gimple, instead of the FE, means we have to recreate the bit
field comparison that's been gimplified.  We no longer have a comparison but:

  _3 = tp_10(D)->chrono_type;
  if (_3 != 0)

or worse:

  _1 = tp_10(D)->chrono_type;
  _2 = (int) _1;
  if (_1 == 0)

I'm certainly willing to tackle this, but I want to make sure I don't throw
cycles away.

Thoughts?

Richard, Jeff, Jakub?

[Bug c++/67935] internal compiler error: Segmentation fault

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
I cannot reproduce it w/ any gcc version in my setup.

[Bug tree-optimization/83922] New: [8 Regression] ICE: Segmentation fault (in contains_struct_check)

[asolokha at gmx dot com]

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

Bug ID: 83922
   Summary: [8 Regression] ICE: Segmentation fault (in
contains_struct_check)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180114 snapshot (r256677) ICEs when compiling the following
snippet w/ -O1 -ftree-loop-vectorize:

int j4;

void
k1 (int ak)
{
  while (ak < 1)
{
  int ur;

  for (ur = 0; ur < 2; ++ur)
{
  ++j4;
  if (j4 != 0)
j4 = 0;
}

  ++ak;
}
}

% gcc-8.0.0-alpha20180114 -O1 -ftree-loop-vectorize -c iagj4cra.c
during GIMPLE pass: vect
iagj4cra.c: In function 'k1':
iagj4cra.c:4:1: internal compiler error: Segmentation fault
 k1 (int ak)
 ^~
0xc9520f crash_signal
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/toplev.c:325
0xef9f4e contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree.h:3240
0xef9f4e vect_set_loop_condition_masked
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vect-loop-manip.c:739
0xefb553 vect_set_loop_condition(loop*, _loop_vec_info*, tree_node*,
tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vect-loop-manip.c:928
0xef1d9d vect_transform_loop(_loop_vec_info*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vect-loop.c:8891
0xf0e1be vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vectorizer.c:740

[Bug c++/83921] New: GCC rejects constexpr initialization of empty aggregate.

[eric at efcs dot ca]

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

Bug ID: 83921
   Summary: GCC rejects constexpr initialization of empty
aggregate.
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:
// g++ -std=c++14
struct Foo {};
constexpr void test() {
  Foo f; // error: uninitialized variable 'f' in 'constexpr' function
}


This error is obviously correct for non-empty types, however surely an empty
struct doesn't need an initializer?

If we agree this is a bug, it is a regression from the 6x release series, which
doesn't diagnose this code.

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
(In reply to Arnd Bergmann from comment #4)

> I'd suggest sticking with the libressl test case from comment 1, and
> ignoring the kernel version until the libressl one is fully understood. It
> seems very likely that fixing one will also address the other.

Alright, let's start with libressl which is user-space.

> Are you able to start with the test procedure from comment 1, or do you need
> something that can be scripted better, e.g. in a single C file?

abulafia:/tmp/portable [master]$ ./autogen.sh
pulling upstream openbsd source
Cloning into 'openbsd'...
...
copying manpages
configure.ac:32: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Perhaps this is sensitive to the autoconf version.  I am running 2.69 on Fedora
27.

But I think a single C file would be easier.  Everyone's running a different
(probably Linux) OS variant around here.

Thanks.

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jan 18 01:04:36 2018
New Revision: 256830

URL: https://gcc.gnu.org/viewcvs?rev=256830=gcc=rev
Log:
2018-01-17  Harald Anlauf  

Back from mainline
PR fortran/83874
* decl.c (add_init_expr_to_sym): Do not dereference NULL pointer.

2018-01-17  Harald Anlauf  

Back from mainline
PR fortran/83874
* gfortran.dg/pr83874.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr83874.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jan 18 00:30:42 2018
New Revision: 256829

URL: https://gcc.gnu.org/viewcvs?rev=256829=gcc=rev
Log:
2018-01-17  Harald Anlauf  

Backport from mainline
PR fortran/83874
* decl.c (add_init_expr_to_sym): Do not dereference NULL pointer.

2018-01-17  Harald Anlauf  

Backport from mainline
PR fortran/83874
* gfortran.dg/pr83874.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83874.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 17 23:50:02 2018
New Revision: 256824

URL: https://gcc.gnu.org/viewcvs?rev=256824=gcc=rev
Log:
2018-01-17  Harald Anlauf  

PR fortran/83874
* decl.c (add_init_expr_to_sym): Do not dereference NULL pointer.


2018-01-17  Harald Anlauf  

PR fortran/83874
* gfortran.dg/pr83874.f90: New test.

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

[Bug c++/83824] [6/7 Regression] ICE on invalid C++ code with alignas: in chainon, at tree.c:3037

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE on   |[6/7 Regression] ICE on
   |invalid C++ code with   |invalid C++ code with
   |alignas: in chainon, at |alignas: in chainon, at
   |tree.c:3037 |tree.c:3037

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/83824] [6/7/8 Regression] ICE on invalid C++ code with alignas: in chainon, at tree.c:3037

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 17 23:42:36 2018
New Revision: 256823

URL: https://gcc.gnu.org/viewcvs?rev=256823=gcc=rev
Log:
PR c++/83824
* parser.c (attr_chainon): New function.
(cp_parser_label_for_labeled_statement, cp_parser_decl_specifier_seq,
cp_parser_namespace_definition, cp_parser_init_declarator,
cp_parser_type_specifier_seq, cp_parser_parameter_declaration,
cp_parser_gnu_attributes_opt): Use it.
(cp_parser_member_declaration, cp_parser_objc_class_ivars,
cp_parser_objc_struct_declaration): Likewise.  Don't reset
prefix_attributes if attributes is error_mark_node.

* g++.dg/cpp0x/pr83824.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83824.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[pageexec at gmail dot com]

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

--- Comment #4 from PaX Team  ---
any update on this? it seems that the window for fixing 5.x was missed but
perhaps it's still not too late for the others, especially if they get updated
for spectre anyway...

[Bug target/83920] [nvptx] bad predicate reset

[cesar at gcc dot gnu.org]

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

--- Comment #1 from cesar at gcc dot gnu.org ---
Created attachment 43165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43165=edit
assembly code

[Bug target/83920] New: [nvptx] bad predicate reset

[cesar at gcc dot gnu.org]

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

Bug ID: 83920
   Summary: [nvptx] bad predicate reset
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43164=edit
gemm test case

Here  Tom posted a
patch to workaround a PTX JIT bug. However, workaround may clobber a live
predicate register. Consider the offloaded code for the attached gemm.f90
(built using trunk with -fopenacc -O3, but the underlying problem is present in
og7 and impacts da-1.c). 

The nvptx compiler generates:

$L35:
selp.u32%r348, 1, 0, %r191;
shfl.idx.b32%r348, %r348, 0, 31;
setp.ne.u32 %r191, %r348, 0;
@%r191  bra.uni $L2;
@%r341  bra $L34;
mov.u32 %r155, %r61;
shl.b64 %r158, %r43, 5;
cvt.s64.s32 %r192, %r155;
add.u64 %r161, %r192, 1;
add.u32 %r193, %r53, -1;
cvt.u64.u32 %r166, %r193;
add.u64 %r194, %r41, 2;
add.u64 %r195, %r194, %r166;
mad.lo.u64  %r156, %r43, %r161, %r195;
shl.b64 %r169, %r39, 5;
mad.lo.u64  %r167, %r161, %r39, %r37;
setp.eq.f32 %r266, %r49, 0f;
setp.le.s32 %r267, %r53, 0;
add.u32 %r270, %r55, -1;
mov.f32 %r271, 0f;
setp.eq.f32 %r272, %r49, 0f3f80;
$L34:
$L11:
setp.eq.u32 %r266, 1, 0;
@%r341  bra $L33;
$L33:
selp.u32%r347, 1, 0, %r266;
shfl.idx.b32%r347, %r347, 0, 31;
setp.ne.u32 %r266, %r347, 0;
@!%r266 bra.uni $L22;
bra $L3;
$L12:

Note how %r266 is defined in block $L35, but then it gets clobbered in block
$L33. 

This corresponds to the case where beta == 0 in the gemm.f90. I think there
might be other PTX JIT bugs lurking here, because the test program still works
as intended.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #12 from acsawdey at gcc dot gnu.org ---
Another data point: go1 built with AT10.0 on willow2 does not fail on genoa,
whereas go1 built with AT 10.0 on genoa does fail. 

Going to see if I can nail down which .o file is the carrier for failing
tomorrow. 

Also with the change previously noted in ira-costs.c why do I see a difference
already in the fixup_cfg4 dump which should be way before ira?

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #11 from acsawdey at gcc dot gnu.org ---
It appears that -O1 -fexpensive-optimizations is the minimal optimization to
trigger this fail. And of what -fexpensive-optimizations turns on, this piece
in ira-costs.s (find_costs_and_classes) appears to cause the fail:

  /* Normally we scan the insns once and determine the best class to
 use for each allocno.  However, if -fexpensive-optimizations are
 on, we do so twice, the second time using the tentative best
 classes to guide the selection.  */
  for (pass = start; pass <= flag_expensive_optimizations; pass++)
{

If I replace flag_expensive_optimizations with false here, then -O1
-fexpensive-optimizations does not fail the compile command I posted earlier.
However -O2 does still fail.

[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/83875] [feature request] target_clones compatible SIMD capability/length check

[kretz at kde dot org]

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

--- Comment #7 from Matthias Kretz  ---
Hmm,

what should the following print?

constexpr int native_simd_width = __builtin_target_supports("avx512f") ? 64 :
__builtin_target_supports("avx") ? 32 : __builtin_target_supports("sse") ? 16 :
__builtin_target_supports("mmx") ? 8 : 0;

constexpr int native_simd_width_f() {
return __builtin_target_supports("avx512f") ? 64 :
__builtin_target_supports("avx") ? 32 : __builtin_target_supports("sse") ? 16 :
__builtin_target_supports("mmx") ? 8 : 0;
}

[[gnu::target_clones("default,avx,avx512f")]]
void f() {
std::cout << native_simd_width << ' ' << native_simd_width_f();
}

[Bug fortran/83864] ICE in gfc_apply_init, at fortran/expr.c:4271

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
Regtests on i686-pc-linux-gnu.

Obvious patch submitted:

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01607.html

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
> compiles cleanly, which is the first time that's happened on this machine
> under N32.  Successful builds on this machine take about 8 hours.  Fail
> builds~3-4 hours.  It's during stage2-bubble when compiling genrecog.c
> will bail out, claiming no more virtual memory (2GB RAM + 3GB of swap).

Can you invoke the problematic command manually and add -save-temps to it? 
This will give you a .i file, then gzip it and attach it to the PR.

[Bug c++/78344] ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1347)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #4 from Paolo Carlini  ---
Fixed for 8.

[Bug c++/78344] ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1347)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jan 17 21:29:59 2018
New Revision: 256821

URL: https://gcc.gnu.org/viewcvs?rev=256821=gcc=rev
Log:
/cp
2018-01-17  Paolo Carlini  

PR c++/78344
* decl.c (grokdeclarator): Do not append the error_mark_node
due to an erroneous optional attribute-specifier-seq.

/testsuite
2018-01-17  Paolo Carlini  

PR c++/78344
* g++.dg/cpp0x/alignas13.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alignas13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Patch submitted:

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01600.html

[Bug c++/83897] [8 Regression] Useless __builtin_unreachable () emitted by the C++ FE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug c++/83897] [8 Regression] Useless __builtin_unreachable () emitted by the C++ FE

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 17 21:08:36 2018
New Revision: 256819

URL: https://gcc.gnu.org/viewcvs?rev=256819=gcc=rev
Log:
PR c++/83897
* cp-gimplify.c (cp_maybe_instrument_return): Handle
CLEANUP_POINT_EXPR.

* g++.dg/cpp0x/pr83897.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83897.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Regtested without new failures on i686-pc-linux-gnu.

Will submit patch with testcase.

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Wed Jan 17 20:40:46 2018
New Revision: 256818

URL: https://gcc.gnu.org/viewcvs?rev=256818=gcc=rev
Log:

PR ipa/83051
* ipa-inline.c (flatten_function): Do not overwrite final inlining
failure.
* gcc.c-torture/compile/pr83051-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr83051-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81054] [7 Regression] ICE with volatile variable in constexpr function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |volatile variable in|volatile variable in
   |constexpr function  |constexpr function

--- Comment #6 from Paolo Carlini  ---
Fixed for 8.1.0.

[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jan 17 20:29:25 2018
New Revision: 256817

URL: https://gcc.gnu.org/viewcvs?rev=256817=gcc=rev
Log:
/cp
2018-01-17  Paolo Carlini  

PR c++/81054
* constexpr.c (ensure_literal_type_for_constexpr_object): Return
error_mark_node when we give an error.
* decl.c (cp_finish_decl): Use the latter.

/testsuite
2018-01-17  Paolo Carlini  

PR c++/81054
* g++.dg/cpp0x/constexpr-ice19.C: New.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jan 17 20:28:47 2018
New Revision: 256816

URL: https://gcc.gnu.org/viewcvs?rev=256816=gcc=rev
Log:
/cp
2018-01-17  Paolo Carlini  

PR c++/81054
* constexpr.c (ensure_literal_type_for_constexpr_object): Return
error_mark_node when we give an error.
* decl.c (cp_finish_decl): Use the latter.

/testsuite
2018-01-17  Paolo Carlini  

PR c++/81054
* g++.dg/cpp0x/constexpr-ice19.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
The following obvious patch fixes the ICE:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 256671)
+++ gcc/fortran/decl.c  (working copy)
@@ -1718,7 +1718,7 @@
}
  else if (init->expr_type == EXPR_ARRAY)
{
- if (init->ts.u.cl)
+ if (init->ts.u.cl && init->ts.u.cl->length)
{
  const gfc_expr *length = init->ts.u.cl->length;
  if (length->expr_type != EXPR_CONSTANT)

Needs regtesting, though.

[Bug rtl-optimization/56069] [6/7/8 Regression] RA pessimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0

--- Comment #18 from Jeffrey A. Law  ---
Same reasoning in c#16/c#17 applies now, sadly.

[Bug middle-end/61037] array-bounds false positive

[s...@li-snyder.org]

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

scott snyder  changed:

   What|Removed |Added

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

--- Comment #1 from scott snyder  ---
I don't reproduce this any more with either gcc 7 or 8.

[Bug c++/83919] New: [8 regression] spurious -Wignored-qualifiers warning

[s...@li-snyder.org]

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

Bug ID: 83919
   Summary: [8 regression] spurious -Wignored-qualifiers warning
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

With gcc version 
gcc version 8.0.1 20180115 (experimental) (GCC) 

compiling this source with -Wextra -std=c++17 gets a warning:

-- x.cc -
enum class Conf;
struct foo
{
  foo (const Conf& conf) : x{conf} {}
  const Conf x;
};
--

$ ~/gcc/build/gcc/cc1plus -quiet x.cc -Wextra  -std=c++17 
x.cc: In constructor ‘foo::foo(const Conf&)’:
x.cc:4:34: warning: type qualifiers ignored on cast result type
[-Wignored-qualifiers]
   foo (const Conf& conf) : x{conf} {}
  ^

I don't see any obvious reason why this should give a warning.

The warning goes away if one uses x(conf) rather than x{conf} in the
initialization.  I also do not see this warning with gcc 7.2.1.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||law at redhat dot com

--- Comment #14 from Jeffrey A. Law  ---
I wonder if this could be addressed with a more reasonable address computation
reassociation.

  _14 = index.6_13 * 8; <- here
  _16 = x_15(D) + _14;
  _17 = *_16;
  _20 = _14 + 8;
  _21 = x_15(D) + _20;
  _22 = *_21;
  _23 = _17 + _22;
  _26 = _14 + 16;
  _27 = x_15(D) + _26;

ISTM that we associating as (x + (y + c)) which seems like a mistake in this
case.

If we associated as (x + y) + c, then the (x + y) would become a common
subexpression eliminating a bunch of unnecessary address computations.

Of course, I'm sure there are cases where (x + (y + c)) is better.  Though ISTM
that generally (x + y) + c ought to be better for the addressing modes
available on most targets.

Anyway, something to think about.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
I think the easiest fix is move optimize_bit_field_compare from where it is
currently done and do it only in some late gimple pass, around
pass_fold_builtins/store merging or so?  Dunno which exact one though.

[Bug sanitizer/82825] [8 regression] Many libsanitizer tests FAIL: dyld: Symbol not found: ___lsan_default_options

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-01/msg01589.ht
   ||ml
 Resolution|--- |FIXED

--- Comment #6 from Rainer Orth  ---
Fixed for GCC 8.1.

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #4 from Arnd Bergmann  ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Arnd Bergmann from comment #0)
> 
> > If there is enough interest in addressing the slowdown, it should be
> > possible to create a version of the kernel AES implementation that can be
> > run in user space, as the current method of reproducing the results is
> > fairly tedious.
> 
> I would say that a 20% slowdown is significant enough that we should
> definitely look into this.  A user space version would help immensely here.

The 20% number I got was from 7.1.1 to 7.2.1, but I can't reproduce the
7.1.1 performance any more, so it's possible that this was supposed to be
15.3 cycles instead of 13.5 cycles, but we'd still have a 13% regression
using the kernel implementation, and a 9% regression with libressl, which is
probably still significant.

> > The source code is apparently derived from a common source, but has evolved
> > in different ways, and the version from the kernel appears to be much faster
> > overall. 
> 
> It looks like you have various benchmarks based on different code bases. 
> This is not good for reproduceability and diagnosing the problem.  Could we
> settle on one, and ideally a (simple) user space version?  This will
> drastically increase the likelihood of finding a solution :).

I'd suggest sticking with the libressl test case from comment 1, and ignoring
the kernel version until the libressl one is fully understood. It seems very
likely that fixing one will also address the other.

Are you able to start with the test procedure from comment 1, or do you need
something that can be scripted better, e.g. in a single C file?

> Also, is this a GCC 8 regression?  It looks like in most of the benchmarks
> you post, GCC 8 performs pretty close to 4.x.  Again, settling on one
> benchmark, preferably in user space, would really help.

I had originally classified it as "7.2 regression", Richard changed it to "7/8
regression", which I think is correct: The problem is almost certainly the
"-fcode-hoisting" optimization step, and both gcc-7 and gcc-8 show about a 10%
difference between the normal "-O2" and "-O2 -fno-code-hoisting", it's just
that gcc-8 is faster overall.

[Bug c++/83918] New: [c++17, regression from 7.2] ICE on constexpr eval of datatype involving function and variadic template

[dimitri.gorokhovik at free dot fr]

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

Bug ID: 83918
   Summary: [c++17, regression from 7.2] ICE on constexpr eval of
datatype involving function and variadic template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

Hi,

The following code below compiles with GCC 7.2 (Ubuntu 7.2.0-8ubuntu3) but
provokes the crash (probably segfault) of gcc (GCC) 8.0.1 20180117
(experimental) (r256776).

I honestly tried to look for duplicates in Bugzilla, but it feels like not the
right moment ;-(




constexpr unsigned f (unsigned a, unsigned b) { return a > b ? a : b; }


template  struct mult_width;

template  struct list;

template 
struct mult_width , list <b, bs...>>
{
enum : unsigned 
{
h = f (sizeof (a), sizeof (b)),
t = mult_width , list >::width,
width = f (h, t)
};
};

template <>
struct mult_width , list <>>
{
enum : unsigned { width = 0 };
};


constexpr static const auto w { mult_width , list
<9,8,7,6,5,4,3,2,1>>::width };
static_assert (w == sizeof (int));

==

Backtrace:

Compilation started at Wed Jan 17 20:20:33

/home/user/gcc-trunk/dist/bin/g++ -std=c++17  -c bug-1.cpp -o bug-1
bug-1.cpp:17:18: internal compiler error: Segmentation fault
   width = f (h, t)
  ^
0xe76e3f crash_signal
../../srcdir/gcc/toplev.c:325
0x82209c potential_constant_expression_1
../../srcdir/gcc/cp/constexpr.c:5386
0x821f8d potential_constant_expression_1
../../srcdir/gcc/cp/constexpr.c:5323
0x8dc487 cp_parser_constant_expression
../../srcdir/gcc/cp/parser.c:9736
0x8f340e cp_parser_enumerator_definition
../../srcdir/gcc/cp/parser.c:18343
0x8f340e cp_parser_enumerator_list
../../srcdir/gcc/cp/parser.c:18283
0x8f340e cp_parser_enum_specifier
../../srcdir/gcc/cp/parser.c:18210
0x8f340e cp_parser_type_specifier
../../srcdir/gcc/cp/parser.c:16670
0x900086 cp_parser_decl_specifier_seq
../../srcdir/gcc/cp/parser.c:13559
0x8efc66 cp_parser_member_declaration
../../srcdir/gcc/cp/parser.c:23443
0x8f0d4a cp_parser_member_specification_opt
../../srcdir/gcc/cp/parser.c:23298
0x8f0d4a cp_parser_class_specifier_1
../../srcdir/gcc/cp/parser.c:22440
0x8f2d89 cp_parser_class_specifier
../../srcdir/gcc/cp/parser.c:22692
0x8f2d89 cp_parser_type_specifier
../../srcdir/gcc/cp/parser.c:16698
0x900086 cp_parser_decl_specifier_seq
../../srcdir/gcc/cp/parser.c:13559
0x904eb5 cp_parser_single_declaration
../../srcdir/gcc/cp/parser.c:27001
0x90523c cp_parser_template_declaration_after_parameters
../../srcdir/gcc/cp/parser.c:26693
0x905afc cp_parser_explicit_template_declaration
../../srcdir/gcc/cp/parser.c:26930
0x905afc cp_parser_template_declaration_after_export
../../srcdir/gcc/cp/parser.c:26949
0x90af09 cp_parser_declaration
../../srcdir/gcc/cp/parser.c:12661
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Compilation exited abnormally with code 1 at Wed Jan 17 20:20:33

[Bug sanitizer/82825] [8 regression] Many libsanitizer tests FAIL: dyld: Symbol not found: ___lsan_default_options

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Wed Jan 17 19:31:43 2018
New Revision: 256813

URL: https://gcc.gnu.org/viewcvs?rev=256813=gcc=rev
Log:
Guard against undefined weak symbols before Mac OS X 10.9 (PR sanitizer/82825)

PR sanitizer/82825
* sanitizer_common/sanitizer_internal_defs.h: Cherry-pick upstream
r??.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
I realize the warnings are happening in VRP1.  EVRP and VRP1 use different
styles of analysis and it can be the case that one is better suited for
cleaning things up than the other.

But I really should have re-familiarized myself with the BZ first :-)

We need to prove that the reference to chrono_type and the BIT_FIELD_REF are
actually the same.  That way the result of the first conditional can be used to
prove the second conditional is always false making the out of bounds reference
unreachable.

It probably needs to be done in FRE since that's our best bet to expose the
relationship between the conditionals prior to VRP1.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[aldyh at redhat dot com]

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

--- Comment #12 from Aldy Hernandez  ---
The warning occurs in vrp1, not evrp, but for the record...

evrp dump:
tcp_chrono_set (struct tcp_sock * tp)
{
  int type;
   _1;
  int _2;
  unsigned char _3;
  unsigned char _4;

   :
  _1 = tp_11(D)->chrono_type;
  _2 = (int) _1;
  if (_1 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = BIT_FIELD_REF <*tp_11(D), 8, 96>;
  _4 = _3 & 3;
  if (_4 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  tp_11(D)->chrono_stat[-1] = 1234;

   :
  return;
}

vrp1 dump with ASSERT_EXPRs:
   [local count: 1073741825]:
  _1 = tp_6(D)->chrono_type;
  tp_8 = ASSERT_EXPR ;
  if (_1 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _2 = BIT_FIELD_REF <*tp_8, 8, 96>;
  _3 = _2 & 3;
  if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435456]:
  tp_8->chrono_stat[-1] = 1234;

vrp1 dump after ASSERT_EXPRs have been removed:
   [local count: 1073741825]:
  _1 = tp_6(D)->chrono_type;
  if (_1 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _2 = BIT_FIELD_REF <*tp_6(D), 8, 96>;
  _3 = _2 & 3;
  if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435456]:
  tp_6(D)->chrono_stat[-1] = 1234;

On Wed, Jan 17, 2018 at 2:19 PM, law at redhat dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
>
> --- Comment #11 from Jeffrey A. Law  ---
> What do the dumps look like?  In particular evrp & vrp1?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug target/70682] [9 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0
Summary|[8 Regression]  |[9 Regression]
   |-fcompare-debug building|-fcompare-debug building
   |LLVM with checking=release  |LLVM with checking=release
   |compiler on ppc64le |compiler on ppc64le

--- Comment #5 from Jakub Jelinek  ---
Too late to do it for GCC8 as well.  The workaround is still in.

[Bug sanitizer/82825] [8 regression] Many libsanitizer tests FAIL: dyld: Symbol not found: ___lsan_default_options

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
As it has been acked upstream, please just apply it to gcc trunk and after a
while ping upstream.  Thanks.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
What do the dumps look like?  In particular evrp & vrp1?

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez  ---
Further reduced testcase.  Can be reproduced with -O2 -Wall.

struct tcp_sock {
  int   chrono_stat[3];
  unsigned char chrono_type:2;
};

void tcp_chrono_set(struct tcp_sock *tp)
{
  int type = 1;
  if (type > tp->chrono_type)
{
  if (tp->chrono_type > 0)
tp->chrono_stat[tp->chrono_type - 1] = 1234;
}
}

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #7 from Joshua Kinard  ---
(In reply to Eric Botcazou from comment #6)
> Please retry with the current 7 branch, it contains additional fixes.

I did about a week ago.  Tried building gcc-7-branch HEAD with both gcc-6.4.0
and gcc-5.3.0, and both failed in the same spot.  If something was added in the
last week, I can re-test.  I also tried gcc-HEAD with gcc-6.4.0 and that also
failed.

FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
compiles cleanly, which is the first time that's happened on this machine under
N32.  Successful builds on this machine take about 8 hours.  Fail
builds~3-4 hours.  It's during stage2-bubble when compiling genrecog.c will
bail out, claiming no more virtual memory (2GB RAM + 3GB of swap).  So PR59461
clearly has some kind of issue on N32, with -march=mips3 or -march=r12000
(build machine is an SGI Octane w/ an R14000 CPU, so fairly old school).

The only other working MIPS machine I have is an SGI O2 with a rare RM7000 CPU.
 But gcc on that thing takes about 2-3 days for a successful build.  However,
it is running O32 ABI under uclibc-ng, so odds are likely gcc-7.x would compile
successfully.

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Thomas Garnier from comment #5)
> I didn't try the patch yet, that could be a good starting point (still need
> change in switch optimization and segment registers). What is the
> consequence of the change in default_binds_local_p_3? Is it supposed to
> remove the need for a GOT / PLT?

It should.  If not, please provide a testcase.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #9 from Aldy Hernandez  ---
I'll take a look.

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[thgarnie at google dot com]

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

--- Comment #5 from Thomas Garnier  ---
I didn't try the patch yet, that could be a good starting point (still need
change in switch optimization and segment registers). What is the consequence
of the change in default_binds_local_p_3? Is it supposed to remove the need for
a GOT / PLT?

[Bug c++/81843] [8 Regression] ICE on valid C++11 code with variadic templates: in tsubst_pack_expansion, at cp/pt.c:11524

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/83916] [7/8 Regression] Internal compiler error on valid template code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-17
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.3
Summary|Internal compiler error on  |[7/8 Regression] Internal
   |valid template code |compiler error on valid
   ||template code
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r243871.  Doesn't ICE with -fno-new-ttp-matching.

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Kees Cook from comment #3)
> Any progress on getting this into a GCC release?

Has anyone tried my patch at all? Does it work?

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

[kees at outflux dot net]

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

Kees Cook  changed:

   What|Removed |Added

 CC||kees at outflux dot net

--- Comment #3 from Kees Cook  ---
Any progress on getting this into a GCC release?

[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug debug/83917] New: [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[daniel.santos at pobox dot com]

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

Bug ID: 83917
   Summary: [8 Regression] with -mcall-ms2sysv-xlogues, stepping
into x86 tail-call restore stub gives bad backtrace
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com
  Target Milestone: ---
Target: x86-64-*-*

Here is an example.

0x7bc8fd8e  465 if ((status = alloc_object_attributes(
attr, ,  ))) return status;
1: x/2i $rip
=> 0x7bc8fd8e :  jmpq   0x7bcaebbc <__sse_resms64fx_16>
   0x7bc8fd93 :  nopl   0x0(%rax,%rax,1)
Wine-gdb>
__sse_resms64fx_16 () at
/home/daniel/proj/sys/gcc/git/libgcc/config/i386/resms64fx.h:39
39  mov -0x60(%rsi),%r14
1: x/2i $rip
=> 0x7bcaebbc <__sse_resms64fx_16>: mov-0x60(%rsi),%r14
   0x7bcaebc0 <__sse_resms64fx_15>: mov-0x58(%rsi),%r13
Wine-gdb> bt
#0  __sse_resms64fx_16 () at
/home/daniel/proj/sys/gcc/git/libgcc/config/i386/resms64fx.h:39
#1  0x006900750062005c in ?? ()
#2  0x006d005c0064006c in ?? ()
#3  0x003b00320033006d in ?? ()
#4  0x0077005c003a0043 in ?? ()
#5  0x003c006e0069 in ?? ()
#6  0x00034850 in ?? ()
#7  0x in ?? ()

At this point, I'm not emitting any debug information in the stubs.

[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness

[ktkachov at gcc dot gnu.org]

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

--- Comment #17 from ktkachov at gcc dot gnu.org ---
As mentioned in PR, sched1 exposes this problem.

[Bug target/49678] scan for mov fails in gcc.target/arm/pr42575.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Dup.

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

[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu.org

--- Comment #16 from ktkachov at gcc dot gnu.org ---
*** Bug 49678 has been marked as a duplicate of this bug. ***

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Resolved r256809.  Manually tested original testcase this time too.

[Bug c++/83287] [8 Regression] ice in tsubst_copy, at cp/pt.c:14884

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jan 17 18:11:49 2018
New Revision: 256809

URL: https://gcc.gnu.org/viewcvs?rev=256809=gcc=rev
Log:
[C++/83287] Another overload lookup ice

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01580.html
PR c++/83287
* init.c (build_raw_new_expr): Scan list for lookups to keep.

PR c++/83287
* g++.dg/lookup/pr83287-2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr83287-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83632] pdt_26.f03:29:0: internal compiler error: in final_scan_insn, at final.c:3063

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #4 from Andreas Schwab  ---
.

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

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

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

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #4 from Andreas Schwab  ---
*** Bug 83632 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Thanks. While I could not find why we blow up with Haswell tuning but not say
Sandybridge, the main problem is that with all those -fno-... flags we have a
few insns of the form rK = rN where rN is loop-invariant and rK is unused, so
the insns are movable anywhere, including across the loop backedge (since
pipelining is enabled). We try to fill schedule holes (caused by long-latency
integer division insns) by repeatedly pipelining them. Eventually sched_times
cut off should prevent that, but it doesn't grow as intended because
bookkeeping copies get sched_times 0, and expr merging takes the minimum of two
sched_times.

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 18:08:05 2018
New Revision: 256808

URL: https://gcc.gnu.org/viewcvs?rev=256808=gcc=rev
Log:
PR c++/81843 - ICE with variadic member template.

PR c++/72801
* pt.c (unify_pack_expansion): Don't try to deduce enclosing
template args.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/variadic171.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/81843] [8 Regression] ICE on valid C++11 code with variadic templates: in tsubst_pack_expansion, at cp/pt.c:11524

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 18:08:05 2018
New Revision: 256808

URL: https://gcc.gnu.org/viewcvs?rev=256808=gcc=rev
Log:
PR c++/81843 - ICE with variadic member template.

PR c++/72801
* pt.c (unify_pack_expansion): Don't try to deduce enclosing
template args.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/variadic171.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/82331] [7 Regression] ICE specializing template for function pointer

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 18:07:53 2018
New Revision: 256807

URL: https://gcc.gnu.org/viewcvs?rev=256807=gcc=rev
Log:
PR c++/82331 - ICE with variadic partial specialization of auto

* pt.c (unify) [TEMPLATE_PARM_INDEX]: Set processing_template_decl
around call to tsubst.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/nontype-auto13.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/82760] Incorrect code generated for aligned new

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 18:07:45 2018
New Revision: 256806

URL: https://gcc.gnu.org/viewcvs?rev=256806=gcc=rev
Log:
PR c++/82760 - memory corruption with aligned new.

* call.c (build_operator_new_call): Update *args if we add the
align_arg.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/aligned-new8.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/call.c

[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #14 from David Malcolm  ---
Should be fixed by r256804; sorry again for the breakage.

[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 17 17:51:25 2018
New Revision: 256804

URL: https://gcc.gnu.org/viewcvs?rev=256804=gcc=rev
Log:
C++: Fix crash in warn_for_memset within templates (PR c++/83814)

gcc/c-family/ChangeLog:
PR c++/83814
* c-common.c (fold_for_warn): Move to c/c-fold.c and cp/expr.c.

gcc/c/ChangeLog:
PR c++/83814
* c-fold.c (fold_for_warn): Move from c-common.c, reducing to just
the C part.

gcc/cp/ChangeLog:
PR c++/83814
* expr.c (fold_for_warn): Move from c-common.c, reducing to just
the C++ part.  If processing a template, call
fold_non_dependent_expr rather than fully folding.

gcc/testsuite/ChangeLog:
PR c++/83814
PR c++/83902
* g++.dg/wrappers/pr83814.C: New test case.
* g++.dg/wrappers/pr83902.C: New test case.


Added:
trunk/gcc/testsuite/g++.dg/wrappers/pr83814.C
trunk/gcc/testsuite/g++.dg/wrappers/pr83902.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83902] [8 Regression] ice in decompose, at wide-int.h:932

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 17 17:51:25 2018
New Revision: 256804

URL: https://gcc.gnu.org/viewcvs?rev=256804=gcc=rev
Log:
C++: Fix crash in warn_for_memset within templates (PR c++/83814)

gcc/c-family/ChangeLog:
PR c++/83814
* c-common.c (fold_for_warn): Move to c/c-fold.c and cp/expr.c.

gcc/c/ChangeLog:
PR c++/83814
* c-fold.c (fold_for_warn): Move from c-common.c, reducing to just
the C part.

gcc/cp/ChangeLog:
PR c++/83814
* expr.c (fold_for_warn): Move from c-common.c, reducing to just
the C++ part.  If processing a template, call
fold_non_dependent_expr rather than fully folding.

gcc/testsuite/ChangeLog:
PR c++/83814
PR c++/83902
* g++.dg/wrappers/pr83814.C: New test case.
* g++.dg/wrappers/pr83902.C: New test case.


Added:
trunk/gcc/testsuite/g++.dg/wrappers/pr83814.C
trunk/gcc/testsuite/g++.dg/wrappers/pr83902.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 17:44:42 2018
New Revision: 256803

URL: https://gcc.gnu.org/viewcvs?rev=256803=gcc=rev
Log:
PR c++/81067 - redundant NULL warning.

* call.c (convert_like_real): Restore null_node handling.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/72801] ICE on invalid C++ code with ill-formed class member specialization: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3521

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 17:44:35 2018
New Revision: 256802

URL: https://gcc.gnu.org/viewcvs?rev=256802=gcc=rev
Log:
PR c++/81843 - ICE with variadic member template.

PR c++/72801
* pt.c (unify_pack_expansion): Don't try to deduce enclosing
template args.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic171.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/81843] [8 Regression] ICE on valid C++11 code with variadic templates: in tsubst_pack_expansion, at cp/pt.c:11524

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Jan 17 17:44:35 2018
New Revision: 256802

URL: https://gcc.gnu.org/viewcvs?rev=256802=gcc=rev
Log:
PR c++/81843 - ICE with variadic member template.

PR c++/72801
* pt.c (unify_pack_expansion): Don't try to deduce enclosing
template args.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic171.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug tree-optimization/83914] [8 Regression] ice in vect_is_simple_use with -O3

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Started with r256630 (so definitely mine)

[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction

[glisse at gcc dot gnu.org]

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

--- Comment #18 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #17)
> Created attachment 43162 [details]
> gcc8-pr61240.patch
> 
> The C FE doesn't do this optimization anymore, but c_fully_fold does because
> the generic folding code folds it.  This should fix that.  Can't reproduce
> warning with C++.

I had no idea that convert and view_convert would not be equivalent here, it is
great that the fix is so simple, thanks.
(Maybe some day pointer_plus will take a signed argument and this will become
unnecessary...)

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-17
 Ever confirmed|0   |1

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez  ---
(In reply to Arnd Bergmann from comment #0)

> If there is enough interest in addressing the slowdown, it should be
> possible to create a version of the kernel AES implementation that can be
> run in user space, as the current method of reproducing the results is
> fairly tedious.

I would say that a 20% slowdown is significant enough that we should definitely
look into this.  A user space version would help immensely here.

> The source code is apparently derived from a common source, but has evolved
> in different ways, and the version from the kernel appears to be much faster
> overall. 

It looks like you have various benchmarks based on different code bases.  This
is not good for reproduceability and diagnosing the problem.  Could we settle
on one, and ideally a (simple) user space version?  This will drastically
increase the likelihood of finding a solution :).

Also, is this a GCC 8 regression?  It looks like in most of the benchmarks you
post, GCC 8 performs pretty close to 4.x.  Again, settling on one benchmark,
preferably in user space, would really help.

Thanks.

[Bug tree-optimization/83914] [8 Regression] ice in vect_is_simple_use with -O3

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-17
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Very likely mine.

[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
Created attachment 43163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43163=edit
gzipped C source code

The original code now seems to have broken between date 20180112 and
today, 20180117.

$ ~/gcc/results/bin/gcc -c -w -O2 bug366.c
during IPA pass: inline
che_heuristics.c:534: internal compiler error: in estimate_edge_growth, at
ipa-inline.h:85
0x1786d40 estimate_edge_growth
../../trunk/gcc/ipa-inline.h:84
0x178ac8f want_inline_small_function_p
../../trunk/gcc/ipa-inline.c:747
0x178b542 update_caller_keys
../../trunk/gcc/ipa-inline.c:1320
0x178cece inline_small_functions
../../trunk/gcc/ipa-inline.c:2022

Reduced code seems fine, however.

[Bug tree-optimization/83914] [8 Regression] ice in vect_is_simple_use with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Slightly cleaned up testcase:
struct { int *a[8]; } *b;
int c, *d;
void
foo ()
{
  int f;
  for (; f; b = d, f--)
{
  d = b + 1;
  for (c = 8; c; c--)
b->a[c] = d;
}
}

Need to build a few revisions in bisect seed before being able to bisect this,
but it is certainly newer than r256599.

[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to Tom de Vries from comment #1)
> Tightening the arm_arch_v6_ok test like this would fix the failure:
> ...
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index b57f545..75ca0a3 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2848,6 +2848,11 @@ foreach { armfunc armflag armdef } { v4 "-march=armv4
> -marm" __ARM_ARCH_4__
> #if !defined (DEF)
> #error !DEF
> #endif
> +   int
> +   f (void)
> +   {
> +   return 0;
> +   }
> } "FLAG" ]
> }
>  
> ...

Hi Tom,

Coming back to this, I think this is a good idea to do independently of the
builtin-bswap-1.c comments I made in comment #5.
I'm preparing a patch to refactor the builtin-bswap* tests to make them more
robust, but if you posted this patch to gcc-patches I'd approve it.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #12 from Andrew Jenner  ---
I have been reading gcc-patches and keeping a list of the rs6000 changes that I
will need to port. I will go through the svn log for rs6000 as well to make
sure I haven't missed anything. Thanks!

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
Even rs6000 changes related to IEEE long double support are potentially 
relevant to powerpcspe (not anything related to binary128 in VSX, 
obviously, but more generic IEEE long double changes).  I suspect the 
support for IEEE long double for 32-bit is pretty bit-rotten (old ABI 
passing by reference, I think), but logically it's just as meaningful for 
this port as for rs6000 (and powerpcspe should stay compatible with the 
soft-float ABI in the rs6000 port).

Shared between the ports (so you don't need to do any cleanup there at 
present for this issue): libgcc code, documentation, 
testsuite/gcc.target/powerpc.

As powerpcspe is neither a primary nor secondary target, you're free to 
apply non-regression-fix changes as you wish, but it's up to you to have 
the port in a stable state at the time of branching as any instability of 
such a port won't be relevant to choosing when to branch for a release.

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 17 16:56:56 2018
New Revision: 256801

URL: https://gcc.gnu.org/viewcvs?rev=256801=gcc=rev
Log:
lto, testsuite: Fix ICE in -Wodr (PR lto/83121)

PR lto/83121 reports an ICE deep inside the linemap code when -Wodr
reports on a type mismatch.

The root cause is that the warning can access the DECL_SOURCE_LOCATION
of a streamed-in decl before the lto_location_cache has been applied.

lto_location_cache::input_location stores RESERVED_LOCATION_COUNT (==2)
as a poison value until the cache is applied:
250   /* Keep value RESERVED_LOCATION_COUNT in *loc as linemap lookups will
251  ICE on it.  */

The fix is relatively simple: apply the cache before reading the
DECL_SOURCE_LOCATION.

Triggering the ICE was fiddly: it seems to be affected by many things,
including the order of files, and (I think) by filenames.  My theory is
that it's affected by the ordering of the tree nodes in the LTO stream:
for the ICE to occur, the types in question need to be compared before
some other operation flushes the lto_location_cache.  This ordering
is affected by the hash-based ordering in DFS in lto-streamer-out.c, which
might explain why r255066 seemed to trigger the bug; the only relevant
change to LTO there seemed to be:
  * lto-streamer-out.c (hash_tree): Hash TYPE_EMPTY_P and DECL_PADDING_P.
If so, then the bug was presumably already present, but hidden.

The patch also adds regression test coverage for the ICE, which is more
involved - as far as I can tell, we don't have an existing way to verify
diagnostics emitted during link-time optimization.

Hence the patch adds some machinery to lib/lto.exp to support two new
directives: dg-lto-warning and dg-lto-message, corresponding to
dg-warning and dg-message respectively, where the diagnostics are
expected to be emitted at link-time.

The test case includes examples of LTO warnings and notes in both the
primary and secondary source files

Doing so required reusing the logic from DejaGnu for handling diagnostics.
Unfortunately the pertinent code is a 50 line loop within a ~200 line Tcl
function in dg.exp (dg-test), so I had to copy it from DejaGnu, making
various changes as necessary (see lto_handle_diagnostics_for_file in the
patch; for example the LTO version supports multiple source files,
identifying which source file emitted a diagnostic).

For non-LTO diagnostics we currently ignore surplus "note" diagnostics.
This patch updates lto_prune_warns to follow this behavior (since
otherwise we'd need numerous dg-lto-message directives for the motivating
test case).

The patch adds these PASS results to g++.sum:

PASS: g++.dg/lto/pr83121 cp_lto_pr83121_0.o assemble, -O0 -flto
PASS: g++.dg/lto/pr83121 cp_lto_pr83121_1.o assemble, -O0 -flto
PASS: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_0.C line 6)
PASS: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_0.C line 8)
PASS: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_1.C line 2)
PASS: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_1.C line 3)
PASS: g++.dg/lto/pr83121 cp_lto_pr83121_0.o-cp_lto_pr83121_1.o link, -O0 -flto

The output for dg-lto-message above refers to "warnings", rather than
"messages" but that's the same as for the non-LTO case, where dg-message
also refers to "warnings".

gcc/ChangeLog:
PR lto/83121
* ipa-devirt.c (add_type_duplicate): When comparing memory layout,
call the lto_location_cache before reading the
DECL_SOURCE_LOCATION of the types.

gcc/testsuite/ChangeLog:
PR lto/83121
* g++.dg/lto/pr83121_0.C: New test case.
* g++.dg/lto/pr83121_1.C: New test case.
* lib/lto.exp (lto_handle_diagnostics_for_file): New procedure,
adapted from DejaGnu's dg-test.
(lto_handle_diagnostics): New procedure.
(lto_prune_warns): Ignore informational notes.
(lto-link-and-maybe-run): Add "messages_by_file" param.
Call lto_handle_diagnostics.  Avoid issuing "unresolved" for
"execute" when "link" fails if "execute" was not specified.
(lto-can-handle-directive): New procedure.
(lto-get-options-main): Call lto-can-handle-directive.  Add a
dg-messages local, using it to set the caller's
dg-messages-by-file for the given source file.
(lto-get-options): Likewise.
(lto-execute): Add dg-messages-by-file local, and pass it to
lto-link-and-maybe-run.


Added:
trunk/gcc/testsuite/g++.dg/lto/pr83121_0.C
trunk/gcc/testsuite/g++.dg/lto/pr83121_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/lto.exp

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed by r256801.

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #3 from Wilco  ---
Fixed

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
That would be appreciated.  Besides killing the non-SPE relevant stuff in
powerpcspe, I think a review of the rs6000 changes from the last year that
might be relevant to powerpcspe is desirable too.  While changes that were done
for all backends usually were done for powerpcspe too, without much testing
though, most of the rs6000 fixes weren't, and while lots of that has been
related to ISAs powerpcspe doesn't have, some of it certainly applies even to
this port.

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #9 from Wilco  ---
Fixed by r256800.

[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0
Summary|[6/7/8 Regression] glib2|[6/7/8/9 Regression] glib2
   |warning pragmas stopped |warning pragmas stopped
   |working |working

--- Comment #21 from Jakub Jelinek  ---
Same arguments that deferred this to gcc-8 apply now to defer it to gcc-9.
David, do you think you could handle this for GCC9?

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #9 from Andrew Jenner  ---
Sorry for the lack of comment from me - I only just saw this bug (I was not
receiving email from bugzilla but hopefully I have fixed this now).

I am part-way through the cleanup. I will commit what I have so far before the
end of January if it is not finished - there may be more to come after that.