[Bug fortran/88871] [9.0 regression] ICE segmentation fault in f951

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
My suspicion goes toward the fix for PR81849, so maybe also the gcc-7 and gcc-8
branches are affected.

[Bug c++/88872] ICE with g++ 8.x in cp_build_addr_expr_1, at cp/typeck.c:5936

[m.olbrich at pengutronix dot de]

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

--- Comment #1 from m.olbrich at pengutronix dot de ---
I forgot to mention: This only happens with "-std=c++17"

[Bug c++/88872] New: ICE with g++ 8.x in cp_build_addr_expr_1, at cp/typeck.c:5936

[m.olbrich at pengutronix dot de]

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

Bug ID: 88872
   Summary: ICE with g++ 8.x in cp_build_addr_expr_1, at
cp/typeck.c:5936
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.olbrich at pengutronix dot de
  Target Milestone: ---

Created attachment 45437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45437&action=edit
Test code to reproduce the ICE

The current gcc-8-branch generates a ICE with the attached code.
This does not happen with trunk and was introduces in revision 260674
("PR c++/85864 - literal template and default template arg.").

ice.cxx:6:45: warning: literal operator suffixes not preceded by ‘_’ are
reserved for future standardization [-Wliteral-suffix]
 template  constexpr a operator"" n() { return d; }
 ^
ice.cxx: In instantiation of ‘j<  >::k() [with
 = int]:: [with auto:1 = int]’:
ice.cxx:19:40:   required from ‘void j<  >::k() [with
 = int]’
ice.cxx:25:22:   required from here
ice.cxx:19:31: internal compiler error: in cp_build_addr_expr_1, at
cp/typeck.c:5936
 [](auto) { constexpr auto l = 2n; }(keywords);
   ^
0x5906e8 cp_build_addr_expr_1
.../gcc/gcc/cp/typeck.c:5936
0x5906e8 cp_build_addr_expr_1
.../gcc/gcc/cp/typeck.c:5797
0x5d02b7 convert_like_real
.../gcc/gcc/cp/call.c:7081
0x5d3669 build_over_call
.../gcc/gcc/cp/call.c:7999
0x5d29e9 build_new_method_call_1
.../gcc/gcc/cp/call.c:9378
0x5d29e9 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
.../gcc/gcc/cp/call.c:9453
0x5d52f9 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
.../gcc/gcc/cp/call.c:8980
0x60496f ocp_convert(tree_node*, tree_node*, int, int, int)
.../gcc/gcc/cp/cvt.c:907
0x641545 expand_default_init
.../gcc/gcc/cp/init.c:1843
0x641545 expand_aggr_init_1
.../gcc/gcc/cp/init.c:2021
0x64185b build_aggr_init(tree_node*, tree_node*, int, int)
.../gcc/gcc/cp/init.c:1761
0x60fe57 build_aggr_init_full_exprs
.../gcc/gcc/cp/decl.c:6283
0x60fe57 check_initializer
.../gcc/gcc/cp/decl.c:6432
0x61e99b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
.../gcc/gcc/cp/decl.c:7145
0x6b846c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
.../gcc/gcc/cp/pt.c:16767
0x6b6b43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
.../gcc/gcc/cp/pt.c:16921
0x6b6b43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
.../gcc/gcc/cp/pt.c:16921
0x6b6b43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
.../gcc/gcc/cp/pt.c:16921
0x6b57c8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
.../gcc/gcc/cp/pt.c:16606
0x6b57c8 instantiate_decl(tree_node*, bool, bool)
.../gcc/gcc/cp/pt.c:24056

[Bug fortran/88871] New: [9.0 regression] ICE segmentation fault in f951

[juergen.reuter at desy dot de]

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

Bug ID: 88871
   Summary: [9.0 regression] ICE segmentation fault in f951
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 45436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45436&action=edit
File that triggers the ICE.

The following (legacy) code included in our software package fails compilation
with an ICE in f951 with r267961, while r267903 was still working. 
$ gfortran -g -O2 mnread.f 
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter  ---
I think this fix or something very near by causes an ICE in our code, I will
provide a bug report soon.

[Bug rtl-optimization/88870] New: ICE: Segmentation fault (in df_worklist_propagate_backward)

[asolokha at gmx dot com]

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

Bug ID: 88870
   Summary: ICE: Segmentation fault (in
df_worklist_propagate_backward)
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20190113 snapshot (r267906), 8.2, 7.4, 6.3, 5.4, 4.9.4, 4.8.5
all ICE when compiling the following snippet w/ -O1 -fexceptions
-fnon-call-exceptions -ftrapv -fno-tree-dominator-opts:

int ou, je;

void
r8 (int *y4)
{
  int dc = 0;

  {
int by;

y4 = &dc;

for (;;)
  {
y4 = &by;
je = 0;
by = dc + 1;
je = dc = 1;
++ou;
  }
  }
}

% gcc-9.0.0-alpha20190113 -O1 -fexceptions -fnon-call-exceptions -ftrapv
-fno-tree-dominator-opts -c hbwhwojh.c
during RTL pass: rtl_dce
hbwhwojh.c: In function 'r8':
hbwhwojh.c:22:1: internal compiler error: Segmentation fault
   22 | }
  | ^
0xd6fc7f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/toplev.c:326
0x96e542 df_worklist_propagate_backward
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/df-core.c:953
0x96e542 df_worklist_dataflow_doublequeue
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/df-core.c:1043
0x96e542 df_worklist_dataflow(dataflow*, bitmap_head*, int*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/df-core.c:1120
0x96eb2c df_analyze_problem(dataflow*, bitmap_head*, int*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/df-core.c:1174
0x1580c52 fast_dce
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/dce.c:1161
0x1580cd4 rest_of_handle_fast_dce
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190113/work/gcc-9-20190113/gcc/dce.c:1186

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Am testing a fix.

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

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
This is an interesting bug.  Fortran 2003 exlicitly forbids
a procedure pointer from appearing in a READ statement.

F2003:C932 (R915) A variable that is an input-item shall
  not be a procedure pointer.

This constraint is missing in F2008 and F2018.  One then 
looks at from say F2008

R916 input-item  is variable
 or io-implied-do

Well, a procedure pointer is certainly not an io-implied-do.
So, one must argue that a procedure pointer is not a variable.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
On the #c22 testcase this started with r242549, but guess it has been latent
before.

[Bug middle-end/86308] [7/8/9 Regression] ICE in verify_gimple calling an invalid index() declaration

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Looks like I dropped the ball on this.  Let me see if I can still get it done
for GCC 9.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Self-contained testcase which actually fails because of this bug, even e.g.
when compiled with -O0 and gcc 8.2.1.  That doesn't mean this bug shouldn't be
P1, because preventing bootstrap on a primary target is extremely severe.

struct S { int a, b, c; int *d; };
struct T { int *e, *f, *g; } *t = 0;
int *o = 0;

__attribute__((noipa))
void bar (int *x, int y, int z, int w)
{
  if (w == -1)
{
  if (x != 0 || y != 0 || z != 0)
__builtin_abort ();
}
  else if (w != 0 || x != t->g || y != 0 || z != 12)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (struct S *x, struct S *y, int *z, int w)
{
  *o = w;
  if (w)
bar (0, 0, 0, -1);
  x->d = z;
  if (y->d)
y->c = y->c + y->d[0];
  bar (t->g, 0, y->c, 0);
}

int
main ()
{
  int a[4] = { 8, 9, 10, 11 };
  struct S s = { 1, 2, 3, &a[0] };
  struct T u = { 0, 0, &a[3] };
  o = &a[2];
  t = &u;
  foo (&s, &s, &a[1], 5);
  if (s.c != 12 || s.d != &a[1])
__builtin_abort ();
  return 0;
}

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[tromey at gcc dot gnu.org]

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

--- Comment #14 from Tom Tromey  ---
(In reply to Jonathan Wakely from comment #8)
> Something like __builtin_unreachable() to say "trust me" would be nice, but
> I can't think how to do it.

How about an attribute that can be attached to the member?
Then tree-ssa-uninit could check for this and suppress the warning.

[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Should be fixed on trunk by r267957.

[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jan 15 23:29:15 2019
New Revision: 267957

URL: https://gcc.gnu.org/viewcvs?rev=267957&root=gcc&view=rev
Log:
Fix ICE on class-template argument deduction (PR c++/88795)

PR c++/88795 reports an ICE building a function_type for a deduction guide
when the substitution into the function signature fails, due to an
error_mark_node being returned from tsubst_arg_types but not being checked
for.  This error_mark_node gets used as the TYPE_ARG_TYPES, leading to
ICEs in various places that assume this is a TREE_LIST.

This patch checks the result of tsubst_arg_types and propagates the failure
if it returns error_mark_node.  It also adds an assertion to
build_function_type, to fail faster if passed in error_mark_node.

gcc/cp/ChangeLog:
PR c++/88795
* pt.c (build_deduction_guide): Bail out if tsubst_arg_types
fails.

gcc/testsuite/ChangeLog:
PR c++/88795
* g++.dg/template/pr88795.C: New test.

gcc/ChangeLog:
PR c++/88795
* tree.c (build_function_type): Assert that arg_types is not
error_mark_node.


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

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug libstdc++/88859] [8/9 Regression] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
__y is passed in %rsi:

(gdb) p &__y
Address requested for identifier "__y" which is in register $rsi
(gdb) p __y
$24 = {static npos = , _M_len = 10, 
  _M_str = 0x402008 L"costa rica"}
(gdb) p/x $rsi
$25 = 0x402008000a
(gdb) 

   0x00401690 <+32>:mov%rdi,%rdx
   ^^^ This should be "mov %edi, %edx".
   0x00401693 <+35>:shr$0x20,%rsi
   0x00401697 <+39>:shr$0x20,%rdi
   0x0040169b <+43>:callq  0x401050 

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Short testcase -O2 -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16
-mtls-dialect=gnu -marm -march=armv7-a+fp:

struct S { int a, b, c; int *d; };
void bar (int, int, int, int);

void
foo (struct S *x, struct S *y, int *z)
{
  x->d = z;
  if (y->d)
y->c = y->c + y->d[0];
  bar (0, 0, y->c, 0);
}

This one actually isn't miscompiled (dunno how to convince sched2 that it wants
to schedule the ldrd before the x->d store), but if you put a breakpoint on
true_dependence_1 if mem->mode == E_DImode || x->mode == E_DImode, then you
should be able to see that it considers swapping those and doesn't find
aliasing reason not to.

What the peephole2 does is similar to what e.g. store-merging does, which for
alias sets does:
  if (!n1->alias_set
  || alias_ptr_types_compatible_p (n1->alias_set, n2->alias_set))
n->alias_set = n1->alias_set;
  else
n->alias_set = ptr_type_node;
i.e. uses alias set 0 if they aren't compatible.

Another possibility would be to use an alternate pattern for the ldrd when it
is matched by such a peephole2, instead of presenting it as a DImode read
present it as 2 SImode reads, so (set r2 (mem:SI ...)) (set r3 (mem:SI ...)). 
That way you could use the original MEM_ALIAS_SET and MEM_EXPRs.  Seems arm.md
even has similar patterns like *thumb2_ldrd_base.  So, in ldrdstrd.md do a
similar thing for TARGET_ARM as for TARGET_THUMB2, just the TARGET_ARM patterns
would need to also verify the two registers are consecutive (can be done in the
insn condition) and make sure it handles any cases where the two memory
addresses are 4 bytes appart (again, can be done in the insn condition).
I think this would be better than to drop alias set to 0, which then can
prevent optimal scheduling etc.

[Bug c++/88869] New: ICE (Segmentation Fault) when using lambda

[daniel at hebirobotics dot com]

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

Bug ID: 88869
   Summary: ICE (Segmentation Fault) when using lambda
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at hebirobotics dot com
  Target Milestone: ---

I found a bug when trying to pass a lambda to a structure which holds the
lambda along with some additional state. I haven't had time to simply my repro
to see where the code begins to "break," but a segmentation fault is clearly an
indication of something going wrong within the compiler. Clang seems to compile
the godbolt link which GCC struggles with below.

While the version I specified is `8.2.1`, I am not entirely sure which versions
this can be reproduced on. I originally found it on my Fedora 29 machine
running `gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6)`, but it also appears to be
reproducible on the `gcc (trunk)` version from Matt Godbolt's website
(gcc.godbolt.org) as of 15 January 2019.

I have attached a simplified version of the code I found this bug in here:
https://gcc.godbolt.org/z/4LQb4j

[Bug libstdc++/88859] [8/9 Regression] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
Breakpoint 1, std::char_traits::compare (__n=, 
__s2=, __s1=)
at
/export/build/gnu/tools-build/gcc-x32-debug-8/build-x86_64-linux/x86_64-pc-linux-gnu/x32/libstdc++-v3/include/bits/char_traits.h:420
420   return wmemcmp(__s1, __s2, __n);
(gdb) c
Continuing.

Breakpoint 2, __wmemcmp_avx2_movbe ()
at ../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:61
61  shl $2, %rdx
$7 = 18049617241309194
(gdb) p/x $rdx
$8 = 0x402008000a
(gdb) 


18049617241309194 is a bogus length.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[ktkachov at gcc dot gnu.org]

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

--- Comment #20 from ktkachov at gcc dot gnu.org ---
Thanks for investigating this.
At an initial glance, I guess this is something gen_operands_ldrd_strd in
config/arm/arm.c should handle

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek  ---
To me, this looks like buggy arm peephole2.
In *.compgotos pass we have:
(insn 96 95 97 18 (set (mem/f:SI (plus:SI (reg/v/f:SI 4 r4 [orig:137 vr_ ]
[137])
(const_int 12 [0xc])) [12 MEM[(struct vn_reference_s
*)vr__23(D)].vuse+0 S4 A32])
(reg/v/f:SI 12 ip [orig:135 vuse ] [135]))
"/tmp/tree-ssa-sccvn.ii":87248:12 650 {*arm_movsi_vfp}
 (expr_list:REG_DEAD (reg/v/f:SI 12 ip [orig:135 vuse ] [135])
(expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:137 vr_ ] [137])
(nil
(insn 97 96 98 18 (set (reg/f:SI 3 r3 [orig:118 _11 ] [118])
(mem/f:SI (plus:SI (reg/f:SI 1 r1 [orig:123 prephitmp_29 ] [123])
(const_int 12 [0xc])) [12 prephitmp_29->vuse+0 S4 A32]))
"/tmp/tree-ssa-sccvn.ii":87249:11 650 {*arm_movsi_vfp}
 (nil))
(insn 98 97 99 18 (set (reg:SI 2 r2 [orig:120 _14 ] [120])
(mem:SI (plus:SI (reg/f:SI 1 r1 [orig:123 prephitmp_29 ] [123])
(const_int 8 [0x8])) [4 prephitmp_29->hashcode+0 S4 A32])) 650
{*arm_movsi_vfp}
 (nil))

The first stmt is the vr->vuse = ... store from vr->vuse = vuse_ssa_val (vuse);
The next two stmts load vr->hashcode and vr->vuse, but unfortunately the GIMPLE
optimizers weren't able to figure out that
vr is equal to vr__23(D):
  # _42 = PHI 
  # prephitmp_29 = PHI 
  MEM[(struct vn_reference_s *)vr__23(D)].vuse = _42;
  _11 = prephitmp_29->vuse;
  pretmp_49 = prephitmp_29->hashcode;
at that point (note, vr is address taken variable).

Then comes peephole2 and does:
Splitting with gen_peephole2_11
scanning new insn with uid = 217.
deleting insn with uid = 98.
deleting insn with uid = 97.
verify found no changes in insn with uid = 217.

and constructs
(insn 96 95 217 18 (set (mem/f:SI (plus:SI (reg/v/f:SI 4 r4 [orig:137 vr_ ]
[137])
(const_int 12 [0xc])) [12 MEM[(struct vn_reference_s
*)vr__23(D)].vuse+0 S4 A32])
(reg/v/f:SI 12 ip [orig:135 vuse ] [135]))
"/tmp/tree-ssa-sccvn.ii":87248:12 650 {*arm_movsi_vfp}
 (expr_list:REG_DEAD (reg/v/f:SI 12 ip [orig:135 vuse ] [135])
(expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:137 vr_ ] [137])
(nil
(insn 217 96 99 18 (set (reg:DI 2 r2)
(mem:DI (plus:SI (reg/f:SI 1 r1 [orig:123 prephitmp_29 ] [123])
(const_int 8 [0x8])) [4 prephitmp_29->hashcode+0 S8 A32])) -1
 (nil))
out of this.  The insn 217 is a ldrd.  The bug is that the DImode MEM uses the
same MEM_ALIAS_SET and same MEM_EXPR as
that of the SImode prephitmp_29->hashcode read, even when it now covers two
fields of the structure.  So, either it needs to throw away MEM_EXPR and clear
MEM_ALIAS_SET, or find something conservatively correct covering both.

Finally, sched2 comes and swaps the two, because the (incorrect) aliasing info
makes alias.c believe it can swap the two:
(insn:TI 217 116 96 12 (set (reg:DI 2 r2)
(mem:DI (plus:SI (reg/f:SI 1 r1 [orig:123 prephitmp_29 ] [123])
(const_int 8 [0x8])) [4 prephitmp_29->hashcode+0 S8 A32])) 652
{*movdi_vfp}
 (nil))
(insn:TI 96 217 109 12 (set (mem/f:SI (plus:SI (reg/v/f:SI 4 r4 [orig:137 vr_ ]
[137])
(const_int 12 [0xc])) [12 MEM[(struct vn_reference_s
*)vr__23(D)].vuse+0 S4 A32])
(reg/v/f:SI 12 ip [orig:135 vuse ] [135]))
"/tmp/tree-ssa-sccvn.ii":87248:12 650 {*arm_movsi_vfp}
 (expr_list:REG_DEAD (reg/v/f:SI 12 ip [orig:135 vuse ] [135])
(expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:137 vr_ ] [137])
(nil

and thus, instead of using the new vr->vuse value for the vr->hashcode
computation we use the old one.

[Bug libstdc++/88782] [8/9 Regression] Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc > 8.2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9 Regression] Crash when |[8/9 Regression] Crash when
   |mixing make_shared from gcc |mixing make_shared from gcc
   |<= 8.2 with make_shared |<= 8.2 with make_shared
   |from gcc >= 8.3 |from gcc > 8.2

--- Comment #3 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #0)
> The change introduced in r266380 makes newer gcc >= 8.3 and gcc 9

I'm changing the summary to say > 8.2 because there is no 8.3 release yet, so
claiming this affects 8.3 is misleading.

It affects the gcc-8-branch post r266380 which means 8.2.1 (20181122) and
later, but it's going to be fixed before the 8.3 release.

[Bug fortran/43136] Excess copy-in/copy-out with character argument

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Actually fixed in r267953, the original commit had the wrong PR number.

Closing.

[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran

[tkoenig at gcc dot gnu.org]

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

Bug 43136 Summary: Excess copy-in/copy-out with character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43136

   What|Removed |Added

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

[Bug fortran/43136] Excess copy-in/copy-out with character argument

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 15 22:20:26 2019
New Revision: 267954

URL: https://gcc.gnu.org/viewcvs?rev=267954&root=gcc&view=rev
Log:
2019-01-15  Thomas Koenig  

PR fortran/43136
* resolve.c (resolve_array_ref): Add equal_length argument; set it
if the length of the substring equals that of the orignal
variable.
(resolve_ref): Remove the substring if it is equal in length to
the original variable, unless it is an EXPR_SUBSTRING).

2019-01-15  Thomas Koenig  

PR fortran/43136
* gfortran.dg/actual_array_substr_3.f90: New test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug fortran/43072] unneeded temporary (s=s+f(a))

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan 15 22:18:55 2019
New Revision: 267953

URL: https://gcc.gnu.org/viewcvs?rev=267953&root=gcc&view=rev
Log:
2019-01-15  Thomas Koenig  

PR fortran/43072
* resolve.c (resolve_array_ref): Add equal_length argument; set it
if the length of the substring equals that of the orignal
variable.
(resolve_ref): Remove the substring if it is equal in length to
the original variable, unless it is an EXPR_SUBSTRING).

2019-01-15  Thomas Koenig  

PR fortran/43072
* gfortran.dg/actual_array_substr_3.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/actual_array_substr_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
I think the problem is that we're not detecting narrowing conversions in
decltype; which is basically a dup of PR 78244 assigned to... me.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
So, I've hacked up assembly version which contained 2 versions of this function
(good and bad) plus a wrapper function:
void *
vn_reference_lookup_2b (ao_ref *op, tree vuse, unsigned int cnt, void *vr_);
void *
vn_reference_lookup_2c (ao_ref *op, tree vuse, unsigned int cnt, void *vr_);

void *
vn_reference_lookup_2a (ao_ref *op, tree vuse, unsigned int cnt, void *vr_)
{
  vn_reference_t vr = (vn_reference_t)vr_;
  vn_reference_s a = *vr;
  void *r1 = vn_reference_lookup_2a (op, vuse, cnt, vr_);
  vn_reference_s b = *vr;
  *vr = a;
  void *r2 = vn_reference_lookup_2b (op, vuse, cnt, vr_);
  if (r1 != r2 || __builtin_memcmp (vr, &b, sizeof (b)))
fancy_abort (__FILE__, __LINE__, __FUNCTION__);
  return r1;
}

adjusted in the assembly, so that it is actually that vn_reference_lookup_2
that calls the good and bad versions.
This ICEs on the second call to vn_reference_lookup_2.
vuse is .MEM_59, so is vr->vuse on entry and vr->hashcode is 0xd16d45ea.
The
  if (vr->vuse)
vr->hashcode = vr->hashcode - (vr->vuse)->base.u.version;
is performed correctly in both, changing vr->hashcode to 0xd16d45af (i.e.
subtracting 59), next vr->vuse is updated to .MEM_48.
The problem is with the
  if (vr->vuse)
vr->hashcode = vr->hashcode + (vr->vuse)->base.u.version;
in the good version it does what the source tells it to do, adds 48, making
vr->hashcode 0xd16d45df and calling find_slot_with_hash with that value.
But in the bad version, we actually store 0xd16d45ea again.

[Bug libstdc++/88859] [8/9 Regression] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
[hjl@gnu-skx-1 pr88859]$ cat x.cc 
#include 

#define VERIFY(fn) if (!(fn)) __builtin_abort();

int
main() 
{
  std::experimental::wstring_view   str_0(L"costa rica");
  std::experimental::wstring_view   str_1(L"costa marbella");
  std::experimental::wstring_view   str_2(L"cost");
  std::experimental::wstring_view   str_3(L"costa ricans");
  std::experimental::wstring_view  str_4;

  str_4 = str_0;
  VERIFY( !(str_0 == str_1) );
  VERIFY( !(str_0 == str_2) );
  VERIFY( !(str_0 == str_3) );
  VERIFY( !(str_1 == str_0) );
  VERIFY( !(str_2 == str_0) );
  VERIFY( !(str_3 == str_0) );
  VERIFY( str_4 == str_0 );
  VERIFY( str_0 == str_4 );

  VERIFY( !(str_0 == L"costa marbella") );
  VERIFY( !(str_0 == L"cost") );
  VERIFY( !(str_0 == L"costa ricans") );
  VERIFY( !(L"cost" == str_0) );
  VERIFY( !(L"costa ricans" == str_0) );
  VERIFY( L"costa rica" == str_0 );
  VERIFY( str_0 == L"costa rica" );

  VERIFY( L"costa ricans" != str_0 );
  VERIFY( !(L"costa rica" != str_0) );

  return 0;
}
[hjl@gnu-skx-1 pr88859]$ make
g++ -O2 -mx32 -S x.cc
g++ -O2 -mx32 -o x x.s
./x
make: *** [Makefile:12: all] Segmentation fault
[hjl@gnu-skx-1 pr88859]$

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk, branch-8, and branch-7.  Closing.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 15 20:53:13 2019
New Revision: 267952

URL: https://gcc.gnu.org/viewcvs?rev=267952&root=gcc&view=rev
Log:
2019-01-15  Steven G. Kargl  

PR fortran/81849
* resolve.c (resolve_symbol): Host associated varaibles can appear
in the specification statement of a RESULT array.

2019-01-15  Steven G. Kargl  

PR fortran/81849
* gfortran.dg/pr81849.f90: New test.

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

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Assertion fails in dom_info::calc_dfs_tree:

457   /* This aborts e.g. when there is _no_ path from ENTRY to EXIT at
all.  */
458   gcc_assert (m_nodes == (unsigned int) m_n_basic_blocks - 1);

(gdb) p m_nodes
$8 = 9
(gdb) p m_n_basic_blocks 
$9 = 11

Block 9 in .263r.ud_dce has one in-edge from block 6 (insn 29), and no out-edge
Block 9 in .264r.combine has no in-edges or out-edges

Within .263r.ud_dce:

(note 25 69 26 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 26 25 28 6 (set (reg/f:DI 142)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC1") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL) [3  S8 A8])) "/tmp/test.c":7:21 608
{*movdi_internal64}
 (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
(nil)))
(insn 28 26 29 6 (set (reg:SI 135 [ i ])
(mem/c:SI (plus:DI (reg/f:DI 142)
(const_int 4 [0x4])) [1 i+0 S4 A32])) "/tmp/test.c":7:21 494
{*movsi_internal1}
 (expr_list:REG_EQUAL (mem/c:SI (const:DI (plus:DI (symbol_ref:DI
("*.LANCHOR1") [flags 0x182])
(const_int 4 [0x4]))) [1 i+0 S4 A32])
(nil)))
(insn 29 28 30 6 (set (mem:SI (plus:DI (reg/f:DI 142)
(const_int 4 [0x4])) [1 s+4 S4 A32])
(reg:SI 135 [ i ])) "/tmp/test.c":7:21 494 {*movsi_internal1}
 (expr_list:REG_DEAD (reg:SI 135 [ i ])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil

...but within .264r.combine:

[...snip...]
allowing combination of insns 28 and 29
original costs 4 + 4 = 8
replacement cost 0
deferring deletion of insn with uid = 28.
modifying insn i329: [r142:DI+0x4]=[r142:DI+0x4]
  REG_EH_REGION 0x1
deferring rescan insn with uid = 29.
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
Can't combine i2 into i3
deleting noop move 29
deferring deletion of insn with uid = 29.
starting the processing of deferred insns
rescanning insn with uid = 23.
ending the processing of deferred insns

[...snip...]

(note 25 69 26 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 26 25 28 6 (set (reg/f:DI 142)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC1") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL) [3  S8 A8])) "/tmp/test.c":7:21 608
{*movdi_internal64}
 (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
(nil)))
(note 28 26 30 6 NOTE_INSN_DELETED)

which, if I'm reading it right, seems to have deleted the usage of EH region 1,
and has left block 9 orphaned.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 15 20:45:43 2019
New Revision: 267951

URL: https://gcc.gnu.org/viewcvs?rev=267951&root=gcc&view=rev
Log:
2019-01-15  Steven G. Kargl  

PR fortran/81849
* resolve.c (resolve_symbol): Host associated varaibles can appear
in the specification statement of a RESULT array.

2019-01-15  Steven G. Kargl  

PR fortran/81849
* gfortran.dg/pr81849.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr81849.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/88859] [8/9 Regression] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-15
Summary|FAIL:   |[8/9 Regression] FAIL:
   |experimental/string_view/op |experimental/string_view/op
   |erators/wchar_t/2.cc|erators/wchar_t/2.cc
   |execution test  |execution test
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
This was triggered by r254832.  The bug may be latent before.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
It's not obvious to me what machine code is wrong here.  Maybe it is obvious
to someone who is better at Arm code than I am?

Does it all work if you use -fno-if-conversion2 though?  Or, what other
later pass causes it?  Or is the RTL code immediately after combine already
bad?

[Bug c/88726] [7 Regression] GCC thinks that translation unit does not contain a definition of inline function.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|8.3 |7.5
Summary|[7/8 Regression] GCC thinks |[7 Regression] GCC thinks
   |that translation unit does  |that translation unit does
   |not contain a definition of |not contain a definition of
   |inline function.|inline function.

--- Comment #4 from Joseph S. Myers  ---
Also now fixed for GCC 8.3.

[Bug c/88720] [7 Regression] Strange error message about nested function declared but not defined when using inline.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|8.3 |7.5
Summary|[7/8 Regression] Strange|[7 Regression] Strange
   |error message about nested  |error message about nested
   |function declared but not   |function declared but not
   |defined when using inline.  |defined when using inline.

--- Comment #4 from Joseph S. Myers  ---
Also now fixed for GCC 8.3.

[Bug c/88726] [7/8 Regression] GCC thinks that translation unit does not contain a definition of inline function.

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Jan 15 20:32:00 2019
New Revision: 267949

URL: https://gcc.gnu.org/viewcvs?rev=267949&root=gcc&view=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/88720, PR
c/88726).

Bugs 88720 and 88726 report issues where a function is declared inline
in an inner scope, resulting in spurious diagnostics about it being
declared but never defined when that scope is left (possibly in some
cases also wrongly referring to the function as a nested function).
These are regressions that were introduced with the support for C99
inline semantics in 4.3 (they don't appear with 4.2; it's possible
some aspects of the bugs might have been introduced later than 4.3).

For the case of functions being wrongly referred to as nested,
DECL_EXTERNAL was not the right condition for a function being
non-nested; TREE_PUBLIC is appropriate for the case of non-nested
functions with external linkage, while !b->nested means this is the
outermost scope in which the function was declared and so avoids
catching the case of a file-scope static being redeclared inline
inside a function.

For the non-nested, external-linkage case, the code attempts to avoid
duplicate diagnostics by diagnosing only when scope != external_scope,
but actually scope == external_scope is more appropriate, as it's only
when the file and external scopes are popped that the code can
actually tell whether a function ended up being defined, and all such
functions will appear in the (GCC-internal) external scope.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* c-decl.c (pop_scope): Use TREE_PUBLIC and b->nested to determine
whether a function is nested, not DECL_EXTERNAL.  Diagnose inline
functions declared but never defined only for external scope, not
for other scopes.

gcc/testsuite:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* gcc.dg/inline-40.c, gcc.dg/inline-41.c: New tests.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/inline-40.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/inline-41.c
Modified:
branches/gcc-8-branch/gcc/c/ChangeLog
branches/gcc-8-branch/gcc/c/c-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c/88720] [7/8 Regression] Strange error message about nested function declared but not defined when using inline.

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Jan 15 20:32:00 2019
New Revision: 267949

URL: https://gcc.gnu.org/viewcvs?rev=267949&root=gcc&view=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/88720, PR
c/88726).

Bugs 88720 and 88726 report issues where a function is declared inline
in an inner scope, resulting in spurious diagnostics about it being
declared but never defined when that scope is left (possibly in some
cases also wrongly referring to the function as a nested function).
These are regressions that were introduced with the support for C99
inline semantics in 4.3 (they don't appear with 4.2; it's possible
some aspects of the bugs might have been introduced later than 4.3).

For the case of functions being wrongly referred to as nested,
DECL_EXTERNAL was not the right condition for a function being
non-nested; TREE_PUBLIC is appropriate for the case of non-nested
functions with external linkage, while !b->nested means this is the
outermost scope in which the function was declared and so avoids
catching the case of a file-scope static being redeclared inline
inside a function.

For the non-nested, external-linkage case, the code attempts to avoid
duplicate diagnostics by diagnosing only when scope != external_scope,
but actually scope == external_scope is more appropriate, as it's only
when the file and external scopes are popped that the code can
actually tell whether a function ended up being defined, and all such
functions will appear in the (GCC-internal) external scope.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* c-decl.c (pop_scope): Use TREE_PUBLIC and b->nested to determine
whether a function is nested, not DECL_EXTERNAL.  Diagnose inline
functions declared but never defined only for external scope, not
for other scopes.

gcc/testsuite:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* gcc.dg/inline-40.c, gcc.dg/inline-41.c: New tests.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/inline-40.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/inline-41.c
Modified:
branches/gcc-8-branch/gcc/c/ChangeLog
branches/gcc-8-branch/gcc/c/c-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/88868] [SSE] pshufb can be omitted for a specific pattern

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-15
  Component|tree-optimization   |target
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
When the second argument is constant, I think we should turn _mm_shuffle_epi8
into a __builtin_shuffle.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 15 20:17:35 2019
New Revision: 267948

URL: https://gcc.gnu.org/viewcvs?rev=267948&root=gcc&view=rev
Log:
2019-01-15  Steven G. Kargl  

PR fortran/81849
* resolve.c (resolve_symbol): Host associated varaibles can appear
in the specification statement of a RESULT array.

2019-01-15  Steven G. Kargl  

PR fortran/81849
* gfortran.dg/pr81849.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr81849.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88863] ICE in extract_insn, at recog.c:2305

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
dup.

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

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
*** Bug 88863 has been marked as a duplicate of this bug. ***

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Tue, Jan 15, 2019 at 07:21:16PM +, paul.richard.thomas at gmail dot com
wrote:
> 
> Hi Steve and Thomas,
> 
> I plead guilty to creating confusing code... It developed step
> by step and I didn't go back and consolidate it.
> 
> If you can simplify it and still obtain the same result, that
> would be great.
> 

Paul,

I'll take a closer look at the code later this week (unless
Thomas beats me).  I doubt that this is the only confusing
code ever committed. :-)

[Bug c++/88613] [9 Regression] ICE in size_binop_loc at fold-const.c:1900 since r267272

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
Hi Steve and Thomas,

I plead guilty to creating confusing code... It developed step by step
and I didn't go back and consolidate it.

If you can simplify it and still obtain the same result, that would be great.

Cheers

Paul

On Tue, 15 Jan 2019 at 15:36, sgk at troutmask dot apl.washington.edu
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810
>
> --- Comment #5 from Steve Kargl  ---
> On Tue, Jan 15, 2019 at 12:39:13PM +, tkoenig at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810
> >
> > Thomas Koenig  changed:
> >
> >What|Removed |Added
> > 
> >  CC||tkoenig at gcc dot gnu.org
> >
> > --- Comment #4 from Thomas Koenig  ---
> > As far as I can see, the duplicated code does not do anything bad,
> > and removing the duplicate also would not do anything bad.
> >
> > A patch removing the duplication is pre-approved, provided it
> > passes a regression test.
> >
>
> Are you sure it is duplicate code?
>
> Here, if reverse[m] == GFC_ENABLE_REVERSE and this_dep == GFC_DEP_BACKWARD,
> then reverse[m] is update to GFC_REVERSE_SET; otherwise it is left as-is
> which is GFC_ENABLE_REVERSE.
>
> /* Set reverse if backward dependence and not inhibited.  */
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
>   reverse[m] = (this_dep == GFC_DEP_BACKWARD) ?
> GFC_REVERSE_SET : reverse[m];
>
> Here, if reverse[m] was updated to GFC_REVERSE_SET, the first
> conditional fails and reverse[m] is left unchanged.  However, if
> reverse[m] was left unchanged from above, it is then GFC_ENABLE_REVERSE.
> gfortran then checks this_dep == GFC_DEP_FORWARD and updates accordingly.
>
> /* Set forward if forward dependence and not inhibited.  */
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
>   reverse[m] = (this_dep == GFC_DEP_FORWARD) ?
> GFC_FORWARD_SET : reverse[m];
>
> The code is likely correct as-is, but confusing.  Some would have
> written
>
> /* Set reverse if backward dependence and not inhibited.  */
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE
>  && this_dep == GFC_DEP_BACKWARD)
>   reverse[m] = GFC_REVERSE_SET;
>
> /* Set forward if forward dependence and not inhibited.  */
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE
> && this_dep == GFC_DEP_FORWARD)
>   reverse[m] = GFC_FORWARD_SET;
>
> or
>
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
>   {
>  if (this_dep == GFC_DEP_BACKWARD)
>reverse[m] = GFC_REVERSE_SET;
>  else if (this_dep == GFC_DEP_FORWARD)
>reverse[m] = GFC_FORWARD_SET;
>   }
>
> If this_dep can only take on the values of GFC_REVERSE_SET and
> GFC_DEP_FORWARD, then the above can be collapsed to
>
> if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
>reverse[m] = this_dep == GFC_DEP_BACKWARD
>   ? GFC_REVERSE_SET : GFC_FORWARD_SET;
>
> Looks like this PR is a false positive.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-15
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed (with target==ppc64le-redhat-linux)

[Bug tree-optimization/88867] -Waggressive-loop-optimizations doesn't warn when -faggressive-loop-optimizations is in play

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to John Levon from comment #2)
> There is no Address Sanitizer in our kernel, bootloaders etc.

There is support for asan in the Linux kernel and maybe others.  Again security
is about auditing and not just about warnings.

[Bug tree-optimization/88867] -Waggressive-loop-optimizations doesn't warn when -faggressive-loop-optimizations is in play

[levon at movementarian dot org]

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

--- Comment #2 from John Levon  ---
There is no Address Sanitizer in our kernel, bootloaders etc.

[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00865.html

[Bug c++/88312] [9 regression] Mishandled explicitly provided parameter pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88868] New: [SSE] pshufb can be omitted for a specific pattern

[wojciech_mula at poczta dot onet.pl]

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

Bug ID: 88868
   Summary: [SSE] pshufb can be omitted for a specific pattern
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech_mula at poczta dot onet.pl
  Target Milestone: ---

SSSE3 instruction PSHUFB (and the AVX2 counterpart VPSHUFB) acts as a
no-operation
when its argument is a sequence 0..15. Such invocation does not alter shuffled
register, thus PSHUFB can be safely omitted

BTW, clang does this optimization, but ICC doesn't.

---pshufb.c---
#include 

__m128i shuffle(__m128i x) {
const __m128i noop = _mm_setr_epi8(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
12, 13, 14, 15);
return _mm_shuffle_epi8(x, noop);
}
---eof---

$ gcc --version
gcc (Debian 8.2.0-13) 8.2.0

$ gcc -O3 -march=skylake -S pshufb.c 
$ cat pshufb.s
shuffle:
vpshufb .LC0(%rip), %xmm0, %xmm0
ret
.LC0:
.byte   0
.byte   1
.byte   2
.byte   3
.byte   4
.byte   5
.byte   6
.byte   7
.byte   8
.byte   9
.byte   10
.byte   11
.byte   12
.byte   13
.byte   14
.byte   15

An expected output:

shuffle:
ret

[Bug c++/88866] [9 Regression] g++.dg/cpp0x/variadic126.C fails with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/88866] [9 Regression] g++.dg/cpp0x/variadic126.C fails with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan 15 18:35:01 2019
New Revision: 267944

URL: https://gcc.gnu.org/viewcvs?rev=267944&root=gcc&view=rev
Log:
PR c++/88866
* g++.dg/cpp0x/variadic126.C: Tweak dg-error.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/variadic126.C

[Bug c/85949] __attribute__ ((format (printf,1,1))); improve error messages

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
There are two kinds of warnings for printf-type functions: -Wformat implemented
in the front-ends, and -Wformat-overflow/truncation implemented in the
middle-end.  The former detects mostly just type-based errors and doesn't
depend on optimization, while the latter detects errors that depend on control
and data flow analyses exposed by optimization (buffer overflow, truncation,
null pointers, and some uses of  unterminated character arrays as %s
arguments).  Some bugs that are in the intersection of the two are not detected
by either.

The test case in attachment 45435 is of the latter kind: it depends on data
flow analysis.  With optimization enabled it can detect the bug in the second
call to str_fmt(), but only if the call uses the arguments (or is not known not
to use it).  The extra argument in the first call to str_fmt() is not detected
-- it's in the third class of problems: the front-end doesn't see the value of
the format string and the middle-end doesn't check for extra arguments.

Ideally, there would be just one implementation of all format warnings that did
all kinds of checking, but merging the two existing implementations would be a
lot of effort.  Short of that, we could look into moving (or duplicating) some
of the same front-end checks into the middle-end in cases where it's important.
 The trick is to avoid issuing duplicate warnings between the two sets of
checks.  The caveat with that, though, is that detecting the problems with
non-constants only works with optimization.

$ cat t.c && gcc -O2  -S -Wall t.c
void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,1,2)));

int main()
{
const int i = 0;
const char * str = "abc";
const char * str2 = "%s";

str_fmt(str, i);

str_fmt(str2, i);
}
t.c: In function ‘main’:
t.c:11:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   11 | str_fmt(str2, i);
  | ^~~~

[Bug fortran/88803] gfortran documentation warning: '.' or ',' must follow @xref

[dominiq at gcc dot gnu.org]

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

--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Jan 15 18:26:07 2019
New Revision: 267943

URL: https://gcc.gnu.org/viewcvs?rev=267943&root=gcc&view=rev
Log:
2019-01-15  Dominique d'Humieres  

PR fortran/88803
* gfortran.texi: Replace @xref with @ref and adjust the sentence.


Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/gfortran.texi

[Bug tree-optimization/88867] -Waggressive-loop-optimizations doesn't warn when -faggressive-loop-optimizations is in play

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---
>Otherwise, such code becomes impossible to find and fix.

I think with Address Santizier you could find it and fix it.

That being said security is about auditing and putting in place auditing
methods.

[Bug c/88867] New: -Waggressive-loop-optimizations doesn't warn when -faggressive-loop-optimizations is in play

[levon at movementarian dot org]

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

Bug ID: 88867
   Summary: -Waggressive-loop-optimizations doesn't warn when
-faggressive-loop-optimizations is in play
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: levon at movementarian dot org
  Target Milestone: ---

Given how dangerous -faggressive-loop-optimizations has been proven to be, it's
unfortunate that -Waggressive-loop-optimizations is non-functional in even
simple cases. For example this test case:

#define NULL ((void *)0)

static char *arr[2] = { "nasal", "demons" };

long
func()
{
int i;

for (i = 0; i <= 2; i++) {
if (arr[i] == NULL && i == 0)
return (0xbad);
}

return (0xfad);
}

Is optimized to "return 0xbad" with -faggressive-loop-optimizations, but it is
not possible to get GCC to warn about this. -Waggressive-loop-optimizations
should warn every single time it relies on out-of-bounds behaviour like this.
Otherwise, such code becomes impossible to find and fix.

Same with trunk gcc on godbolt:

https://godbolt.org/z/MN1beq

[Bug c++/88866] [9 Regression] g++.dg/cpp0x/variadic126.C fails with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|rejects-valid   |

--- Comment #1 from Marek Polacek  ---
Ah actually that's invalid code and the error message just needs tweaking.  No
need for tentative parsing.

[Bug c/85949] __attribute__ ((format (printf,1,1))); improve error messages

[jg at jguk dot org]

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

--- Comment #6 from Jonny Grant  ---
Created attachment 45435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45435&action=edit
Could these be detected as errors?

[Bug c/85949] __attribute__ ((format (printf,1,1))); improve error messages

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Unfortunately, not easily.  By the time attribute arguments are being validated
their location information has been stripped.  Keeping it around is possible
but will likely involve some intrusive changes that would not be appropriate at
this stage of GCC 9 development.  Hopefully we can improve things in GCC 10. 
David Malcolm has been doing great work in the area of diagnostic location
information so maybe it's already on his to-do list.

[Bug fortran/43210] Initializer of huge static arrays should be improved

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Dominique d'Humieres  ---
This PR is almost ten year old. Any point to let it rot anymore?

[Bug c++/88866] New: g++.dg/cpp0x/variadic126.C fails with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Bug ID: 88866
   Summary: g++.dg/cpp0x/variadic126.C fails with -std=c++2a
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

FAIL: g++.dg/cpp0x/variadic126.C  -std=c++2a  (test for errors, line 6)
FAIL: g++.dg/cpp0x/variadic126.C  -std=c++2a (test for excess errors)

error: type/value mismatch at argument 1 in template parameter list for
'template struct A'
error: expected '{' before ';' token

starting with r267741.  Perhaps we need tentative parsing after all...

[Bug c++/88866] g++.dg/cpp0x/variadic126.C fails with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-15
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/88865] New: [[no_unique_address]] leads to sizeof(T) == 0, which cannot be

[redbeard0531 at gmail dot com]

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

Bug ID: 88865
   Summary: [[no_unique_address]] leads to sizeof(T) == 0, which
cannot be
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/rJT5X9

struct B {};
struct A {
[[no_unique_address]] B a;
[[no_unique_address]] B b;
[[no_unique_address]] B c;
[[no_unique_address]] B d;
};

int f() {
return sizeof(A);
}

f():
pushrbp
mov rbp, rsp
mov eax, 0
pop rbp
ret

In addition to the major issue that sizeof(A) must not be 0, it also must not
be 1 either. It must be (at least) 4.
http://eel.is/c++draft/intro.object#9.sentence-2 is very clear that
[[no_unique_address]] (which clauses 7 and 8 define to mean a "subobject of
zero size") only allows members of *different types* to overlap. a,b,c, and d
are all distinct objects of the same type B, and therefore must have distinct
addresses.

> Two objects with overlapping lifetimes that are not bit-fields may have the 
> same address if one is nested within the other, or if at least one is a 
> subobject of zero size and they are of different types; otherwise, they have 
> distinct addresses and occupy disjoint bytes of storage.


https://godbolt.org/z/160XGN shows that some parts of gcc seem to understand
this rule, some something very strange must be going on.

[Bug inline-asm/52813] %rsp in clobber list is silently ignored

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Jan 15 16:46:54 2019
New Revision: 267941

URL: https://gcc.gnu.org/viewcvs?rev=267941&root=gcc&view=rev
Log:
PR inline-asm/52813 revisited

The original patch for this PR made it an error to list the stack
pointer in the clobber list of an inline asm.  However, the general
feeling seemed to be that going straight to a hard error was too harsh,
since there's quite a bit of existing code that has the clobber.

This patch implements the compromise discussed on IRC of making it
a -Wdeprecated warning instead.

2019-01-15  Richard Sandiford  

gcc/
PR inline-asm/52813
* doc/extend.texi: Document that listing the stack pointer in the
clobber list of an asm is a deprecated feature.
* common.opt (Wdeprecated): Moved from c-family/c.opt.
* cfgexpand.c (asm_clobber_reg_is_valid): Issue a -Wdeprecated
warning instead of an error for clobbers of the stack pointer.
Add a note explaining why.

gcc/c-family/
PR inline-asm/52813
* c.opt (Wdeprecated): Move documentation and variable to common.opt.

gcc/d/
PR inline-asm/52813
* lang.opt (Wdeprecated): Reference common.opt instead of c.opt.

gcc/testsuite/
PR inline-asm/52813
* gcc.target/i386/pr52813.c (test1): Turn the diagnostic into a
-Wdeprecated warning and expect a following note:.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cfgexpand.c
trunk/gcc/common.opt
trunk/gcc/d/ChangeLog
trunk/gcc/d/lang.opt
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr52813.c

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #33 from Rainer Orth  ---
Unless I'm mistaken, we've now established that there's no bug in gcc here.
Thus closing as invalid.

[Bug c++/88864] New: default template arguments not merged across all declarations

[barry.revzin at gmail dot com]

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

Bug ID: 88864
   Summary: default template arguments not merged across all
declarations
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Shorter repro from StackOverflow https://stackoverflow.com/q/54202462/2069064:

struct B {
template B(T t);
};

template 
B::B(T t) { }

B b(3);


This is rejected by all versions of gcc because of an inability to deduce U.

[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  ---
> (6) ...

The additional patch

--- ../_clean/gcc/fortran/symbol.c  2019-01-09 22:54:02.0 +0100
+++ gcc/fortran/symbol.c2019-01-15 16:28:17.0 +0100
@@ -1306,9 +1306,7 @@ gfc_add_save (symbol_attribute *attr, sa
   if (s == SAVE_EXPLICIT)
 gfc_unset_implicit_pure (NULL);

-  if (s == SAVE_EXPLICIT && attr->save == SAVE_EXPLICIT)
+  if (s == SAVE_EXPLICIT && attr->save == SAVE_EXPLICIT && flag_automatic)
 {
   if (!gfc_notify_std (GFC_STD_LEGACY,
 "Duplicate SAVE attribute specified at %L",

silences the warnings (errors).

Do we need to add to the -fno-automatic doc a note saying that TUs with
variables having an explicit SAVE attribute are silently accepted (even with
-std=f*)?

Along this line do we need to forbid it with -pedantic (by adding &&
!pedantic)?

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
so, no... it doesn't have a name.

(lldb) p ((tree)0x1446212f8)->decl_minimal.name
(tree) $5 = 0x

[Bug libstdc++/70303] Value-initialized debug iterators

[Casey at Carter dot net]

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

--- Comment #5 from Casey Carter  ---
IIRC my reasoning was that [random.access.iterators] specifies the operational
semantics of `a < b` to be `b - a > 0`, which suggests but doesn't quite
require that `a < b` is valid whenever `b - a` is valid.

[Bug libstdc++/70303] Value-initialized debug iterators

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #4 from Casey Carter  ---
(In reply to Jonathan Wakely from comment #3)
> Or is the implication of equality being valid that a+n is valid for n==0,
> and therefore b-a is valid, and therefore relational ops are valid?

Certainly b-a is required to be valid, since such an n exists as required by
[random.access.iterators] - but admittedly the IS doesn't specify the domain
for relational comparisons on Cpp17 iterators. IMO this is a defect since it
implies you can *never* compare two iterators with e.g. <. 

We should require the domain of relational comparisons to be the same as the
domain of equality, which would then make it clear that value-initialized
iterators are in their domain. (I was under the impression that we *did*
require this "somewhere" when I filed this issue and fixed MSFTL's iterators.)

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Some more progress.
I've used
--- gcc/combine.c.jj2019-01-10 11:43:17.050333949 +0100
+++ gcc/combine.c   2019-01-15 14:47:28.009094300 +0100
@@ -2319,6 +2319,9 @@ contains_muldiv (rtx x)
 }
 }


+int cxcnt = -1;
+int cxcurcnt = 0;
+
 /* Determine whether INSN can be used in a combination.  Return nonzero if
not.  This is used in try_combine to detect early some cases where we
can't perform combinations.  */
@@ -2361,7 +2364,8 @@ cant_combine_insn_p (rtx_insn *insn)
 #endif
  || (HARD_REGISTER_P (dest)
  && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (dest))
- && targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO
(dest))
+ && (targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO
(dest)))
+ || (getenv ("COMBINE_FIRST") && cxcurcnt == cxcnt)
 return 1;

   return 0;
@@ -14993,6 +14997,12 @@ make_more_copies (void)
 {
   basic_block bb;

+  if (cxcnt == -1 && getenv ("COMBINE_CNT"))
+cxcnt = atoi (getenv ("COMBINE_CNT"));
+  ++cxcurcnt;
+  if (getenv ("COMBINE_SECOND") && cxcurcnt == cxcnt)
+return;
+
   FOR_EACH_BB_FN (bb, cfun)
 {
   rtx_insn *insn;

hack to undo both or any one of the two changes r265398 did on the function of
my choice (initialy for binary search I was using cxcurcnt >= cxcnt instead of
cxcurcnt == cxcnt in the two spots), and found that with
COMBINE_CNT=74 COMBINE_FIRST=1 COMBINE_SECOND=1
sort.i works as in stage1, so  it is
_ZL21vn_reference_lookup_2P6ao_refP9tree_nodejPv that actually matters.
COMBINE_CNT=74 COMBINE_SECOND=1 generates the same (good assembly) as
COMBINE_CNT=74 COMBINE_FIRST=1 COMBINE_SECOND=1, while
COMBINE_CNT=74 COMBINE_FIRST=1 doesn't work the same as COMBINE_CNT=200.
The "bad" to "good" assembly difference is:
.type   _ZL21vn_reference_lookup_2P6ao_refP9tree_nodejPv, %function
 _ZL21vn_reference_lookup_2P6ao_refP9tree_nodejPv:
.fnstart
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
movwr0, #:lower16:global_options
-   mov ip, r1
-   movtr0, #:upper16:global_options
push{r4, r5, r6, lr}
.save {r4, r5, r6, lr}
-   ldr r0, [r0, #88]
+   movtr0, #:upper16:global_options
+   mov r5, r3
.pad #8
sub sp, sp, #8
-   str r3, [sp]
-   ldr r1, [r0, #540]
-   cmp r1, r2
+   ldr r3, [r0, #88]
+   str r5, [sp]
+   ldr r3, [r3, #540]
+   cmp r3, r2
bcc .L2103
-   movwr5, #:lower16:.LANCHOR1
-   mov r4, r3
-   movtr5, #:upper16:.LANCHOR1
-   ldr r3, [r5, #176]
+   movwr4, #:lower16:.LANCHOR1
+   mov ip, r1
+   movtr4, #:upper16:.LANCHOR1
+   ldr r3, [r4, #176]
cmp r3, #0
-   strne   ip, [r3]
-   ldr r3, [r4, #12]
+   strne   r1, [r3]
+   ldr r3, [r5, #12]
cmp r3, #0
ldrne   r2, [r3, #4]
-   ldrne   r3, [r4, #8]
+   ldrne   r3, [r5, #8]
subne   r3, r3, r2
-   strne   r3, [r4, #8]
-   cmp ip, #0
+   strne   r3, [r5, #8]
+   cmp r1, #0
beq .L2104
-   ldr r6, [r5, #12]
+   ldr r6, [r4, #12]
b   .L2101
 .L2127:
-   ldr ip, [r2, #4]
+   ldr ip, [r3, #4]
 .L2099:
-   ldr r3, [r5, #8]
+   ldr r3, [r4, #8]
cmp r3, ip
beq .L2125
ldrbr3, [ip, #3]@ zero_extendqisi2
tst r3, #2
beq .L2126
 .L2101:
ldr r2, [ip, #4]
add r1, sp, #4
mov r0, r6
str ip, [sp, #4]
bl 
_ZN10hash_tableI17vn_ssa_aux_hasher11xcallocatorE14find_with_hashERKP9tree_nodej
-   ldr r2, [r0]
-   cmp r2, #0
+   ldr r3, [r0]
+   cmp r3, #0
beq .L2098
-   ldrbr3, [r2, #16]   @ zero_extendqisi2
-   tst r3, #1
+   ldrbr2, [r3, #16]   @ zero_extendqisi2
+   tst r2, #1
bne .L2127
 .L2098:
ldr ip, [sp, #4]
b   .L2099
 .L2126:
-   ldr r1, [sp]
+   ldr r3, [sp]
 .L2097:
-   ldrdr2, [r1, #8]
-   str ip, [r4, #12]
-   ldr r0, [r5, #28]
-   cmp r3, #0
-   ldrne   r3, [r3, #4]
+   str ip, [r5, #12]
+   ldr r1, [r3, #12]
+   ldr r2, [r3, #8]
+   ldr r0, [r4, #28]
+   cmp r1, #0
+   ldrne   r1, [r1, #4]
ldr r0, [r0, #8]
-   addne   r2, r2, r3
-   mov r3, #0
-   strne   r2, [r1, #8]
+   addne   r2, r2, r1
mov r1, sp
+   strne   r2, [r3, #8]
+   mov r3, #0
bl 
_ZN10hash_tableI19vn_reference_hasher11xcallocatorE19find_slot_with_hashERKP14vn_reference_sj13insert_option
cmp r0, #0
ldrne   r0,

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
dunno if this is helpful...

frame #4: 0x0001007b4288 lto1`::add_pubtype(decl=0x000144625f18,
die=0x000144627f50) at dwarf2out.c:11333
   11330  scope = TYPE_P (decl) ? TYPE_CONTEXT (decl) : NULL;
   11331  if (scope && TREE_CODE (scope) == NAMESPACE_DECL)
   11332{
-> 11333  scope_name = lang_hooks.dwarf_name (scope, 1);
   11334  if (scope_name != NULL && scope_name[0] != '\0')
   11335scope_name = concat (scope_name, sep, NULL);
   11336  else

(lldb) p (void)debug_tree(decl)
 
constant 8>
unit-size 
constant 1>
align:8 warn_if_not_align:0 symtab:1147305808 alias-set -1 canonical-type
0x144625f18 context >
(lldb) p (void)debug_tree((tree) 0x1446212f8)
 >
VOID /src/gcc-trunk/gcc/testsuite/g++.dg/asan/pr78651.C:7:1
align:1 warn_if_not_align:0 context >

[Bug debug/86549] [8/9 Regression] -flto -g0 vs. -g issues

[rguenth at gcc dot gnu.org]

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

Bug 88046 Summary: [9 Regression] ICE in add_data_member_location_attribute at 
gcc/dwarf2out.c:19237 since r261885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046

   What|Removed |Added

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

[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 15 16:06:42 2019
New Revision: 267940

URL: https://gcc.gnu.org/viewcvs?rev=267940&root=gcc&view=rev
Log:
2019-01-15  Richard Biener  

PR debug/88046
* dwarf2out.c (gen_member_die): Do not generate inheritance
DIEs late.

* g++.dg/lto/pr88046_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr88046_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
That means we have unreachable blocks.

[Bug tree-optimization/88862] ICE in extract_affine, at graphite-sese-to-poly.c:313

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Richard Biener from comment #7)
> > (In reply to Iain Sandoe from comment #5)
> > > =  pr78651 is:
> > > 
> > > $ /XC/9.4/usr/bin/lldb --
> > > /scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1 -fPIC
> > > -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase pr78651.exe
> > > -mmacosx-version-min=10.12.0 -mtune=core2 -m32 
> > > -mmacosx-version-min=10.12.0
> > > -mtune=core2 -auxbase-strip pr78651.exe.lto.o -g -O2 -O2 -version
> > > -fdiagnostics-color=never -fno-openmp -fno-openacc -fsanitize=address
> > > -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
> > > -fmessage-length=0 -flto-partition=none -fpic
> > > @/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccUkv7Up -o pr78651.s
> > > (lldb) target create
> > > "/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1"
> > > Current executable set to
> > > '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1'
> > > (x86_64).
> > > (lldb) settings set -- target.run-args  "-fPIC"
> > > "-feliminate-unused-debug-symbols" "-quiet" "-dumpdir" "./" "-dumpbase"
> > > "pr78651.exe" "-mmacosx-version-min=10.12.0" "-mtune=core2" "-m32"
> > > "-mmacosx-version-min=10.12.0" "-mtune=core2" "-auxbase-strip"
> > > "pr78651.exe.lto.o" "-g" "-O2" "-O2" "-version" 
> > > "-fdiagnostics-color=never"
> > > "-fno-openmp" "-fno-openacc" "-fsanitize=address"
> > > "-fno-diagnostics-show-caret" "-fno-diagnostics-show-line-numbers"
> > > "-fmessage-length=0" "-flto-partition=none" "-fpic"
> > > "@/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccUkv7Up" "-o"
> > > "pr78651.s"
> > > (lldb) b internal_error
> > > r
> > > Breakpoint 1: where = lto1`internal_error(char const*, ...) + 121 
> > > [inlined]
> > > _ZN21auto_diagnostic_groupC4Ev, address = 0x0001010abcb9
> > > (lldb) r
> > > Process 22101 launched:
> > > '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1'
> > > (x86_64)
> > > GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> > > 267925] (x86_64-apple-darwin16)
> > >   compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> > > 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> > > version isl-0.20-GMP
> > > 
> > > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> > > GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> > > 267925] (x86_64-apple-darwin16)
> > >   compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> > > 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> > > version isl-0.20-GMP
> > > 
> > > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> > > Process 22101 stopped
> > > * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> > > frame #0: 0x0001010abcb9 lto1`internal_error(char const*, ...)
> > > [inlined] _ZN21auto_diagnostic_groupC4Ev(this=) at
> > > diagnostic.c:1616
> > >1613   
> > >1614   auto_diagnostic_group::auto_diagnostic_group ()
> > >1615   {
> > > -> 1616 global_dc->diagnostic_group_nesting_depth++;
> > >1617   }
> > >1618   
> > >1619   /* Destructor: "pop" this group from global_dc.  */
> > > Target 0: (lto1) stopped.
> > > (lldb) bt
> > > * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> > >   * frame #0: 0x0001010abcb9 lto1`internal_error(char const*, ...)
> > > [inlined] _ZN21auto_diagnostic_groupC4Ev(this=) at
> > > diagnostic.c:1616
> > > frame #1: 0x0001010abcb9 lto1`internal_error(gmsgid="in %s, at
> > > %s:%d")
> > > frame #2: 0x00010170bf9c lto1`fancy_abort(file=,
> > > line=, function=) at diagnostic.c:1607
> > > frame #3: 0x0001015991fc lto1`lhd_decl_printable_name(tree_node*,
> > > int) at langhooks.c:222
> > > frame #4: 0x0001007b4288 
> > > lto1`::add_pubtype(decl=0x000143e25f18,
> > > die=0x000143e27f50) at dwarf2out.c:11333
> > > frame #5: 0x0001007e70f1
> > > lto1`::gen_struct_or_union_type_die(type=0x000143e25f18,
> > > context_die=, usage=) at dwarf2out.c:25256
> 
> 
> > 
> > That I can't reproduce even when backing out all dwarf2out.c changes.
> 
> pubnames are on by default on Darwin, and not for Linux?

True.  But -g[gnu-]pubnames doesn't change things :/  So we run into

const char *
lhd_decl_printable_name (tree decl, int ARG_UNUSED (verbosity))
{
  gcc_assert (decl && DECL_NAME (decl));
  return IDENTIFIER_POINTER (DECL_NAME (decl));

with a decl without a name?

[Bug target/88863] New: ICE in extract_insn, at recog.c:2305

[marxin at gcc dot gnu.org]

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

Bug ID: 88863
   Summary: ICE in extract_insn, at recog.c:2305
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: ppc64-linux-gnu

Following is causing trouble:

$ cat math.i
int a;
void b() {
  __builtin_log(a);
  __builtin_logf(a);
  __builtin_logl(a);
  __builtin_log10f(a);
  __builtin_log10l(a);
  __builtin_log1p(a);
  __builtin_log2f(a);
}

$ ppc64-linux-gnu-gcc -fno-tree-dce -fno-tree-sink -Ofast -c math.i -c
math.i: In function ‘b’:
math.i:10:1: error: unrecognizable insn:
   10 | }
  | ^
(insn 21 20 22 4 (set (reg:DI 138)
(ungt:DI (reg:CCFP 137)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
math.i:10:1: internal compiler error: in extract_insn, at recog.c:2305
0x577d1d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:108
0x577d39 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:116
0x577226 extract_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/recog.c:2305
0x7cc4ef instantiate_virtual_regs_in_insn
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:1605
0x7cc4ef instantiate_virtual_regs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:1975
0x7cc4ef execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/function.c:2024

[Bug tree-optimization/88862] ICE in extract_affine, at graphite-sese-to-poly.c:313

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug tree-optimization/88862] New: ICE in extract_affine, at graphite-sese-to-poly.c:313

[marxin at gcc dot gnu.org]

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

Bug ID: 88862
   Summary: ICE in extract_affine, at graphite-sese-to-poly.c:313
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabihf

One graphite ICE:

$ arm-linux-gnueabi-gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/loc_2.f90 -O2
-fno-tree-loop-im --param graphite-max-nb-scop-params=2147483647
-fgraphite-identity -fwrapv
during GIMPLE pass: graphite
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/loc_2.f90:19:0:

   19 | subroutine testloc
  | 
internal compiler error: in extract_affine, at graphite-sese-to-poly.c:313
0x118db5d extract_affine
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:313
0x118dced extract_affine
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:293
0x118ef2a add_condition_to_pbb
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:347
0x118ef2a add_conditions_to_domain
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:414
0x118ef2a build_iteration_domains
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:864
0x118f107 build_poly_scop(scop*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite-sese-to-poly.c:1213
0x11821e8 graphite_transform_loops()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite.c:406
0x11825b0 graphite_transforms
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite.c:476
0x11825b0 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/graphite.c:553

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug target/88861] New: [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[marxin at gcc dot gnu.org]

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

Bug ID: 88861
   Summary: [9 Regression] ICE in calc_dfs_tree, at
dominance.c:458
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: ppc64-linux-gnu

Following is causing ICE:

$ cat flex.ii
struct Ax {
  int n, a[];
};

int i = 12345678;
int main() {
  static Ax s{456, i};
  ((s.a[0]) ? (void)0 : (void)0);
}

$ ppc64-linux-gnu-g++ flex.ii -O2 -fnon-call-exceptions -c

during RTL pass: ce2
flex.ii: In function ‘int main()’:
flex.ii:9:1: internal compiler error: in calc_dfs_tree, at dominance.c:458
9 | }
  | ^
0x5923df calc_dfs_tree
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/dominance.c:458
0x82365d calculate_dominance_info(cdi_direction)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/dominance.c:734
0x7c476d flow_loops_find(loops*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/cfgloop.c:431
0x9ed2ae loop_optimizer_init(unsigned int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/loop-init.c:93
0x117c280 if_convert
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/ifcvt.c:5374
0x117dc1d execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/ifcvt.c:5553

[Bug libstdc++/88859] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> Is r267938 a bisection result?

No.

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Richard Biener from comment #7)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Richard Biener from comment #4)
> > > Hmm, I can no longer reproduce -g0 vs -g on x86_64-linux.  Ians 
> > > testresults
> > > now
> > > list
> > > 

> > > but I can't reproduce with pr62017.C or pr78651.C either right now.
> > 
> > 81021 has indeed started to pass (I didn't notice when).
> > 
> > = 62017 is:
 
> OK, that's PR88046 for which I have a patch in my tree.

great.
> 
> > 
> > =  pr78651 is:
> > 
> > $ /XC/9.4/usr/bin/lldb --
> > /scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1 -fPIC
> > -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase pr78651.exe
> > -mmacosx-version-min=10.12.0 -mtune=core2 -m32 -mmacosx-version-min=10.12.0
> > -mtune=core2 -auxbase-strip pr78651.exe.lto.o -g -O2 -O2 -version
> > -fdiagnostics-color=never -fno-openmp -fno-openacc -fsanitize=address
> > -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
> > -fmessage-length=0 -flto-partition=none -fpic
> > @/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccUkv7Up -o pr78651.s
> > (lldb) target create
> > "/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1"
> > Current executable set to
> > '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1'
> > (x86_64).
> > (lldb) settings set -- target.run-args  "-fPIC"
> > "-feliminate-unused-debug-symbols" "-quiet" "-dumpdir" "./" "-dumpbase"
> > "pr78651.exe" "-mmacosx-version-min=10.12.0" "-mtune=core2" "-m32"
> > "-mmacosx-version-min=10.12.0" "-mtune=core2" "-auxbase-strip"
> > "pr78651.exe.lto.o" "-g" "-O2" "-O2" "-version" "-fdiagnostics-color=never"
> > "-fno-openmp" "-fno-openacc" "-fsanitize=address"
> > "-fno-diagnostics-show-caret" "-fno-diagnostics-show-line-numbers"
> > "-fmessage-length=0" "-flto-partition=none" "-fpic"
> > "@/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccUkv7Up" "-o"
> > "pr78651.s"
> > (lldb) b internal_error
> > r
> > Breakpoint 1: where = lto1`internal_error(char const*, ...) + 121 [inlined]
> > _ZN21auto_diagnostic_groupC4Ev, address = 0x0001010abcb9
> > (lldb) r
> > Process 22101 launched:
> > '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++2/../../lto1'
> > (x86_64)
> > GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> > 267925] (x86_64-apple-darwin16)
> > compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> > 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> > version isl-0.20-GMP
> > 
> > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> > GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> > 267925] (x86_64-apple-darwin16)
> > compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> > 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> > version isl-0.20-GMP
> > 
> > GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> > Process 22101 stopped
> > * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> > frame #0: 0x0001010abcb9 lto1`internal_error(char const*, ...)
> > [inlined] _ZN21auto_diagnostic_groupC4Ev(this=) at
> > diagnostic.c:1616
> >1613 
> >1614 auto_diagnostic_group::auto_diagnostic_group ()
> >1615 {
> > -> 1616   global_dc->diagnostic_group_nesting_depth++;
> >1617 }
> >1618 
> >1619 /* Destructor: "pop" this group from global_dc.  */
> > Target 0: (lto1) stopped.
> > (lldb) bt
> > * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> >   * frame #0: 0x0001010abcb9 lto1`internal_error(char const*, ...)
> > [inlined] _ZN21auto_diagnostic_groupC4Ev(this=) at
> > diagnostic.c:1616
> > frame #1: 0x0001010abcb9 lto1`internal_error(gmsgid="in %s, at
> > %s:%d")
> > frame #2: 0x00010170bf9c lto1`fancy_abort(file=,
> > line=, function=) at diagnostic.c:1607
> > frame #3: 0x0001015991fc lto1`lhd_decl_printable_name(tree_node*,
> > int) at langhooks.c:222
> > frame #4: 0x0001007b4288 lto1`::add_pubtype(decl=0x000143e25f18,
> > die=0x000143e27f50) at dwarf2out.c:11333
> > frame #5: 0x0001007e70f1
> > lto1`::gen_struct_or_union_type_die(type=0x000143e25f18,
> > context_die=, usage=) at dwarf2out.c:25256


> 
> That I can't reproduce even when backing out all dwarf2out.c changes.

pubnames are on by default on Darwin, and not for Linux?

[Bug libstdc++/88859] FAIL: experimental/string_view/operators/wchar_t/2.cc execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
Is r267938 a bisection result?

[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
With the modified testcase the ICE started with r173679:

$ ./cc1plus.173678 -quiet ~/k.C -std=c++0x
k.C: In function ‘void g()’:
k.C:11:7: error: invalid initialization of reference of type ‘const Foo&’ from
expression of type ‘’
k.C:6:6: error: in passing argument 1 of ‘void f(const Foo&, int)’

$ ./cc1plus.173679 -quiet ~/k.C -std=c++0x
k.C: In function ‘void g()’:
k.C:11:7: internal compiler error: in cxx_eval_bare_aggregate, at
cp/semantics.c:6539
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/88855] [9 Regression] ICE: verify_ssa failed (error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 15 15:37:29 2019
New Revision: 267939

URL: https://gcc.gnu.org/viewcvs?rev=267939&root=gcc&view=rev
Log:
2019-01-15  Richard Biener  

PR tree-optimization/88855
* tree-if-conv.c (combine_blocks): Collect
SSA_NAME_OCCURS_IN_ABNORMAL_PHI from propagated out virtuals.

* gcc.dg/pr88855.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr88855.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/88855] [9 Regression] ICE: verify_ssa failed (error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Tue, Jan 15, 2019 at 12:39:13PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810
> 
> Thomas Koenig  changed:
> 
>What|Removed |Added
> 
>  CC||tkoenig at gcc dot gnu.org
> 
> --- Comment #4 from Thomas Koenig  ---
> As far as I can see, the duplicated code does not do anything bad,
> and removing the duplicate also would not do anything bad.
> 
> A patch removing the duplication is pre-approved, provided it
> passes a regression test.
> 

Are you sure it is duplicate code?

Here, if reverse[m] == GFC_ENABLE_REVERSE and this_dep == GFC_DEP_BACKWARD,
then reverse[m] is update to GFC_REVERSE_SET; otherwise it is left as-is
which is GFC_ENABLE_REVERSE.

/* Set reverse if backward dependence and not inhibited.  */
if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
  reverse[m] = (this_dep == GFC_DEP_BACKWARD) ?
GFC_REVERSE_SET : reverse[m];

Here, if reverse[m] was updated to GFC_REVERSE_SET, the first
conditional fails and reverse[m] is left unchanged.  However, if
reverse[m] was left unchanged from above, it is then GFC_ENABLE_REVERSE.
gfortran then checks this_dep == GFC_DEP_FORWARD and updates accordingly.

/* Set forward if forward dependence and not inhibited.  */
if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
  reverse[m] = (this_dep == GFC_DEP_FORWARD) ?
GFC_FORWARD_SET : reverse[m];

The code is likely correct as-is, but confusing.  Some would have
written

/* Set reverse if backward dependence and not inhibited.  */
if (reverse && reverse[m] == GFC_ENABLE_REVERSE
 && this_dep == GFC_DEP_BACKWARD)
  reverse[m] = GFC_REVERSE_SET;

/* Set forward if forward dependence and not inhibited.  */
if (reverse && reverse[m] == GFC_ENABLE_REVERSE
&& this_dep == GFC_DEP_FORWARD)
  reverse[m] = GFC_FORWARD_SET;

or

if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
  {
 if (this_dep == GFC_DEP_BACKWARD)
   reverse[m] = GFC_REVERSE_SET;
 else if (this_dep == GFC_DEP_FORWARD)
   reverse[m] = GFC_FORWARD_SET;
  }

If this_dep can only take on the values of GFC_REVERSE_SET and
GFC_DEP_FORWARD, then the above can be collapsed to

if (reverse && reverse[m] == GFC_ENABLE_REVERSE)
   reverse[m] = this_dep == GFC_DEP_BACKWARD
  ? GFC_REVERSE_SET : GFC_FORWARD_SET;

Looks like this PR is a false positive.

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Richard Biener from comment #4)
> > Hmm, I can no longer reproduce -g0 vs -g on x86_64-linux.  Ians testresults
> > now
> > list
> > 
> > FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (internal compiler error)
> > FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (test for excess errors)
> > FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (internal
> > compiler error)
> > FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (test for
> > excess errors)
> > FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (internal compiler error)
> > FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (test for excess errors)
> > FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (internal
> > compiler error)
> > FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (test for
> > excess errors)
> > 
> > but I can't reproduce with pr62017.C or pr78651.C either right now.
> 
> 81021 has indeed started to pass (I didn't notice when).
> 
> = 62017 is:
> 
> $ /XC/9.4/usr/bin/lldb --
> /scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1 -fPIC
> -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase pr62017.exe
> -mmacosx-version-min=10.12.0 -mtune=core2 -m32 -mmacosx-version-min=10.12.0
> -mtune=core2 -auxbase-strip pr62017.exe.lto.o -g -O2 -O2 -version
> -fdiagnostics-color=never -fno-openmp -fno-openacc -fPIC -fsanitize=address
> -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
> -fmessage-length=0 -flto-partition=none
> @/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccyWmZmy -o pr62017.s
> (lldb) target create
> "/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1"
> Current executable set to
> '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1'
> (x86_64).
> (lldb) settings set -- target.run-args  "-fPIC"
> "-feliminate-unused-debug-symbols" "-quiet" "-dumpdir" "./" "-dumpbase"
> "pr62017.exe" "-mmacosx-version-min=10.12.0" "-mtune=core2" "-m32"
> "-mmacosx-version-min=10.12.0" "-mtune=core2" "-auxbase-strip"
> "pr62017.exe.lto.o" "-g" "-O2" "-O2" "-version" "-fdiagnostics-color=never"
> "-fno-openmp" "-fno-openacc" "-fPIC" "-fsanitize=address"
> "-fno-diagnostics-show-caret" "-fno-diagnostics-show-line-numbers"
> "-fmessage-length=0" "-flto-partition=none"
> "@/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccyWmZmy" "-o"
> "pr62017.s"
> (lldb) b internal_error
> Breakpoint 1: where = lto1`internal_error(char const*, ...) + 121 [inlined]
> _ZN21auto_diagnostic_groupC4Ev, address = 0x0001010abcb9
> (lldb) r
> Process 22051 launched:
> '/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1'
> (x86_64)
> GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> 267925] (x86_64-apple-darwin16)
>   compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> version isl-0.20-GMP
> 
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision
> 267925] (x86_64-apple-darwin16)
>   compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
> 267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl
> version isl-0.20-GMP
> 
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Process 22051 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x0)
> frame #0: 0x000100f7a941 lto1`tree_to_shwi(t=0x) at
> tree.c:7169
>7166   tree_fits_shwi_p (const_tree t)
>7167   {
>7168 return (t != NULL_TREE
> -> 7169 && TREE_CODE (t) == INTEGER_CST
>7170 && wi::fits_shwi_p (wi::to_widest (t)));
>7171   }
>7172   
> Target 0: (lto1) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x0)
>   * frame #0: 0x000100f7a941 lto1`tree_to_shwi(t=0x) at
> tree.c:7169
> frame #1: 0x0001007ddb3b
> lto1`::add_data_member_location_attribute(die=0x00014482b9b0,
> decl=0x0001448250c0, ctx=) at dwarf2out.c:19306
> frame #2: 0x0001007e6c3e lto1`::gen_struct_or_union_type_die(tree,
> dw_die_ref, debug_info_usage) at dwarf2out.c:24580
> frame #3: 0x0001007e6b29
> lto1`::gen_struct_or_union_type_die(type=0x000144826000,
> context_die=0x00014482b000, usage=)
> frame #4: 0x0001007e205e
> lto1`::gen_tagged_type_die(type=0x000144826000,
> context_die=, usage=DINFO_USAGE_DIR_USE) at dwarf2out.c:25430
> frame #5: 0x0001007e248f
> lto1`::gen_typedef_die(decl=0x000144821558,
> context_die=0x00014482b000) at dwarf2out.c:25344
> frame #6: 0x0001007e2a15
> lto1`::gen_decl_die(d

[Bug c/85949] __attribute__ ((format (printf,1,1))); improve error messages

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-15
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Martin: would it be possible to enhance the location?

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
62017 would seem to suggest that we've generated bad code for the stage#3
tree_fits_shwi_p function (which would be a separate issue) but maybe the tree
shouldn't be null anyway.

[Bug c/85949] __attribute__ ((format (printf,1,1))); improve error messages

[jg at jguk dot org]

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

Jonny Grant  changed:

   What|Removed |Added

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

--- Comment #3 from Jonny Grant  ---
Clang gets the attribute parameter right :-

:7:62: error: 'format' attribute parameter 2 is out of bounds

void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,2,3)));

 ^  ~
1 error generated.
Compiler returned: 1

[Bug web/88860] New: Clarify gcc online manual 6.38 Attribute Syntax

[jg at jguk dot org]

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

Bug ID: 88860
   Summary: Clarify gcc online manual 6.38 Attribute Syntax
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello

I propose two changes to clarify gcc online manual 6.38 Attribute Syntax

https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax


1) Change "infelicities" to "limitations" - I'm an English native speaking, I
don't know that word "infelicities" and I've certainly never used or read it.
Could that change be made?

2) Provide a __attribute__ ((format (printf,1,2))); example. Explaining which
arguments it relates to. Eg add something like the following :-

=
The following __attribute__ causes gcc to check run printf argument checks on
argument '3' which is 'const char * string format' (when visible at compile
time), against argument '4' the '...' variadic ellipsis.  In the example below,
arguments '1' and '2' are not checked.

void string_format(const char * prefix, size_t line, const char * const format,
...) __attribute__ ((format (printf,3,4)));


==

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Richard Biener from comment #4)
> Hmm, I can no longer reproduce -g0 vs -g on x86_64-linux.  Ians testresults
> now
> list
> 
> FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (internal compiler error)
> FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (test for excess errors)
> FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (internal
> compiler error)
> FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (test for
> excess errors)
> FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (internal compiler error)
> FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (test for excess errors)
> FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (internal
> compiler error)
> FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (test for
> excess errors)
> 
> but I can't reproduce with pr62017.C or pr78651.C either right now.

81021 has indeed started to pass (I didn't notice when).

= 62017 is:

$ /XC/9.4/usr/bin/lldb --
/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1 -fPIC
-feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase pr62017.exe
-mmacosx-version-min=10.12.0 -mtune=core2 -m32 -mmacosx-version-min=10.12.0
-mtune=core2 -auxbase-strip pr62017.exe.lto.o -g -O2 -O2 -version
-fdiagnostics-color=never -fno-openmp -fno-openacc -fPIC -fsanitize=address
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fmessage-length=0 -flto-partition=none
@/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccyWmZmy -o pr62017.s
(lldb) target create
"/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1"
Current executable set to
'/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1' (x86_64).
(lldb) settings set -- target.run-args  "-fPIC"
"-feliminate-unused-debug-symbols" "-quiet" "-dumpdir" "./" "-dumpbase"
"pr62017.exe" "-mmacosx-version-min=10.12.0" "-mtune=core2" "-m32"
"-mmacosx-version-min=10.12.0" "-mtune=core2" "-auxbase-strip"
"pr62017.exe.lto.o" "-g" "-O2" "-O2" "-version" "-fdiagnostics-color=never"
"-fno-openmp" "-fno-openacc" "-fPIC" "-fsanitize=address"
"-fno-diagnostics-show-caret" "-fno-diagnostics-show-line-numbers"
"-fmessage-length=0" "-flto-partition=none"
"@/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccyWmZmy" "-o" "pr62017.s"
(lldb) b internal_error
Breakpoint 1: where = lto1`internal_error(char const*, ...) + 121 [inlined]
_ZN21auto_diagnostic_groupC4Ev, address = 0x0001010abcb9
(lldb) r
Process 22051 launched:
'/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../lto1' (x86_64)
GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision 267925]
(x86_64-apple-darwin16)
compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl version
isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 9.0.0 20190114 (experimental) [trunk revision 267925]
(x86_64-apple-darwin16)
compiled by GNU C version 9.0.0 20190114 (experimental) [trunk revision
267925], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.1.0, isl version
isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Process 22051 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x000100f7a941 lto1`tree_to_shwi(t=0x) at
tree.c:7169
   7166 tree_fits_shwi_p (const_tree t)
   7167 {
   7168   return (t != NULL_TREE
-> 7169   && TREE_CODE (t) == INTEGER_CST
   7170   && wi::fits_shwi_p (wi::to_widest (t)));
   7171 }
   7172 
Target 0: (lto1) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
  * frame #0: 0x000100f7a941 lto1`tree_to_shwi(t=0x) at
tree.c:7169
frame #1: 0x0001007ddb3b
lto1`::add_data_member_location_attribute(die=0x00014482b9b0,
decl=0x0001448250c0, ctx=) at dwarf2out.c:19306
frame #2: 0x0001007e6c3e lto1`::gen_struct_or_union_type_die(tree,
dw_die_ref, debug_info_usage) at dwarf2out.c:24580
frame #3: 0x0001007e6b29
lto1`::gen_struct_or_union_type_die(type=0x000144826000,
context_die=0x00014482b000, usage=)
frame #4: 0x0001007e205e
lto1`::gen_tagged_type_die(type=0x000144826000, context_die=,
usage=DINFO_USAGE_DIR_USE) at dwarf2out.c:25430
frame #5: 0x0001007e248f
lto1`::gen_typedef_die(decl=0x000144821558, context_die=0x00014482b000)
at dwarf2out.c:25344
frame #6: 0x0001007e2a15 lto1`::gen_decl_die(decl=0x000144821558,
origin=, ctx=, context_die=0x00014482b000) at
dwarf2out.c:26314
frame #7: 0x0001007c5ef3
lto1`::gen_type_die_with_usage(type=0x000144826000,
context_die=, usage=DINFO_USAGE_DIR_USE) at dwarf2out.c:25495
frame #8: 0x0001007c785a lto1`::gen_ty

[Bug sanitizer/88791] ASAN deadlocks in threaded application

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
Okey, I really believe there's some ABI incompatibility between libsanitizer
and glibc. Maybe here:

https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc#L266

or maybe struct ucontext_t does not match among GCC and glibc.

Anyway I would start with running GCC's libsanitizer tests in your build
directory:

$ make check -k -j10 RUNTESTFLAGS="asan.exp"

and

$ make check -k RUNTESTFLAGS="tsan.exp"

then search for '^FAIL' in
find gcc/testsuite/ -name '*.log'