[Bug fortran/77961] Allocatable components in CLASS-typed coarrays unsupported.

[vehre at gcc dot gnu.org]

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

--- Comment #2 from vehre at gcc dot gnu.org ---
This is no regression, because before the patch mentioned in comment #1, the
construct of having allocatable components in derived types was flagged as
error. Now this construct is supported for derived types at least. For
class-typed coarrays looking up the token fails.

This bug is similar if not a duplicate of pr77785.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 13 15:34:22 2016
New Revision: 241125

URL: https://gcc.gnu.org/viewcvs?rev=241125=gcc=rev
Log:
2016-10-13  Bill Schmidt  

PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Set cost
to infinite when we have a pointer with an increment of -1.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Egad.  Will revert the create_var_decl hunk, thanks for the heads up.

[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug sanitizer/77963] inconsistent (false?) leaks detection.

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany  ---
lsan does not work with ptrace. 
There is https://github.com/google/sanitizers/issues/728 for it. 
We don't have plans to fix it, but the change I sent for review yesterday 
causes lsan to complain loudly instead of producing false reports. 

If you know how to *fix* it, i.e. to make lsan work with ptrace -- please tell.

[Bug c++/77967] [6/7 Regression] ICE in cp_parser_type_name, at cp/parser.c:16419 (trying to add a method to a template alias)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |6.3
Summary|[6/7 Regression] ICE in |[6/7 Regression] ICE in
   |method_on_alias_internal_er |cp_parser_type_name, at
   |ror.cpp:7:1: internal   |cp/parser.c:16419 (trying
   |compiler error: in  |to add a method to a
   |cp_parser_type_name, at |template alias)
   |cp/parser.c:16419 (trying   |
   |to add a method to a|
   |template alias) |

[Bug c++/77967] [6/7 Regression] ICE in method_on_alias_internal_error.cpp:7:1: internal compiler error: in cp_parser_type_name, at cp/parser.c:16419 (trying to add a method to a template alias)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.5.4, 4.6.4, 4.7.4, 4.8.5,
   ||4.9.4, 5.4.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|trying to add a method to a |[6/7 Regression] ICE in
   |template alias triggers an  |method_on_alias_internal_er
   |internal compiler error |ror.cpp:7:1: internal
   ||compiler error: in
   ||cp_parser_type_name, at
   ||cp/parser.c:16419 (trying
   ||to add a method to a
   ||template alias)
  Known to fail||6.2.0

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

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Just saw your request to include the test case.  I will do this but may ask you
to review the dejagnu bits for accuracy for your target, as these don't fire on
arches I regularly build for.

[Bug c++/66170] Bogus warning with -Wsign-conversion when using static_cast on an int

[sir.vestnik at gmail dot com]

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

Sergey Vidyuk  changed:

   What|Removed |Added

 CC||sir.vestnik at gmail dot com

--- Comment #1 from Sergey Vidyuk  ---
I have similair issue with gcc-6.2

[vestnik@VestniK-laptop C++]$ cat fasttest.cpp 
#include 
#include 

void foo(const std::vector vec, const int idx) {
if (idx < 0 || vec.size() <= static_cast(idx))
{
std::cout << "No such index\n";
return;
}
std::cout << "Valid index\n";
}

int main() {
foo({1, 2, 3, 4 ,5}, 6);
return 0;
}
[vestnik@VestniK-laptop C++]$ g++ -std=c++11 -Wsign-conversion -Wall -Werror
fasttest.cpp -o fasttest
fasttest.cpp: In function 'void foo(std::vector, int)':
fasttest.cpp:5:31: error: conversion to 'std::vector::size_type {aka long
unsigned int}' from 'const int' may change the sign of the result
[-Werror=sign-conversion]
  if (idx < 0 || vec.size() <= static_cast(idx))
   ^~~~
cc1plus: all warnings being treated as errors
[vestnik@VestniK-laptop C++]$ g++ --version
g++ (GCC) 6.2.1 20160830
Copyright (C) 2016 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.


It looks like static_cast type was incorrectly treated as const int instead of
size_t. Changing static_cast(idx) to static_cast(idx)
silences diagnostics but such fix looks lihe a strange hack.

[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---


For completeness, compiles without variable "g" :

$ cat z3.f90
module m
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end

$ gfortran-7-20161009 -O0 -c z3.f90



Problem detected with variable named "f" :

$ cat z4.f90
module m
   real f
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end

$ gfortran-7-20161009 -O0 -c z4.f90
z4.f90:4:13:

z4.f90:2:9:

real f
 2
z4.f90:4:13:

function f()
 1
Error: Procedure 'f' at (1) has an explicit interface and must not have
attributes declared at (2)

[Bug fortran/77971] New: ICE at -O0 in make_decl_rtl, at varasm.c:1310

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77971
   Summary: ICE at -O0 in make_decl_rtl, at varasm.c:1310
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE down to at least 4.8, at -O0 :


$ cat z1.f90
module m
   real g
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end


$ gfortran-7-20161009 -O0 -c z1.f90
z1.f90:7:0:

   g = 2

internal compiler error: in make_decl_rtl, at varasm.c:1310
0xf1e0be make_decl_rtl(tree_node*)
../../gcc/varasm.c:1306
0x90dd88 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9755
0x91a8a6 expand_expr
../../gcc/expr.h:279
0x91a8a6 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5252
0x8083e6 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3649
0x8083e6 expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x80a80e expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x810996 execute
../../gcc/cfgexpand.c:6363

[Bug fortran/77972] New: ICE on broken character continuation with -Wall etc.

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77972
   Summary: ICE on broken character continuation with -Wall etc.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICEs down to at least 4.8; gcc-7 in combination with option -Wall,
or one of -pedantic, -std=f95, -std=f2003, -std=f2008, ...
Follow-up of pr71686.


$ cat z1.f90
program p
   character(8) :: z
   z = 'abc&
!end


$ cat z2.f90
program p
   character(8) :: z = 'abc&
!end


$ gfortran-7-20161009 -Wall z1.f90
0x68903e gfc_format_decoder
../../gcc/fortran/error.c:935
0x13c9bff pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:660
0x13bd020 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:945
0x688d4f gfc_warning
../../gcc/fortran/error.c:792
0x6899e6 gfc_warning(int, char const*, ...)
../../gcc/fortran/error.c:823
0x6fecb8 gfc_next_char_literal(gfc_instring)
../../gcc/fortran/scanner.c:1424
0x6de738 next_string_char
../../gcc/fortran/primary.c:903
0x6e06a7 match_string_constant
../../gcc/fortran/primary.c:1102
0x6e06a7 gfc_match_literal_constant(gfc_expr**, int)
../../gcc/fortran/primary.c:1455
0x6bc01f match_primary
../../gcc/fortran/matchexp.c:149
0x6bc01f match_level_1
../../gcc/fortran/matchexp.c:211
0x6bc01f match_mult_operand
../../gcc/fortran/matchexp.c:267
0x6bc308 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6bc59c match_level_2
../../gcc/fortran/matchexp.c:480
0x6bc6f2 match_level_3
../../gcc/fortran/matchexp.c:551
0x6bc804 match_level_4
../../gcc/fortran/matchexp.c:599
0x6bc804 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6bc9c2 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6bcab2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6bcba2 match_level_5
../../gcc/fortran/matchexp.c:811

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[potswa at mac dot com]

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

--- Comment #3 from David Krauss  ---
… Woops, that f is the function parameter, not the target. So it's not a
conflicting requirement, but it could be a template for fixing the the copy
constructor constraint.

[Bug fortran/77973] New: ICE in scan_omp_1_op, at omp-low.c:3841

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77973
   Summary: ICE in scan_omp_1_op, at omp-low.c:3841
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With version 7 and option -fopenmp :


$ cat z1.f90
subroutine s(x)
   integer :: x(:)
   integer :: i
!$omp parallel
!$omp target teams distribute
   do i = 1, 2
  x(i) = 1
   end do
!$omp end parallel
end


$ gfortran-7-20161009 -fopenmp -c z1.f90
z1.f90:5:0:

 !$omp target teams distribute

internal compiler error: in scan_omp_1_op, at omp-low.c:3841
0xafa012 scan_omp_1_op
../../gcc/omp-low.c:3841
0xee7462 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11684
0xb11b68 scan_omp_op
../../gcc/omp-low.c:394
0xb11b68 scan_sharing_clauses
../../gcc/omp-low.c:2054
0xb20d08 scan_omp_target
../../gcc/omp-low.c:3192
0xb20d08 scan_omp_1_stmt
../../gcc/omp-low.c:3983
0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xaf5c99 scan_omp
../../gcc/omp-low.c:4026
0xb21038 scan_omp_parallel
../../gcc/omp-low.c:2694
0xb21038 scan_omp_1_stmt
../../gcc/omp-low.c:3950
0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xaf5c99 scan_omp
../../gcc/omp-low.c:4026

[Bug c/77970] New: inconsistent and unhelpful -Wformat warning for %lc

[msebor at gcc dot gnu.org]

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

Bug ID: 77970
   Summary: inconsistent and unhelpful -Wformat warning for %lc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following snippet compiles with no warnings on popular 64-bit targets
including powerpc64-*-linux, sparc-sun-solaris2.10, and x86_64-*-linux. 
However, on a number of 32-bit targets the same code causes GCC to issue a
warning about one or the other call pedantically complaining about either the
literal zero not having the expected type of wint_t (e.g., where wint_t is an
alias for long) even though the two have the same size and sign, or about the
L'a' argument not having the wint_t type for the same reason (the type of L'a'
is wchar_t).  (This is analogous to warnings issued for %li with an int
argument, or for %i with a long argument, on ILP32.)

  printf ("%lc", 0);
  printf ("%lc", L'a');

Unlike the warnings for ordinary integer directives which is issued
consistently, issuing the warning for %lc inconsistently, based on the
underlying type of wchar_t and wint_t, and only on uncommon targets and not on
mainstream targets where most code is developed is unhelpful for portability
and only serves to cause code to fail to compile when ported (see for example
the thread around https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00993.html for
the effort it took to clean up these warnings in the builtin-sprintf*.c tests).

Issuing the warning when both the sign and the size of the argument are the
same as those expected is useless entirely since objects of the two types are
indistinguishable.  (The warning is not issued when the types only differ in
signedness such as int and unsigned int unless the -Wformat-signedness option
is explicitly specified.)

To be useful for portability, the warning should be issued consistently on all
targets, especially those where most development is done (LP64 targets such
powerpc64-*-linux and x86_64-*-linux.  The warning is also only useful if there
exists a target where wint_t and wchar_t (for the L'a' case) or int (for the
int argument case) are different sizes.  If there is no such target (I don't
know of one and a survey of GCC config files didn't reveal one either) the
warning isn't useful even if wint_t and wchar_t differ in sign because sign
mismatches are handled separately under the -Wformat-signedness option.

As a data point, Clang stopped issuing this warning in 2011 in response to the
following Clang bug:

  https://llvm.org/bugs/show_bug.cgi?id=7981

GCC should do the same and either suppress the warning altogether or issue it
only with -Wpedantic.

Test case:

$ (set -x && cd ~/tmp && cat a.c && for t in i386-rehat-linux
sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux
hppa-unknown-linux-gnu; do /build/sysroot/$t/bin/$t-gcc -S -Wall -o/dev/null
a.c; done)
+ cd /home/msebor/tmp
+ cat a.c
typedef __WCHAR_TYPE__ wchar_t;

void f (void)
{
  __builtin_printf ("%lc", 0);
  __builtin_printf ("%lc", L'a');
}
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/i386-rehat-linux/bin/i386-rehat-linux-gcc -S -Wall -o/dev/null
a.c
a.c: In function 'f':
a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'long int' [-Wformat=]
   __builtin_printf ("%lc", L'a');
  ~~^
  %ld
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/sparc-sun-solaris2.12/bin/sparc-sun-solaris2.12-gcc -S -Wall
-o/dev/null a.c
a.c: In function 'f':
a.c:5:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'int' [-Wformat=]
   __builtin_printf ("%lc", 0);
  ~~^
  %c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/x86_64-unknown-solaris2.10/bin/x86_64-unknown-solaris2.10-gcc
-S -Wall -o/dev/null a.c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/bfin-uclinux/bin/bfin-uclinux-gcc -S -Wall -o/dev/null a.c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/m68k-linux/bin/m68k-linux-gcc -S -Wall -o/dev/null a.c
a.c: In function 'f':
a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'long int' [-Wformat=]
   __builtin_printf ("%lc", L'a');
  ~~^
  %ld
+ for t in i386-rehat-linux 

[Bug c/77970] inconsistent and unhelpful -Wformat warning for %lc

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I think the correct logic would be something like: if the argument is for 
a standard typedef, and the format doesn't correspond exactly to that 
typedef (or one differing only by sign, e.g. allow %ju for an intmax_t 
unless -Wformat-signedness), warn (with an option to disable it) even if 
they match (or match up to sign) on this particular system.  Likewise if 
the format is for a standard typedef but the argument isn't.  Hard to 
implement for various reasons (including  format macros - 
glibc's definitions of those for intmax_t match the underlying type rather 
than using "j", for example), and would have false positives in various 
cases, but more warnings rather than less seems right here and would make 
warnings more consistent between targets.

The option to disable warnings for mismatched typedefs could then have 
different stringencies for whether it disables even int/long mismatches, 
or only cases that already wouldn't warn but for the use of standard 
typedefs.

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[potswa at mac dot com]

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

--- Comment #2 from David Krauss  ---
The converting constructor requirements also say more explicitly,

  shall not throw exceptions when f is a function pointer
  or a reference_wrapper for some T.

Probably the copy constructor should be worded similarly.

In any case, the exception guarantee isn't affected, as
sizeof(reference_wrapper) == sizeof(T*).

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |tree-optimization
   Target Milestone|--- |6.3
Summary|[6 / 7 Regression] Missed   |[6/7 Regression] Missed
   |optimization for some small |optimization for some small
   |constants   |constants

[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Nice.  Will you commit the patch?  Thanks.

[Bug go/77977] New: stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[msebor at gcc dot gnu.org]

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

Bug ID: 77977
   Summary: stage3 bootstrap error in libgo on x86_64: cannot stat
'stubs.o'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: msebor at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

When configured with
--enable-languages=all,ada,c,c++,fortran,go,lto,objc,obj-c++ today's top of
trunk (at r241131) fails to bootstrap on x86_64-linux with the error below. 
There is no other error earlier that I can see (this was a serial build, i.e.,
with -j1).

make[8]: Entering directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
/usr/bin/mkdir -p runtime/internal; files=`echo
/src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go
/src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go | sed -e 's/[^
]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile
/home/msebor/build/gcc-trunk/./gcc/gccgo -B/home/msebor/build/gcc-trunk/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops
-fno-split-stack -O2 -g  -m32 -I . -c -fgo-pkgpath=`echo
runtime/internal/atomic.lo | sed -e 's/.lo$//' -e 's/-go$//'`
-fgo-compiling-runtime -o runtime/internal/atomic.lo $files
libtool: compile:  /home/msebor/build/gcc-trunk/./gcc/gccgo
-B/home/msebor/build/gcc-trunk/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops
-fno-split-stack -O2 -g -m32 -I . -c -fgo-pkgpath=runtime/internal/atomic
-fgo-compiling-runtime /src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go
/src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go 
libtool: compile: mv -f "stubs.o" "runtime/internal/.libs/atomic.o"
mv: cannot stat 'stubs.o': No such file or directory
Makefile:4942: recipe for target 'runtime/internal/atomic.lo' failed
make[8]: *** [runtime/internal/atomic.lo] Error 1
make[8]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:3039: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:1407: recipe for target 'all' failed
make[6]: *** [all] Error 2
make[6]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:5537: recipe for target 'multi-do' failed
make[5]: *** [multi-do] Error 1
make[5]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:2305: recipe for target 'all-multi' failed
make[4]: *** [all-multi] Error 2
make[4]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:3039: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:1407: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:25608: recipe for target 'all-target-libgo' failed
make[1]: *** [all-target-libgo] Error 2
make[1]: Leaving directory '/home/msebor/build/gcc-trunk'
Makefile:29771: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2
make: Leaving directory '/home/msebor/build/gcc-trunk'

[Bug bootstrap/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This should fix it, but is the fallthru really intended?

--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -4548,6 +4548,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc)
}
}
}
+  /* FALLTHRU */

 case RELOC_TLSGD:
   return "@TLSGD";

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All compilers I have (4.5.0+) ICE.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
That is change:
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];

static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
{
 struct builtin_fw *b_fw;

 for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
--- CUT --

to (there might already be a macro in linux which does the asm like below
already):

extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];

static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
{
 struct builtin_fw *b_fw;
 struct builtin_fw *b_fw_start = __start_builtin_fw, b_fw_end =
__end_builtin_fw;
 asm("":"+r"(b_fw_start));
 asm("":"+r"(b_fw_end));


 for (b_fw = b_fw_start; b_fw != b_fw_end; b_fw++) {

[Bug bootstrap/77974] New: m68k bootstrap failure due to -Werror=implicit-fallthrough

[mikpelinux at gmail dot com]

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

Bug ID: 77974
   Summary: m68k bootstrap failure due to
-Werror=implicit-fallthrough
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gcc-7-20161009 on m68k-linux fails with:

/mnt/scratch/objdir7/./prev-gcc/xg++ -B/mnt/scratch/objdir7/./prev-gcc/
-B/mnt/scratch/install7/m68k-unknown-linux-gnu/bin/ -nostdinc++
-B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu
 -I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include 
-I/mnt/scratch/gcc-7-20161009/libstdc++-v3/libsupc++
-L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -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 -Werror  
-DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-7-20161009/gcc
-I/mnt/scratch/gcc-7-20161009/gcc/.
-I/mnt/scratch/gcc-7-20161009/gcc/../include
-I/mnt/scratch/gcc-7-20161009/gcc/../libcpp/include 
-I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber
-I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber/dpd -I../libdecnumber
-I/mnt/scratch/gcc-7-20161009/gcc/../libbacktrace   -o m68k.o -MT m68k.o -MMD
-MP -MF ./.deps/m68k.TPo /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c: In function 'const char*
m68k_get_reloc_decoration(m68k_reloc)':
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4537:4: error: this
statement may fall through [-Werror=implicit-fallthrough]
if (TARGET_68020)
^~
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4551:5: note: here
 case RELOC_TLSGD:
 ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [m68k.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir7/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir7'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir7'
make: *** [bootstrap] Error 2

I believe gcc-7-20161002 had the same issue.  gcc-7-20160918 bootstrapped fine.

Configuration options:
/mnt/scratch/gcc-7-20161009/configure --prefix=/mnt/scratch/install7
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++
--disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto
--disable-multilib --disable-libgomp

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4, 5.4.0
   Keywords||ice-on-valid-code, openmp
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org,
   ||mjambor at suse dot cz
 Ever confirmed|0   |1
Summary|ICE in scan_omp_1_op, at|[6/7 Regression] ICE in
   |omp-low.c:3841  |scan_omp_1_op, at
   ||omp-low.c:3841
  Known to fail||6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r232549 (HSA branch merge).

[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

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

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

--- Comment #2 from Andreas Schwab  ---
I think this is intented:

diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index a104193c23..0eb1528079 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -4546,6 +4546,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc)
  return "";
}
}
+ return "";
}

 case RELOC_TLSGD:

[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from Ian Lance Taylor  ---
Jakub, did you figure anything out about this?

[Bug c/77975] New: [6 / 7 Regression] Missed optimization for some small constants

[quiath at go2 dot pl]

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

Bug ID: 77975
   Summary: [6 / 7 Regression] Missed optimization for some small
constants
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: quiath at go2 dot pl
  Target Milestone: ---

When compiling with GCC 6.1, 6.2 or 7.0 the code generated with -O1 -O2 and -O3
does not fold depending on some small constants e.g. 3 used in the body of the
function. GCC 5.4 was better.

Example code:

// missed optimization, compiled to a loop
unsigned int f3() {
  unsigned int a = 3;
  while (a) {
a >>= 1;
  }
  return a; 
}

// expected optimization, compiled to a single instruction
unsigned int f7() {
  unsigned int a = 7;
  while (a) {
a >>= 1;
  }
  return a; 
}

x86-64 assembly from gcc 7 (identical for 6) according to godbolt.org
Note that f7 is folded while f3 is not.

f3():
mov eax, 3
.L2:
shr eax
jne .L2
mov eax, 0
ret
f7():
mov eax, 0
ret

See also example here: https://godbolt.org/g/ircKQ0

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to PeteVine from comment #7)
> BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by
> the presence of `-flto` among environment C(XX)FLAGS, as otherwise it
> definitely makes sense for configure to always sanitize those flags.

With --with-build-config=bootstrap-lto you will not need -flto in C(XX)FLAGS. 
Really -flto in C(XX)FLAGS is the cause of the problem you are running into.

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-13
 Ever confirmed|0   |1

--- Comment #9 from Andrew Pinski  ---
.

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Created attachment 39806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39806=edit
Patch to remove special-case for reference_wrapper.

This patch makes it work as desired. We need to fix 3-4 test cases too which
explicitly check for the current behaviour (it's by design, matching
Boost.Function).

I submitted a defect report, with a proposed change to make the copy + move
constructors say "if f’s target is a callable
object passed viaspecialization of reference_wrapper
or a function pointer."

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Thu Oct 13 18:25:15 2016
New Revision: 241135

URL: https://gcc.gnu.org/viewcvs?rev=241135=gcc=rev
Log:
Create the *logue in the same order as before (PR77962)

PR77962 shows Go failing on 32-bit x86.  This happens because the i386
port requires the split stack prologue to be created before the normal
prologue, and my previous patch changed it to be the other way around.

This patch changes it back.  Things will be exactly as before for targets
that do not do shrink-wrapping for separate components.  For targets
that *do* support it, all three prologue/epilogue creation functions
will now be called twice for functions that have anything wrapped
separately (instead of just the prologue created twice).


PR bootstrap/77962
* function.c (thread_prologue_and_epilogue_insns): Call all
make_*logue_seq in the same order as traditional.  Call them
all a second time if shrink_wrapped-separate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c

[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.6.0.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 13 19:50:41 2016
New Revision: 241139

URL: https://gcc.gnu.org/viewcvs?rev=241139=gcc=rev
Log:
2016-10-13  Bill Schmidt  

PR tree-optimization/77937
* gcc.dg/torture/pr77937-1.c: New.
* gcc.dg/torture/pr77937-2.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77937-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr77937-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Yeah.

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

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
*** Bug 77977 has been marked as a duplicate of this bug. ***

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

--- Comment #10 from PeteVine  ---
Yeah, I began suspecting as much yesterday so I left it running overnight on
ARM. It managed to get to stage comparison but failed due to many differences.

But not before I'd got impatient in the morning and did a start/stop switching
the linker back to gold, probably my fault :)

[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Oct 13 22:26:36 2016
New Revision: 241143

URL: https://gcc.gnu.org/viewcvs?rev=241143=gcc=rev
Log:
PR c++/71912 - [6/7 regression] flexible array in struct in union rejected

gcc/cp/ChangeLog:

PR c++/71912
* class.c (struct flexmems_t):  Add members.
(find_flexarrays): Add arguments.  Correct handling of anonymous
structs.
(diagnose_flexarrays): Adjust to issue warnings in addition to errors.
(check_flexarrays): Add argument.
(diagnose_invalid_flexarray): New functions.

gcc/testsuite/ChangeLog:

PR c++/71912
* g++.dg/ext/flexary4.C: Adjust.
* g++.dg/ext/flexary5.C: Same.
* g++.dg/ext/flexary9.C: Same.
* g++.dg/ext/flexary19.C: New test.
* g++.dg/ext/flexary18.C: New test.
* g++.dg/torture/pr64312.C: Add a dg-error directive to an ill-formed
regression test.
* g++.dg/compat/struct-layout-1_generate.c (subfield): Add argument.
Avoid generating a flexible array member in an array.


Added:
trunk/gcc/testsuite/g++.dg/ext/flexary18.C
trunk/gcc/testsuite/g++.dg/ext/flexary19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
trunk/gcc/testsuite/g++.dg/ext/flexary4.C
trunk/gcc/testsuite/g++.dg/ext/flexary5.C
trunk/gcc/testsuite/g++.dg/ext/flexary9.C
trunk/gcc/testsuite/g++.dg/torture/pr64312.C

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Trippelsdorf  ---
Is subtracting undefined, too?

-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   for (b_fw = __start_builtin_fw;  __end_builtin_fw - b_fw; b_fw++) {

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #9)
> Is subtracting undefined, too?
Yes.  Comparing two unrelated arrays or subtracting them is undefined.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #12 from John Paul Adrian Glaubitz  ---
Hi!

We just recently started seeing this issue in Debian, however, only for the
powerpc-linux-gnuspe targets, i.e. e500v2 (Debian architecture: powerpcspe)
[1]:

g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qtextboundaryfinder.o
tools/qtextboundaryfinder.cpp
tools/qtextboundaryfinder.cpp: In member function 'bool
QTextBoundaryFinder::isAtBoundary() const':
tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
validate_condition_mode, at config/rs6000/rs6000.c:17958
 }
 ^
0x109c5aab validate_condition_mode(rtx_code, machine_mode)
../../src/gcc/config/rs6000/rs6000.c:17957
0x10b438df branch_comparison_operator(rtx_def*, machine_mode)
../../src/gcc/config/rs6000/predicates.md:1125
0x10b43b13 branch_positive_comparison_operator(rtx_def*, machine_mode)
../../src/gcc/config/rs6000/predicates.md:1204
0x10b5bad7 recog_72
../../src/gcc/config/rs6000/altivec.md:643
0x10bb7f3b recog_for_combine_1
../../src/gcc/combine.c:10945
0x10bbd4ff recog_for_combine
../../src/gcc/combine.c:11142
0x10bcb0c7 try_combine
../../src/gcc/combine.c:3503
0x10bcec7f combine_instructions
../../src/gcc/combine.c:1475
0x10bcec7f rest_of_handle_combine
../../src/gcc/combine.c:14356
0x10bcec7f execute
../../src/gcc/combine.c:14399
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qtimeline.o tools/qtimeline.cpp
g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qvector.o tools/qvector.cpp
Preprocessed source stored into /tmp/ccg5tpbm.out file, please attach this to
your bugreport.

I'm attaching the pre-processed source in case that might be useful. Odd that
despite this bug being so old, it just surfaced on Debian powerpcspe recently.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=qt4-x11=powerpcspe=4%3A4.8.7%2Bdfsg-9=1476330034

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
You don't need it for both.
  struct builtin_fw *b_fw = __start_builtin_fw;
  asm ("" : "+r" (b_fw));
  for (; b_fw != __end_builtin_fw; b_fw++) {
should be enough.  And indeed, without that it is undefined behavior.

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
related to/duplicate of pr68040?

[Bug fortran/68040] [5/6/7 Regression] Internal compiler error: Error reporting routines re-entered.

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
related to/duplicate of pr77972?

[Bug c++/77976] `auto x = type{…}` initialization syntax rejects `explicit` user-defined conversion

[tomaszkam at gmail dot com]

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

Tomasz Kamiński  changed:

   What|Removed |Added

 CC||tomaszkam at gmail dot com

--- Comment #1 from Tomasz Kamiński  ---
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999

[Bug debug/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #10 from Andrew Pinski  ---
Fixed over 2 years ago but forgot to close.

[Bug c++/71912] [6 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7 regression] flexible   |[6 regression] flexible
   |array in struct in union|array in struct in union
   |rejected|rejected
  Known to fail|7.0 |

--- Comment #8 from Martin Sebor  ---
Fixed on trunk in r241143.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
Created attachment 39807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39807=edit
Pre-processed source for tools/qtextboundaryfinder.cpp

[Bug tree-optimization/64567] missed optimization: redundant test before clearing bit(s)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Andrew Pinski  ---
(In reply to Rasmus Villemoes from comment #2)
> (In reply to Andreas Schwab from comment #1)
> > This transformation is incorrect if the lvalue may be pointing to a
> > read-only object.
> 
> True. And one may also incur an extra cache penalty if the cache line
> containing foo was already held shared but not exclusive.

Or incorrect due to C11/C++11 memory model.  Anyways it is correct for scalar
auto variables and this should be transformed at the gimple level if not
already.

[Bug sanitizer/59962] --with-build-config=bootstrap-asan doesn't work

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Does this work now?

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Beware of pr30617 in the test in comment 4! Otherwise the patch seems to work
as expected.

Thanks,

Dominique

> Le 13 oct. 2016 à 16:14, pault at gcc dot gnu.org  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
> 
> --- Comment #5 from Paul Thomas  ---
> Created attachment 39805
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit
> Fix for the PR
> 
> The attached fixes the testcase in the comment and more besides. I think that
> some of the fix is unnecessary. I will do final adjustments once I am back at
> base.
> 
> It bootstraps and regtests on FC23/x87_64
> 
> Paul
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #7)
> You don't need it for both.
>   struct builtin_fw *b_fw = __start_builtin_fw;
>   asm ("" : "+r" (b_fw));
>   for (; b_fw != __end_builtin_fw; b_fw++) {
> should be enough.  And indeed, without that it is undefined behavior.

You might want to do end only then instead of the start.  Because in theory GCC
could say it is always false as &__end_builtin_fw[-1] is undefined behavior too
so GCC say if the initial value was not __end_builtin_fw[0] go into an infinite
loop.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #5)
> Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for
> __start_builtin_fw and __end_builtin_fw

Shouldn't we recommend "+g" instead of "+r"?

(In reply to Markus Trippelsdorf from comment #9)
> Is subtracting undefined, too?
> 
> -   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
> +   for (b_fw = __start_builtin_fw;  __end_builtin_fw - b_fw; b_fw++) {

See bug 77813.

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
Testing fix now.

[Bug middle-end/77981] New: gcc 7 miscompiles kernel

[jirislaby at gmail dot com]

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

Bug ID: 77981
   Summary: gcc 7 miscompiles kernel
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jirislaby at gmail dot com
  Target Milestone: ---

I am using
gcc-7 (SUSE Linux) 7.0.0 20161007 (experimental)
from martin liska's
https://build.opensuse.org/project/show/home:marxin:syzkaller

And the kernel does not boot. It is looping and page faulting inside 
get_builtin_firmware:
{
#ifdef CONFIG_FW_LOADER
struct builtin_fw *b_fw;

for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
if (!strcmp(name, b_fw->name)) {
cd->size = b_fw->size;
cd->data = b_fw->data;
return true;
}
}
#endif
return false;
}

But
$ nm vmlinux-4.8.1-* |grep __.*_builtin_fw
81ac2158 R __end_builtin_fw
81ac2158 R __start_builtin_fw


And sure, the test b_fw != __end_builtin_fw seems to be removed from the code:
81049d20 :
81049d20:   e8 fb bb 68 00  callq  816d5920
<__fentry__>
81049d25:   41 54   push   %r12
81049d27:   49 89 fcmov%rdi,%r12
81049d2a:   55  push   %rbp
81049d2b:   48 89 f5mov%rsi,%rbp
81049d2e:   53  push   %rbx
81049d2f:   48 c7 c3 58 21 ac 81mov$0x81ac2158,%rbx
81049d36:   eb 04   jmp81049d3c

81049d38:   48 83 c3 18 add$0x18,%rbx
81049d3c:   48 8b 33mov(%rbx),%rsi
81049d3f:   48 89 efmov%rbp,%rdi
81049d42:   e8 d9 3d 36 00  callq  813adb20

81049d47:   85 c0   test   %eax,%eax
81049d49:   75 ed   jne81049d38

81049d4b:   48 8b 43 10 mov0x10(%rbx),%rax
81049d4f:   49 89 44 24 08  mov%rax,0x8(%r12)
81049d54:   48 8b 43 08 mov0x8(%rbx),%rax
81049d58:   5b  pop%rbx
81049d59:   5d  pop%rbp
81049d5a:   49 89 04 24 mov%rax,(%r12)
81049d5e:   b8 01 00 00 00  mov$0x1,%eax
81049d63:   41 5c   pop%r12
81049d65:   c3  retq   
81049d66:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
81049d6d:   00 00 00 



gcc-6 produces this:
81ac2230 R __end_builtin_fw
81ac2230 R __start_builtin_fw

and (chopped)

81049e39:   48 c7 c3 30 22 ac 81mov$0x81ac2230,%rbx
81049e40:   48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e47:   74 3f   je 81049e88


The 'if' ^

81049e49:   48 89 f5mov%rsi,%rbp
81049e4c:   49 89 fcmov%rdi,%r12
81049e4f:   eb 0d   jmp81049e5e

81049e51:   48 83 c3 18 add$0x18,%rbx
81049e55:   48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e5c:   74 2a   je 81049e88

81049e5e:   48 8b 33mov(%rbx),%rsi
81049e61:   48 89 efmov%rbp,%rdi
81049e64:   e8 f7 1e 36 00  callq  813abd60

81049e69:   85 c0   test   %eax,%eax
81049e6b:   75 e4   jne81049e51

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jirislaby at gmail dot com

--- Comment #12 from Andrew Pinski  ---
*** Bug 77981 has been marked as a duplicate of this bug. ***

[Bug middle-end/77981] gcc 7 miscompiles kernel

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Bug in the kernel, see dup bug 77964.

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

[Bug tree-optimization/77980] New: Regression in GCC-7.0.0's optimizer.

[ishiura-compiler at ml dot kwansei.ac.jp]

/7.0.0/lto-wrapper
target: x86_64-pc-linux-gnu
configure woth: ../gcc/configure --prefix=/home/kota/opt/gcc
--program-suffix=-7.0 --disable-multilib --enable-languages=c
thred model: posix
gcc version 7.0.0 20161013 (experimental) (GCC)


using built-in specs.
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

 */

[Bug fortran/77978] New: stop codes misinterpreted in both f2003 and f2008

[john.harper at vuw dot ac.nz]

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

Bug ID: 77978
   Summary: stop codes misinterpreted in both f2003 and f2008
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

Stop codes changed from the f2003 standard to f2008. The first of these 2 
programs has a stop code valid in f2003 but not in f2008, the second has a stop
code valid in f2008 but not in f2003. But gfortran 6.1.1 happily compiles and
runs both programs with either -std=f2003 or -f2008.

Here are the program listings, gfortran -v result, and the results of compiling
with the -std options that should not have worked:

cayley[~/Jfh] % cat stopnumber.f90
! stop666 (no space before 666) is valid f95 or f2003 but bad f2008
  implicit none
  stop666
end program
cayley[~/Jfh] % cat stopnumber2.f90
! stop expression is valid f2008 but bad f2003
  implicit none 
  stop merge(667,668,.true.)
end program 
cayley[~/Jfh] % gfortran -v
Using built-in specs.   
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper  
Target: x86_64-pc-linux-gnu 
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release  
Thread model: posix 
gcc version 6.1.1 20160602 (GCC)
cayley[~/Jfh] % gfortran -std=f2008 stopnumber.f90
cayley[~/Jfh] % ./a.out 
STOP 666
cayley[~/Jfh] % gfortran -std=f2003 stopnumber2.f90 
cayley[~/Jfh] % ./a.out
STOP 667
cayley[~/Jfh] %

[Bug tree-optimization/77979] New: ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 77979
   Summary: ICE on valid code at -Os and above on
x86_64-linux-gnu: Segmentation fault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161013 (experimental) [trunk revision 241136] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-6.2 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: Segmentation fault
 void fn1 ()
  ^~~
0xbe954f crash_signal
../../gcc-source-trunk/gcc/toplev.c:338
0xe7b040 tree_check
../../gcc-source-trunk/gcc/tree.h:3286
0xe7b040 get_value_range
../../gcc-source-trunk/gcc/tree-vrp.c:650
0xe7f51c get_vr_for_comparison
../../gcc-source-trunk/gcc/tree-vrp.c:7134
0xe7f51c compare_names
../../gcc-source-trunk/gcc/tree-vrp.c:7299
0xe7f51c vrp_evaluate_conditional_warnv_with_ops
../../gcc-source-trunk/gcc/tree-vrp.c:7389
0xe7f93b vrp_evaluate_conditional
../../gcc-source-trunk/gcc/tree-vrp.c:7423
0xe90f36 simplify_stmt_for_jump_threading
../../gcc-source-trunk/gcc/tree-vrp.c:10349
0xdf169e simplify_control_stmt_condition
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:453
0xdf20e8 thread_through_normal_block
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1088
0xdf3402 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*))
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1189
0xe88843 identify_jump_threads
../../gcc-source-trunk/gcc/tree-vrp.c:10536
0xe88843 vrp_finalize
../../gcc-source-trunk/gcc/tree-vrp.c:10624
0xe88843 execute_vrp
../../gcc-source-trunk/gcc/tree-vrp.c:11016
0xe88843 execute
../../gcc-source-trunk/gcc/tree-vrp.c:11102
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


---


int a, b, c, d, e, f;

void fn1 ()
{ 
  int g = b;
  a = -~(d || a) << 4 || e;
  b = c || g ^ a;
  if (f < g)
d = e;
}

[Bug driver/36312] should refuse to overwrite input file with output file

[riccardo at cs dot wisc.edu]

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

Riccardo Mutschlechner  changed:

   What|Removed |Added

 CC||riccardo at cs dot wisc.edu

--- Comment #21 from Riccardo Mutschlechner  ---
Not sure if this is the best place to start, but here goes. I've noticed
another similar issue.

Let's say you've compiled a binary, `test`, from a source `test.c`. If you then
flip the arguments to gcc by mistake, `gcc -o test.c test` rather than `gcc -o
test test.c`, you will overwrite the source file by trying to compile the
binary, thus losing it permanently without some other backup.

Can I add some functionality that double checks against compiling *into* a
source file extension? 

Is this cruft, or something that would actually be used - and if so, what is a
good way to go about doing this? 

Would love to do it ASAP.

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Andrew Pinski  ---
How does this work for everyone else?  Can you attach the preprocessed source?

[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Oct 13 08:51:21 2016
New Revision: 241088

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

2016-09-01  Andre Vehreschild  

PR fortran/72832
* trans-expr.c (gfc_copy_class_to_class): Add generation of
runtime array bounds check.
* trans-intrinsic.c (gfc_conv_intrinsic_size): Add a crutch to
get the descriptor of a function returning a class object.
* trans-stmt.c (gfc_trans_allocate): Use the array spec on the
array to allocate instead of the array spec from source=.

gcc/testsuite/ChangeLog:

2016-09-01  Andre Vehreschild  

PR fortran/72832
* gfortran.dg/allocate_with_source_22.f03: New test.
* gfortran.dg/allocate_with_source_23.f03: New test.  Expected to
fail.



Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_22.f03
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_23.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
Waiting one week before backporting to gcc-6.

[Bug sanitizer/77963] New: inconsistent (false?) leaks detection.

[pawel_sikora at zoho dot com]

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

Bug ID: 77963
   Summary: inconsistent (false?) leaks detection.
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel_sikora at zoho dot com
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
  Target Milestone: ---

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

hi,

i've observed that running application under gdb/ltrace/strace reports strange
memory leaks, e.g:

% make
g++ -Wall -g2 s.cpp -fsanitize=address -Og -shared -fPIC -o s.so -lboost_thread
g++ -Wall -g2 m.cpp -fsanitize=address -Og -o m ./s.so -ldl

[pawels@pawels]~/ssd/leaks% ./m; echo $?
0

[pawels@pawels]~/ssd/leaks% ltrace ./m  
__asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0x7f833ad36540) 
  = 0
__libc_start_main([ "./m" ] 
__asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0
__asan_version_mismatch_check_v6(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0
__asan_register_globals(0x601080, 2, 0x7ffddcdce898, 0) = 0
dlopen("./s.so", 1) = 0x7f833cbabb18
dlsym(0x7f833cbabb18, "foo") = 0x7f833b7e4d20
dlclose(0x7f833cbabb18) = 0
__asan_unregister_globals(0x601080, 2, 0, 1) = 0x80078140

=
==4777==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 440 byte(s) in 1 object(s) allocated from:
#0 0x7f833baaeea0 in operator new(unsigned long)
(/lib64/libasan.so.3+0xc7ea0)
#1 0x7f833a33a83d in boost::detail::make_external_thread_data()
(/lib64/libboost_thread.so.1.60.0+0x1283d)

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f833baaeea0 in operator new(unsigned long)
(/lib64/libasan.so.3+0xc7ea0)
#1 0x7f833a33a9e9 in boost::detail::make_external_thread_data()
(/lib64/libboost_thread.so.1.60.0+0x129e9)

SUMMARY: AddressSanitizer: 464 byte(s) leaked in 2 allocation(s).
+++ exited (status 1) +++

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
expand_assignment is called with
REALPART_EXPR 
as to, where C.3418 is CONST_DECL.
Of course one can't store into a CONST_DECL.
If I compare this to how we compile:
program p
   interface
  subroutine s(x)
 real :: x
  end
   end interface
   call s(1.0)
end
subroutine s(x)
   real :: x
   x = x + 1
end
then the difference is that
to_rtx = expand_expr (to, NULL_RTX, VOIDmode, EXPAND_WRITE);
in that case returns
(mem:SF (reg/f:DI 90) [1 C.3418+0 S4 A32])
and not the CONST_DOUBLE.  I'll have a look.

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 CC||ian at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug target/77957] [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 13 08:29:03 2016
New Revision: 241087

URL: https://gcc.gnu.org/viewcvs?rev=241087=gcc=rev
Log:
PR target/77957
* hooks.h (hook_tree_void_null): Declare.
* hooks.c (hook_tree_void_null): New function.
* langhooks.c (lhd_return_null_tree_v): Remove.
* langhooks-def.h (lhd_return_null_tree_v): Remove.
* cfgexpand.c (stack_protect_prologue): If guard_decl is NULL,
set y to const0_rtx.
* function.c (stack_protect_epilogue): Likewise.
* config/tilepro/tilepro.c (TARGET_STACK_PROTECT_GUARD): Redefine
if TARGET_THREAD_SSP_OFFSET is defined.
* config/s390/s390.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/sparc/sparc.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/tilegx/tilegx.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/rs6000/rs6000.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/i386/i386.c (TARGET_STACK_PROTECT_GUARD): Likewise.
(ix86_stack_protect_guard): New function.
c/
* c-objc-common.h (LANG_HOOKS_GETDECLS): Use hook_tree_void_null
instead of lhd_return_null_tree_v.
ada/
* gcc-interface/misc.c (LANG_HOOKS_GETDECLS): Use hook_tree_void_null
instead of lhd_return_null_tree_v.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-objc-common.h
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/s390/s390.c
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/tilegx/tilegx.c
trunk/gcc/config/tilepro/tilepro.c
trunk/gcc/function.c
trunk/gcc/hooks.c
trunk/gcc/hooks.h
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c

[Bug tree-optimization/77956] [7 Regression] ICE in insert_debug_temp_for_var_def with -g and -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Ok, seems it got fixed by the fix for PR77920.  Without that I see (with
checking):

inout.c:3987:1: error: use operand missing for stmt
direction_70
direction_88 = 1 - direction_70;
inout.c:3987:1: internal compiler error: verify_ssa failed
0x1128e4f verify_ssa(bool, bool)
/space/rguenther/src/svn/early-lto-debug/gcc/tree-ssa.c:1158
0xd748e3 execute_function_todo

and

inout.c:3987:1: internal compiler error: Segmentation fault
0xe932c6 crash_signal
/space/rguenther/src/svn/early-lto-debug/gcc/toplev.c:337
0x11268f6 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
/space/rguenther/src/svn/early-lto-debug/gcc/tree-ssa.c:316
0x1126fc7 insert_debug_temps_for_defs(gimple_stmt_iterator*)
/space/rguenther/src/svn/early-lto-debug/gcc/tree-ssa.c:504
0xb1b706 gsi_remove(gimple_stmt_iterator*, bool)
/space/rguenther/src/svn/early-lto-debug/gcc/gimple-iterator.c:567

when I add -fno-checking.

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

[Bug bootstrap/77962] New: [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[jakub at gcc dot gnu.org]

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

Bug ID: 77962
   Summary: [7 Regression] Bootstrap failure on x86_64-linux
starting with r241063
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I'm getting bootstrap (and non-bootstrap) x86_64-linux and i686-linux failures
while building 32-bit libgo.  The problem seems to be 2 ICEs during configure,
and -fPIC, -o and -fsplit-stack options aren't detected as supported because of
that.  The lack of -o one breaks the build.

Short testcase in x86_64-linux ../configure --disable-bootstrap
--enable-languages=c,c++,go --enable-checking=yes,rtl,extra configured
compiler:

echo 'package main; func main() { }' > conftest.go
./go1 -quiet conftest.go -m32 -O2 -fPIC
conftest.go: In function ‘main.main’:
conftest.go:1:15: internal compiler error: in ix86_expand_epilogue, at
config/i386/i386.c:14213
 package main; func main() { }
   ^
0xfc4f26 ix86_expand_epilogue(int)
../../gcc/config/i386/i386.c:14212
0x11da49f gen_epilogue()
../../gcc/config/i386/i386.md:12654
0xf97da8 target_gen_epilogue
../../gcc/config/i386/i386.md:12165
0x9617dd make_epilogue_seq
../../gcc/function.c:5842
0x9617dd thread_prologue_and_epilogue_insns()
../../gcc/function.c:5940
0x962032 rest_of_handle_thread_prologue_and_epilogue
../../gcc/function.c:6386
0x962032 execute
../../gcc/function.c:6428
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

14212 gcc_assert (!m->fs.sp_valid
14213 || m->fs.sp_offset == frame.stack_pointer_offset);
(gdb) p m->fs.sp_valid
$5 = 1
(gdb) p m->fs.sp_offset
$6 = 12
(gdb) p frame.stack_pointer_offset
$7 = 4

[Bug tree-optimization/77956] [7 Regression] ICE in insert_debug_temp_for_var_def with -g and -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Mine.

[Bug middle-end/77920] [7 Regression] 186.crafty doesn't compile

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
*** Bug 77956 has been marked as a duplicate of this bug. ***

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #6)
> Maybe turning on RTL checking will find the problem is located.

Indeed, the rtl-checking enabled build says:

internal compiler error: RTL check: expected code 'mem', have 'const_double' in
get_mem_attrs, at rtl.h:3300
0xa8b327 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
../../git/gcc/gcc/rtl.c:811
0x8345d8 get_mem_attrs
../../git/gcc/gcc/rtl.h:3300
0x83038b get_mem_attrs
../../git/gcc/gcc/expr.c:6950
0x83038b store_field
../../git/gcc/gcc/expr.c:6778
0x82d2e3 expand_assignment(tree_node*, tree_node*, bool)
../../git/gcc/gcc/expr.c:5167
0x7253bd expand_gimple_stmt_1
../../git/gcc/gcc/cfgexpand.c:3649
0x7253bd expand_gimple_stmt
../../git/gcc/gcc/cfgexpand.c:3745

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Created attachment 39801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39801=edit
preliminary patch

This patch fixes the i386 problem (or, works around it).  On 32-bit
i386 the split prologue has to be created before the regular prologue
as far as I see.

Testing now if that works on powerpc; if not, we can always also
disallow separate shrink-wrapping functions with split stack (maybe
not a bad idea anyway).

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 39802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39802=edit
gcc7-pr77959.patch

Untested fix.

[Bug c++/68391] -Wsuggest-override does not work on Item 12 of Effective Modern C++

[a.volkov at rusbitech dot ru]

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

Alexander Volkov  changed:

   What|Removed |Added

 CC||a.volkov at rusbitech dot ru

--- Comment #1 from Alexander Volkov  ---
-Wsuggest-override should not produce warnings in this case, because none of
members of Derived override virtual functions of Base.

-Woverloaded-virtual has another meaning: "With this option, the compiler warns
when you define a function with the same name as a virtual function, but with a
type signature that does not match any declarations from the base class."

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Author: vries
Date: Thu Oct 13 11:40:33 2016
New Revision: 241103

URL: https://gcc.gnu.org/viewcvs?rev=241103=gcc=rev
Log:
Revert backport "Remove RECORD_TYPE special-casing in
std_canonical_va_list_type"

2016-10-13  Tom de Vries  

revert:
2016-10-11  Tom de Vries  

backport from trunk:
2016-10-11  Tom de Vries  

PR middle-end/77558
* builtins.c (std_canonical_va_list_type): Remove RECORD_TYPE
special-casing.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/builtins.c

[Bug tree-optimization/77943] [5/6/7 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Thu Oct 13 10:06:35 2016
New Revision: 241090

URL: https://gcc.gnu.org/viewcvs?rev=241090=gcc=rev
Log:
Do not merge BBs with a different EH landing pads (PR

PR tree-optimization/77943
* g++.dg/tree-ssa/pr77943.C: New test.
PR tree-optimization/77943
* tree-ssa-tail-merge.c (merge_stmts_p): Do not merge BBs with
a different EH landing pads.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr77943.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-tail-merge.c

[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

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

[Bug c++/77431] warn for having the same code in if-else branches

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Marek Polacek  ---
Coalescing.

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

[Bug tree-optimization/77943] [5/6 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6 Regression]
   |Optimization incorrectly|Optimization incorrectly
   |commons noexcept calls with |commons noexcept calls with
   |non-noexcept calls  |non-noexcept calls

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

[Bug c++/65856] -Wsuggest-override shall not report a warning on final method

[a.volkov at rusbitech dot ru]

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

Alexander Volkov  changed:

   What|Removed |Added

 CC||a.volkov at rusbitech dot ru

--- Comment #11 from Alexander Volkov  ---
Please, reopen.

Of course, it makes sense to suggest adding override in the following case:
struct A {
  virtual void f();
};
struct B : A {
  virtual void f() final override;
};

B::f() is specified as virtual, so if we remove A::f(), then B::f() will not
become a new virtual, but we'll get a compile error instead thanks to
'override' keyword.

But it is redundant in the following case:
struct A {
  virtual void f();
};
struct B : A {
  void f() final;
};

It is absolutely clear that B::f() overrides A::f(). If we remove A::f() or
change it's signature, then we'll get an error. There is no need to add
'override' here.

[Bug c++/65856] -Wsuggest-override shall not report a warning on final method

[a.volkov at rusbitech dot ru]

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

--- Comment #12 from Alexander Volkov  ---
Sorry, it should be
struct B : A {
  virtual void f() final;
};
in the first example.

[Bug c/77946] -Wimplicit-fallthrough=1 ICE: tree check: expected tree that contains ‘decl with visibility’ structure, have ‘label_decl’

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 13 10:42:36 2016
New Revision: 241094

URL: https://gcc.gnu.org/viewcvs?rev=241094=gcc=rev
Log:
PR c/77946
* tree.h (FALLTHROUGH_LABEL_P): Use private_flag instead of
public_flag.
* varasm.c (default_binds_local_p_3): Formatting fix.

* c-c++-common/Wimplicit-fallthrough-34.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-34.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h
trunk/gcc/varasm.c

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
Started with r235622:

commit 73447cc5d17178b0a756be48133e55fdc7574c13
Author: rguenth 
Date:   Fri Apr 29 08:36:49 2016 +

2016-04-29  Richard Biener  

PR tree-optimization/13962
PR tree-optimization/65686
* tree-ssa-alias.h (ptrs_compare_unequal): Declare.
* tree-ssa-alias.c (ptrs_compare_unequal): New function
using PTA to compare pointers.
* match.pd: Add pattern for pointer equality compare simplification
using ptrs_compare_unequal

good:
callkmem_cache_alloc
testq   %rax, %rax  
movq%rax, %r12  
je  .L28
movq$__start_builtin_fw, %r13   
cmpq$__end_builtin_fw, %r13 
jne .L86
jmp .L30
.L32:   
addq$24, %r13   
cmpq$__end_builtin_fw, %r13 
je  .L30
.L86:   
movq0(%r13), %rsi   
movq%rbx, %rdi  
callstrcmp  

--

bad:
callkmem_cache_alloc
testq   %rax, %rax  
movq%rax, %r15  
movq(%rsp), %r8 
je  .L6 
movq$__start_builtin_fw, %rbx   
jmp .L7 
.L20:   
addq$24, %rbx   
.L7:
movq(%rbx), %rsi
movq%rbp, %rdi  
callstrcmp

[Bug c++/77967] New: trying to add a method to a template alias triggers an internal compiler error

[kaelig.chatel at lixoft dot com]

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

Bug ID: 77967
   Summary: trying to add a method to a template alias triggers an
internal compiler error
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaelig.chatel at lixoft dot com
  Target Milestone: ---

Created attachment 39804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39804=edit
preprocessed source code raising the error

--
Fixing the code will remove the problem. And the output still gives the
location of the error, if no real diagnosis as usual for an invalid code.

So, I think this is a trivial bug in its consequencies for users.
--


The problem is that an "internal compiler error" is raised for the attached
code:

- first, a template alias is defined

- then, an erroneous code tries to define a method for this template alias as
if it was a template class  (in the first use case, it was previously a class,
and I forgot to clean this part of my code, raising the "internal compiler
error").


-- command 

gcc -v -save-temps -std=c++11 method_on_alias_internal_error.cpp

- command outputs ---

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE method_on_alias_internal_error.cpp
-mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess
-fstack-protector-strong -Wformat -Wformat-security -o
method_on_alias_internal_error.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed
method_on_alias_internal_error.ii -quiet -dumpbase
method_on_alias_internal_error.cpp -mtune=generic -march=x86-64 -auxbase
method_on_alias_internal_error -std=c++11 -version -fstack-protector-strong
-Wformat -Wformat-security -o method_on_alias_internal_error.s
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 15157934e8203caff79287fd8f2d2843
method_on_alias_internal_error.cpp:7:1: internal compiler error: in
cp_parser_type_name, at cp/parser.c:15248
 bar::bar(const T& cr)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

--- Comment #7 from PeteVine  ---
BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by
the presence of `-flto` among environment C(XX)FLAGS, as otherwise it
definitely makes sense for configure to always sanitize those flags.

[Bug c/77964] New: [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

Bug ID: 77964
   Summary: [7 Regression] Linux kernel firmware loader
miscompiled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

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

A Linux kernel build with gcc trunk crashes early during boot.
It happens during loading of builtin firmware.

RIP points to strcmp() in fw_get_builtin_firmware() on a bogus address.

markus@x4 linux % scripts/faddr2line ./vmlinux _request_firmware+0xa8
_request_firmware+0xa8/0xff:
fw_get_builtin_firmware at drivers/base/firmware_class.c:55
 (inlined by) _request_firmware_prepare at drivers/base/firmware_class.c:1066
 (inlined by) _request_firmware at drivers/base/firmware_class.c:1149


drivers/base/firmware_class.c:
  49 static bool fw_get_builtin_firmware(struct firmware *fw, const char *name, 
  50 void *buf, size_t size)
  51 {  
  52 struct builtin_fw *b_fw;   
  53
  54 for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)
{   
  55 if (strcmp(name, b_fw->name) == 0) {   
  56 fw->size = b_fw->size; 
  57 fw->data = b_fw->data; 
  58
  59 if (buf && fw->size <= size)   
  60 memcpy(buf, fw->data, fw->size);   
  61 return true;   
  62 }  
  63 }  
  64
  65 return false;  
  66 }

I have attached the firmware_class.i file.
The kernel crashes for -O1 -O2 and -Os. Strangely -O3 is fine.

Haven't looked deeper yet, but maybe someone sees what is going on?

[Bug c/77964] [7 Regression] Linux kernel firmware loader miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to David Krauss from comment #0)
> This is not conforming.

Hmm, I think that's debatable.

[func.wrap.func.con] says:

  Throws: shall not throw exceptions if f’s target is a callable object
  passed via reference_wrapper or a function pointer.


By your interpretation, it is impossible for the target to be a callable object
passed by reference_wrapper, because the target will be the reference_wrapper
itself. This wording seems to imply that when the function(F) constructor is
passed a reference_wrapper the target should be the wrapped T.

However, the function(F) constructor doesn't say anything like that, it says
"*this targets a copy of f".

So I'm tempted to say this is a defect in the standard. The copy constructor is
trying to be helpful, and say it won't throw under certain conditions, but it
does so confusingly.

[Bug c/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 linux % gcc --save-temps -Wp,-MD,drivers/base/.firmware_class.o.d
-nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -march=k8 -mno-red-zone
-mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables
-fno-delete-null-pointer-checks -Wno-maybe-uninitialized -Wno-frame-address -O2
--param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector
-Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer
-fno-var-tracking-assignments -g -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types
-DCC_HAVE_ASM_GOTO -DKBUILD_BASENAME='"firmware_class"'
-DKBUILD_MODNAME='"firmware_class"' -c -o drivers/base/firmware_class.o
drivers/base/firmware_class.c

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can you bisect? Suspect changes might be the shrink wrapping changes from last
night - r241063 and r241059-r241061.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #2)
> Can you bisect? Suspect changes might be the shrink wrapping changes from
> last night - r241063 and r241059-r241061.

It is much older issue. Even gcc from 20160928 fails.

And bisecting is annoying, because unfortunately the failure only happens
on bare metal (booting under qemu is fine). So I have to reboot all the time.

I will try to bisect by looking at the assembly output.

[Bug c/77946] -Wimplicit-fallthrough=1 ICE: tree check: expected tree that contains ‘decl with visibility’ structure, have ‘label_decl’

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 13 12:15:38 2016
New Revision: 241108

URL: https://gcc.gnu.org/viewcvs?rev=241108=gcc=rev
Log:
2016-10-13  Richard Biener  

PR middle-end/77826
* genmatch.c (struct capture): Add value_match member.
(commutate): Preserve value_match.
(lower_opt_convert): Likewise.
(lower_cond): Likewise.
(replace_id): Likewise.
(struct dt_operand): Add value_match member.
(decision_tree::cmp_node): Compare it.
(decision_tree::insert_operand): Honor it when finding and
when appending a DT_MATCH.
(dt_operand::gen_match_op): Generate a type check after
operand_equal_p if ! value_match for both GENERIC and GIMPLE.
(parser::get_internal_capture_id): New helper.
(parser::finish_match_operand): New function lowering @@.
(parser::parse_capture): Parse @@ as value-match.
(parser::parse_expr): Use get_internal_capture_id.
(parser::parse_simplify): Call finish_match_operand.
(walk_captures): New helper.
* match.pd (X - (X / Y) * Y -> X % Y): Use value-matching instead
of operand_equal_p.
((X /[ex] A) * A -> X): Likewise.
((X | Y) ^ X -> Y & ~ X): Handle constants properly by using
convert[12] and value-matching.
((A | B) & (A | C) ->  A | (B & C)): Likewise.
((X | Y) | Y -> X | Y): Likewise.
((X ^ Y) ^ Y -> X): Likewise.
(A - (A & B) -> ~B & A): Likewise.
((T)(P + A) - (T)P -> (T) A): Likewise.
((T)P - (T)(P + A) -> -(T) A): Likewise.
((T)(P + A) - (T)(P + B) -> (T)A - (T)B): Likewise.
* doc/match-and-simplify.texi: Amend capture section.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/match-and-simplify.texi
trunk/gcc/genmatch.c
trunk/gcc/match.pd

[Bug c/77965] New: -Wduplicated-cond should find duplicated condition / identical expressions of form "a || a" or "a && a"

[burnus at gcc dot gnu.org]

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

Bug ID: 77965
   Summary: -Wduplicated-cond should find duplicated condition /
identical expressions of form "a || a" or "a && a"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

First, I wonder whether "-Wduplicated-cond" should be enabled by -Wextra (or
even -Wall).

Secondly, it only warns for "if (a) ... else if (a) ...". However, it would be
also useful to warn for  "(a || a)" and "(a && a)" as such code is easily
written by copy'n'paste.

[Possibly, instead of -Wduplicated-cond it should be used with
-Wtautological-compare?]

By comparison, cppcheck finds this issue and outputs:
  (style) Same expression on both sides of '||'.


Example:
#include 

int foo(int x) {
  assert (x == 5 || x == 5);
  return (x == 5 || x == 5) ? 1 : 0;
}

[Bug c/77966] New: Corrupt function with -fsanitize-coverage=trace-pc

[jpoimboe at redhat dot com]

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

Bug ID: 77966
   Summary: Corrupt function with -fsanitize-coverage=trace-pc
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpoimboe at redhat dot com
  Target Milestone: ---

In the Linux kernel, we found another case (other than bug 70646) where a
couple of functions are getting corrupted.  Arnd Bergmann reduced it down to a
simple test case, and I've reduced it slightly further:

$ cat test.c
typedef int spinlock_t;
extern unsigned int ioread32(void *);

struct vnic_wq_ctrl {
unsigned int error_status;
};

struct vnic_wq {
struct vnic_wq_ctrl *ctrl;
} mempool_t;

struct snic {
unsigned int wq_count;
__attribute__ ((__aligned__)) struct vnic_wq wq[1];
spinlock_t wq_lock[1];
};

unsigned int snic_log_q_error_err_status;

void snic_log_q_error(struct snic *snic)
{
unsigned int i;
for (i = 0; i < snic->wq_count; i++)
snic_log_q_error_err_status =
ioread32(>wq[i].ctrl->error_status);
}

$ gcc -O2 -fno-reorder-blocks -fsanitize-coverage=trace-pc -c test.c -o test.o
$ objdump -dr test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   53  push   %rbx
   1:   48 89 fbmov%rdi,%rbx
   4:   e8 00 00 00 00  callq  9 
5: R_X86_64_PC32__sanitizer_cov_trace_pc-0x4
   9:   8b 03   mov(%rbx),%eax
   b:   85 c0   test   %eax,%eax
   d:   75 09   jne18 
   f:   5b  pop%rbx
  10:   e9 00 00 00 00  jmpq   15 
11: R_X86_64_PC32   __sanitizer_cov_trace_pc-0x4
  15:   0f 1f 00nopl   (%rax)
  18:   e8 00 00 00 00  callq  1d 
19: R_X86_64_PC32   __sanitizer_cov_trace_pc-0x4
  1d:   48 8b 7b 10 mov0x10(%rbx),%rdi
  21:   e8 00 00 00 00  callq  26 
22: R_X86_64_PC32   ioread32-0x4
  26:   83 3b 01cmpl   $0x1,(%rbx)
  29:   89 05 00 00 00 00   mov%eax,0x0(%rip)# 2f

2b: R_X86_64_PC32   snic_log_q_error_err_status-0x4
  2f:   76 de   jbef 
  31:   e8 00 00 00 00  callq  36 
32: R_X86_64_PC32   __sanitizer_cov_trace_pc-0x4

Notice how the function ends unexpectedly after the last call to
__sanitizer_cov_trace_pc().

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Andrew Pinski  ---
Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for
__start_builtin_fw and __end_builtin_fw

[Bug c/77966] Corrupt function with -fsanitize-coverage=trace-pc

[vda.linux at googlemail dot com]

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

Denis Vlasenko  changed:

   What|Removed |Added

 CC||vda.linux at googlemail dot com

--- Comment #1 from Denis Vlasenko  ---
Simplified a bit:
- spinlock_t is not essential
- mempool_t is not essential
- snic_log_q_error_err_status variable is not necessary
- __attribute__ ((__aligned__)) can be dropped too
- struct vnic_wq can be folded
OTOH:
- struct vnic_wq_ctrl wrapping of int variable is necessary
- wq_lock[1] unused member is necessary (makes gcc "know for sure" that wq[1]
is 1-element array)
- each of -O2 -fno-reorder-blocks -fsanitize-coverage=trace-pc are necessary


extern unsigned int ioread32(void *);
struct vnic_wq_ctrl {
unsigned int error_status;
};
struct snic {
unsigned int wq_count;
struct vnic_wq_ctrl *wq[1];
int wq_lock[1];
};
void snic_log_q_error(struct snic *snic)
{
unsigned int i;
for (i = 0; i < snic->wq_count; i++)
ioread32(>wq[i]->error_status);
}


:
   0:   53  push   %rbx
   1:   48 89 fbmov%rdi,%rbx
   4:   e8 00 00 00 00  callq  __sanitizer_cov_trace_pc
   9:   8b 03   mov(%rbx),%eax
   b:   85 c0   test   %eax,%eax  # snic->wq_count==0?
   d:   75 09   jne18
   f:   5b  pop%rbx # yes, 0
  10:   e9 00 00 00 00  jmpq   __sanitizer_cov_trace_pc #tail call
  15:   0f 1f 00nopl   (%rax)

  18:   e8 00 00 00 00  callq  __sanitizer_cov_trace_pc
  1d:   48 8b 7b 08 mov0x8(%rbx),%rdi
  21:   e8 00 00 00 00  callq  ioread32
  26:   83 3b 01cmpl   $0x1,(%rbx) # snic->wq_count<=1?
  29:   76 e4   jbef
  2b:   e8 00 00 00 00  callq  __sanitizer_cov_trace_pc


Looks like gcc thinks that the loop can execute only zero or one time
(or else we run off wq[1]). So when it iterated once:

  21:   e8 00 00 00 00  callq  ioread32

it checks that snic->wq_count <= 1

  26:   83 3b 01cmpl   $0x1,(%rbx)
  29:   76 e4   jbef

and if not, we are in "impossible" land and just stop codegen.
-fsanitize-coverage=trace-pc generator twitches one last time:

  2b:   e8 00 00 00 00  callq  __sanitizer_cov_trace_pc

[Bug c/77966] Corrupt function with -fsanitize-coverage=trace-pc

[vda.linux at googlemail dot com]

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

--- Comment #2 from Denis Vlasenko  ---
Without -fsanitize-coverage=trace-pc, the second, redundant check
"snic->wq_count<=1?" is not generated. This eliminates the hanging "impossible"
code path:

:
   0:   8b 07   mov(%rdi),%eax
   2:   85 c0   test   %eax,%eax
   4:   74 09   je f
   6:   48 8b 7f 08 mov0x8(%rdi),%rdi
   a:   e9 00 00 00 00  jmpq   ioread32
   f:   c3  retq