[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[asolokha at gmx dot com]

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

--- Comment #11 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #10)
> This PR apparently can be closed now?

Sorry, didn't realize it's pending for backport to the 7 branch.

[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
This PR apparently can be closed now?

[Bug tree-optimization/84873] New: [8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[asolokha at gmx dot com]

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

Bug ID: 84873
   Summary: [8 Regression] ICE: verify_ssa failed (error:
definition in block 3 does not dominate use in block
4)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -frounding-math:

int
i1 (int w3, int n9)
{
  return w3 >> ((long int)(1 + 0.1) + -!n9);
}

% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20180311 -frounding-math -c tdofpqt6.c
tdofpqt6.c: In function 'i1':
tdofpqt6.c:5:1: error: definition in block 3 does not dominate use in block 4
 }
 ^
for SSA_NAME: _2 in statement:
iftmp.0_7 = (unsigned int) _2;
during GIMPLE pass: ssa
tdofpqt6.c:5:1: internal compiler error: verify_ssa failed
0xeb076a verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa.c:1188
0xbc31cd execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/passes.c:2001
0xbc3fee execute_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/passes.c:2048

[Bug bootstrap/84800] ICE building gcc in isl_factorization.c with xgcc on SPARC Solaris with 8-20180304 snapshot

[andrewm.roberts at sky dot com]

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

--- Comment #2 from Andrew Roberts  ---
Rebuilt with 8-20180311 snapshot, and it now builds successfully:

/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8-20180311/libexec/gcc/sparc-sun-solaris2.10/8.0.1/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ../gcc-8-20180311/configure --prefix=/usr/local/gcc-8-20180311
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/usr/ccs/bin/as
--without-gnu-as --build=sparc-sun-solaris2.10 --target=sparc-sun-solaris2.10
--enable-languages=c,c++,fortran --enable-shared --enable-libssp --enable-nls
--enable-threads=posix --with-included-gettext --with-libiconv-prefix=/opt/csw
--with-system-zlib=/opt/csw --with-isl
Thread model: posix
gcc version 8.0.1 20180311 (experimental) (GCC)

[Bug rtl-optimization/84872] New: [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536

[asolokha at gmx dot com]

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

Bug ID: 84872
   Summary: [8 Regression] ICE in create_preheader, at
cfgloopmanip.c:1536
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -O1 -floop-parallelize-all -freorder-blocks-and-partition
-fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-dce:

void
s6 (int nx)
{
  int z8[2];
  int uw, vs = 0;

  for (uw = 0; uw < 2; ++uw)
z8[uw] = 0;
  for (uw = 0; uw < 2; ++uw)
z8[uw] = 0;

  while (vs < 1)
while (nx < 1)
  ++nx;
}

% gcc-8.0.0-alpha20180311 -O1 -floop-parallelize-all
-freorder-blocks-and-partition -fschedule-insns2 -fselective-scheduling2
-fsel-sched-pipelining -fno-tree-dce -c cix8q525.c
during RTL pass: sched2
cix8q525.c: In function 's6':
cix8q525.c:15:1: internal compiler error: in create_preheader, at
cfgloopmanip.c:1536
 }
 ^
0x5cfe79 create_preheader(loop*, int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/cfgloopmanip.c:1535
0x89aa57 create_preheaders(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/cfgloopmanip.c:1552
0xb156b9 apply_loop_flags
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/loop-init.c:64
0xb160ec loop_optimizer_init(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/loop-init.c:123
0xc5714d sel_init_pipelining()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched-ir.c:6093
0xc57582 sel_find_rgns()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched-ir.c:6240
0xc4ca74 find_rgns
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:1077
0xc4ca74 sched_rgn_init(bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3250
0xc6e181 sel_global_init
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7661
0xc6e181 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7715
0xc4de55 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3729
0xc4de55 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3873

[Bug c++/84820] [6/7/8 Regression] Bogus pointer-to-member accepted within template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Mar 15 04:34:45 2018
New Revision: 258549

URL: https://gcc.gnu.org/viewcvs?rev=258549=gcc=rev
Log:
PR c++/84820 - no error for invalid qualified-id.

* parser.c (cp_parser_make_indirect_declarator): Don't wrap
cp_error_declarator.

Added:
trunk/gcc/testsuite/g++.dg/parse/qualified5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/parse/error21.C

[Bug c++/84820] [6/7/8 Regression] Bogus pointer-to-member accepted within template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84801] [8 Regression] ICE: Segmentation fault instead of "error: parameter packs not expanded with '...'"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/84801] [8 Regression] ICE: Segmentation fault instead of "error: parameter packs not expanded with '...'"

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Mar 15 03:49:07 2018
New Revision: 258548

URL: https://gcc.gnu.org/viewcvs?rev=258548=gcc=rev
Log:
PR c++/84801 - ICE with unexpanded pack in lambda.

We avoid complaining about unexpanded packs when inside a lambda,
since the lambda as a whole could be part of a pack expansion.
But that can only be true if the lambda is in a template context.

* pt.c (check_for_bare_parameter_packs): Don't return early for a
lambda in non-template context.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/84801] [8 Regression] ICE: Segmentation fault instead of "error: parameter packs not expanded with '...'"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #21 from Jason Merrill  ---
That looks like a good approach.

[Bug c++/81236] Crash when calling a template member function from generic lambda

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Mar 15 03:08:24 2018
New Revision: 258547

URL: https://gcc.gnu.org/viewcvs?rev=258547=gcc=rev
Log:
PR c++/81236 - auto variable and auto function

* pt.c (tsubst_baselink): Update the type of the BASELINK after
mark_used.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn48.C
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

--- Comment #11 from Bobby Lu  ---
(In reply to Tim Shen from comment #9)
> I see. Can you show the ulimit *stack* information? I believe it's -s.
> 
> Also, try -O2 so that the functions are inlined.
> 
> As for the stack overflow, it's a known issue. To workaround this, please
> set a bigger stack size.

$ ulimit -s
unlimited

-O2 resolves the issue. Thank you very much! So basically the issue can be
explained as recursive call not being optimized out. Thus stack overflows is
expected?

This explains everything actually. I was trying to control so many different
possible things and reproducing the bug. Removing random string parts would
resolve it issue sometime, which now is just due to string is shorter thus
stack needed is smaller?

[Bug target/83451] FAIL: gfortran.dg/matmul_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Author: danglin
Date: Wed Mar 14 23:55:02 2018
New Revision: 258543

URL: https://gcc.gnu.org/viewcvs?rev=258543=gcc=rev
Log:
PR target/83451
* config/pa/pa.c (pa_emit_move_sequence):  Always emit secondary reload
insn for floating-point loads and stores.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/pa/pa.c

[Bug target/83451] FAIL: gfortran.dg/matmul_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
Author: danglin
Date: Wed Mar 14 23:51:06 2018
New Revision: 258542

URL: https://gcc.gnu.org/viewcvs?rev=258542=gcc=rev
Log:
PR target/83451
* config/pa/pa.c (pa_emit_move_sequence):  Always emit secondary reload
insn for floating-point loads and stores.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/pa/pa.c

[Bug target/83451] FAIL: gfortran.dg/matmul_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed on trunk.

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Are you sure it's an infinite loop? It looks like a null pointer dereference:

0x00403f64 in std::_Any_data::_M_access (this=0x0)

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[timshen at gcc dot gnu.org]

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

--- Comment #9 from Tim Shen  ---
I see. Can you show the ulimit *stack* information? I believe it's -s.

Also, try -O2 so that the functions are inlined.

As for the stack overflow, it's a known issue. To workaround this, please set a
bigger stack size.

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

Bobby Lu  changed:

   What|Removed |Added

  Attachment #43661|0   |1
is obsolete||

--- Comment #8 from Bobby Lu  ---
Created attachment 43662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43662=edit
longer GDB stack trace

longer GDB stack trace. The rest is the same just overflows and segfault

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

--- Comment #7 from Bobby Lu  ---
Created attachment 43661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43661=edit
Gdb stack trace.

$ ulimit
unlimited

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[timshen at gcc dot gnu.org]

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

--- Comment #6 from Tim Shen  ---
Will you able to provide a stack trace and/or ulimit information?

[Bug target/83451] FAIL: gfortran.dg/matmul_10.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Wed Mar 14 23:31:57 2018
New Revision: 258541

URL: https://gcc.gnu.org/viewcvs?rev=258541=gcc=rev
Log:
PR target/83451
* config/pa/pa.c (pa_emit_move_sequence):  Always emit secondary reload
insn for floating-point loads and stores.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #5 from Tim Shen  ---
Sorry I don't have a crayxc. On my x86_64 linux machine I can't reproduce the
crash. I used:

g++ (Debian 7.3.0-5) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libstdc++/78420] [6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely  ---
Author: redi
Date: Wed Mar 14 23:02:01 2018
New Revision: 258540

URL: https://gcc.gnu.org/viewcvs?rev=258540=gcc=rev
Log:
PR libstdc++/78420 Make std::less etc. yield total order for pointers

In order for std::less etc. to meet the total order requirements of
[comparisons] p2 we need to cast unrelated pointers to uintptr_t before
comparing them. Those casts aren't allowed in constant expressions, so
only cast when __builtin_constant_p says the result of the comparison is
not a compile-time constant (because the arguments are not constants, or
the result of the comparison is unspecified). When the result is
constant just compare the pointers directly without casting.

This ensures that the function can be called in constant expressions
with suitable arguments, but still yields a total order even for
otherwise unspecified pointer comparisons.

For std::less etc. add new overloads for pointers, which use
std::less> directly. Also change the generic
overloads to detect when the comparison would call a built-in relational
operator with pointer operands, and dispatch that case to the
corresponding specialization for void pointers.

PR libstdc++/78420
* include/bits/stl_function.h (greater<_Tp*>, less<_Tp*>)
(greater_equal<_Tp*>, less_equal<_Tp>*): Add partial specializations
to ensure total order for pointers.
(greater, less, greater_equal, less_equal):
Add operator() overloads for pointer arguments and make generic
overloads dispatch to new _S_cmp functions when comparisons would
use built-in operators for pointers.
* testsuite/20_util/function_objects/comparisons_pointer.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/function_objects/comparisons_pointer.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_function.h

[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7

[carll at gcc dot gnu.org]

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

--- Comment #5 from Carl Love  ---
Author: carll
Date: Wed Mar 14 23:01:12 2018
New Revision: 258539

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

2018-03-14  Carl Love  

PR target/84422
* config/rs6000/rs6000-builtin.def: Change expansion for
VMULESW to BU_P8V_AV_2.
Change expansion for VMULEUW to BU_P8V_AV_2.
* config/rs6000/rs6000.c: Change
ALTIVEC_BUILTIN_VMULESW to P8V_BUILTIN_VMULESW.
Change ALTIVEC_BUILTIN_VMULEUW to P8V_BUILTIN_VMULEUW.
Change ALTIVEC_BUILTIN_VMULOSW to P8V_BUILTIN_VMULOSW.
Change ALTIVEC_BUILTIN_VMULOUW to P8V_BUILTIN_VMULOUW.
* config/rs6000/rs6000-c.c: Change
ALTIVEC_BUILTIN_VMULESW to P8V_BUILTIN_VMULESW.
Change ALTIVEC_BUILTIN_VMULEUW to P8V_BUILTIN_VMULEUW.
Change ALTIVEC_BUILTIN_VMULOSW to P8V_BUILTIN_VMULOSW.
Change ALTIVEC_BUILTIN_VMULOUW to P8V_BUILTIN_VMULOUW.

Modified:
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000.c

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #10 from Pat Haugen  ---
(In reply to Pat Haugen from comment #9)
> (pr83497, which I'm still digging on). Ignoring output miscompare and just
> timing the two versions built with -fno-tree-vectorize, I see that the 
> performance is similar. So possibly a powerpc vector cost issue.
> 

And then again, maybe not. Running with -fno-tree-vectorize and removing
-ffast-math (which eliminates the output miscompare), I still see the
degradation.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #6 from Zhendong Su  ---
(In reply to Martin Liška from comment #5)
> > gcc version 8.0.1 20180310 (experimental) [trunk revision 258413] (GCC)
> 
> Just a nit, this revision mentioned above is actually from GCC 7 branch.
> Isn't that the issue?

Martin, it was checked out from the main trunk @
svn://gcc.gnu.org/svn/gcc/trunk. 

I still see the ICE with rev. 258535: 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180314 (experimental) [trunk revision 258535] (GCC) 
$ 
$ gcctk -O3 -c small.c  
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc8ff8b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x1437abc smallest_int_mode_for_size(poly_int<1u, unsigned long>)
../../gcc-source-trunk/gcc/machmode.h:842
0x1437abc find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x1437abc get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x143a41c record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x143b2c2 scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x143c4b2 dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x143c4b2 rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
0x143c4b2 execute
../../gcc-source-trunk/gcc/dse.c:3672
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.
$

[Bug fortran/84870] [7/8 Regression] ICE in gfc_trans_structure_assign, at fortran/trans-expr.c:7651

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-14
  Known to work||6.4.0
   Target Milestone|--- |7.4
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0.1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
The problem is in decl.c (merge_array_spec).  There is
no check for rank+corank >= 15.  So, gfortran tries merging
2 array specs that exceed the static memory.

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

Bobby Lu  changed:

   What|Removed |Added

  Attachment #43659|0   |1
is obsolete||

--- Comment #4 from Bobby Lu  ---
Created attachment 43660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43660=edit
Correction to the previous file. That was the gcc5.4 reproduction source. Sorry

Single source file to reproduce the bug. This is the one for gcc-7.1.0. I
uploaded a wrong one. Sorry for the confusion.

compile with 

g++ -std=c++11 regex.cpp -lpthread
./a.out
Segmentation fault (core dumped)

g++ -v 
Using built-in specs.
COLLECT_GCC=/opt/gcc/7.1.0/bin/../snos/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/snos/libexec/gcc/x86_64-suse-linux/7.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../cray-gcc-7.1.0-201705230545.65f29659747b4/configure
--prefix=/opt/gcc/7.1.0/snos --disable-nls --libdir=/opt/gcc/7.1.0/snos/lib
--enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/7.1.0/snos/include/g++
--with-slibdir=/opt/gcc/7.1.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog
--disable-multilib
Thread model: posix
gcc version 7.1.0 20170502 (Cray Inc.) (GCC) 

uname -a 
Linux edison03 4.4.103-92.56-default #1 SMP Wed Dec 27 16:24:31 UTC 2017
(2fd2155) x86_64 x86_64 x86_64 GNU/Linux

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

--- Comment #3 from Bobby Lu  ---
Created attachment 43659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43659=edit
Single source file to reproduce the bug

compile with 

g++ -std=c++11 regex.cpp -lpthread
./a.out
Segmentation fault (core dumped)

g++ -v 
Using built-in specs.
COLLECT_GCC=/opt/gcc/7.1.0/bin/../snos/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/snos/libexec/gcc/x86_64-suse-linux/7.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../cray-gcc-7.1.0-201705230545.65f29659747b4/configure
--prefix=/opt/gcc/7.1.0/snos --disable-nls --libdir=/opt/gcc/7.1.0/snos/lib
--enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/7.1.0/snos/include/g++
--with-slibdir=/opt/gcc/7.1.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog
--disable-multilib
Thread model: posix
gcc version 7.1.0 20170502 (Cray Inc.) (GCC) 

uname -a 
Linux edison03 4.4.103-92.56-default #1 SMP Wed Dec 27 16:24:31 UTC 2017
(2fd2155) x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/71569] [6 regression] Crash: External definition of template member from template struct

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||fiesh at zefix dot tv

--- Comment #15 from Jason Merrill  ---
*** Bug 84197 has been marked as a duplicate of this bug. ***

[Bug c++/84197] [7/8 Regression] Segmentation fault when setting -g

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed by patch for bug 71569.

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

[Bug target/84757] [7/8 Regression] Useless MOVs and PUSHes to store results of MUL

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Sorry, the analysis took more time than I thought.

This PR can be solved only by introducing live range analysis in LRA on
**subreg level**.  IRA already has such analysis and therefore it makes such
allocation (a right allocation in this case) which LRA became to consider
questionable after committing
http://gcc.gnu.org/viewcvs/gcc?view=revision=244942.

If any spill happened for the test, LRA would have generated the same code by
GCC as before committing the patch.  So on bigger functions, LRA actually
generates the same quality code as for GCC 6.3.

I think the PR will be not fixed for GCC-8 because implementing sub-register
live range analysis in LRA is a big job and would be risky for the release.

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

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Mar 14 19:17:03 2018
New Revision: 258533

URL: https://gcc.gnu.org/viewcvs?rev=258533=gcc=rev
Log:
PR c++/83916 - ICE with template template parameters.

* pt.c (convert_template_argument): Don't substitute into type of
non-type parameter if we don't have enough arg levels.
(unify): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/template/ttp31.C
trunk/gcc/testsuite/g++.dg/template/ttp32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/84869] [7/8 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-14
 Ever confirmed|0   |1
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.0.1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed around 2016-10-13.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #4 from Serge Belyshev  ---
CC: Jim Wilson, as it is a recent change by him.

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

[Bug fortran/84868] [7/8 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-14
   Target Milestone|--- |7.4
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0.1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed around 2016-12-06.

[Bug libgomp/84871] New: libgomp examples-4/declare_target-[12].f90 fail with nvptx Titan V offloading

[cesar at gcc dot gnu.org]

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

Bug ID: 84871
   Summary: libgomp examples-4/declare_target-[12].f90 fail with
nvptx Titan V offloading
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Both libgomp.fortran/examples-4/declare_target-1.f90 and
libgomp.fortran/examples-4/declare_target-2.f90 fail when offloaded on Nvidia
Titan V (or Volta family) GPUs running Nvida driver 390.25. The failure appears
to be the result of a limited per-CUDA thread stack size of 1024b as collected
by cuCtxGetLimit (..., CU_LIMIT_STACK_SIZE).

Those tests only fail at -O1, -O2 and -Os. Furthermore, all of the tests pass
on older Nvidia GPUs, including Kepler (K80s) and Pascal (GeForce 1080).

One thing I noticed was that ptxas reports that it is spilling more registers
to the stack for the Volta GPUs than it is for Pascal GPUs. Here's the relevant
statistics for Pascal:

ptxas info: Function properties for __e_53_1_mod_MOD_fib
24 bytes stack frame, 24 bytes spill stores, 24 bytes spill loads

Here are the corresponding statistics for Volta:

ptxas info: Function properties for __e_53_1_mod_MOD_fib
40 bytes stack frame, 40 bytes spill stores, 40 bytes spill loads

Given that we can't control the PTX driver JIT, maybe we should either reduce
the recursion depth in declare_target-[12].f90 to 20 (actually fib (22) works,
but I don't a newer driver to break it again), or or just xfail those tests for
nvptx targets. 

The CUDA driver API provides cuCtxSetLimit function to adjust the stack limit,
but apparently, that only adjusts the upper bound limit.

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #14 from Martin Liška  ---
Honza can you reproduce that or can we close it?

[Bug tree-optimization/83043] [8 Regression] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P1  |P4
 CC||marxin at gcc dot gnu.org

--- Comment #11 from Martin Liška  ---
I also believe it's not P1, thus adjusting to P4.

Tom I would add:

diff --git a/libgomp/testsuite/libgomp.graphite/force-parallel-1.c
b/libgomp/testsuite/libgomp.graphite/force-parallel-1.c
index 0393356f9f2..01ac124f0a0 100644
--- a/libgomp/testsuite/libgomp.graphite/force-parallel-1.c
+++ b/libgomp/testsuite/libgomp.graphite/force-parallel-1.c
@@ -1,3 +1,5 @@
+/* { dg-options "-fno-ipa-partial-inlining" } */
+
 void abort (void);

 int x[1000];

Because IPA fn split does not play any role in the test. Then I would adjust
expected output.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
We have seen this sort of thing come up a number of times in the past.  Jeff
and I have discussed changing jump threading to either avoid introducing paths
involving invalid calls, or inserting __builtin_unreachable/__builtin_trap. 
That could not only avoid false positives but also make it possible to emit
more efficient code.

[Bug fortran/84870] New: [7/8 Regression] ICE in gfc_trans_structure_assign, at fortran/trans-expr.c:7651

[gs...@t-online.de]

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

Bug ID: 84870
   Summary: [7/8 Regression] ICE in gfc_trans_structure_assign, at
fortran/trans-expr.c:7651
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161127 and 20161204 :


$ cat z1.f90
program p
   type t
  real, allocatable :: a
   end type
   type t2
  type(t), allocatable :: b
   end type
   type(t2) :: x, y[*]
   x%b = t(1.0)
   y = x
   y%b%a = 2.0
end


$ gfortran-7-20161127 -c z1.f90 -fcoarray=lib
$
$ gfortran-8-20180311 -c z1.f90 -fcoarray=lib
z1.f90:1:0:

 program p

internal compiler error: Segmentation fault
0xb9b07f crash_signal
../../gcc/toplev.c:325
0x7822a0 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7651
0x783fdf gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7771
0x77db7c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7938
0x785872 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10094
0x76646d generate_coarray_sym_init
../../gcc/fortran/trans-decl.c:5368
0x734c7b do_traverse_symtree
../../gcc/fortran/symbol.c:4159
0x765695 generate_coarray_init
../../gcc/fortran/trans-decl.c:5417
0x7718cc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6435
0x7007c0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7007c0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74735f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/84869] New: [7/8 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

[gs...@t-online.de]

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

Bug ID: 84869
   Summary: [7/8 Regression] ICE in gfc_class_len_get, at
fortran/trans-expr.c:233
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161016 and 20161023 :


$ cat z1.f90
program p
   type t
   end type
   call s
contains
   function f()
  class(t), allocatable :: f(:)
   end
   subroutine s
  class(*), allocatable :: z(:)
  allocate (z, source=f())
   end
end


$ gfortran-7-20161016 -c z1.f90
$
$ gfortran-8-20180311 -c z1.f90
z1.f90:11:0:

   allocate (z, source=f())

internal compiler error: Segmentation fault
0xb9b07f crash_signal
../../gcc/toplev.c:325
0x774c0e gfc_class_len_get(tree_node*)
../../gcc/fortran/trans-expr.c:233
0x785417 trans_class_vptr_len_assignment
../../gcc/fortran/trans-expr.c:8194
0x785d29 trans_class_assignment
../../gcc/fortran/trans-expr.c:9849
0x785d29 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10232
0x7b95b1 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6566
0x749f67 trans_code
../../gcc/fortran/trans.c:1996
0x771449 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6497
0x7712c7 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5509
0x7712c7 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6426
0x7007c0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7007c0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74735f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/84868] [7/8 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---


Works with different names (a, c) :


$ cat z2.f90
module m
   character(:), allocatable :: a
contains
   function f(n) result(z)
  character, parameter :: c(3) = ['x', 'y', 'z']
  integer, intent(in) :: n
  character(len_trim(c(n))) :: z
  z = c(n)
   end
end
program p
   use m
   print *, f(2)
end


$ gfortran-8-20180311 z2.f90 -static-libgfortran
$ a.out
 y

[Bug fortran/84868] New: [7/8 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

[gs...@t-online.de]

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

Bug ID: 84868
   Summary: [7/8 Regression] ICE in gfc_conv_descriptor_offset, at
fortran/trans-array.c:208
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161204 and 20161211 :


$ cat z1.f90
module m
   character(:), allocatable :: c
contains
   function f(n) result(z)
  character, parameter :: c(3) = ['x', 'y', 'z']
  integer, intent(in) :: n
  character(len_trim(c(n))) :: z
  z = c(n)
   end
end
program p
   use m
   print *, f(2)
end


$ gfortran-7-20161204 -c z1.f90
$
$ gfortran-8-20180311 -c z1.f90
z1.f90:13:0:

print *, f(2)

internal compiler error: in gfc_conv_descriptor_offset, at
fortran/trans-array.c:208
0x74e222 gfc_conv_descriptor_offset
../../gcc/fortran/trans-array.c:208
0x75349c gfc_conv_descriptor_offset_get(tree_node*)
../../gcc/fortran/trans-array.c:220
0x75349c gfc_conv_array_offset(tree_node*)
../../gcc/fortran/trans-array.c:2967
0x75349c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3575
0x780ddd gfc_conv_variable
../../gcc/fortran/trans-expr.c:2737
0x77db02 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7926
0x78a98c gfc_conv_intrinsic_function_args
../../gcc/fortran/trans-intrinsic.c:223
0x79dc3d gfc_conv_intrinsic_len_trim
../../gcc/fortran/trans-intrinsic.c:6248
0x79dc3d gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9134
0x77d545 gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6784
0x77dae2 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7918
0x77fa8a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.c:4409
0x77b6f7 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:5970
0x77d59c gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6808
0x77dae2 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7918
0x7843aa gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8018
0x7a3d56 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2585
0x749ec7 trans_code
../../gcc/fortran/trans.c:2044
0x7a1807 build_dt
../../gcc/fortran/trans-io.c:2027
0x749ee7 trans_code
../../gcc/fortran/trans.c:2016

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #3 from G. Steinmetz  ---
The limit (sum of dimensions and codimensions) was recently
lifted from N=7 to N=15, but unfortunately the (N+1)-problem
remains. Adding 8 dims to testcases above, updated backtrace :


$ cat zz1.f90
program p
   real, dimension(1,2,1,2,1,2,1,2), codimension[1,2,1,2,1,2,1,*] :: z
end


$ gfortran-8-20180311 -c zz1.f90 -fcoarray=single
f951: internal compiler error: free_expr0(): Bad expr type
0x6a68ff gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1358
0x6a76fb free_expr0
../../gcc/fortran/expr.c:499
0x6a775d gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.c:520
0x678ff9 gfc_free_array_spec(gfc_array_spec*)
../../gcc/fortran/array.c:329
0x699f1e gfc_match_data_decl()
../../gcc/fortran/decl.c:5834
0x6f5bb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f92ae match_word
../../gcc/fortran/parse.c:376
0x6f92ae decode_statement
../../gcc/fortran/parse.c:376
0x6fb1d4 next_free
../../gcc/fortran/parse.c:1230
0x6fb1d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fcfec parse_spec
../../gcc/fortran/parse.c:3670
0x6fefb3 parse_progunit
../../gcc/fortran/parse.c:5667
0x700594 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x74735f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Perhaps making it unsigned short would be better, though I wonder if it just
isn't a bug that STACK_BOUNDARY is not constant, that is ABI changing thing,
doesn't __attribute__((aligned)) change based on what BIGGEST_ALIGNMENT is?

[Bug target/84521] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[sudi at gcc dot gnu.org]

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

--- Comment #25 from sudi at gcc dot gnu.org ---
Proposed patch. This obviously does not solve all the issues

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00668.html

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
I see it fixed since r257490, thus I'm closing that.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Seems the kernel testcase is actually more like:
void f (void*);

void __attribute__ ((noinline, noclone))
g (const void *p, unsigned n)
{
  unsigned char a[8];
  if (n > sizeof a - 1)
return;

  for (; n > 0; n -= *a)
  {
 *a = n > 255 ? 255 : n;

__builtin_memcpy (a + 1, p, *a);   // no warning (good)
f (a);
  }
}

void __attribute__ ((noinline, noclone))
h (const void *p, unsigned n)
{
  unsigned char a[8];
  if (n > sizeof a - 1)
return;

  for (; n > 0; n -= *a)
  {
if (n > 255)
  *a = 255;
else
  *a = n;

__builtin_memcpy (a + 1, p, *a);   // bogus -Warray-bounds
f (a);
  }
}

where the memcpy calls don't clobber *a, but there is another call that makes a
escape and could modify the value, so I'm afraid there is absolutely nothing
VRP can do here and the only fix is not to warn on statements affected by jump
threading.

What the kernel should have used (if it couldn't use get rid of the loop
altogether like it did) would be something like:
void f (void*);

void __attribute__ ((noinline, noclone))
g (const void *p, unsigned n)
{
  unsigned char a[8], t;
  if (n > sizeof a - 1)
return;

  for (; n > 0; n -= t)
  {
 t = n > 255 ? 255 : n;
 *a = t;

__builtin_memcpy (a + 1, p, t);   // no warning (good)
f (a);
  }
}

void __attribute__ ((noinline, noclone))
h (const void *p, unsigned n)
{
  unsigned char a[8], t;
  if (n > sizeof a - 1)
return;

  for (; n > 0; n -= t)
  {
if (n > 255)
  t = 255;
else
  t = n;
*a = t;

__builtin_memcpy (a + 1, p, t);   // no warning (good)
f (a);
  }
}

i.e. introduce a temporary for the size in the current iteration and use that
across the calls that might have but don't really change that.

[Bug target/8480] reload ICEs for LAPACK code on powerpc64-linux

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Wed Mar 14 17:26:38 2018
New Revision: 258529

URL: https://gcc.gnu.org/viewcvs?rev=258529=gcc=rev
Log:
Add test-case (PR ipa/84805).

2018-03-14  Martin Liska  

PR ipa/8480
* g++.dg/lto/pr84805_0.C: New test.
* g++.dg/lto/pr84805_1.C: New test.
* g++.dg/lto/pr84805_2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr84805_0.C
trunk/gcc/testsuite/g++.dg/lto/pr84805_1.C
trunk/gcc/testsuite/g++.dg/lto/pr84805_2.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/84850] [8 Regression] -Wclass-memaccess on a memcpy in a copy assignment operator with no nontrivial bases or members

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So just handle this PR now (warning less; handle copy assignment ops like copy
ctors) and deal with the rest (warning more) for stage1.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The warning is in response to the call to memcpy(d, s, 255) in h():

   [local count: 477815112]:
  a[0] = 255;
  __builtin_memcpy (, p_15(D), 255);
  _26 = a[0];

The wording seems clear:  The function is forming an offset that is out of the
bounds of the referenced object.

The range of the out-of-bounds offset is [9, 255], while the bounds of the
object are [0, 8].

If you think you have of a better/clearer way to phrase it then please propose
it.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note, even teaching VRP to look through stores and loads from memory wouldn't
help here, not even for the first function, because it uses *a as the length,
but also overwrites it (potentially or for real) with the memcpy, so the
compiler can't really know anything about *a in the second and following
iterations, except that it is unsigned char and thus [0, 255].  n can wrap
around.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That is just something gimple-ssa-warn-restrict.c mades up from the call with
255 constant size.  Figuring out from the warning wording that it complains
about a call with constant length 255 is impossible.

[Bug fortran/84867] Wrong code generated, except at -O0, with inappropriate Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Lack of warning doesn't imply the code is valid.

[Bug fortran/84867] Wrong code generated, except at -O0, with inappropriate Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]

[jiri.pitt...@jh-inst.cas.cz]

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

--- Comment #3 from jiri.pitt...@jh-inst.cas.cz ---
Created attachment 43658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43658=edit
similar buggy behavior without any compiler warning

[Bug fortran/84867] Wrong code generated, except at -O0, with inappropriate Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Last reconfirmed|2018-03-14 00:00:00 |
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Jakub Jelinek  ---
That is undefined behavior, so the warning correctly tells you your code will
not really work properly.
GCC has -funconstrained-commons option you can use to make that sort of
defined.
'-funconstrained-commons'
 This option tells the compiler that variables declared in common
 blocks (e.g.  Fortran) may later be overridden with longer trailing
 arrays.  This prevents certain optimizations that depend on knowing
 the array bounds.
Or you can use -fno-aggressive-loop-optimizations, though the hack is still UB
and it still might cause problems.

[Bug fortran/84867] Wrong code generated, except at -O0, with inappropriate Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I think it is pr69368 again!-(also related to pr44882).

The code is invalid: it will fail at run time if you compile it with
-fcheck=bounds.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Have you tried to make the variables signed instead (or HOST_WIDE_INT)?

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #43577|0   |1
is obsolete||
  Attachment #43578|0   |1
is obsolete||

--- Comment #20 from Jakub Jelinek  ---
Created attachment 43657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43657=edit
gcc8-pr79937.patch

This patch seems to fix all the testcase and passes check-c++-all.
Given that #c18 is rejected, I wonder if it wouldn't be sufficient.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #1 from David Abdurachmanov  
---
I am using bdba439399552531c0fe82da5037386715f07940 (git) or r258481 (svn) and
I hit the same issue:

../../gcc/calls.c: In function ‘poly_int64 compute_argument_block_size(int,
args_size*, tree, tree, int)’:   
../../gcc/calls.c:2201:60: error: comparison of integer expressions of
different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare]   
   if (ACCUMULATE_OUTGOING_ARGS && preferred_stack_boundary > STACK_BOUNDARY)

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-14
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
GCC 5.x is no longer supported, please try with a current release (6.4 or 7.3),
and please provide source as required by the bug reporting guidelines.

For a libstdc++ bug it doesn't need to be preprocessed source, but we still
need the source to reproduce the problem.

[Bug fortran/84867] New: Wrong code generated, except at -O0, with inappropriate Warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]

[jiri.pitt...@jh-inst.cas.cz]

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

Bug ID: 84867
   Summary: Wrong code generated, except at -O0, with
inappropriate Warning: iteration 1 invokes undefined
behavior [-Waggressive-loop-optimizations]
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiri.pitt...@jh-inst.cas.cz
  Target Milestone: ---

Created attachment 43656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43656=edit
source codes demonstrating the problem

Many old F77 codes in my research field use a 'hack' to dynamically allocate a
memory
by a malloc() called from C, while referring to the allocated memory by an
index with
respect to an array declared in a common block. When used in a way when a loop
of
constant length gets unrolled, the compiler produced Warning: iteration 1
invokes undefined behavior [-Waggressive-loop-optimizations] at any
optimization level higher than -O0 and generated wrong assembly code with a
single instruction
movsd   %xmm3, 776(%r15,%rax,8)
rather than 6 instructions from the completely unrolled loops
movsd   %xmm3, (%rbx,%rax,8)
movsd   %xmm3, 8(%rbx,%rax,8)
movsd   %xmm3, 16(%rbx,%rax,8)
movsd   %xmm6, 776(%rbx,%rax,8)
movsd   %xmm6, 784(%rbx,%rax,8)
movsd   %xmm6, 792(%rbx,%rax,8)
Interestingly, after declaring common/formal/work(2) both the problem and the
warning disappears, although
formally the dimensions of the array work() are also exceeded.
Although formally viewed this way of doing dynamic allocation is a dirty hack
exceeding declared
array dimensions (and crossing even to a different virtual memory section by a
huge array index),
it is widespread in old codes and should not be broken.
I have observed the same behavior with a wide range of gfortran versions from
4.9.3 to 7.3.0
(installed under gentoo linux).

[Bug c++/84850] [8 Regression] -Wclass-memaccess on a memcpy in a copy assignment operator with no nontrivial bases or members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I have a patch that handles both pr84851 and pr84850.  I don't view this report
as a regression any more than the other PR.  The warning does what it was
designed to do.  It was just designed to be strict in this case and overly
permissive in the other.

[Bug c++/84866] New: Incorrectly instantiating move ctor when a union's move constructor is implicitly deleted

[zhangxy at google dot com]

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

Bug ID: 84866
   Summary: Incorrectly instantiating move ctor when a union's
move constructor is implicitly deleted
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangxy at google dot com
  Target Milestone: ---

Please see https://godbolt.org/g/5VTrtz for a reduced test case.

The reasoning is: if is_move_constructor() is true, I should be able to move
construct a T (even though it might be using the copy ctor).

Note:
- The bug seems to be exist since early versions (tried 4.9).
- The bug is not relevant to the standard versions, i.e. -std=c++11 or
-std=c++17.
- The bug only occurs when a type (with trivial copy ctor and nontrivial move
ctor) is nested in a union, not when it is at top level of the union.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[andrey.y.guskov at intel dot com]

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

--- Comment #26 from Andrey Guskov  ---
Martin, Jakub, for the Base optset (-Ofast -funroll-loops -march=haswell) there
is no change, 628 keeps failing, but for O2 (-O2 -ffast-math -march=haswell) it
did start passing.

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

--- Comment #1 from Bobby Lu  ---
No compiler warning is generated

[Bug libstdc++/84865] New: Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

[shaoqin2 at illinois dot edu]

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

Bug ID: 84865
   Summary: Regular expression regex_search falls into infinite
loop causing segfault on crayxc machines
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaoqin2 at illinois dot edu
  Target Milestone: ---

Using regex_search in a multi threaded environment on crayxc super computer
will cause infinite loop and segfault. g++ information is here

Target: x86_64-suse-linux
Configured with: ../cray-gcc-5.3.0/configure 
--prefix=/opt/gcc/5.3.0/snos 
--disable-nls --libdir=/opt/gcc/5.3.0/snos/lib 
--enable-languages=c,c++,fortran 
--with-gxx-include-dir=/opt/gcc/5.3.0/snos/include/g++ 
--with-slibdir=/opt/gcc/5.3.0/snos/lib 
--with-system-zlib --enable-shared 
--enable-__cxa_atexit 
--build=x86_64-suse-linux 
--with-ppl --with-cloog
Thread model: posix
gcc version 5.3.0 20151204 (Cray Inc.) (GCC) 

uname -a
Linux edison11 4.4.103-92.56-default #1 SMP Wed Dec 27 16:24:31 UTC 2017
(2fd2155) x86_64 x86_64 x86_64 GNU/Linux


Command line to reproduce this segfault: 
(.cpp file is not attached per guideline. Feel free to ask me to post it, it's
super short and simple, I extracted minimum error reproducing code)

g++ -std=c++11 -save-temps regex.cpp -lpthread
./a.out
Segmentation fault (core dumped)

[Bug preprocessor/84864] Issues with large line numbers >= 2^31

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Note to self:
 
/home/david/coding-3/gcc-git-bugfixing/src/backup-patches/linenum_type-throughout.patch

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
[...]
> I looked at using linenum_type throughout, but doing so turned into
> a large patch[...]

I opened PR 84864 to track fixing this in a later release.

[Bug preprocessor/84864] Issues with large line numbers >= 2^31

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84852
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug preprocessor/84864] New: Issues with large line numbers >= 2^31

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84864
   Summary: Issues with large line numbers >= 2^31
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: deferred, diagnostic
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

PR 84852 describes an ICE on this source code:

$ cat test.c
#line 77
int foo (void) { return strlen(""); }

On fixing the ICE, the #line directive leads to negative line numbers, with the
diagnostic reported here:

  test.c:-812156815:25:

The 77 is truncated to unsigned 32 bits (linenum_type), from
0x1cf977871 to 0xcf977871 == 3482810481.

In some places we use linenum_type (unsigned int); in others we use int,
leading to the printing of -812156815 for the line number.

We already warn for too-large line numbers with -pedantic:

test.c:1:7: warning: line number out of range
 #line 77
   ^~

There seem to be at least two issues here:
* silent truncation of #line
* use of negative numbers for such cases

I experimented with using linenum_type throughout for the fix for PR 84852, but
it was more invasive that I'd have liked in stage 4, so filing this to track
addressing this when stage 1 opens.

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r258526.

[Bug sanitizer/84863] false-positive -Warray-bounds warning with -fsanitize-coverage=object-size

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Never use -Werror with -fsanitize=*, those really do cause new warnings because
the code intentionally is less optimized and the runtime check themselves
prevent further optimizations, so warnings that depend on optimizations can't
work properly.

[Bug c/84195] newlines in deprecated diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||deferred
   Assignee|unassigned at gcc dot gnu.org  |nickc at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #3 from David Malcolm  ---
Candidate patch here:
  https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00977.html

[Bug sanitizer/84863] New: false-positive -Warray-bounds warning with -fsanitize-coverage=object-size

[arnd at linaro dot org]

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

Bug ID: 84863
   Summary: false-positive -Warray-bounds warning with
-fsanitize-coverage=object-size
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 43655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43655=edit
linux/net/xfrm/xfrm_output.c, preprocessed, not reduced.

Among the linux kernel build warnings I see from enabling sanitizers
(CONFIG_UBSAN_SANITIZE_ALL), this is one that seems interesting and not yet
reported:

In file included from /git/arm-soc/include/linux/kernel.h:10,
 from /git/arm-soc/include/linux/list.h:9,
 from /git/arm-soc/include/linux/module.h:9,
 from /git/arm-soc/net/xfrm/xfrm_output.c:13:
/git/arm-soc/net/xfrm/xfrm_output.c: In function 'xfrm_output_resume':
/git/arm-soc/include/linux/compiler.h:251:20: error: array subscript 4 is above
array bounds of 'struct nf_hook_entries *[3]' [-Werror=array-bounds]
   __read_once_size(&(x), __u.__c, sizeof(x));  \
^~~~
/git/arm-soc/include/linux/compiler.h:257:22: note: in expansion of macro
'__READ_ONCE'
 #define READ_ONCE(x) __READ_ONCE(x, 1)
  ^~~
/git/arm-soc/include/linux/rcupdate.h:351:48: note: in expansion of macro
'READ_ONCE'
  typeof(*p) *p1 = (typeof(*p) *__force)READ_ONCE(p); \
^
/git/arm-soc/include/linux/rcupdate.h:488:2: note: in expansion of macro
'__rcu_dereference_check'
  __rcu_dereference_check((p), (c) || rcu_read_lock_held(), __rcu)
  ^~~
/git/arm-soc/include/linux/rcupdate.h:546:28: note: in expansion of macro
'rcu_dereference_check'
 #define rcu_dereference(p) rcu_dereference_check(p, 0)
^
/git/arm-soc/include/linux/netfilter.h:219:15: note: in expansion of macro
'rcu_dereference'
   hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
   ^~~

The original function looks like

static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
  struct sock *sk, struct sk_buff *skb,
  struct net_device *indev, struct net_device *outdev,
  int (*okfn)(struct net *, struct sock *, struct
sk_buff *))
{
struct nf_hook_entries *hook_head = NULL;
int ret = 1;

rcu_read_lock();
switch (pf) {
case NFPROTO_IPV4:
hook_head = rcu_dereference(net->nf.hooks_ipv4[hook]);
break;
case NFPROTO_IPV6:
hook_head = rcu_dereference(net->nf.hooks_ipv6[hook]);
break;
case NFPROTO_ARP:
#ifdef CONFIG_NETFILTER_FAMILY_ARP
hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
#endif
break;
case NFPROTO_BRIDGE:
#ifdef CONFIG_NETFILTER_FAMILY_BRIDGE
hook_head = rcu_dereference(net->nf.hooks_bridge[hook]);
#endif
break;
#if IS_ENABLED(CONFIG_DECNET)
case NFPROTO_DECNET:
hook_head = rcu_dereference(net->nf.hooks_decnet[hook]);
break;
#endif
default:
WARN_ON_ONCE(1);
break;
}

where the net->nf.hooks_* fields all have different sizes. The function is
called with constant arguments for 'pf' and 'hook', and for this caller, the
latter is out of range for the net->nf.hooks_arp[] array, but in a line that
is never reached. Reproduced with all versions that support the object-size
sanitizer (gcc-5 through 8).

With the attached preprocessed file, reproduce with

$ arm-linux-gnueabi-gcc-8.0.1 -Wall -O2 -c net/xfrm/xfrm_output.i -Werror  
-fsanitize=object-size  -fno-strict-aliasing

The warning also shows up with an x86 compiler, but that causes other problems.
I can produce a reduced version that works on x86 if needed.

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar 14 13:58:13 2018
New Revision: 258526

URL: https://gcc.gnu.org/viewcvs?rev=258526=gcc=rev
Log:
Fix ICE for missing header fix-it hints with overlarge #line directives (PR
c/84852)

PR c/84852 reports an ICE inside diagnostic_show_locus when printing
a diagnostic for a source file with a #line >= 2^31:

  #line 77
  int foo (void) { return strlen(""); }

where we're attempting to print a fix-it hint at the top of the file
and underline the "strlen" (two "line spans").

The
  #line 77
won't fix within the 32-bit linenum_type, and is truncated from
  0x1cf977871
to
   0xcf977871
i.e. 3482810481 in decimal.

Such a #line is reported by -pedantic and -pedantic-errors, but we
shouldn't ICE.

The ICE is an assertion failure within layout::calculate_line_spans,
where the line spans have not been properly sorted.

The layout_ranges are stored as int, rather than linenum_type,
giving line -812156815 for the error, and line 1 for the fix-it hint.

However, line_span uses linenum_type rather than int.

line_span::comparator compares these values as int, and hence
decides that (linenum_type)3482810481 aka (int)-812156815 is less
than line 1.

This leads to this assertion failing in layout::calculate_line_spans:

1105  gcc_assert (next->m_first_line >= current->m_first_line);

since it isn't the case that 1 >= 3482810481.

The underlying problem is the mix of types for storing line numbers:
in parts of libcpp and diagnostic-show-locus.c we use linenum_type;
in other places (including libcpp's expanded_location) we use int.

I looked at using linenum_type throughout, but doing so turned into
a large patch, so this patch fixes the ICE in a less invasive way
by merely using linenum_type more consistently just within
diagnostic-show-locus.c, and fixing line_span::comparator to properly
handle line numbers (and line number differences) >= 2^31, by using
a new helper function for linenum_type differences, computing the
difference using long long, and using the sign of the difference
(as the difference might not fit in the "int" return type imposed
by qsort).

gcc/ChangeLog:
PR c/84852
* diagnostic-show-locus.c (class layout_point): Convert m_line
from int to linenum_type.
(line_span::comparator): Use linenum "compare" function when
comparing line numbers.
(test_line_span): New function.
(layout_range::contains_point): Convert param "row" from int to
linenum_type.
(layout_range::intersects_line_p): Likewise.
(layout::will_show_line_p): Likewise.
(layout::print_source_line): Likewise.
(layout::should_print_annotation_line_p): Likewise.
(layout::print_annotation_line): Likewise.
(layout::print_leading_fixits): Likewise.
(layout::annotation_line_showed_range_p): Likewise.
(struct line_corrections): Likewise for field m_row.
(line_corrections::line_corrections): Likewise for param "row".
(layout::print_trailing_fixits): Likewise.
(layout::get_state_at_point): Likewise.
(layout::get_x_bound_for_row): Likewise.
(layout::print_line): Likewise.
(diagnostic_show_locus): Likewise for locals "last_line" and
"row".
(selftest::diagnostic_show_locus_c_tests): Call test_line_span.
* input.c (selftest::test_linenum_comparisons): New function.
(selftest::input_c_tests): Call it.
* selftest.c (selftest::test_assertions): Test ASSERT_GT,
ASSERT_GT_AT, ASSERT_LT, and ASSERT_LT_AT.
* selftest.h (ASSERT_GT): New macro.
(ASSERT_GT_AT): New macro.
(ASSERT_LT): New macro.
(ASSERT_LT_AT): New macro.

gcc/testsuite/ChangeLog:
PR c/84852
* gcc.dg/fixits-pr84852-1.c: New test.
* gcc.dg/fixits-pr84852-2.c: New test.

libcpp/ChangeLog:
* include/line-map.h (compare): New function on linenum_type.


Added:
trunk/gcc/testsuite/gcc.dg/fixits-pr84852-1.c
trunk/gcc/testsuite/gcc.dg/fixits-pr84852-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/input.c
trunk/gcc/selftest.c
trunk/gcc/selftest.h
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h

[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
To give an updated: I'm awaiting approval of the aarch64 parts of my patch:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00392.html

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

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

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

[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1

[ktkachov at gcc dot gnu.org]

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

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

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-14
  Known to work||7.3.1
   Target Milestone|--- |8.0
Summary|bogus -Warray-bounds on a   |[8 Regression] bogus
   |memcpy in a loop|-Warray-bounds on a memcpy
   ||in a loop
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The reason is a missed phiopt to MIN_EXPR for h and VRP not propagating through
memory.

we have

   [local count: 955630223]:
  if (n_6 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  a[0] = 255;
  goto ; [100.00%]

   [local count: 477815112]:
  _1 = (unsigned char) n_6;
  a[0] = _1;

   [local count: 955630223]:
  _2 = a[0];

where we lack a pass replacing that with

   
   # tem = PHI <255(5), _1(6)>
   a[0] = tem;
   _2 = a[0];

and then a MIN_EXPR.

Not sure why thw warn_restrict pass ends up with this kind of value-range
here though.  In the IL we have threaded the n > 255 check though and
ended up with an explicit memcpy (..., 255);  but that's not [9, 255].

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #24)
> I can confirm that the Jakub's commit is fixing that. Revering the patch I
> see a miscomparison. That said, I would close it as resolved. Andrey?

That is weird, because we've figured that in the actual SPEC test it is used in
a loop with a variable exponent.  If it no longer reproduces, isn't that some
other change?  For a real fix I was hoping somebody would provide new, faster
and precise exp10{,f,l} implementations to glibc and then we could just use
exp10 rather than exp.

[Bug middle-end/84858] wrong exception handling of std::function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-14
 CC||rguenth at gcc dot gnu.org
  Component|c++ |middle-end
Version|5.4.0   |7.3.1
 Ever confirmed|0   |1
  Known to fail||7.3.0

--- Comment #1 from Richard Biener  ---
Confirmed with GCC 7.3.

[Bug c/84853] [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/84854] [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c++/84851] missing -Wclass-memaccess for a memcpy in a copy ctor with a non-trivial member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/84850] [8 Regression] -Wclass-memaccess on a memcpy in a copy assignment operator with no nontrivial bases or members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0
Summary|-Wclass-memaccess on a  |[8 Regression]
   |memcpy in a copy assignment |-Wclass-memaccess on a
   |operator with no nontrivial |memcpy in a copy assignment
   |bases or members|operator with no nontrivial
   ||bases or members

--- Comment #3 from Richard Biener  ---
But this one is a regression while PR84851 is an improvement request.

[Bug inline-asm/84861] -flto with asm() optimizes too much

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
PR 57703 seems to be the "canonical instance" for the toplevel-asms-with-lto
issue.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #24 from Martin Liška  ---
I can confirm that the Jakub's commit is fixing that. Revering the patch I see
a miscomparison. That said, I would close it as resolved. Andrey?

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
(In reply to Patrik Huber from comment #14)
> It even seems a few percent slower after the FDO stuff. But the `
> -fprofile-use` is a bit weird. If there is no .gcda file, it doesn't
> complain. If you give it a file that doesn't exist (e.g. -fprofile-use=foo),
> then it doesn't complain either. So how can I check whether it really ran
> the FDO?

Yep, maybe having an option that will cause failure would be a good idea.
Anyway, you can use -fdump-ipa-profile and check *.065i.profile file where you
should see something like:

...
Read edge from 0 to 2, count:1
1 edge counts read
...

Note that -fprofile-use=foo tells the compiler to search in *folder* foo for
corresponding gcda files.

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
Created attachment 43654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43654=edit
optimized dump after the revision

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
Created attachment 43653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43653=edit
optimized dump before the revision

[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active

[chefmax at gcc dot gnu.org]

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

--- Comment #5 from chefmax at gcc dot gnu.org ---
Created attachment 43652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43652=edit
Untested fix

Simple untested fix that seems to cure the issue.

[Bug c++/84855] structered bindings require "decomposed" type to be copy'able

[h2+bugs at fsfe dot org]

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

--- Comment #5 from Hannes Hauswedell  ---
Sure, that follows from the definition "For each identifier, a variable whose
type is "reference to std::tuple_element::type" is introduced".
This wouldn't have to be implemented like this, though...

My original intuition (and probably that of others) was that 
auto CR [ a, b ] = f;

leads to 

auto CR a = std::get<0>(f);
auto CR b = std::get<1>(f);

where CR can be "", "&", "&&" or "const &".

Instead something like this happens:
auto CR e = f;
auto && a = std::get<0>(e);
auto && b = std::get<1>(e);

I assume this design was chosen to be able to materialise temporaries and I
don't see an obvious way of handling that with a different design. But I still
feel like it is less intuitive in the general case and in my case also prevents
the plan (because I explicitly don't want perfect forwarding).

But that's a different matter and I will stop wasting your dev time ;-)

[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active

[chefmax at gcc dot gnu.org]

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

chefmax at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #4 from chefmax at gcc dot gnu.org ---
Hm, it seems that ASan is breaking internal ABI between GCC and libstdc++ by
adding redzones to global .LDFCM* symbols:

$ ~/install/master/bin/g++ /tmp/throws.cc -fsanitize=address -fPIC -S -o bad.s

...
.LLSDACSE1:
.byte   0x2
.byte   0
.byte   0x1
.byte   0x7d
.align 4
.long   DW.ref._ZTI1A-.
.long   .LDFCM0-.
.LLSDATT1:
...
...
...
.LDFCM0:
.zero   56   <== inserted by ASan
.quad   _ZTIN12_GLOBAL__N_114SomeRandomTypeE
.hidden DW.ref.__gxx_personality_v0
.weak   DW.ref.__gxx_personality_v0
.section   
.data.DW.ref.__gxx_personality_v0,"awG",@progbits,DW.ref.__gxx_personality_v0,comdat
.align 8
.type   DW.ref.__gxx_personality_v0, @object
.size   DW.ref.__gxx_personality_v0, 8


AFAU, during exception handling, libstdc++ tries to obtain a pointer to
`typeinfo for (anonymous namespace)::SomeRandomType' from a constant offset
from `.LDFCM0' label and gets zero, because ASan added a right redzone. I
suspect that not sanitizing `.LDFCM*' variables (and probably all other debug
vars) should resolve the issue.

[Bug target/84280] [6/7/8 Regression] Performance regression in g++-7 with Eigen for non-AVX2 CPUs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||aoliva at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #15 from Martin Liška  ---
I can confirm that on my Haswell machine:
model name  : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

I see regression with -march=core2 -mtune=core2 -O3 starting from r226901
(first time in GCC 5.x).

Time difference is:
0:00:14.975390
vs
0:00:11.889274

[Bug c++/84222] [6/7/8 Regression] [[deprecated]] class complains about internal class usage

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 43651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43651=edit
gcc8-pr84222.patch

Untested fix.