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

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
It still happens, but on another unit this time:

markus@x4 ffmpeg % cat h264dsp.i
extern int fn2(int);
extern int fn3(int);
int a, b, c;
void fn1(long p1) {
  char *d;
  for (;; d += p1) {
d[0] = fn2(1 >> a);
fn3(0);
fn3(c >> a);
d[1] = fn3(d[1] * b + c >> a);
d[4] = fn3(d[4] * b + c >> a);
d[5] = fn3(d[5] * b + c >> a);
  }
}

markus@x4 ffmpeg % gcc -march=amdfam10 -O3 -c -S h264dsp.i
h264dsp.i: In function ‘fn1’:
h264dsp.i:4:6: internal compiler error: in replace_one_candidate, at
gimple-ssa-strength-reduction.c:3369
 void fn1(long p1) {
  ^~~

Simply building ffmpeg with -march=amdfam10 finds these bugs.

Please consider reverting your original patch until you come up with solution.

[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 #9 from Bill Schmidt  ---
Keeping this open until the fix has some burn-in time, planning to backport to
GCC 6 and 5.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #4)
> Looks like middle-end problem to me:

Maybe turning on RTL checking will find the problem is located.

[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 #8 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 13 01:08:20 2016
New Revision: 241082

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

PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Use
POINTER_TYPE_P on the candidate type to determine whether
candidates in this chain require pointer arithmetic.


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

[Bug c++/77731] Parameter pack expansion doesn't work when used to define argument list

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Clang accepts the code.

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
Another test:

struct T 
{ 
int x = 0; 
bool y = 0; 
constexpr T() {}
};

int main()
{
constexpr T t = (T{} = T{});
}

prog.cc: In function 'int main()':
prog.cc:10:31: error: accessing value of '' through a 'char [5]'
glvalue in a constant expression
 constexpr T t = (T{} = T{});
   ^

That looks rather bad.

[Bug c++/77927] unary right fold fails to compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Ville Voutilainen  ---
Clang accepts the code.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Marc Mutz from comment #12)
> Is replacing a matching comment with __attribute__(fallthrough)) so
> complicated as to make this a wontfix?

It is not really possible.
__attribute__((fallthrough)) has precise rules on where it can appear, while /*
FALLTHRU */ comments, being comments, can appear anywhere.  Especially with
-Wimplicit-fallthrough=1 when all comments are considered fallthru comments...

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[marc.mutz at kdab dot com]

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

--- Comment #12 from Marc Mutz  ---
Is replacing a matching comment with __attribute__(fallthrough)) so complicated
as to make this a wontfix?

[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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-*, alphaev68-*-*

--- Comment #5 from Uroš Bizjak  ---
Also fails for alphaev68-linux-gnu:

internal compiler error: Segmentation fault
0x120948993 crash_signal
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:337
0x120d359b0 alpha_legitimate_address_p
/space/homedirs/uros/gcc-svn/trunk/gcc/config/alpha/alpha.c:857
0x1209439eb default_addr_space_legitimate_address_p(machine_mode, rtx_def*,
bool, unsigned char)
/space/homedirs/uros/gcc-svn/trunk/gcc/targhooks.c:1344
0x12087f613 memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
/space/homedirs/uros/gcc-svn/trunk/gcc/recog.c:1336
0x120500963 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
/space/homedirs/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
0x120552b07 store_field
/space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:6938
0x12054de3b expand_assignment(tree_node*, tree_node*, bool)
/space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:5167
0x1203f251b expand_gimple_stmt_1
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649
0x1203f251b expand_gimple_stmt
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3745
0x1203f908b expand_gimple_basic_block
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:5752
0x1203fc2db execute
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:6363

[Bug c++/55004] [meta-bug] constexpr issues

[myriachan at gmail dot com]

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

Bug 67333 Summary: [C++11][constexpr] constexpr functions incorrectly prohibit 
taking references to volatile types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67333

   What|Removed |Added

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

[Bug c++/67333] [C++11][constexpr] constexpr functions incorrectly prohibit taking references to volatile types

[myriachan at gmail dot com]

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

Melissa  changed:

   What|Removed |Added

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

--- Comment #3 from Melissa  ---
Seems to have been fixed sometime between 6.0 and 6.1.

[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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #4 from Uroš Bizjak  ---
Looks like middle-end problem to me:

Program received signal SIGSEGV, Segmentation fault.
0x00ef2ddb in ix86_decompose_address (addr=0x41,
out=out@entry=0x7fffd490) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954
14954 if (TARGET_64BIT && GET_MODE (addr) == DImode)
(gdb) p addr
$10 = (rtx) 0x41

(gdb) bt
#0  0x00ef2ddb in ix86_decompose_address (addr=0x41,
out=out@entry=0x7fffd490) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954
#1  0x00ef4ddc in ix86_legitimate_address_p (addr=,
strict=) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:15668
#2  0x00b1f4af in memory_address_addr_space_p (mode=mode@entry=SFmode,
addr=addr@entry=0x41, as=)
at /home/uros/gcc-svn/trunk/gcc/recog.c:1336
#3  0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168,
mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, 
adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0,
size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
#4  0x008b3d1c in store_field (target=0x7fffefdec168, bitsize=32,
bitpos=0, bitregion_start=, bitregion_end=,
mode=SFmode, 
exp=0x7fffeffd8c48, alias_set=2, nontemporal=false, reverse=false) at
/home/uros/gcc-svn/trunk/gcc/expr.c:6938
#5  0x008afd2f in expand_assignment (to=to@entry=0x7fffeffc4a60,
from=from@entry=0x7fffeffd8c48, nontemporal=)
at /home/uros/gcc-svn/trunk/gcc/expr.c:5167
#6  0x0079c6ee in expand_gimple_stmt_1 (stmt=0x7fffeffc88c0) at
/home/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649

(gdb) f 3
#3  0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168,
mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, 
adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0,
size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
2221  && (!validate || memory_address_addr_space_p (mode, addr,
(gdb) list
2216size = defattrs->size;
2217
2218  /* If there are no changes, just return the original memory
reference.  */
2219  if (mode == GET_MODE (memref) && !offset
2220  && (size == 0 || (attrs.size_known_p && attrs.size == size))
2221  && (!validate || memory_address_addr_space_p (mode, addr,
attrs.addrspace)))
2223return memref;
2224
2225  /* ??? Prefer to create garbage instead of creating shared rtl.
(gdb) p addr
$8 = (rtx) 0x41

Corrupted RTX is passed from adjust_address_1.

[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 #7 from Bill Schmidt  ---
OK, I can reproduce now, and understand the problem better.  This patch fixes
the problem.  I'll regstrap it and get it committed shortly.

Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 240946)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2816,8 +2816,7 @@ analyze_increments (slsr_cand_t first_dep, machine
   else if (incr == 0
   || incr == 1
   || (incr == -1
-  && (gimple_assign_rhs_code (first_dep->cand_stmt)
-  != POINTER_PLUS_EXPR)))
+  && !POINTER_TYPE_P (first_dep->cand_type)))
incr_vec[i].cost = COST_NEUTRAL;

   /* FORNOW: If we need to add an initializer, give up if a cast from

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The ICE has been fixed between revisions r213007 (2014-07-24, ICE) and r213805
(2014-08-11, compiles).

[Bug c/38295] Support pointer difference as constant in static initializer

[fw at gcc dot gnu.org]

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

--- Comment #11 from Florian Weimer  ---
Created attachment 39799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39799=edit
label.c

(In reply to Andrew Pinski from comment #6)
> Not always since they could be in different sections via -ffunction-sections
> or the user put them into different sections.  The layout of the sections is
> not known until link time.

For label differences, the difference is only known at assembly time, not
compile time.  So you can really evaluate the constant in GCC, either.  You can
even get assembler warnings and incorrect data, as the attached code shows.  It
produces an assembler warning for me:

/tmp/ccAMdJhn.s: Assembler messages:
/tmp/ccAMdJhn.s:1237: Warning: value 0x1680 truncated to 0x80

(The reproducer is slightly convoluted to work around bug 77951.)

There might also be targets where label differences are only known at link
time, too.

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
No ICE with version 5.4.0 too.

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[jason at gcc dot gnu.org]

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

Bug 77742 Summary: Warning about placement new for over-aligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77742

   What|Removed |Added

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

[Bug c++/77742] Warning about placement new for over-aligned type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |7.0

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

[Bug fortran/77961] [7 Regression] ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/77958] printf format checking -vs- variadic template functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||jakub at redhat dot com,
   ||marxin at gcc dot gnu.org
  Known to work||4.5.4, 4.6.4, 4.7.4, 5.4.0
   Target Milestone|--- |6.3
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, on trunk started to appear again with r231499.
Current back-trace is the same as the one in 4.9.x.

[Bug fortran/77960] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug fortran/77961] [7 Regression] ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE: verify_type failed, at |[7 Regression] ICE:
   |tree.c:14085 ;  |verify_type failed, at
   |gen_type_die_with_usage, at |tree.c:14085 ;
   |dwarf2out.c:22942   |gen_type_die_with_usage, at
   ||dwarf2out.c:22942
 Ever confirmed|0   |1

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

[Bug c++/77958] printf format checking -vs- variadic template functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
It would certainly be nice if it did work, though I think it doesn't simply
because attribute format isn't designed to be used with variadic funtion
templates.  I don't have a sense how involved extending it to those would be
but let me confirm this as an enhancement request.

Btw., it's nice to see that because the -Wfornat-length warning runs later than
-Wformat it handles this case even without the attribute.  Moving -Wformat to a
later stage would have the same effect, in addition to letting it detect more
problems (e.g., when the format string isn't a literal).

$ cat z.C && gcc -S -O2  -Wall -Wextra -Wpedantic z.C
char d [4];

template
static inline void
whatever (char *d, const char *fmt, Args&&... args)
{
  __builtin_sprintf(d, fmt, args...);
}

void qq()
{
  whatever(d, "hi %s", "bob");
}

z.C: In function ‘void qq()’:
z.C:10:6: warning: ‘%s’ directive writing 3 bytes into a region of size 1
[-Wformat-length=]
 void qq()
  ^~
z.C:7:3: note: format output 7 bytes into a destination of size 4
   __builtin_sprintf(d, fmt, args...);
   ^

[Bug c++/77742] Warning about placement new for over-aligned type

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Oct 12 18:04:51 2016
New Revision: 241073

URL: https://gcc.gnu.org/viewcvs?rev=241073=gcc=rev
Log:
PR c++/77742 - -Waligned-new and placement new.
* init.c (build_new_1): Don't -Waligned-new about placement new.
(malloc_alignment): New.  Consider MALLOC_ABI_ALIGNMENT.
* decl.c (cxx_init_decl_processing): New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/aligned-new7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c

[Bug fortran/77961] New: ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

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

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

Bug ID: 77961
   Summary: ICE: verify_type failed, at tree.c:14085 ;
gen_type_die_with_usage, at dwarf2out.c:22942
   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 observed with test version gfortran-7-20160925 and newer.
No ICE with gfortran-7-20160918 and older.
Needs option -g :


$ cat z1.f90
program p
   type t
   end type
   type t2
  type(t), allocatable :: c(:)
   end type
   type(t2) :: x[*]
   allocate (x%c(2), source=t())
contains
   subroutine s(x)
  class(*) :: x[*]
   end
end


$ gfortran-7-20161009 -g -fcoarray=single -c z1.f90
$ gfortran-7-20161009 -g -fcoarray=lib -c z1.f90
z1.f90:12:0:

end

Error: TYPE_CANONICAL is not compatible
  constant 384>
unit size  constant 48>
align 64 symtab 1200810336 alias set -1 canonical type 0x2b1647957540
fields 
asm_written public unsigned DI
size 
unit size 
align 64 symtab 1200808976 alias set -1 canonical type
0x2b16477852a0
pointer_to_this >
unsigned DI file z1.f90 line 10 col 0 size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
DI file z1.f90 line 10 col 0 size 
unit size 
align 64 offset_align 128 offset  bit
offset  context  chain >>
pointer_to_this  chain >
  constant 448>
unit size  constant 56>
align 64 symtab 0 alias set -1 canonical type 0x2b1647957540
fields 
unsigned restrict DI
size 
unit size 
align 64 symtab 1200988480 alias set -1 canonical type
0x2b164778b930>
unsigned DI file z1.f90 line 12 col 0 size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
DI file z1.f90 line 12 col 0 size 
unit size 
align 64 offset_align 128 offset  bit
offset  context  chain >>
pointer_to_this  chain >
z1.f90:12:0: internal compiler error: verify_type failed
0xee98e2 verify_type(tree_node const*)
../../gcc/tree.c:14085
0x8c25ec gen_type_die_with_usage
../../gcc/dwarf2out.c:22942
0x8c3c36 gen_type_die
../../gcc/dwarf2out.c:23140
0x8b7ed0 gen_decl_die
../../gcc/dwarf2out.c:23794
0x8cb015 gen_member_die
../../gcc/dwarf2out.c:22611
0x8cb015 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:22717
0x8cb015 gen_tagged_type_die
../../gcc/dwarf2out.c:22920
0x8c2c5c gen_type_die_with_usage
../../gcc/dwarf2out.c:23085
0x8c3c36 gen_type_die
../../gcc/dwarf2out.c:23140
0x8b83a9 gen_decl_die
../../gcc/dwarf2out.c:23739
0x8b8d86 dwarf2out_decl
../../gcc/dwarf2out.c:24213
0x8d3b84 dwarf2out_type_decl
../../gcc/dwarf2out.c:23921
0xb5a0bf rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:333
0x7b3b03 gfc_finish_type(tree_node*)
../../gcc/fortran/trans-types.c:2247
0x7b74d4 gfc_get_derived_type(gfc_symbol*, bool)
../../gcc/fortran/trans-types.c:2711
0x7b7c9c gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1110
0x7b5cc3 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x74eb24 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1640
0x752767 generate_local_decl
../../gcc/fortran/trans-decl.c:5313
0x70dfcb do_traverse_symtree
../../gcc/fortran/symbol.c:3962

[Bug fortran/77960] New: ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966

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

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

Bug ID: 77960
   Summary: ICE in gfc_conv_ss_startstride, at
fortran/trans-array.c:3966
   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 invalid code, down to at least 4.8 :


$ cat z1.f90
program p
   procedure(g), pointer :: f
   f => g
   read(99) f
contains
   function g() result(z)
  integer :: z(2)
  z = 1
   end
end


$ gfortran-7-20161009 z1.f90
z1.f90:4:0:

read(99) f

internal compiler error: in gfc_conv_ss_startstride, at
fortran/trans-array.c:3966
0x730c76 gfc_conv_ss_startstride(gfc_loopinfo*)
../../gcc/fortran/trans-array.c:3966
0x790184 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2520
0x723ff7 trans_code
../../gcc/fortran/trans.c:1918
0x78ce50 build_dt
../../gcc/fortran/trans-io.c:1962
0x724027 trans_code
../../gcc/fortran/trans.c:1886
0x7538b8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6257
0x6de1a0 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6de1a0 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720e22 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77959] New: ICE in ix86_decompose_address, at i386/i386.c:14954

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

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

Bug ID: 77959
   Summary: ICE in ix86_decompose_address, at i386/i386.c:14954
   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: ---

Invalid code with ICE down to at least 4.8, at -Os, -O1 or higher.
No ICE with version 5.4.1.


$ cat z1.f90
program p
   interface
  subroutine s(x)
 real :: x
  end
   end interface
   call s(1.0)
end
subroutine s(x)
   complex :: x
   x = x + 1
end


$ gfortran-7-20161009 -O2 z1.f90
z1.f90:3:18:

   subroutine s(x)
  1
Warning: Interface mismatch in global procedure 's' at (1): Type mismatch in
argument 'x' (REAL(4)/COMPLEX(4))
z1.f90:11:0:

x = x + 1

internal compiler error: Segmentation fault
0xc2a7cf crash_signal
../../gcc/toplev.c:337
0xf69ea4 ix86_decompose_address(rtx_def*, ix86_address*)
../../gcc/config/i386/i386.c:14954
0xf6bd9b ix86_legitimate_address_p
../../gcc/config/i386/i386.c:15668
0xb8b07e memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
../../gcc/recog.c:1336
0x8df897 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
../../gcc/emit-rtl.c:2221
0x91e9b1 store_field
../../gcc/expr.c:6938
0x91a7b7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5167
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 c++/77958] New: printf format checking -vs- variadic template functions

[tromey at gcc dot gnu.org]

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

Bug ID: 77958
   Summary: printf format checking -vs- variadic template
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Consider this test case, derived from code I found in firefox:

#include 
#include 

template
static void
// __attribute__ ((format (printf, 1, 2)))
whatever(const char *fmt, Args&&... args)
{
  printf(fmt, args...);
}

void qq()
{
  whatever("hi %d", "bob");
}


If I compile this with -Wformat, I don't get any warnings.

However, if I uncomment the __attribute__, I get:

pokyo. g++ -Wall -c -Wformat q.cc
q.cc: In substitution of ‘template void whatever(const char*,
Args&& ...) [with Args = {const char (&)[4]}]’:
q.cc:14:26:   required from here
q.cc:7:1: error: args to be formatted is not ‘...’
 whatever(const char *fmt, Args&&... args)
 ^~~~


I think the attribute approach ought to work.

[Bug c++/77911] Comparing function pointers in a constexpr function can produce an error.

[yhueotnk at pokemail dot net]

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

--- Comment #3 from Dr Hilbert Swan  ---
A generous fellow offered me this workaround for the time being:

   void test1(){}
   void test2(){}
   void test3(){}
   void test4(){}
   #define FUNCTION_LIST test1, test2, test3, test4

   template 
   struct SearchFun
   {
   static constexpr int Idx = SearchFun::Idx;
   };

   template 
   struct SearchFun
   {
   static constexpr int Idx = N;
   };

   template 
   using FindMatchingIdx = SearchFun<0, Fun, FUNCTION_LIST>;

   // Tests
   constexpr unsigned int loc1 = FindMatchingIdx::Idx;
   static_assert(loc1 == 0, "");
   constexpr unsigned int loc2 = FindMatchingIdx::Idx;
   static_assert(loc2 == 1, "");
   constexpr unsigned int loc3 = FindMatchingIdx::Idx;
   static_assert(loc3 == 2, "");

   // If the array is needed
   typedef void (*func)();
   func funcs[] = { FUNCTION_LIST };

   // If desired the template alias can be wrapped in a macro

   #define FindMatching(Fun) FindMatchingIdx::Idx
   constexpr unsigned int loc4 = FindMatching(test2);
   static_assert(loc4 == 1, "");

[Bug c/77909] -Wimplicit-fallthrough: accept more comment variants

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
This was fixed by Jakub's patch:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=126636026724ab5faecb017cfaf9dabbd3754ef3

-Wimplicit-fallthrough=1 should fix all of your issues.

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|4.6.1   |6.0
 Resolution|--- |FIXED

--- Comment #20 from Jason Merrill  ---
Fixed in GCC 6.

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

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
Indeed, gold is definitely a factor, but look what happens after switching back
to ld.bfd on ARM:

make[6]: Entering directory
`/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src'
/bin/bash ../libtool --tag CXX   --mode=link
/home/guest/gcc-svn-master/build/./gcc/xgcc -shared-libgcc
-B/home/guest/gcc-svn-master/build/./gcc -nostdinc++
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc7/arm-linux-gnueabihf/bin/ -B/usr/gcc7/arm-linux-gnueabihf/lib/
-isystem /usr/gcc7/arm-linux-gnueabihf/include -isystem
/usr/gcc7/arm-linux-gnueabihf/sys-include -Wl,-O1 -Wl,-z,relro
-Wl,--gc-sections  -std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=libstdc++.la  -o
libstdc++.la -version-info 6:23:0 -Wl,--version-script=libstdc++-symbols.ver
-lm -rpath /usr/gcc7/lib compatibility.lo compatibility-debug_list.lo
compatibility-debug_list-2.lo  compatibility-c++0x.lo
compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo
compatibility-chrono.lo compatibility-condvar.lo 
../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la 
libtool: link:  /home/guest/gcc-svn-master/build/./gcc/xgcc -shared-libgcc
-B/home/guest/gcc-svn-master/build/./gcc -nostdinc++
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc7/arm-linux-gnueabihf/bin/ -B/usr/gcc7/arm-linux-gnueabihf/lib/
-isystem /usr/gcc7/arm-linux-gnueabihf/include -isystem
/usr/gcc7/arm-linux-gnueabihf/sys-include -fPIC -DPIC -D_GLIBCXX_SHARED
-shared -nostdlib /usr/lib/arm-linux-gnueabihf/crti.o
/home/guest/gcc-svn-master/build/./gcc/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-lm -L/home/guest/gcc-svn-master/build/./gcc -L/lib/arm-linux-gnueabihf
-L/usr/lib/arm-linux-gnueabihf -lc -lgcc_s
/home/guest/gcc-svn-master/build/./gcc/crtendS.o
/usr/lib/arm-linux-gnueabihf/crtn.o  -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections
-Wl,--version-script=libstdc++-symbols.ver   -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.23
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:69:30:
note: type 'struct __cow_string' should match type 'struct __cow_string'
   typedef basic_string __cow_string;
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:48:10:
note: the incompatible type is defined here
   struct __cow_string
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:69:30:
note: type 'struct __cow_string' should match type 'struct __cow_string'
   typedef basic_string __cow_string;
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:48:10:
note: the incompatible type is defined here
   struct __cow_string
  ^
`__gnu_end_cleanup' referenced in section `.text.__cxa_end_cleanup' of
/tmp/ccKTGZUi.ltrans0.ltrans.o: defined in discarded section `.text' of
eh_arm.o (symbol from plugin)
collect2: error: ld returned 1 exit status

[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 #1 from Jakub Jelinek  ---
Created attachment 39798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39798=edit
gcc7-pr77957.patch

One of the problems is that for TARGET_THREAD_SSP_OFFSET targets we completely
wastefully create a MEM we don't really need and then ignore it.  This untested
patch attempts to avoid that.

The more important bug is somewhere in the rs6000 backend, that the useless
MEMs at -O0 confuse the backend enough that it contains (useless) .LCTOC0
reference/load without corresponding definition of .LCTOC0.  I'll leave this
part to the rs6000 maintainers.

[Bug libgomp/66553] openmp tasks produce libgomp warnings with fsanitize=thread

[jtaylor.debian at googlemail dot com]

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

--- Comment #3 from Julian Taylor  ---
Would adding a libgomp threadsanitizer configure switch be an option?
It could enable --disable-linux-futex which you need for omp critical sections,
set the right compile and link flags and add some extra locks in the task
structure to remove the false positives.


note gcc 6.2 still produces thread sanitizer errors with the above example when
using tasks:

==
WARNING: ThreadSanitizer: data race (pid=12405)
  Write of size 4 at 0x7d880001c900 by thread T1 (mutexes: write M12):
#0 gomp_team_barrier_set_task_pending ../libgomp/config/posix/bar.h:125
(libgomp.so.1+0x0001bd5b)
#1 GOMP_task ../libgomp/task.c:455 (libgomp.so.1+0x0001bd5b)
#2 main._omp_fn.0 /tmp/jtaylor/test2.c:17 (a.out+0x00400aff)
#3 gomp_thread_start ../libgomp/team.c:119 (libgomp.so.1+0x00022860)

  Previous read of size 4 at 0x7d880001c900 by thread T4 (mutexes: write M11):
#0 gomp_barrier_wait_start ../libgomp/config/posix/bar.h:82
(libgomp.so.1+0x0002619b)
#1 gomp_team_barrier_wait ../libgomp/config/posix/bar.c:252
(libgomp.so.1+0x0002619b)
#2 gomp_team_barrier_wait_final ../libgomp/config/posix/bar.h:104
(libgomp.so.1+0x0002286c)
#3 gomp_thread_start ../libgomp/team.c:120 (libgomp.so.1+0x0002286c)

  Location is heap block of size 5440 at 0x7d880001c800 allocated by main
thread:
#0 malloc ../../../../libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000298bc)
#1 gomp_malloc ../libgomp/alloc.c:37 (libgomp.so.1+0xb06a)
#2 gomp_new_team ../libgomp/team.c:168 (libgomp.so.1+0x000228fa)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Mutex M12 (0x7d880001cf40) created at:
#0 pthread_mutex_init
../../../../libsanitizer/tsan/tsan_interceptors.cc:1091
(libtsan.so.0+0x0002b4be)
#1 gomp_mutex_init ../libgomp/config/posix/mutex.h:40
(libgomp.so.1+0x0002291a)
#2 gomp_new_team ../libgomp/team.c:174 (libgomp.so.1+0x0002291a)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Mutex M11 (0x7d880001c890) created at:
#0 pthread_mutex_init
../../../../libsanitizer/tsan/tsan_interceptors.cc:1091
(libtsan.so.0+0x0002b4be)
#1 gomp_mutex_init ../libgomp/config/posix/mutex.h:40
(libgomp.so.1+0x00025bde)
#2 gomp_barrier_init ../libgomp/config/posix/bar.c:37
(libgomp.so.1+0x00025bde)
#3 gomp_new_team ../libgomp/team.c:173 (libgomp.so.1+0x0002290b)
#4 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#5 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Thread T1 (tid=12407, running) created by main thread at:
#0 pthread_create ../../../../libsanitizer/tsan/tsan_interceptors.cc:876
(libtsan.so.0+0x0002ad6d)
#1 gomp_team_start ../libgomp/team.c:806 (libgomp.so.1+0x000231cd)
#2 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129f7)
#3 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Thread T4 (tid=12410, running) created by main thread at:
#0 pthread_create ../../../../libsanitizer/tsan/tsan_interceptors.cc:876
(libtsan.so.0+0x0002ad6d)
#1 gomp_team_start ../libgomp/team.c:806 (libgomp.so.1+0x000231cd)
#2 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129f7)
#3 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

SUMMARY: ThreadSanitizer: data race ../libgomp/config/posix/bar.h:125 in
gomp_team_barrier_set_task_pending
==
2 0
==
WARNING: ThreadSanitizer: data race (pid=12405)
  Read of size 4 at 0x7d880001cf88 by thread T1:
#0 GOMP_task ../libgomp/task.c:318 (libgomp.so.1+0x0001b69a)
#1 main._omp_fn.0 /tmp/jtaylor/test2.c:17 (a.out+0x00400aff)
#2 gomp_thread_start ../libgomp/team.c:119 (libgomp.so.1+0x00022860)

  Previous write of size 4 at 0x7d880001cf88 by thread T2 (mutexes: write M12):
#0 gomp_barrier_handle_tasks ../libgomp/task.c:1295
(libgomp.so.1+0x000178be)
#1 gomp_team_barrier_wait_end ../libgomp/config/posix/bar.c:155
(libgomp.so.1+0x00025f15)
#2 gomp_team_barrier_wait ../libgomp/config/posix/bar.c:252
(libgomp.so.1+0x000261db)
#3 gomp_team_barrier_wait_final ../libgomp/config/posix/bar.h:104
(libgomp.so.1+0x0002286c)
#4 gomp_thread_start ../libgomp/team.c:120 (libgomp.so.1+0x0002286c)

  Location is heap block of size 5440 at 0x7d880001c800 allocated by main
thread:
#0 malloc ../../../../libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000298bc)
#1 gomp_malloc ../libgomp/alloc.c:37 (libgomp.so.1+0xb06a)
#2 gomp_new_team ../libgomp/team.c:168 (libgomp.so.1+0x000228fa)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main 

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Markus Trippelsdorf from comment #10)
> The testcase from PR77955:
> 
> markus@x4 /tmp % cat fall.c
> void bar(int);
> 
> void foo(int i) {
>   switch (i) {
>   case 1: {
> bar(1);
> // fall-through
>   }
>   case 2:

Well, this one is even much harder than the preprocessor issue, it isn't
solvable by preserving CPP_COMMENT tokens and ignoring them, there are tokens
in between the fallthru comment and case keyword even after preprocessing here.
I'm afraid this is a clear WONTFIX, move the comment or better use
__attribute__((fallthrough))/[[fallthrough]] instead.

> bar(2);
>   default:
> break;

Not warning here is completely intentional, it is a fallthru into break;

[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> That link worked for me. Thanks

For me too.

I think the reference C1556 (R1527) is rather

C1255 (R1227) If MODULE appears in the prefix of a module subprogram, 
the subprogram shall specify the same characteristics and dummy argument 
names as its corresponding module procedure interface body.

I overlooked it my F2015 draft.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
The testcase from PR77955:

markus@x4 /tmp % cat fall.c
void bar(int);

void foo(int i) {
  switch (i) {
  case 1: {
bar(1);
// fall-through
  }
  case 2:
bar(2);
  default:
break;
  }
}
markus@x4 /tmp % gcc -Wimplicit-fallthrough=1 -c fall.c
fall.c: In function ‘foo’:
fall.c:6:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
 bar(1);
 ^~
fall.c:9:3: note: here
   case 2:
   ^~~~

Two issues; the first is the bogus warning, the second that we don't
warn for the case 2 fall-through.

[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

Jakub Jelinek  changed:

   What|Removed |Added

 Target||powerpc64le-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |6.3
 Ever confirmed|0   |1

[Bug target/77957] New: [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

Bug ID: 77957
   Summary: [6/7 Regression] Undefined .LCTOC0 with
-fstack-protector-strong -mminimal-toc -O0 on ppc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void
foo (void)
{
  unsigned long x = 0;
  asm volatile ("" : : "r" () : "memory");
}

int
main ()
{
  foo ();
  return 0;
}

fails to link on powerpc64le-linux with -fstack-protector-strong -mminimal-toc
-O0:
gcc -fstack-protector-strong -mminimal-toc -O0 -o /tmp/test{,.c}
/tmp/ccldrAkU.o: In function `foo':
test.c:(.text+0x20): undefined reference to `.LCTOC0'
collect2: error: ld returned 1 exit status

I can reproduce also with a cross-compiler, the important trigger is that
TARGET_LIBC_PROVIDES_SSP must be defined to 1.  This compiled fine with 4.8,
fails with 6.2 and current trunk.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

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

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Ah, right.  Ok.

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

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #4)
> It'll be hard to "fix" the first testcase:
> .

Thanks.

The testcase from comment 3 is a dup of pr77886 and fixed by 
the patch that Jakub posted there.

So if there is already an existing bug for the first testcase,
feel free to close this bug.

[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[jvdelisle at charter dot net]

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

--- Comment #5 from jvdelisle at charter dot net ---
On 10/11/2016 10:21 PM, damian at sourceryinstitute dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903
>
> --- Comment #4 from Damian Rouson  ---
> Check the date on your draft.   The latest draft is dated 31 August 2016.
> C1556 appears on page 330. Does the following link work for you?
>
> http://j3-fortran.org/doc/year/16/16-007.pdf
>
> I'm working on obtaining a publicly accessible link in case the above one
> doesn't work.
>
> Damian
>

That link worked for me. Thanks

Jerry

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
It'll be hard to "fix" the first testcase:
.

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
$ cat tc.c
xfig_wiggly_yend ()
{
  int a = 1;
  for (;;)
{
  a = abs (a - 1);
  fprintf (a, xfig_wiggly_yend);
}
}

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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

--- Comment #32 from Jack Howarth  ---
(In reply to Iain Sandoe from comment #30)
oblem with a small set of tests).
> 
> I'm going to rebase and post the patches

Any ETA on the rebased patches being posted?

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-10-12
  Component|c   |tree-optimization
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice in  |[7 Regression] ICE in
   |insert_debug_temp_for_var_d |insert_debug_temp_for_var_d
   |ef with -g and -O2  |ef with -g and -O2
   Target Milestone|--- |7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r240865. I've been reducing the test-case.

[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 #6 from Martin Liška  ---
Created attachment 39797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39797=edit
Untested patch

[Bug c/77956] New: ice in insert_debug_temp_for_var_def with -g and -O2

[dcb314 at hotmail dot com]

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

Bug ID: 77956
   Summary: ice in insert_debug_temp_for_var_def with -g and -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached code, when compiled by gcc trunk dated 20161012, with
compiler flags -g -O2, does this:

inout.c: In function ‘xfig_wiggly’:
inout.c:3987:1: internal compiler error: Segmentation fault
0xaeecd7 crash_signal
../../trunk/gcc/toplev.c:337
0xc9d7fc insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
../../trunk/gcc/tree-ssa.c:316
0xc9e397 insert_debug_temps_for_defs(gimple_stmt_iterator*)
../../trunk/gcc/tree-ssa.c:504
0x87f44f gsi_remove(gimple_stmt_iterator*, bool)
../../trunk/gcc/gimple-iterator.c:567

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 12 14:37:53 2016
New Revision: 241053

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

PR debug/77947
* cgraphunit.c (analyze_functions): Preserve cgraph nodes
function context.

* g++.dg/torture/pr77947.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr77947.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Another issue:

markus@x4 /tmp % cat fall.c
void bar(int);

template  void foo(int i, bool bo) {
  switch (i) {
  case 1:
if (!bo)
  break;
  // Fall through.
  case 2:
bar(2);
  default:
break;
  }
}

template void foo(int, bool);
template void foo(int, bool);

markus@x4 /tmp % g++ -Wimplicit-fallthrough=1 -c fall.c
fall.c: In function ‘void foo(int, bool) [with T = int]’:
fall.c:6:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
 if (!bo)
 ^~
fall.c:9:3: note: here
   case 2:
   ^~~~
fall.c: In function ‘void foo(int, bool) [with T = void*]’:
fall.c:6:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
 if (!bo)
 ^~
fall.c:9:3: note: here
   case 2:
   ^~~~

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #1)
> (In reply to Markus Trippelsdorf from comment #0)
> > As you can see gcc issues a bogus warning and doesn't warn for the case 2
> > fallthrough.
> 
> It falls through to default: break; so it should warn for that case.

Yes, that is what I meant to say.

[Bug c/77955] New: -Wimplicit-fallthrough=1 issue

[trippels at gcc dot gnu.org]

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

Bug ID: 77955
   Summary: -Wimplicit-fallthrough=1 issue
   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: ---

markus@x4 /tmp % cat fall.c
void bar(int);

void foo(int i) {
  switch (i) {
  case 1: {
bar(1);
// fall-through
  }
  case 2:
bar(2);
  default:
break;
  }
}
markus@x4 /tmp % gcc -Wimplicit-fallthrough=1 -c fall.c
fall.c: In function ‘foo’:
fall.c:6:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
 bar(1);
 ^~
fall.c:9:3: note: here
   case 2:
   ^~~~

As you can see gcc issues a bogus warning and doesn't warn for the case 2
fallthrough.

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
(In reply to Markus Trippelsdorf from comment #0)
> As you can see gcc issues a bogus warning and doesn't warn for the case 2
> fallthrough.

It falls through to default: break; so it should warn for that case.

[Bug lto/77954] New: LTO_STREAMER_DEBUG ICE with OpenMP SIMD clones

[tschwinge at gcc dot gnu.org]

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

Bug ID: 77954
   Summary: LTO_STREAMER_DEBUG ICE with OpenMP SIMD clones
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

If you enable gcc/lto-streamer.h:LTO_STREAMER_DEBUG, the
libgomp.fortran/declare-simd-4.f90 test case will run into an ICE, because of
gcc/lto-streamer.c:lto_orig_address_remove failing in "gcc_assert (slot)".

If Intel MIC (emulated) offloading is enabled,
libgomp.c/examples-4/declare_target-5.c and
libgomp.fortran/examples-4/declare_target-5.f90 fail in the same way.

I have not analyzed whether that is a real problem, or "just" a problem with
LTO_STREAMER_DEBUG -- but bootstrap build and full testsuite run with
LTO_STREAMER_DEBUG enabled doesn't exhibit any additional problems.

[Bug target/77952] c++11 and gcc: internal compiler error: in convert_move

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
ICEs for all revisions started from 4.8.0, former versions do not accept target
attribute.

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
> if the type contains trailing padding bytes (but one bytes between members).

The last bit is nonsense. I meant to say that padding between members seemed
OK.

[Bug target/77953] New: [MIPS] ice: insn does not satisfy its constraints - __bswapsi2

[james410 at cowgill dot org.uk]

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

Bug ID: 77953
   Summary: [MIPS] ice: insn does not satisfy its constraints -
__bswapsi2
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james410 at cowgill dot org.uk
  Target Milestone: ---

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

Compiling the attached source with:

mipsel-linux-gnu-gcc -c -mabi=64 -mno-abicalls -march=mips64 -mlong-calls -O2
-fno-strict-aliasing -fstack-protector-strong ice.c

Gives the following ICE:
ice.c:33:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 124 42 122 3 (parallel [
(set (reg/f:DI 22 $22 [228])
(symbol_ref:DI ("__bswapsi2") [flags 0x241]))
(clobber (scratch:DI))
]) ice.c:28 287 {*lea64}
 (nil))
ice.c:33:1: internal compiler error: in extract_constrain_insn, at recog.c:2190

Tested on Debian's GCC 5.4.0, 6.1.1 and 6.2.0.
The bug does NOT occur on 4.9.2.

[Bug c++/77952] New: c++11 and gcc: internal compiler error: in convert_move

[igor at chub dot in]

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

Bug ID: 77952
   Summary: c++11 and gcc: internal compiler error: in
convert_move
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor at chub dot in
  Target Milestone: ---

I have the following code:

typedef int  __v8si __attribute__ ((__vector_size__ (32)));

class T
{
public:
   __v8si v;

   __attribute__((target("avx2")))
   T(int p ):v(__extension__ __v8si{p,p,p,p,p,p,p,p}){}

   __attribute__((target("avx2")))
   T(__v8si p):v(p){}

   __attribute__((target("avx2")))
   T operator * ( T  b ) const
   {
  return __builtin_ia32_pmulld256( v , b.v ) ;
   }
};

void h(int *);

__attribute__((target("default")))
void h(int *)
{
}

__attribute__((target("avx2")))
void h(int *)
{
 const T a(1);
 const T b(2);
 const T c (a * b);
}

int main()
{
  return 0;
}

If I try to compile it, I have the following error:

$ gcc test.cpp -std=c++11

test.cpp: In member function 'T T::operator*(T) const':
test.cpp:17:48: internal compiler error: in convert_move, at expr.c:315
   return __builtin_ia32_pmulld256( v , b.v ) ;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I have tried to compile it with various gcc versions: 4.9.2, 5.3 and several
other versions.

Have you any ideas why it happens, and how could I solve the problem?

gcc test.cpp -std=c++11 -mavx2 works.

gcc test.cpp -std=c++11 -O1 works.

but I want to compile the code with -O0

[Bug c++/77949] [7 Regression] ICE on invalid code in internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:907

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug ada/64057] possible issue in the shared implementation of Ada.Strings.Unbounded

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #6 from Arnaud Charlet  ---
Should hopefully be fixed now.

[Bug ada/64057] possible issue in the shared implementation of Ada.Strings.Unbounded

[charlet at gcc dot gnu.org]

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

--- Comment #5 from Arnaud Charlet  ---
Author: charlet
Date: Wed Oct 12 10:32:53 2016
New Revision: 241025

URL: https://gcc.gnu.org/viewcvs?rev=241025=gcc=rev
Log:
2016-10-12  Eric Botcazou  

PR ada/64057
* exp_ch5.adb (Is_Non_Local_Array): Return true for every array
that is not a component or slice of an entity in the current
scope.


Modified:
trunk/gcc/ada/exp_ch5.adb

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
As we do not reclaim B::m_fn2::C::m_fn1 we IMHO shouldn't reclaim its
decl_function_context either.  In that case we'd generate proper debug info
for B::m_fn2::C::m_fn1 which we end up using in the code later on through
devirt.

Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 241022)
+++ gcc/cgraphunit.c(working copy)
@@ -1126,6 +1126,13 @@ analyze_functions (bool first_time)
= cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (decl));
  origin_node->used_as_abstract_origin = true;
}
+ /* Preserve a functions function context node.  It will
+later be needed to output debug info.  */
+ if (tree fn = decl_function_context (decl))
+   {
+ cgraph_node *origin_node = cgraph_node::get_create (fn);
+ enqueue_node (origin_node);
+   }
}
  else
{

fixes this bug (and creates proper debug info).

[Bug c++/77950] GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed.

libcxxabi's demangler gives:

eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >&&
eggs::variants::detail::forward > >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >,
eggs::variants::variant,
eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >,
eggs::variants::variant,
eggs::variants::variant,
eggs::variants::variant,
eggs::variants::variant >
ossia::vec_merger_impl<2>::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
>(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > > >
const&)::'lambda'(eggs::variants::variant > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
ossia::strong_value > >,
ossia::strong_value > >
>&)&&>(std::remove_reference
> >, ossia::strong_value > 
> >>, ossia::strong_value > >, 
> >ossia::strong_value > >, 
> >ossia::strong_value > >, 
> >ossia::strong_value
> > > >::type&)

libiberty overflows the stack and Ian's Go demangler doesn't handle the symbol.

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Before r240578 everything prevailed until the very end and the context DIE we
tried to force would be still there.  In the end everything would get removed
again, of course.  GCC 6 emits no debug info for m_fn2 or the contained
classes/methods (B is also not present).  So IMHO avoiding all the work
early makes very much sense.

IPA says

_Z3fn1R1A/8 (void fn1(A&)) @0x7ffbf1620e60
  Type: function definition analyzed
  Visibility: public
  References:
  Referring:
  First run: 0
  Function flags: body
  Called by:
  Calls:
   Polymorphic indirect call of type const struct A token:0(1.00 per call) (can
throw external)
Outer type (dynamic):struct A (or a derived type) (maybe in construction)
offset 0
_ZZNK1B5m_fn2EvENK1C5m_fn1Ev/0 (virtual bool B::m_fn2() const::C::m_fn1()
const) @0x7ffbf16202e0

which probably means that fn1 (being a global function) could be called from
another TU which has B::m_fn2 used (ODR, etc.) and with C as p1.  OTOH
that's only possible if C "escapes" from B::m_fn2 (though we don't do such
analysis).

So in the end the speculative devirt is sensible but then reclaiming of
B::m_fn2 is a bit over-eager given we later somehow "inline" B::m_fn2::C:m_fn1
(and ICE in that process).

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Honza?

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 12 Oct 2016, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77947
> 
> --- Comment #5 from Martin Liška  ---
> Created attachment 39791
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39791=edit
> Really reduced test-case

So we are properly creating a DIE for m_fn1 early but then end up
removing it via prune_unused_types.  It looks like this is because
the DIE for C has the CU as parent rather than B::m_fn2.  It
first gets created in limbo (via dwarf2out_type_decl) because:

  /* If we're a function-scope tag, initially use a parent of NULL;
 this will be fixed up in decls_for_scope.  */
  if (decl_function_context (decl))
context_die = NULL;

but we never end up calling dwarf2out_early_global_decl for B::m_fn2
and thus the limbo gets re-parented to the CU DIE (as we record
the TREE_TYPE for DW_TAG_class_type DIEs, not the TYPE_DECL):

  if (DECL_P (node->created_for))
origin = get_context_die (DECL_CONTEXT 
(node->created_for));
  else if (TYPE_P (node->created_for))
origin = scope_die_for (node->created_for, comp_unit_die 
());

and scope_die_for simply doesn't handle FUNCTION_DECL as containing_scope.

B::m_fn2 has been optimized out as unreachable which is the reason we
are not ending up in decls_for_scope eventually.

IMHO optimizing C as unused is ok.  The question is why we end up
with inlining m_fn1 ...

looks like we devirtualize the call in fn1 to B::C::m_fn1:

t.ii:25:14: note: speculatively devirtualizing call in void fn1(A&)/8 to 
virtual bool B::m_fn2() const::C::m_fn1() const/0
Indirect call -> speculative call void fn1(A&)/8 => virtual bool 
B::m_fn2() const::C::m_fn1() const/0
1 polymorphic calls, 0 devirtualized, 1 speculatively devirtualized, 0 
cold
0 have multiple targets, 0 overwritable, 0 already speculated (0 agree, 0 
disagree), 0 external, 0 not defined, 0 artificial, 0 infos dropped
Symbol table:

and -fno-devirtualize fixes it.

-> we shouldn't reclaim B::m_fn2 when we later end up devirtualizing
to B::m_fn2::C::m_fn1 (or rather we should never devirtualize to
a local class method?)

[Bug rtl-optimization/77951] Incorrect placement of label which does not affect execution flow

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is not a bug and the documentation in this extension already says this is
undefined.  Since you don't do any computed gotos gcc can change the location
of the labels without any care.

Note there are many duplicate bug reports of reporting this exact behavior.

[Bug rtl-optimization/77951] New: Incorrect placement of label which does not affect execution flow

[fw at gcc dot gnu.org]

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

Bug ID: 77951
   Summary: Incorrect placement of label which does not affect
execution flow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39794=edit
label-bug.c

The attached test case aborts at run time because the end label is moved up
before the call instruction, making it equal to the begin label:

.L3:
.L4:
callf
movl$.L4, %eax
subl$.L3, %eax
ret

I suspect this happens because the label is never used as a jump target, but
the test shows that there is still a way in which the label placement can
matter.

This is a purely synthetic test case, extracted from a test I wrote for bug
38295.  I did not observe any miscompilation of applications due to this issue.

label-bug.c.276r.split4 has:

(note/s 4 2 6 2 ("begin") NOTE_INSN_DELETED_LABEL 3)
(call_insn 6 4 7 2 (call (mem:QI (symbol_ref:DI ("f") [flags 0x3] 
) [0 f S1 A8])
(const_int 0 [0])) label-bug.c:12 673 {*call}
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("f") [flags 0x3]  )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))
(note/s 7 6 9 2 ("end") NOTE_INSN_DELETED_LABEL 4)

But label-bug.c.277r.sched2 turns this into:

(note/s 4 2 7 2 ("begin") NOTE_INSN_DELETED_LABEL 3)
(note/s 7 4 6 2 ("end") NOTE_INSN_DELETED_LABEL 4)
(call_insn:TI 6 7 9 2 (call (mem:QI (symbol_ref:DI ("f") [flags 0x3] 
) [0 f S1 A8])
(const_int 0 [0])) label-bug.c:12 673 {*call}
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("f") [flags 0x3]  )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(nil))

So it seems an RTL issue.

The above RTL dumps are from a fairly old GCC 7 from May, but I see the same
issue with gcc version 5.3.1 20160406 (Red Hat 5.3.1-6), in
label-bug.c.255r.split4 and label-bug.c.256r.sched2 there.

[Bug c++/77950] New: GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 77950
   Summary: GCC produces un-demanglable symbols with [] (auto&) {
... } lambdas in templates
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

Created attachment 39793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39793=edit
Preprocessed source exhibiting the bug

My problem is in the attachement starting at line 135809, within the struct
vec_merger_impl.

When I have this code : 

template
struct vec_merger_impl
{
  template
  ossia::value_with_unit operator()(const Dataspace_T& ds)
  {
if(ds)
{
  return eggs::variants::apply([&] (auto& unit) ->
ossia::value_with_unit {
return detail::vec_value_merger{idx}(unit, val);
  }, ds);
}
return {};
  }
};

The lambda [&] (auto& unit) ... produces undemanglable code, which makes the
software undebuggable... doing "nm -a preprocessed.o | c++filt" fails at the
following symbol : 

_ZN4eggs8variants6detail7forwardIOZN5ossia15vec_merger_implILi2EEclINS0_7variantIJNS3_12strong_valueINS3_11speed_ratioISt5ratioILl1ELl1EENS8_INS9_ISA_ILl16093440ELl3600EENS8_INS9_ISA_ILl1000ELl3600EENS8_INS9_ISA_ILl1852ELl3600EENS8_INS9_ISA_ILl3048ELl1EENS8_INS9_ISA_ILl3048ELl3600EEENS7_IJNS3_5valueENS7_IJNS8_INS3_14distance_ratioISB_NS8_INSV_ISA_ILl1000ELl1EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl1000EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl1EENS8_INSV_ISA_ILl254ELl1EENS8_INSV_ISN_NS8_INSV_ISA_ILl16093440ELl1ENS7_IJNS8_INS3_14cartesian_3d_uEEENS8_INS3_14cartesian_2d_uEEENS8_INS3_11spherical_uEEENS8_INS3_7polar_uEEENS8_INS3_8opengl_uEEENS8_INS3_13cylindrical_uEEST_NS7_IJNS8_INS3_12quaternion_uEEENS8_INS3_7euler_uEEENS8_INS3_6axis_uEENS7_IJNS8_INS3_8degree_uEEENS8_INS3_8radian_uEENS7_IJNS8_INS3_6argb_uEEENS8_INS3_6rgba_uEEENS8_INS3_5rgb_uEEENS8_INS3_5bgr_uEEENS8_INS3_7argb8_uEEENS8_INS3_5hsv_uEEENS8_INS3_6cmy8_uEEENS8_INS3_5xyz_uEENS7_IJNS8_INS3_8linear_uEEENS8_INS3_10midigain_uEEENS8_INS3_9decibel_uEEENS8_INS3_13decibel_raw_uERKT_EUlRS38_E_EEOS38_RNSt16remove_referenceIS38_E4typeE

If I change my lambda by an equivalent functor (can be tested in the attached
source by setting -DFIXED_VERSION, the code passes through c++filt (and GDB)
without problems.

[Bug libfortran/77663] libgfortran/caf/single.c: three minor problems and a lost token

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from vehre at gcc dot gnu.org ---
No complains so far, closing.

[Bug c++/77949] [7 Regression] ICE on invalid code in internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:907

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 39792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39792=edit
Test-case

[Bug c++/77949] New: [7 Regression] ICE on invalid code in internal compiler error: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:907

[marxin at gcc dot gnu.org]

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

Bug ID: 77949
   Summary: [7 Regression] ICE on invalid code in internal
compiler error: in
linemap_position_for_loc_and_offset, at
libcpp/line-map.c:907
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following test-case was accidentally created as a secondary product of a
test-case reduction. The code is very crappy, but causes an ICE:

$ g++ linemap-ice2.ii
...
linemap-ice2.ii:1:4063: error: expected ‘;’ at end of member declaration
linemap-ice2.ii:1:4095: internal compiler error: in
linemap_position_for_loc_and_offset, at libcpp/line-map.c:907
 :const_iterator, bool> result = cobject_info_set.insert(co);
return *(result.first); } inline void basic_oarchive_impl::save_object(
basic_oarchive & ar const void *t const basic_oserializer & bos )
inline void basic_oarchive_implsave_pointer }
   
   
   
^
0x1591bd3 linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../libcpp/line-map.c:907
0x7922d9 cp_parser_class_specifier_1
../../gcc/cp/parser.c:21810
0x794221 cp_parser_class_specifier
../../gcc/cp/parser.c:21961
0x794221 cp_parser_type_specifier
../../gcc/cp/parser.c:16102
0x7a82e9 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13019
0x7bc7b5 cp_parser_member_declaration
../../gcc/cp/parser.c:22696
0x791c88 cp_parser_member_specification_opt
../../gcc/cp/parser.c:22548
0x791c88 cp_parser_class_specifier_1
../../gcc/cp/parser.c:21712
0x794221 cp_parser_class_specifier
../../gcc/cp/parser.c:21961
0x794221 cp_parser_type_specifier
../../gcc/cp/parser.c:16102
0x7a82e9 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13019
0x7b2691 cp_parser_simple_declaration
../../gcc/cp/parser.c:12546
0x7b2ada cp_parser_block_declaration
../../gcc/cp/parser.c:12493
0x7bacfe cp_parser_declaration
../../gcc/cp/parser.c:12390
0x7bb156 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12266
0x7bb8d8 cp_parser_namespace_body
../../gcc/cp/parser.c:17940
0x7bb8d8 cp_parser_namespace_definition
../../gcc/cp/parser.c:17916
0x7bae17 cp_parser_declaration
../../gcc/cp/parser.c:12374
0x7bb156 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12266
0x7bb488 cp_parser_translation_unit
../../gcc/cp/parser.c:4360

Started to ICE with r238008.

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work|5.4.0, 6.2.0|
Summary|[7 Regression] GCC  |GCC generates invalid
   |generates invalid constexpr |constexpr copy/move
   |copy/move assignment|assignment operators for
   |operators for types with|types with trailing
   |trailing padding.   |padding.

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> 5 and 6 compile it happily.

Ugh, no they don't, sorry, I was compiling the wrong thing.

5 ICEs, 6 has the same error as 7.

[Bug c++/77945] [7 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.4.0, 6.2.0
Summary|GCC generates invalid   |[7 Regression] GCC
   |constexpr copy/move |generates invalid constexpr
   |assignment operators for|copy/move assignment
   |types with trailing |operators for types with
   |padding.|trailing padding.
  Known to fail||7.0

--- Comment #1 from Jonathan Wakely  ---
5 and 6 compile it happily.

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 39791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39791=edit
Really reduced test-case

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 Ever confirmed|0   |1

[Bug c++/77948] New: Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals

[rguenth at gcc dot gnu.org]

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

Bug ID: 77948
   Summary: Option processing of -std=c++11 -std=gnu++11 doesn't
reset ext_numeric_literals
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

int main(int argc, char *argv[])
{
  __float128 f = 1.0Q;
  return 0;
}

> g++-6 t.C -std=c++11 -std=gnu++11
t.C: In function ‘int main(int, char**)’:
t.C:3:18: error: unable to find numeric literal operator ‘operator""Q’
   __float128 f = 1.0Q;
  ^~~~
t.C:3:18: note: use -std=gnu++11 or -fext-numeric-literals to enable more
built-in suffixes

possibly because we do

case OPT_std_c__11:
case OPT_std_gnu__11:
  if (!preprocessing_asm_p)
{
  set_std_cxx11 (code == OPT_std_c__11 /* ISO */);
  if (code == OPT_std_c__11)
cpp_opts->ext_numeric_literals = 0;
}
  break;

but do _not_ set it to 1 for code == OPT_std_gnu__11.  Adding
-fext-numeric-literals as first argument works (-std=c++11 doesn't reset it).

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #39790|0   |1
is obsolete||

--- Comment #4 from Martin Liška  ---
Comment on attachment 39790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39790
Reduced test-case

Wrongly reduced test-case (converged to another ICE) :)

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 39790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39790=edit
Reduced test-case

[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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

I already have it.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #5)
> I think my preference would be to try TREE_PRIVATE bit for it instead.

I can do it.

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0

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

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

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Marek Polacek from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > Thanks.  More reduced (that fails even with -Wimplicit-fallthrough):
> > 
> > Did you mean without?
> 
> No, I meant with, but that it will ICE with any level from 1 to 4 that way.

But only with -O0.

[Bug debug/77947] [7 Regression] ICE with -g and -O2 in strip_naming_typedef

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-10-12
  Component|c++ |debug
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice with -g and -O2 in  |[7 Regression] ICE with -g
   |strip_naming_typedef|and -O2 in
   ||strip_naming_typedef
  Known to fail||7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r240578. I'm reducing the test-case.

[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 #6 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Thanks.  More reduced (that fails even with -Wimplicit-fallthrough):
> 
> Did you mean without?

No, I meant with, but that it will ICE with any level from 1 to 4 that way.

[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 #5 from Jakub Jelinek  ---
The problem is that varasm.c uses TREE_PUBLIC on all decls, but it now means
something different on LABEL_DECLs.  So either we tweak it:
--- gcc/varasm.c.jj 2016-10-09 13:19:09.0 +0200
+++ gcc/varasm.c2016-10-12 09:57:21.499076633 +0200
@@ -6847,7 +6847,7 @@ default_binds_local_p_3 (const_tree exp,
 bool extern_protected_data, bool common_local_p)
 {
   /* A non-decl is an entry in the constant pool.  */
-  if (!DECL_P (exp))
+  if (!DECL_P (exp) || TREE_CODE (exp) == LABEL_DECL)
 return true;

   /* Weakrefs may not bind locally, even though the weakref itself is always
@@ -6856,8 +6856,8 @@ default_binds_local_p_3 (const_tree exp,
  FIXME: We can resolve the weakref case more curefuly by looking at the
  weakref alias.  */
   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
-  || (TREE_CODE (exp) == FUNCTION_DECL
-  && lookup_attribute ("ifunc", DECL_ATTRIBUTES (exp
+  || (TREE_CODE (exp) == FUNCTION_DECL
+ && lookup_attribute ("ifunc", DECL_ATTRIBUTES (exp
 return false;

   /* Static variables are always local.  */
@@ -6972,7 +6972,7 @@ decl_binds_to_current_def_p (const_tree
   gcc_assert (DECL_P (decl));
   if (!targetm.binds_local_p (decl))
 return false;
-  if (!TREE_PUBLIC (decl))
+  if (!TREE_PUBLIC (decl) || TREE_CODE (decl) == LABEL_DECL)
 return true;

   /* When resolution is available, just use it.  */

and wait for other spots that should change, or we choose a different flag.
I think my preference would be to try TREE_PRIVATE bit for it instead.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #3)
> Thanks.  More reduced (that fails even with -Wimplicit-fallthrough):

Did you mean without?

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Hmm, I ran a successful --with-build-config=bootstrap-lto aarch64 bootstrap a
couple of weeks ago.
I'll try again with the latest trunk.
Maybe using gold is causing the issues?

[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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
I'll take a look.

[Bug c++/77947] New: ice with -g and -O2 in strip_naming_typedef

[dcb314 at hotmail dot com]

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

Bug ID: 77947
   Summary: ice with -g and -O2 in strip_naming_typedef
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached code, when compiled by gcc trunk dated 20161012, and compiler
flags -g -O2, does this:

$ ../results/bin/gcc -c -g -O2 bug309.cc
libs/serialization/src/basic_oarchive.cpp: In member function ‘virtual bool
boost::archive::detail::basic_oarchive_impl::find(const
boost::serialization::extended_type_info&) const::bosarg::tracking(unsigned
int) const’:
libs/serialization/src/basic_oarchive.cpp:464:1: internal compiler error:
Segmentation fault
0xc29117 crash_signal
../../trunk/gcc/toplev.c:337
0x9008a8 strip_naming_typedef
../../trunk/gcc/dwarf2out.c:5095
0x9008a8 get_context_die
../../trunk/gcc/dwarf2out.c:23429
0x9005c7 force_decl_die
../../trunk/gcc/dwarf2out.c:23448

[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|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Thanks.  More reduced (that fails even with -Wimplicit-fallthrough):
void
foo (void)
{
  static void *p = &
  goto *p;
  /*FALLTHRU*/
  lab:;
}

[Bug debug/77931] PASS->FAIL: gdb.cp/namespace.exp: print ina

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2016-10-12
  Component|c++ |tree-optimization
 Ever confirmed|0   |1
Summary|Optimization incorrectly|[5/6/7 Regression]
   |commons noexcept calls with |Optimization incorrectly
   |non-noexcept calls  |commons noexcept calls with
   ||non-noexcept calls
   Target Milestone|--- |5.5
  Known to fail||4.8.5, 5.2.0, 6.2.0

--- Comment #4 from Richard Biener  ---
It's tail-merging commoning BB3 and BB4 in

void func(bool) (bool callFatal)
Eh tree:
   1 must_not_throw
{
  :
  if (callFatal_2(D) != 0)
goto ;
  else
goto ;

  :
  thrower ();

  :
  [MNT 1] thrower ();

}

A regression at least from tail-merging introduction.

OTOH it might be simply undefined behavior if you throw from inside a
must-not-throw region?  Would have to double-check the C++ standard for this.
(if invoking std::terminate is required)

[Bug bootstrap/68663] Build failure on AIX 7.1

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #3 from The Written Word  
---
(In reply to David Edelsohn from comment #2)
> Group Bull, Perzl, and I have been able to build it.  Are you using an up to
> date AIX Assembler?

Hmm. Let me try upgrading. Thanks.

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

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #1)
> Try -save-temps with -C or -CC ?

Thanks, that works.

int a;
void fn1() {
  static int *b[] = {[0] = &_IND_B, 0};
  goto *b[a]; /**/
LD_IND_B: /*   */;
}

[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes that goes out of scope before the possible tail call site

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I think the only way we can improve this is tracking liveness with CLOBBERs
(but that relies on CLOBBERs being present).  Like walking dominators looking
for
CLOBBERs (or computing full data-flow for the desired set of vars, see
cfgexpand.c:add_scope_conflicts how this works with CLOBBERs).