[Bug rtl-optimization/81301] New: [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 13 dominated by a block in the cold partition (8)) on 32-bit BE powerpc target

[asolokha at gmx dot com]

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

Bug ID: 81301
   Summary: [8 Regression] ICE: verify_flow_info failed (error:
non-cold basic block 13 dominated by a block in the
cold partition (8)) on 32-bit BE powerpc target
   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: ---
Target: powerpc-*-linux-gnu

gcc-8.0.0-alpha20170702 snapshot ICEs when compiling the following snippet w/
-O2 -freorder-blocks-and-partition:

long long int k5;
int v2;

void
h5 (int uh)
{
  if (uh != 0)
{
  uh = 0;
  if (v2 != 0)
uh = 1;

  ++k5;
  if (uh / k5 != 0)
{
  uh = k5;
  if (k5 == 0)
v2 = 0;
}
  v2 /= uh;
}

  k5 = 0;
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20170702 -O2
-freorder-blocks-and-partition -c fdkcfhj8.c
fdkcfhj8.c: In function 'h5':
fdkcfhj8.c:24:1: error: non-cold basic block 13 dominated by a block in the
cold partition (8)
 }
 ^
during RTL pass: ce3
fdkcfhj8.c:24:1: internal compiler error: verify_flow_info failed
0x767d25 verify_flow_info()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170702/work/gcc-8-20170702/gcc/cfghooks.c:259
0x13dadc4 checking_verify_flow_info
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170702/work/gcc-8-20170702/gcc/cfghooks.h:198
0x13dadc4 if_convert
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170702/work/gcc-8-20170702/gcc/ifcvt.c:5447
0x13dc87c execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170702/work/gcc-8-20170702/gcc/ifcvt.c:5593

[Bug rtl-optimization/81300] New: -fpeephole2 breaks __builtin_ia32_sbb_u64, _subborrow_u64 on AMD64

[andreser-gccbugs at mit dot edu]

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

Bug ID: 81300
   Summary: -fpeephole2 breaks __builtin_ia32_sbb_u64,
_subborrow_u64 on AMD64
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreser-gccbugs at mit dot edu
  Target Milestone: ---

Here is a short program for gcc 7.1.1 gives different output with "-O1
-fpeephole2 -m64" and "-O1 -m64".

int main() {
  unsigned long long _discard = 0, zero = 0, maxull = 0;
  unsigned char zero1 = __builtin_ia32_addcarryx_u64(0, 0, 0, &_discard);
  unsigned char zero2 = __builtin_ia32_addcarryx_u64(zero1, 0, 0, );
  __builtin_ia32_sbb_u64(0x0, 2, -1, &_discard);
  unsigned char one = __builtin_ia32_sbb_u64(0, zero, 1, );
  unsigned long long x = __builtin_ia32_sbb_u64(one, zero2, 0, &_discard);
  unsigned long long z1 = 0;
  __asm__ ("movq %1, %0;" :"+r"(z1) :"r"(x));
  unsigned long long z2 = 3;
  __asm__ ("movq %1, %0;" :"+r"(z2) :"r"(x));
  return 1-(z1 | z2);
}

Without -fpeephole2, the exit code is 0. With -fpeephole2, the exit code is 1.
I think this program should be deterministic, so I am tentatively attributing
the difference to a flaw in the peephole2 optimizations. Disassembling the
compiled code indeed shows that one of the SBB intrinsics has been dropped...
of course this by itself isn't evidence of anything going wrong as the whole
program could in principle be constant-propagated away, but what is going on
looks off to me.

Annotated side-by-side diff of relevant disassembly:
http://web.mit.edu/~andreser/Public/O1-fpeephole2.diff.html

The same disassembly for email-users' convenience. O1:

 :
   0:   bf 00 00 00 00  mov$0x0,%edi
   5:   b8 00 00 00 00  mov$0x0,%eax
   a:   ba 00 00 00 00  mov$0x0,%edx
   f:   80 c2 ffadd$0xff,%dl
  12:   48 89 c1mov%rax,%rcx
  15:   48 11 c1adc%rax,%rcx
  18:   0f 92 c2setb   %dl
; dl = 0
  1b:   be 01 00 00 00  mov$0x1,%esi
  20:   40 80 c7 ff add$0xff,%dil
  24:   48 19 f1sbb%rsi,%rcx ; rcx-rsi = 0 - 1 = 0xff...ff,
CF = 1
  27:   0f 92 c1setb   %cl
; cl = 1
  2a:   0f b6 d2movzbl %dl,%edx
  2d:   80 c1 ffadd$0xff,%cl ; cl = 0; CF = 1
  30:   48 19 c2sbb%rax,%rdx
; rdx = -1; CF = 1
  33:   0f 92 c1setb   %cl
  36:   0f b6 c9movzbl %cl,%ecx
  39:   48 89 c8mov%rcx,%rax
  3c:   ba 03 00 00 00  mov$0x3,%edx
  41:   48 89 camov%rcx,%rdx
  44:   09 d0   or %edx,%eax
  46:   ba 01 00 00 00  mov$0x1,%edx
  4b:   29 c2   sub%eax,%edx
  4d:   89 d0   mov%edx,%eax
  4f:   c3  retq   


With -fpeephole2:

 :

   0:   31 c0   xor%eax,%eax
   2:   31 d2   xor%edx,%edx
   4:   80 c2 ffadd$0xff,%dl
   7:   48 89 c1mov%rax,%rcx
   a:   48 11 c1adc%rax,%rcx
   d:   0f 92 c2setb   %dl
; dl = 0




; cl = 0
  10:   0f b6 d2movzbl %dl,%edx
  13:   31 c9   xor%ecx,%ecx ; cl = 0; CF = 0
  15:   48 19 c2sbb%rax,%rdx
; rdx = 0; CF = 0
  18:   0f 92 c1setb   %cl

  1b:   48 89 c8mov%rcx,%rax
  1e:   ba 03 00 00 00  mov$0x3,%edx
  23:   48 89 camov%rcx,%rdx
  26:   09 d0   or %edx,%eax
  27:   ba 01 00 00 00  mov$0x1,%edx
  2d:   29 c2   sub%eax,%edx
  2f:   89 d0   mov%edx,%eax
  31:   c3  retq

[Bug c++/81299] New: Spurious "set but not used" warning with constexpr variable

[ldionne.2 at gmail dot com]

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

Bug ID: 81299
   Summary: Spurious "set but not used" warning with constexpr
variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code triggers a spurious warning on GCC trunk (8.0 ish):

  struct function_t {
  template 
  void operator()(Xs&& ...) const { }
  };
  constexpr function_t function{};

  int main() {
  constexpr auto fun = ::function;
  auto call = [=](auto ...x) { fun(x...); };
  call();
  }

The output is:

  prog.cc: In function 'int main()':
  prog.cc:8:20: warning: variable 'fun' set but not used
[-Wunused-but-set-variable]
   constexpr auto fun = ::function;
  ^~~

Live example: https://godbolt.org/g/jNhNJV

This is an incredibly annoying bug that was also present in GCC 7 and causes
trivial constexpr code to fail to compile (when -Werror is used) :-(.

Sorry for using Godbolt (which does not clearly show the warning message)
instead of Wandbox, but Wandbox's shareable links feature are not working right
now.

[Bug c++/66967] thread local's destructor not called if compile with -fno-use-cxa-atexit

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |major

--- Comment #1 from Rainer Orth  ---
I'm seeing the same in g++ 7.1.0, either on Solaris 11 where
-fno-use-cxa-atexit
is the default since libc lacks __cxa_atexit, or on Solaris 12 (which has it)
or Linux/x86_64
with -fno-use-cxa-atexit.

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at netcologne dot de]

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

--- Comment #8 from tkoenig at netcologne dot de  
---
Am 03.07.2017 um 23:40 schrieb ebotcazou at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81298
> 
> Eric Botcazou  changed:
> 
> What|Removed |Added
> 
>   CC||ebotcazou at gcc dot gnu.org
> 
> --- Comment #7 from Eric Botcazou  ---
>> Why do we depend on exactly this version? *sigh*
> 
> I think we don't want a minor change to configure.ac to result in a upheaval 
> in
> the generated configure script.  We have dozens of configure scripts and 
> dozens
> of developers, this would be a mess if everyone was free to use his pet
> version.

I understand that desire, but autoconf 2.69 has been around since 2012.
It is hardly a fast-moving target.

I think it would be better to make a change towards 2.69.  The fewer
versions of extra software we have to use to compile gcc, the better.

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
> Why do we depend on exactly this version? *sigh*

I think we don't want a minor change to configure.ac to result in a upheaval in
the generated configure script.  We have dozens of configure scripts and dozens
of developers, this would be a mess if everyone was free to use his pet
version.

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Ah, no, only the gimple code drops overflow, the generic code doesn't :-(
I am still convinced the fix will not be in match.pd.

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
Summary|UBSAN: false positive,  |[6/7/8 Regression] UBSAN:
   |dropped promotion to long   |false positive, dropped
   |type.   |promotion to long type.
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Strange, gimple_resimplify2 already calls drop_tree_overflow, and I am calling
it myself everywhere else in this transformation... I'll have to check how
exactly that OVF flag appears.

[Bug c++/81293] sanitized g++ crashes heap-use-after-free gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543 in printf_common

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-03
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks for the report, can be also seen with valgrind. It's caused by r247417
and I'll fix it.

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Thomas Koenig  ---
Ah, IC.

Trying not to use the pre-built gcc resulted in using
the wrong version of autconf, apparently.

Why do we depend on exactly this version? *sigh*

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

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

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

--- Comment #5 from Andreas Schwab  ---
configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.69.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: m4 failed with exit status: 1
aclocal-1.11: autom4te failed with exit status: 1
make[3]: *** [Makefile:406: ../../trunk/libbacktrace/aclocal.m4] Fehler 1

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
 CC||glisse at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r249447.

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Created attachment 41671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41671=edit
Proposed patch

This is the patch I'm testing.

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  ---
PR81298 mentions a related issue, reproducible on x86_64.

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Matthias Klose  ---
introduced by 249738, adding richi

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Depends on||81295

--- Comment #4 from Thomas Koenig  ---
I mean PR 81295 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81295
[Bug 81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Could be a duplicate of PR 81298.

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|Bootstrap fails during  |[7 Regression]
   |stage1-bubble on|Bootstrapping trunk fails
   |x86_64-pc-linux-gnu with|during stage1-bubble on
   |--enable-maintainer-mode|x86_64-pc-linux-gnu with
   ||--enable-maintainer-mode

--- Comment #2 from Thomas Koenig  ---
Boostrapping with current trunk appears to go much
further, so it seems to be a problem with the gcc7
snapshot used for bootstrapping.

[Bug bootstrap/81298] Bootstrap fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 41670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41670=edit
Output of make -j4

[Bug bootstrap/81298] New: Bootstrap fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[tkoenig at gcc dot gnu.org]

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

Bug ID: 81298
   Summary: Bootstrap fails during stage1-bubble on
x86_64-pc-linux-gnu with --enable-maintainer-mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41669=edit
Config log from failed compilation

Boostrap just failed on me during stage1.  No clear error message that I could
find, just

make[1]: *** [Makefile:27970: stage1-bubble] Fehler 2

Configure was

../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran
--disable-multilib --enable-maintainer-mode

(from a different directory)

followed by

nohup make -j4&

Bootstrapping compiler was

gcc version 7.1.1 20170530 [gcc-7-branch revision 248621] (SUSE Linux)

prerequisites were downloaded with contrib/download_prerequisites

I will attach the nohup.out which failed separately.

[Bug target/81294] _subborrow_u64 argument order inconsistent with intrinsic reference, icc

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
It looks like (now fixed) bug in the documentation. So, following patch should
sync gcc with the fixed docs:

--cut here--
Index: adxintrin.h
===
--- adxintrin.h (revision 249844)
+++ adxintrin.h (working copy)
@@ -33,7 +33,7 @@
 _subborrow_u32 (unsigned char __CF, unsigned int __X,
unsigned int __Y, unsigned int *__P)
 {
-  return __builtin_ia32_sbb_u32 (__CF, __Y, __X, __P);
+  return __builtin_ia32_sbb_u32 (__CF, __X, __Y, __P);
 }

 extern __inline unsigned char
@@ -58,7 +58,7 @@
 _subborrow_u64 (unsigned char __CF, unsigned long long __X,
unsigned long long __Y, unsigned long long *__P)
 {
-  return __builtin_ia32_sbb_u64 (__CF, __Y, __X, __P);
+  return __builtin_ia32_sbb_u64 (__CF, __X, __Y, __P);
 }

 extern __inline unsigned char
--cut here--

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #4)
> The problem is that we hit:
>   if (si != NULL)
> {
>   if (!si->full_string_p && !si->stmt)
> {
>   /* Until now we only had a lower bound on the string length.
>  Install LHS as the actual length.  */
>   si = unshare_strinfo (si);
>   si->nonzero_chars = lhs;
>   si->full_string_p = true;
> }
>   return;
> }
> in handle_builtin_strlen, which changes just that single strinfo record, but
> doesn't do anything for the related ones.  And as strlen doesn't have a vdef
> (it is a pure function), nothing is invalidated, so we end up with a mixture
> of related strinfos where some strinfos are full_string_p and others are
> not,

Bah, sorry, I hadn't considered the lack of a vdef here.

> and e.g. zero_length_string has asserts that this does not happen.
> So, either handle_builtin_strlen needs to adjust also the related strinfos
> if any (note, maybe even if verify_related_strinfos fails we might need to
> do that or invalidate them manually), or we need to invalidate them, or not
> to record this change if we can't adjust or invalidate them all.

Ack.  Will fix.

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
bootstraps with the trunk, still fails with r249929 on the branch.

[Bug c++/65775] Late-specified return type bypasses return type checks (qualified, function, array)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c++/65775] Late-specified return type bypasses return type checks (qualified, function, array)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jul  3 18:10:52 2017
New Revision: 249935

URL: https://gcc.gnu.org/viewcvs?rev=249935=gcc=rev
Log:
/cp
2017-07-03  Paolo Carlini  

PR c++/65775
* decl.c (grokdeclarator): Move checks on function return type after
the splice_late_return_type call; if declspecs->locations[ds_type_spec]
is UNKNOWN_LOCATION fall back to input_location.

/testsuite
2017-07-03  Paolo Carlini  

PR c++/65775
* g++.dg/cpp0x/trailing14.C: New.

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

[Bug fortran/79843] diagnostics: missing word in fortran/symbol.c, conflict_std

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79866] diagnostics: typo in "Variable %s at %L of type EVENT_TYPE"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79866] diagnostics: typo in "Variable %s at %L of type EVENT_TYPE"

[dominiq at gcc dot gnu.org]

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

--- Comment #3 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul  3 18:03:51 2017
New Revision: 249934

URL: https://gcc.gnu.org/viewcvs?rev=249934=gcc=rev
Log:
2017-07-03  Dominique d'Humieres  

PR fortran/79866
* resolve.c (resolve_symbol): Fix typo.

PR testsuite/79866
* gfortran.dg/coarray_event_2.f08: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_event_2.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand

[gcc at baszerr dot eu]

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

bartek 'basz' szurgot  changed:

   What|Removed |Added

 CC||gcc at baszerr dot eu

--- Comment #4 from bartek 'basz' szurgot  ---
issue still present in GCC 7.1.0.

[Bug c++/58894] C++11 lambda doesn't take const variable by reference

[gcc at baszerr dot eu]

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

bartek 'basz' szurgot  changed:

   What|Removed |Added

 CC||gcc at baszerr dot eu

--- Comment #2 from bartek 'basz' szurgot  ---
looks like a duplicate of 53157
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53157).

[Bug fortran/79843] diagnostics: missing word in fortran/symbol.c, conflict_std

[dominiq at gcc dot gnu.org]

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

--- Comment #2 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul  3 17:56:08 2017
New Revision: 249933

URL: https://gcc.gnu.org/viewcvs?rev=249933=gcc=rev
Log:
2017-07-03  Dominique d'Humieres  

PR fortran/79843
* symbol.c (check_conflict): Add missing "conflicts".

PR testsuite/79843
* gfortran.dg/namelist_3.f90: Adjust the dg-error string.
* gfortran.dg/pointer_intent_2.f90: Likewise.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_3.f90
trunk/gcc/testsuite/gfortran.dg/pointer_intent_2.f90

[Bug tree-optimization/81297] New: [8 Regression] ICE in get_single_symbol

[asolokha at gmx dot com]

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

Bug ID: 81297
   Summary: [8 Regression] ICE in get_single_symbol
   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: ---

At least gcc-8.0.0-alpha20170625 and gcc-8.0.0-alpha20170702 snapshots ICE when
compiling the following snippet w/ -O2 (-O3, -Ofast, -Os) -fwrapv:

int
nf (int gy, int x0)
{
  while (gy < 1)
++x0;

  gy += !!gy;
  if (gy < 0)
{
  x0 += gy;
  return (x0 > (gy + x0)) ? (1 / 0) : 1;
}
}

% gcc-8.0.0-alpha20170702 -O2 -fwrapv -w -c umhraicu.c 
during GIMPLE pass: evrp
umhraicu.c: In function 'nf':
umhraicu.c:13:1: internal compiler error: in get_single_symbol, at
tree-vrp.c:799
 }
 ^

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at gcc dot gnu.org]

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

--- Comment #13 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul  3 17:42:54 2017
New Revision: 249930

URL: https://gcc.gnu.org/viewcvs?rev=249930=gcc=rev
Log:
2017-07-03  Dominique d'Humieres  

PR target/81033
* config/darwin.c (darwin_function_switched_text_sections):
Fix spaces.


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

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The problem is that we hit:
  if (si != NULL)
{
  if (!si->full_string_p && !si->stmt)
{
  /* Until now we only had a lower bound on the string length.
 Install LHS as the actual length.  */
  si = unshare_strinfo (si);
  si->nonzero_chars = lhs;
  si->full_string_p = true;
}
  return;
}
in handle_builtin_strlen, which changes just that single strinfo record, but
doesn't do anything for the related ones.  And as strlen doesn't have a vdef
(it is a pure function), nothing is invalidated, so we end up with a mixture of
related strinfos where some strinfos are full_string_p and others are not, and
e.g. zero_length_string has asserts that this does not happen.
So, either handle_builtin_strlen needs to adjust also the related strinfos if
any (note, maybe even if verify_related_strinfos fails we might need to do that
or invalidate them manually), or we need to invalidate them, or not to record
this change if we can't adjust or invalidate them all.

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Better testcase, the above has UB:
void foo (char *x)
{
  x[__builtin_strlen (x)] = ' ';
  x[__builtin_strlen (x)] = ' ';
}

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Reopening since this is about 7 branch rather than the trunk.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 81295 has been marked as a duplicate of this bug. ***

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
dup.

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

[Bug fortran/81296] derived type I/o problem

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. It looks that FORMAT is not (properly?) handled.

[Bug fortran/81296] New: derived type I/o problem

[ian at rhymneyconsulting dot co.uk]

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

Bug ID: 81296
   Summary: derived type I/o problem
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at rhymneyconsulting dot co.uk
  Target Milestone: ---

Created attachment 41668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41668=edit
source file showing error at run time

I believe the following program to be standard conforming.

module dtio_01_module

  type :: person

character (len=40) :: name
integer :: age

  contains

procedure, private :: pwf
generic :: write (formatted) => pwf

  end type person

contains

  subroutine pwf(dtv, unit, iotype, vlist, iostat, iomsg)

! argument definitions

class (person), intent (in) :: dtv
integer, intent (in) :: unit
character (len=*), intent (in) :: iotype
integer, intent (in) :: vlist(:)
integer, intent (out) :: iostat
character (len=*), intent (inout) :: iomsg

! local variable

character (len= 9) :: pfmt

! vlist(1) and (2) are to be used as the field widths of the two
! components of the derived type variable. First set up the format to
! be used for output.

write ( pfmt, '(a,i2,a,i1,a)' ) '(a', vlist(1), ',i', vlist(2), ')'
print *,pfmt

! now the basic output statement

write (unit, fmt=pfmt, iostat=iostat) dtv%name, dtv%age

  end subroutine pwf

end module dtio_01_module

program ch4001

  use dtio_01_module

  type (person) :: person_01=person('Ian Chivers',65)

  print *,person_01%name
  print *,person_01%age

  WRITE( 6, FMT="( DT (20,3) )" ) person_01

  write (6, 10) person_01
  10 format( DT(15,3) )

end program ch4001

I get the following error at run time.

c:\document\fortran\fourth_edition\examples>gfortran ch4001.f90

c:\document\fortran\fourth_edition\examples>a.exe
 Ian Chivers
  65
 (a20,i3) Ian Chivers  65
At line 58 of file ch4001.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Missing DTIO procedure or intrinsic type passed for item
1 in formatted transfer
( DT(15,3) )
   ^

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Matthias Klose  ---
gcc configured with
--with-pkgversion=Debian 7.1.0-8
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --prefix=/usr
--with-gcc-major-version-only --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--enable-objc-gc=auto --enable-secureplt --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --disable-werror --with-long-double-128 --enable-multilib
--enable-checking=release
--enable-languages=c,ada,c++,d,fortran,go,lto,objc,obj-c++
--program-transform-name=s&$&-7&;s&^&
--disable-option-checking --with-target-subdir=powerpc-linux-gnu
--build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu
--disable-intermodule --enable-checking=release,types --disable-coverage
--enable-languages=c,ada,c++,lto --disable-build-format-warnings

[Bug target/81295] New: [7 Regression] bootstrap broken on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 81295
   Summary: [7 Regression] bootstrap broken on powerpc-linux-gnu
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r249793 on the gcc-7-branch with powerpc-linux-gnu (32bit) I see code
generated with the stage1 compiler segfaulting (building libgomp stage1). both
with -O0 and -O2.  my last successful build was r249347.

r249732 on the gcc-6-branch built ok. status of the trunk is unknown.

[Bug c/81294] _subborrow_u64 argument order inconsistent with intrinsic reference, icc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Seems LLVM also agrees with ICC implementation (rather than the past
documentation).

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at gcc dot gnu.org]

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

--- Comment #12 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul  3 15:53:56 2017
New Revision: 249926

URL: https://gcc.gnu.org/viewcvs?rev=249926=gcc=rev
Log:
2017-07-03  Dominique d'Humieres  

PR target/81033
* config/darwin.c (darwin_function_switched_text_sections):
Replace DECL_NAME with DECL_ASSEMBLER_NAME, split assemble_name_raw
in two pieces, and suppress the use of buf.


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

[Bug c/81294] New: _subborrow_u64 argument order inconsistent with intrinsic reference, icc

[andreser-gccbugs at mit dot edu]

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

Bug ID: 81294
   Summary: _subborrow_u64 argument order inconsistent with
intrinsic reference, icc
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreser-gccbugs at mit dot edu
  Target Milestone: ---

gcc expects _subborrow_u64 arguments in a different order than the one
described in intel intrinsics reference and implemented by icc. I couldn't find
any documentation about it, so I am writing this issue under the presumption it
is not intentional.

The two full-width input arguments are swapped. If what icc does is a-b-carry,
gcc does b-a-carry. Needless to say, this most likely breaks any code using
_subborrow_u64 on one of the two compilers.

Curiously, it seems that the intel intrinsics guide *used to* (in April 2016)
describe the same behavior that gcc implements:
https://web.archive.org/web/20160422045348/https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=subb=5283
Now, however, the reference describes icc behavior:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=subborrow_u64=5283,5304,5304

To determine what gcc does, I used the following test program:

#include 
#include 
#include 

int main(int argc, char** argv) {
if (argc != 3) {
return 111;
}
uint64_t a = 0;
uint64_t b = 0;
sscanf(argv[1], "%llu", );
sscanf(argv[2], "%llu", );
unsigned long long s = 0;
uint8_t c = 0;
c = _subborrow_u64(1, a, b, );
printf("_subborrow_u64(1, %llu, %llu) = %llx + (%llx<<64)\n", a, b, s,
c);
}


Output if ran with gcc:
$ ./sbb 0 8
_subborrow_u64(1, 2, 8) = 5 + (0<<64)


Compiled with gcc 7.1: https://godbolt.org/g/Usq5Jb
Compiled with icc  17: https://godbolt.org/g/uMdFFm
The difference can be seen by looking at the address that is in rdx when sscanf
is called and then tracing which argument of sbb that number ends up in.

According to
https://stackoverflow.com/questions/29029572/multi-word-addition-using-the-carry-flag/29212615#comment61187795_29212615,
MSVC seems to agree with icc. If that behavior is the consensus of other
implementations (and the intel reference change was fixing an error), I think
it would make sense for gcc to change to match.

The arguments seem to get swapped at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/adxintrin.h;h=9c4152b9f360c0f9be408c84da4950ded8ad5654;hb=HEAD#l58

_subborrow_u64 (unsigned char __CF, unsigned long long __X,
unsigned long long __Y, unsigned long long *__P)
{ return __builtin_ia32_sbb_u64 (__CF, __Y, __X, __P); }

_subborrow_u32 seems to be affected as well

[Bug target/70676] suboptimal code generation on AVR

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #10 from Georg-Johann Lay  ---
(In reply to night_ghost from comment #9)
> Really this is a best way to fix bugs! Just ignore them - like an ostrich,
> hiding  head in the sand.

I just requested some information as outlines in the bug reporting
instructions.

That you have the information available does not mean I can guess it by magic,
and guessing has turned out to be extremely ineffective, time consuming and
often enough it comes up with guesses that completely diverge from a bug
reportes intention.

At some point I just stopped digging into your stuff and requested some more
information.

Yust the fact that you are not able or not willing to provide that information
does not mean it's nor required.

[Bug c/40528] Add a new ifunc attribute

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #18 from Jeffrey A. Law  ---
Fixed long ago.

[Bug target/81273] Wrong code generated for ARM setting volatile struct field with a literal

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Earnshaw  ---
The compiler gave you what you asked for (though it might not have been what
you wanted, or even expected).  Optimization is irrelevant here.

Just because the address you finally assigned to the structure was aligned
doesn't mean that the compiler can change the access pattern for a volatile
object.  You'd hardly expect that changing base_addr to 0x3f01 would change
the sequence of loads and stores generated, surely?  And don't forget that
unaligned accesses to DEVICE memory are undefined.

[Bug target/81273] Wrong code generated for ARM setting volatile struct field with a literal

[ldeboer at gateway dot net.au]

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

--- Comment #5 from LdB  ---
Okay I understand all that and accept my apology and I will try to follow the
rules exactly in future.

I had to change the alignment command slightly to be valid on ARM 6.3.1
struct __attribute__((__packed__,aligned(__alignof(uint32_tTimerRegisters {
volatile uint32_t Load; //0x00
volatile uint32_t Value; //0x04
};

I am getting viable code with that, so it's undeniable it is an alignment
issue.

I am happy to have that as the solution and I understand it is the most
technically correct. It probably needs to be added to the manual because I
suspect it is going to come up a lot. I have never had the compiler spit
unaligned code as the most optimized code before.

[Bug rtl-optimization/81290] [8 Regression] ICE in update_br_prob_note

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jul  3 14:40:46 2017
New Revision: 249924

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

PR middle-end/81290
* predict.c (force_edge_cold): Be more careful about propagation
backward.
* profile-count.h (profile_probability::guessed,
profile_probability::fdo, profile_count::guessed, profile_count::fdo):
New.
* tree-ssa-threadupdate.c (recompute_probabilities): Result is guessed.

* gcc.c-torture/compile/pr81290.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr81290.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/profile-count.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
So, I believe this has been introduced in r244974 from PR71433.
We have 5 asserts for SSA_NAME 66 in the problematic function:
(gdb) p *asserts.m_auto.m_vecdata[0]
$49 = {bb = , e = 
37)>, si = {ptr = 0x7fffd37523c0, seq = 0x7fffd6407588, 
bb = }, comp_code = EQ_EXPR, val =
, expr = , 
  next = 0x3a29bc0}
(gdb) p *asserts.m_auto.m_vecdata[1]
$50 = {bb = , e = 
37)>, si = {ptr = 0x7fffd3752230, seq = 0x7fffd6407450, 
bb = }, comp_code = EQ_EXPR, val =
, expr = , 
  next = 0x3a29c10}
(gdb) p *asserts.m_auto.m_vecdata[2]
$51 = {bb = , e = 
14)>, si = {ptr = 0x7fffd3752230, seq = 0x7fffd6407450, 
bb = }, comp_code = NE_EXPR, val =
, expr = , 
  next = 0x3a29c60}
(gdb) p *asserts.m_auto.m_vecdata[3]
$52 = {bb = , e = 
37)>, si = {ptr = 0x7fffd37521e0, seq = 0x7fffd6407178, 
bb = }, comp_code = EQ_EXPR, val =
, expr = , 
  next = 0x3a29cb0}
(gdb) p *asserts.m_auto.m_vecdata[4]
$53 = {bb = , e = 
13)>, si = {ptr = 0x7fffd37521e0, seq = 0x7fffd6407178, 
bb = }, comp_code = NE_EXPR, val =
, expr = , next = 0x0}
and the new compare_assert_loc first sorts on !a->e != !b->e, then on
destination index (both are fine for -fcompare-debug), but then
on iterative_hash_expr (a->expr, iterative_hash_expr (a->val, 0)) vs.
iterative_hash_expr (b->expr, iterative_hash_expr (b->val, 0));
which is not ok, because the two val values are ADDR_EXPR of a helper variable
which has different DECL_UID between -g and -g0.

Let me try to fix this by doing another qsort afterwards which ignores the hash
and just uses edge indexes.

[Bug target/70676] suboptimal code generation on AVR

[night_ghost at ykoctpa dot ru]

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

night_ghost at ykoctpa dot ru changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #9 from night_ghost at ykoctpa dot ru ---
Really this is a best way to fix bugs! Just ignore them - like an ostrich,
hiding  head in the sand.

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Fixed by Rainer's commit r249912.

Is this a real fix? IMO introducing ifunc on targets that do not support it
does not look as a good idea!-(

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #11 from simon at pushface dot org ---
(In reply to Jan Hubicka from comment #8)

> Looking into the error I suppose problem is:
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIcE8allocateEmPKv.cold.42:
> 
> and bit later
> 
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIwE8allocateEm.cold.47:
> 
> So perhaps the following fix it?
> Index: darwin.c
> ===
> --- darwin.c  (revision 249872)
> +++ darwin.c  (working copy)
> @@ -3685,7 +3665,7 @@
>  {
>char buf[128];
>snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
> - IDENTIFIER_POINTER (DECL_NAME (decl)));
> + IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
>/* Make sure we pick up all the relevant quotes etc.  */
>assemble_name_raw (fp, (const char *) buf);
>fputs (":\n", fp);

No; bootstrapping from 7.1.0,

/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//ccCIgbl7.s:34470:1: error:
invalid symbol redefinition
___cold_sect_of__ZNKSt7__cxx119money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES4_S4_bRSt8ios_baseRSt12_Ios_Iost:
^
make[6]: *** [cxx11-locale-inst.lo] Error 1
make[6]: *** Waiting for unfinished jobs
/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc6MyXXO.s:33909:1: error:
invalid symbol redefinition
___cold_sect_of__ZNKSt7__cxx119money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES4_S4_bRSt8ios_baseRSt12_Ios_Iost:
^
make[6]: *** [cxx11-wlocale-inst.lo] Error 1

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
The last patch in comment 8 exposes another problem: buf[128] is too small.

The following patch which uses the trick proposed in IRC by Richi to split
assemble_name_raw seems to work

--- ../_clean/gcc/config/darwin.c   2017-01-01 17:39:06.0 +0100
+++ gcc/config/darwin.c 2017-07-03 14:21:19.0 +0200
@@ -3683,11 +3683,9 @@ default_function_sections:
 void
 darwin_function_switched_text_sections (FILE *fp, tree decl, bool new_is_cold)
 {
-  char buf[128];
-  snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
-   IDENTIFIER_POINTER (DECL_NAME (decl)));
   /* Make sure we pick up all the relevant quotes etc.  */
-  assemble_name_raw (fp, (const char *) buf);
+  assemble_name_raw (fp, new_is_cold?"__cold_sect_of_":"__hot_sect_of_");
+  assemble_name_raw (fp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
   fputs (":\n", fp);
 }

[Bug target/81273] Wrong code generated for ARM setting volatile struct field with a literal

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
(In reply to LdB from comment #3)
> I am stunned you could not build the code the only requirement is you
> include the stdint.h so the uint32_t types are defined. I will fix the typos
> are you really saying you can't compile this?
> 

Most compiler developers do not install a complete build environment when
testing bugs.  As such, they do not have the headers available.  This is why
our bug reporting rules ask you to post _preprocessed_ source code.

You've also failed to give:

The options used to configure the compiler when you built it (see the output of
gcc -v).

The list of options you passed to the compiler when running it.  We can only
infer -O2 from your comments.

> Alignment is not really a concern it's a hardware register to the CPU so
> it's a given.

Absolutely alignment is the issue here.  Packed says that the object can be on
any alignment boundary and that materially affects the compiler's behaviour
here.

[Bug target/81273] Wrong code generated for ARM setting volatile struct field with a literal

[ldeboer at gateway dot net.au]

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

--- Comment #3 from LdB  ---
I am stunned you could not build the code the only requirement is you include
the stdint.h so the uint32_t types are defined. I will fix the typos are you
really saying you can't compile this?

#include 
struct __attribute__((__packed__)) TimerRegisters {
volatile uint32_t Load; //0x00
volatile uint32_t Value; //0x04
};

uint32_t base_addr = 0x3F00;
#define TIMER ((struct TimerRegisters*)(base_addr + 0xB400))

void ShowBug (void){
   TIMER->Load =  0x400; // -02 compile and look at code
}

void ShowFix1 (void){
*(volatile uint32_t*)TIMER->Load =  0x400;
}

void ShowFix2 (void){
volatile uint32_t temp = 0x400;
TIMER->Load =  temp;
}

Alignment is not really a concern it's a hardware register to the CPU so it's a
given.

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #16 from Martin Liška  ---
(In reply to Andrey Ryabinin from comment #15)
> (In reply to Martin Liška from comment #14)
> > Fixed on trunk.
> 
> Thanks.
> 
> However there is slight problem with this. Instrumentation is missing without
> -fsanitize-address-use-after-scope option.
> IMO, it should depend only on --param asan-stack=1.
> 
> So the following doesn't produce any output:
> gcc -fsanitize=address -fno-sanitize-address-use-after-scope -O2 asan_test.c
> && ./a.out
> 
> Can we fix this?

It's mistake! I've got patch for that and will send it tomorrow.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 60510 Summary: SLP blocks loop vectorization (with reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60510

   What|Removed |Added

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

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egall at gwmail dot gwu.edu]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #8)
> 
> 
> Looking into the error I suppose problem is:
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIcE8allocateEmPKv.cold.42:
> 
> and bit later
> 
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIwE8allocateEm.cold.47:
> 
> So perhaps the following fix it?
> Index: darwin.c
> ===
> --- darwin.c  (revision 249872)
> +++ darwin.c  (working copy)
> @@ -3685,7 +3665,7 @@
>  {
>char buf[128];
>snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
> - IDENTIFIER_POINTER (DECL_NAME (decl)));
> + IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
>/* Make sure we pick up all the relevant quotes etc.  */
>assemble_name_raw (fp, (const char *) buf);
>fputs (":\n", fp);

I tried this patch; bootstrap still fails for me, albeit on a different file
now. New error message is:

/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/xg++
-B/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/
-B/usr/local/i386-apple-darwin9.8.0/bin/ -nostdinc++
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include/i386-apple-darwin9.8.0

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include
 -I/private/var/root/gcc-git/libstdc++-v3/libsupc++
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -mdynamic-no-pic  -gtoggle -DIN_GCC -fPIC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/private/var/root/gcc-git/my_oddly_named_builddir/./gmp
-I/private/var/root/gcc-git/gmp
-I/private/var/root/gcc-git/my_oddly_named_builddir/./mpfr/src
-I/private/var/root/gcc-git/mpfr/src -I/private/var/root/gcc-git/mpc/src 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/../libbacktrace
-I/private/var/root/gcc-git/my_oddly_named_builddir/./isl/include
-I/private/var/root/gcc-git/isl/include -I/usr/local/include -o
gimple-ssa-store-merging.o -MT gimple-ssa-store-merging.o -MMD -MP -MF
./.deps/gimple-ssa-store-merging.TPo ../../gcc/gimple-ssa-store-merging.c
cc1plus: warning: ‘-mdynamic-no-pic’ overrides ‘-fpic’, ‘-fPIC’, ‘-fpie’ or
‘-fPIE’
/var/tmp//cc2wwOg4.s:2529:FATAL:Symbol
___cold_sect_of__ZN10hash_tableIN8hash_mapI17tree_operand_hashPN12_GLOBAL__N_120imm_store_chain_infoE21simple_hashmap_traitsI19d
already defined.
make[3]: *** [gimple-ssa-store-merging.o] Error 1
make[3]: Leaving directory
`/private/var/root/gcc-git/my_oddly_named_builddir/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make: *** [all] Error 2

[Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #7 from Richard Biener  ---
Fixed for GCC 8.

[Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Jul  3 13:44:13 2017
New Revision: 249919

URL: https://gcc.gnu.org/viewcvs?rev=249919=gcc=rev
Log:
2017-07-03  Richard Biener  

PR tree-optimization/60510
* tree-vect-loop.c (vect_create_epilog_for_reduction): Pass in
the scalar reduction PHI and use it.
(vectorizable_reduction): Properly guard the single_defuse_cycle
path for non-SLP reduction chains where we cannot use it.
Rework reduc_def/index and vector type deduction.  Rework
vector operand gathering during reduction op code-gen.
* tree-vect-slp.c (vect_analyze_slp): For failed SLP reduction
chains dissolve the chain and leave it to non-SLP reduction
handling.

* gfortran.dg/vect/pr60510.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr60510.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c

[Bug ipa/81214] GCC target_clone support does not work for global functions with no references

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Dominique d'Humieres from comment #6)
> At revision r249851 I see the following regression on darwin
> 
> FAIL: gcc.target/i386/mvc6.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/mvc6.c scan-assembler punpcklbw
> UNRESOLVED: gcc.target/i386/mvc6.c scan-assembler vpshufb
> 
> % gcc8 -c -O3 /opt/gcc/_clean/gcc/testsuite/gcc.target/i386/mvc6.c
> /opt/gcc/_clean/gcc/testsuite/gcc.target/i386/mvc6.c:8:1: error: the call
> requires ifunc, which is not supported by this target
>  foo(char *in, char *out, int size)
>  ^~~
> 
> I suspect this to be caused by revision r249840.

Fixed by Rainer's commit r249912.

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[ryabinin.a.a at gmail dot com]

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

--- Comment #15 from Andrey Ryabinin  ---
(In reply to Martin Liška from comment #14)
> Fixed on trunk.

Thanks.

However there is slight problem with this. Instrumentation is missing without
-fsanitize-address-use-after-scope option.
IMO, it should depend only on --param asan-stack=1.

So the following doesn't produce any output:
gcc -fsanitize=address -fno-sanitize-address-use-after-scope -O2 asan_test.c &&
./a.out

Can we fix this?

[Bug c++/81293] New: sanitized g++ crashes heap-use-after-free gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543 in printf_common

[zeccav at gmail dot com]

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

Bug ID: 81293
   Summary: sanitized g++ crashes heap-use-after-free
gcc/libsanitizer/sanitizer_common/sanitizer_common_int
erceptors_format.inc:543 in printf_common
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

// in trunk 249883
// from devirt-45.C
// compile with -fdump-ipa-inline-details -fno-early-inlining -O2 
// SUMMARY: AddressSanitizer: heap-use-after-free
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
in printf_common
struct A {
  virtual int foo () {return 1;}
  int wrapfoo () {foo();}
  A() {wrapfoo();}
};
inline void* operator new(__SIZE_TYPE__ s, void* buf) throw() {
   return buf;
}
struct B:A {virtual int foo () {return 2;}};

static void
test (struct A *a)
{
  static_cast(a)->~B();
  new(a) B();
}

main()
{
  struct B a;
  test ();
}
/*=
==10147==ERROR: AddressSanitizer: heap-use-after-free on address 0x60272470
at pc 0x2b6feac184fb bp 0x7ffcd9ff38e0 sp 0x7ffcd9ff3090
READ of size 2 at 0x60272470 thread T0
#0 0x2b6feac184fa in printf_common
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
#1 0x2b6feac534ff in __asan::ErrorDescription::Print()
../../../../gcc/libsanitizer/asan/asan_errors.h:360
#2 0x2b6feac534ff in __asan::ScopedInErrorReport::~ScopedInErrorReport()
../../../../gcc/libsanitizer/asan/asan_report.cc:167
#3 0x2b6feac534ff in __asan::ReportGenericError(unsigned long, unsigned
long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool)
../../../../gcc/libsanitizer/asan/asan_report.cc:397
#4 0x2b6feac1832b in printf_common
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
#5 0x2b6feac1925b in __interceptor_vfprintf
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1328
#6 0x2b6feac19326 in __interceptor_fprintf
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1373
#7 0x53ab70c in inline_small_functions ../../gcc/gcc/ipa-inline.c:2048
#8 0x53b10a5 in ipa_inline ../../gcc/gcc/ipa-inline.c:2429
#9 0x53b3fb8 in execute ../../gcc/gcc/ipa-inline.c:2835
#10 0x2833dc7 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2492
#11 0x28384cc in execute_ipa_pass_list(opt_pass*)
../../gcc/gcc/passes.c:2927
#12 0x178ae2d in ipa_passes ../../gcc/gcc/cgraphunit.c:2388
#13 0x178be18 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2474
#14 0x178cec5 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2633
#15 0x2dbbe22 in compile_file ../../gcc/gcc/toplev.c:493
#16 0x2dc3f8a in do_compile ../../gcc/gcc/toplev.c:2021
#17 0x2dc49aa in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2155
#18 0x56b3cbe in main ../../gcc/gcc/main.c:39
#19 0x2b6fed475400 in __libc_start_main (/usr/lib64/libc.so.6+0x20400)
#20 0x78a619 in _start
(/home/vitti/1tb/vitti/local/gcc-249691-sanitized/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus+0x78a619)

0x60272470 is located 0 bytes inside of 7-byte region
[0x60272470,0x60272477)
freed by thread T0 here:
#0 0x2b6feac49088 in __interceptor_free
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:45
#1 0x11611c1 in cxx_printable_name_internal ../../gcc/gcc/cp/tree.c:2544
#2 0x116153a in cxx_printable_name(tree_node*, int)
../../gcc/gcc/cp/tree.c:2555
#3 0x16fbf9e in symtab_node::name() const ../../gcc/gcc/symtab.c:522
#4 0x53ab69b in inline_small_functions ../../gcc/gcc/ipa-inline.c:2048
#5 0x53b10a5 in ipa_inline ../../gcc/gcc/ipa-inline.c:2429
#6 0x53b3fb8 in execute ../../gcc/gcc/ipa-inline.c:2835
#7 0x2833dc7 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2492
#8 0x28384cc in execute_ipa_pass_list(opt_pass*)
../../gcc/gcc/passes.c:2927
#9 0x178ae2d in ipa_passes ../../gcc/gcc/cgraphunit.c:2388
#10 0x178be18 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2474
#11 0x178cec5 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2633
#12 0x2dbbe22 in compile_file ../../gcc/gcc/toplev.c:493
#13 0x2dc3f8a in do_compile ../../gcc/gcc/toplev.c:2021
#14 0x2dc49aa in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2155
#15 0x56b3cbe in main ../../gcc/gcc/main.c:39
#16 0x2b6fed475400 in __libc_start_main (/usr/lib64/libc.so.6+0x20400)

previously allocated by thread T0 here:
#0 0x2b6feac493aa in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:62
#1 0x595d890 in xmalloc ../../gcc/libiberty/xmalloc.c:147
#2 

[Bug rtl-optimization/81290] [8 Regression] ICE in update_br_prob_note

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/81291] [5/6/7/8 Regression] wrong code with -O2 -fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp -funroll-loops due to improper carry

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
After downloading trunk 249883 I can confirm the bug disappeared.

[Bug rtl-optimization/81290] [8 Regression] ICE in update_br_prob_note

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
this is bug in threadupdate which makes count to be reliably zero while it is
just result of misupdate and another bug in force_edge_cold that does not know
how to give up on entry block.  I am testing fix.

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Seems a different order in release_ssa_name in that function, in one case it is
198, 2, 199, 23, 40, in the other case 199, 2, 40, 23, 198.  Used
--- tree-ssanames.c.xx  2017-07-01 10:15:12.0 +0200
+++ tree-ssanames.c 2017-07-03 14:43:13.278636615 +0200
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
 #include "stor-layout.h"
 #include "tree-into-ssa.h"
 #include "tree-ssa.h"
+#include "tree-pretty-print.h"

 /* Rewriting a function into SSA form can create a huge number of SSA_NAMEs,
many of which may be thrown away shortly after their creation if jumps
@@ -309,6 +310,14 @@ make_ssa_name_fn (struct function *fn, t
   else
 SSA_NAME_RANGE_INFO (t) = NULL;

+{
+FILE *f = fopen ("/tmp/ssanames", "a");
+fprintf (f, "@@@make_ssa_name ");
+print_generic_expr (f, t, TDF_VOPS|TDF_MEMSYMS);
+fprintf (f, " %s\n", IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(current_function_decl)));
+fclose (f);
+}
+
   SSA_NAME_IN_FREE_LIST (t) = 0;
   SSA_NAME_IS_DEFAULT_DEF (t) = 0;
   imm = &(SSA_NAME_IMM_USE_NODE (t));
@@ -560,6 +569,14 @@ release_ssa_name_fn (struct function *fn
   int saved_ssa_name_version = SSA_NAME_VERSION (var);
   use_operand_p imm = &(SSA_NAME_IMM_USE_NODE (var));

+{
+FILE *f = fopen ("/tmp/ssanames", "a");
+fprintf (f, "@@@release_ssa_name ");
+print_generic_expr (f, var, TDF_VOPS|TDF_MEMSYMS);
+fprintf (f, " %s\n", IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(current_function_decl)));
+fclose (f);
+}
+
   if (MAY_HAVE_DEBUG_STMTS)
insert_debug_temp_for_var_def (NULL, var);

hack to find that out.  Now to debug where those release_ssa_name calls come
from and what is the difference.

[Bug rtl-optimization/81290] [8 Regression] ICE in update_br_prob_note

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
 CC||hubicka at ucw dot cz,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Also started with r249800.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #11 from Markus Trippelsdorf  ---
Fixed.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to Arseny Solokha from comment #9)
> Maybe it's also worthwhile to commit testcase from PR81284?

I don't think this is necessary because the ICEs when building libgcc, even
with
--disable-bootstrap, are obvious enough.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[asolokha at gmx dot com]

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

--- Comment #9 from Arseny Solokha  ---
Maybe it's also worthwhile to commit testcase from PR81284?

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #14)
> Well, I've just noticed that the revision I identified is problematic
> because of compilation errors like:
> 
> /home/trippels/gcc_test/usr/local/include/c++/8.0.0/type_traits:143:12:
> error: ‘value’ is not a member of
> ‘std::is_constructible llvm::detail::DenseSetEmpty, llvm::MDNodeInfo,
> llvm::detail::DenseSetPair, false>,
> llvm::DenseMapIterator llvm::MDNodeInfo,
> llvm::detail::DenseSetPair, false>&&>’
> 
> ... and not because of debug compare.
> Can you please do a pre-processed file with a bit older compiler in order to
> bisect over the revision?

See above. Simply build LLVM trunk (release build) with gcc using
GCC_COMPARE_DEBUG=1.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jul  3 12:17:59 2017
New Revision: 249904

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

PR bootstrap/81285
* loop-doloop.c (add_test): Update profile.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-doloop.c

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
Well, I've just noticed that the revision I identified is problematic because
of compilation errors like:

/home/trippels/gcc_test/usr/local/include/c++/8.0.0/type_traits:143:12: error:
‘value’ is not a member of
‘std::is_constructible, false>,
llvm::DenseMapIterator, false>&&>’

... and not because of debug compare.
Can you please do a pre-processed file with a bit older compiler in order to
bisect over the revision?

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #12)
> (In reply to Markus Trippelsdorf from comment #11)
> > Unfortunately the bisection was unsuccessful (no wonder
> > given that the failure is not 100% reproducible (GC related)).
> 
> Well, I can help you with that. Any idea which value of ggc-min-heapsize to
> select in order to have it "more" bisection stable?

--param ggc-min-expand=0 --param ggc-min-heapsize=0 would be best, but it 
will of course take ages on the unreduced testcase.

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #11)
> Unfortunately the bisection was unsuccessful (no wonder
> given that the failure is not 100% reproducible (GC related)).

Well, I can help you with that. Any idea which value of ggc-min-heapsize to
select in order to have it "more" bisection stable?

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Likely r249880.

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Yes, your patch fixes the problem. Thanks.

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Fixed on trunk.

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
Unfortunately the bisection was unsuccessful (no wonder
given that the failure is not 100% reproducible (GC related)).

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Mon Jul  3 11:48:47 2017
New Revision: 249903

URL: https://gcc.gnu.org/viewcvs?rev=249903=gcc=rev
Log:
ASAN: handle addressable params (PR sanitize/81040).

2017-07-03  Martin Liska  

PR sanitize/81040
* g++.dg/asan/function-argument-1.C: New test.
* g++.dg/asan/function-argument-2.C: New test.
* g++.dg/asan/function-argument-3.C: New test.
2017-07-03  Martin Liska  

PR sanitize/81040
* sanopt.c (rewrite_usage_of_param): New function.
(sanitize_rewrite_addressable_params): Likewise.
(pass_sanopt::execute): Call rewrite_usage_of_param.

Added:
trunk/gcc/testsuite/g++.dg/asan/function-argument-1.C
trunk/gcc/testsuite/g++.dg/asan/function-argument-2.C
trunk/gcc/testsuite/g++.dg/asan/function-argument-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #9)
> (In reply to Jakub Jelinek from comment #5)
> > The bisection looks weird, that is the point before which the unreduced
> > testcase obviously will fail to compile, but that doesn't mean it is the
> > point where the -fcompare-debug bug has been introduced.
> 
> Ok, I'll try to do it with original test-case to find a culprit revision.

No need to. I'm one step away from final bisection...

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> The bisection looks weird, that is the point before which the unreduced
> testcase obviously will fail to compile, but that doesn't mean it is the
> point where the -fcompare-debug bug has been introduced.

Ok, I'll try to do it with original test-case to find a culprit revision.

[Bug tree-optimization/81292] [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-03
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/81286] [6/7 Regression] building for powerpc*-unknown-linux-gnu target fails with RTL checking enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |segher at gcc dot 
gnu.org

--- Comment #4 from Jakub Jelinek  ---
Reassigning to Segher then.

[Bug target/81286] [6/7 Regression] building for powerpc*-unknown-linux-gnu target fails with RTL checking enabled

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
> Untested fix.  gpc_reg_operand allows in some cases a SUBREG of a REG, but
> REGNO is not valid in that case.

Right, Segher forgot to backport his fixlet:
  https://gcc.gnu.org/ml/gcc-cvs/2017-06/msg00448.html

[Bug tree-optimization/81292] New: [8 regression] ICE in zero_length_string, at tree-ssa-strlen.c:822

[dimhen at gmail dot com]

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

Bug ID: 81292
   Summary: [8 regression] ICE in zero_length_string, at
tree-ssa-strlen.c:822
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r249632 PASS
r249892 FAIL

$ cat x.ii
extern "C" unsigned long strlen(const char *);
int a(char *b) {
  b[strlen(b)] = b[strlen(b)] = ' ';
  return 0;
}

$ /usr/local/gcc_current/bin/g++ -fpreprocessed -O2 -c x.ii
during GIMPLE pass: strlen
x.ii: In function ‘int a(char*)’:
x.ii:2:5: internal compiler error: in zero_length_string, at
tree-ssa-strlen.c:822
 int a(char *b) {
 ^
0x7b5ca9 zero_length_string
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:822
0x1252dfa handle_pointer_plus
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:2175
0x1252dfa strlen_optimize_stmt
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:2546
0x1253641 strlen_dom_walker::before_dom_children(basic_block_def*)
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:2728
0x186f85a dom_walker::walk(basic_block_def*)
/home/dimhen/src/gcc_current/gcc/domwalk.c:265
0x124dc5a execute
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:2800
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.


$ /usr/local/gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic
Thread model: posix
gcc version 8.0.0 20170703 (experimental) [trunk revision 249892] (GCC)

[Bug target/81285] [8 Regression] r249888 breaks bootstrap on ppc64le

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
Hi,
does the following patch fix ppc/ia64 (I have checked that it fixes the
arm testcase mentioned earlier).

honza

Index: loop-doloop.c
===
--- loop-doloop.c   (revision 249885)
+++ loop-doloop.c   (working copy)
@@ -347,6 +347,8 @@ add_test (rtx cond, edge *e, basic_block
   rtx op0 = XEXP (cond, 0), op1 = XEXP (cond, 1);
   enum rtx_code code = GET_CODE (cond);
   basic_block bb;
+  /* The jump is supposed to handle an unlikely special case.  */
+  profile_probability prob = profile_probability::very_unlikely ();

   mode = GET_MODE (XEXP (cond, 0));
   if (mode == VOIDmode)
@@ -357,7 +359,7 @@ add_test (rtx cond, edge *e, basic_block
   op1 = force_operand (op1, NULL_RTX);
   label = block_label (dest);
   do_compare_rtx_and_jump (op0, op1, code, 0, mode, NULL_RTX, NULL, label,
-  profile_probability::uninitialized ());
+  prob);

   jump = get_last_insn ();
   if (!jump || !JUMP_P (jump))
@@ -387,12 +389,14 @@ add_test (rtx cond, edge *e, basic_block

   JUMP_LABEL (jump) = label;

-  /* The jump is supposed to handle an unlikely special case.  */
-  add_int_reg_note (jump, REG_BR_PROB, 0);
-
   LABEL_NUSES (label)++;

-  make_edge (bb, dest, (*e)->flags & ~EDGE_FALLTHRU);
+  edge e2 = make_edge (bb, dest, (*e)->flags & ~EDGE_FALLTHRU);
+  e2->probability = prob;
+  e2->count = e2->src->count.apply_probability (prob);
+  (*e)->probability = prob.invert ();
+  (*e)->count = (*e)->count.apply_probability (prob);
+  update_br_prob_note (e2->src);
   return true;
 }

[Bug target/81286] [6/7 Regression] building for powerpc*-unknown-linux-gnu target fails with RTL checking enabled

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 41666 [details]
> gcc7-pr81286.patch
> 
> Untested fix.  gpc_reg_operand allows in some cases a SUBREG of a REG, but
> REGNO is not valid in that case.

I can confirm that I can build both 6-branch and 7-branch with the patch
applied.

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Seems to be between loop and loopinit passes, will need to watch carefully the
SSA_NAME freeing.

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Anyway, I've reproduced it on x86_64-linux with the unreduced testcase, trying
to find which pass starts the differences on
_ZNK4llvm12DenseMapBaseINS_8DenseMapIPNS_26DIGlobalVariableExpressionENS_6detail13DenseSetEmptyENS_10MDNodeInfoIS2_EENS4_12DenseSetPairIS3_S3_S5_S7_S9_E15LookupBucketForIS3_EEbRKT_RPKS9_

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #5)
> The bisection looks weird, that is the point before which the unreduced
> testcase obviously will fail to compile, but that doesn't mean it is the
> point where the -fcompare-debug bug has been introduced.

Yes. Maybe just try to configure LLVM with -O3 and then run 
"GCC_COMPARE_DEBUG=1 ninja" (this is how I came accross the testcase).
And then use the full failing gcc command for bisection.

I will give it a try later.

[Bug target/81291] New: [5/6/7/8 Regression] wrong code with -O2 -fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp -funroll-loops due to improper carry

[zsojka at seznam dot cz]

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

Bug ID: 81291
   Summary: [5/6/7/8 Regression] wrong code with -O2
-fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp
-funroll-loops due to improper carry
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 41667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41667=edit
reduced testcase

Output:
$ powerpc-unknown-linux-gnu-gcc -O2 -fno-rerun-cse-after-loop -fno-tree-ter
-fno-tree-vrp -funroll-loops testcase.c
$ qemu-ppc ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The wrong value of "x" is 0x0001. It seems to be created as:
$ cat testcase.c
...
li 11,1  # _20,
 # testcase.c:11:   a %= ~(u64)0;
sth 8,a@l(7) # aD.2487, a.0_1
 # testcase.c:10:   b = (u64)-a > a;
sth 10,b@l(6)# bD.2488, _7
 # testcase.c:13: }
adde 3,3,11  #, c.4_12, _20
blr
...
eg. r11 is unconditionally set to 1, which seems to be wrong.

It is visible at least after combine; before combine, there is:
$ cat testcase.c.260r.ud_dce
...
(insn 45 88 47 6 (parallel [
(set (reg:SI 179 [+4 ])
(minus:SI (const_int 0 [0])
(reg:SI 167 [ _8+4 ])))
(set (reg:SI 76 ca)
(leu:SI (reg:SI 167 [ _8+4 ])
(const_int 0 [0])))
]) "testcase.c":11 104 {subfsi3_carry}
 (expr_list:REG_UNUSED (reg:SI 76 ca)
(nil)))
...
(insn 66 63 67 6 (parallel [
(set (reg:SI 175 [ _20+4 ])
(plus:SI (reg:SI 130 [ d.5_10+-2 ])
(reg:SI 133 [ e.7_14+-2 ])))
(set (reg:SI 76 ca)
(ltu:SI (plus:SI (reg:SI 130 [ d.5_10+-2 ])
(reg:SI 133 [ e.7_14+-2 ]))
(reg:SI 130 [ d.5_10+-2 ])))
]) 78 {addsi3_carry}
 (expr_list:REG_DEAD (reg:SI 133 [ e.7_14+-2 ])
(expr_list:REG_DEAD (reg:SI 130 [ d.5_10+-2 ])
(nil
(insn 67 66 68 6 (parallel [
(set (reg:SI 174 [ _20 ])
(plus:SI (plus:SI (reg:SI 179 [+4 ])
(reg:SI 179 [+4 ]))
(reg:SI 76 ca)))
(clobber (reg:SI 76 ca))
]) 83 {*addsi3_carry_in_internal}
 (expr_list:REG_DEAD (reg:SI 179 [+4 ])
(expr_list:REG_DEAD (reg:SI 76 ca)
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil)
...

And after combine:
$ cat testcase.c.261r.combine
...
Trying 45 -> 67:
Failed to match this instruction:
(parallel [
(set (reg:SI 174 [ _20 ])
(const_int 1 [0x1]))
(clobber (reg:SI 76 ca))
])
Successfully matched this instruction:
(set (reg:SI 174 [ _20 ])
(const_int 1 [0x1]))
allowing combination of insns 45 and 67
original costs 0 + 8 = 0
replacement cost 4
deferring deletion of insn with uid = 45.
deferring deletion of insn with uid = 45.
modifying insn i367: r174:SI=0x1
deferring rescan insn with uid = 67.
...
(note 45 88 47 6 NOTE_INSN_DELETED)
...
(insn 66 63 67 6 (parallel [
(set (reg:SI 175 [ _20+4 ])
(plus:SI (reg:SI 130 [ d.5_10+-2 ])
(reg:SI 133 [ e.7_14+-2 ])))
(set (reg:SI 76 ca)
(ltu:SI (plus:SI (reg:SI 130 [ d.5_10+-2 ])
(reg:SI 133 [ e.7_14+-2 ]))
(reg:SI 130 [ d.5_10+-2 ])))
]) 78 {addsi3_carry}
 (expr_list:REG_DEAD (reg:SI 133 [ e.7_14+-2 ])
(expr_list:REG_DEAD (reg:SI 130 [ d.5_10+-2 ])
(nil
(insn 67 66 68 6 (set (reg:SI 174 [ _20 ])
(const_int 1 [0x1])) 479 {*movsi_internal1}
 (nil))
...

I don't see how 45 and 67 can be combined when 67 is using reg 76 which is set
by insn 66, but I also do not really understand why insn 67 was present in the
first place (it does r179+r179+ca; why? which is (0-r167)+(0-r167)+ca, which is
0-0+0-0+ca, which is "ca" from insn 66, but value of "ca" from insn 45 (=(0==0)
-> =1) is taken?)

[Bug debug/81278] [8 Regression] -fcompare-debug failure (length)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The bisection looks weird, that is the point before which the unreduced
testcase obviously will fail to compile, but that doesn't mean it is the point
where the -fcompare-debug bug has been introduced.

[Bug rtl-optimization/81290] New: [8 Regression] ICE in update_br_prob_note

[asolokha at gmx dot com]

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

Bug ID: 81290
   Summary: [8 Regression] ICE in update_br_prob_note
   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-alpha20170702 snapshot ICEs when compiling the following snippet w/
-O2 -funroll-loops:

int vz;

void
ms (int sw, int cm)
{
  for (vz = 0; vz < 19; ++vz)
{
 fx:
  sw *= 2;
}

  for (;;)
{
  if (sw != 0)
for (;;)
  {
  }
  if (1 / 0 && cm != 0)
goto fx;
}
}

% gcc-8.0.0-alpha20170702 -O2 -funroll-loops -c -w vev3ezql.c   
during RTL pass: loop2_unroll
vev3ezql.c: In function 'ms':
vev3ezql.c:21:1: internal compiler error: Segmentation fault
 }
 ^

(gdb) where
#0  0x0088fc37 in update_br_prob_note(basic_block_def*) ()
#1  0x00bc2cb9 in force_edge_cold(edge_def*, bool) ()
#2  0x00bc2c6e in force_edge_cold(edge_def*, bool) ()
#3  0x00bc2c6e in force_edge_cold(edge_def*, bool) ()
#4  0x00889800 in duplicate_loop_to_header_edge(loop*, edge_def*,
unsigned int, simple_bitmap_def*, edge_def*, vec*,
int) ()
#5  0x00b0a747 in unroll_loops(int) ()
#6  0x00af92a0 in (anonymous
namespace)::pass_rtl_unroll_loops::execute(function*) ()
#7  0x00bac04a in execute_one_pass(opt_pass*) ()
#8  0x00bac8f4 in execute_pass_list_1(opt_pass*) ()
#9  0x00bac915 in execute_pass_list_1(opt_pass*) ()
#10 0x00bac915 in execute_pass_list_1(opt_pass*) ()
#11 0x00bac939 in execute_pass_list(function*, opt_pass*) ()
#12 0x008ac7c0 in cgraph_node::expand() ()
#13 0x008adb91 in symbol_table::compile() [clone .part.54] ()
#14 0x008afecd in symbol_table::finalize_compilation_unit() ()
#15 0x00c87e88 in compile_file() ()
#16 0x0072f5c7 in toplev::main(int, char**) ()
#17 0x0073155b in main ()

Maybe related to the recent REG_BR_PROB fallout?