[Bug bootstrap/56750] [6/7/8 Regression] static -lstdc++ logic bleeds into all subdirs

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #14 from Aldy Hernandez  ---
Closing as WONTFIX.  There is a work around, as I have specified in comment
#13.

See further discussion here:

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00471.html

[Bug c/84298] Shared TYPE_SIZE_UNIT ends up with freed SSA names

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The fix is to place a DECL_EXPR somewhere by the FE.  We have some duplicates
with similar issues.

[Bug target/84295] [7 Regression] glibc failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.4

[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm
 Status|NEW |ASSIGNED

[Bug c++/84281] Heap grows indefinitely

[fiesh at zefix dot tv]

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

--- Comment #5 from fiesh at zefix dot tv ---
The test case was reduced from an actual translation unit that stalled our
build server.  Since the translation unit itself was invalid C++, the test case
is too. I think it shouldn't be part of the contract that only valid code may
be passed to the compiler.  Therefore to me this is not invalid.

[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Assuming this is fixed now.

[Bug c++/84082] [7 Regression] ICE with broken template function definition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |broken template function|broken template function
   |definition  |definition

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/83659] [7 Regression] ICE on compilable C++ code: in tree_to_shwi, at tree.c:6821

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[7/8 Regression] ICE on |[7 Regression] ICE on
   |compilable C++ code: in |compilable C++ code: in
   |tree_to_shwi, at|tree_to_shwi, at
   |tree.c:6821 |tree.c:6821

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/84232] [8 regression] gcc.dg/tree-ssa/ssa-dom-cse-2.c fail with -march=silvermont

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

[Bug middle-end/84237] [8 Regression] xen build faiulre only zero initializers are allowed in section '.bss.page_aligned.const'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/84285] Fail to statically link with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/84232] [8 regression] gcc.dg/tree-ssa/ssa-dom-cse-2.c fail with -march=silvermont

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  9 06:44:43 2018
New Revision: 257516

URL: https://gcc.gnu.org/viewcvs?rev=257516=gcc=rev
Log:
PR tree-optimization/84232
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: Add -mtune-generic on x86.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c

[Bug sanitizer/84285] Fail to statically link with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  9 06:44:06 2018
New Revision: 257515

URL: https://gcc.gnu.org/viewcvs?rev=257515=gcc=rev
Log:
PR sanitizer/84285
* gcc.c (STATIC_LIBASAN_LIBS, STATIC_LIBTSAN_LIBS,
STATIC_LIBLSAN_LIBS, STATIC_LIBUBSAN_LIBS): Handle -static like
-static-lib*san.

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

[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|rtl-optimization|target
   Target Milestone|--- |6.5
Summary|ICE in create_pre_exit, at  |[6/7/8 Regression] ICE in
   |mode-switching.c:451|create_pre_exit, at
   ||mode-switching.c:451

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  9 05:48:33 2018
New Revision: 257514

URL: https://gcc.gnu.org/viewcvs?rev=257514=gcc=rev
Log:
PR debug/84252
* var-tracking.c (vt_add_function_parameter): Punt for non-onepart
PARALLEL incoming that failed vt_get_decl_and_offset check.

* gcc.target/aarch64/pr84252.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr84252.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug middle-end/84237] [8 Regression] xen build faiulre only zero initializers are allowed in section '.bss.page_aligned.const'

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  9 05:47:24 2018
New Revision: 257513

URL: https://gcc.gnu.org/viewcvs?rev=257513=gcc=rev
Log:
PR middle-end/84237
* output.h (bss_initializer_p): Add NAMED argument, defaulted to false.
* varasm.c (bss_initializer_p): Add NAMED argument, if true, ignore
TREE_READONLY bit.
(get_variable_section): For decls in named .bss* sections pass true as
second argument to bss_initializer_p.

* gcc.dg/pr84237.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84237.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/output.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug c++/83659] [7/8 Regression] ICE on compilable C++ code: in tree_to_shwi, at tree.c:6821

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  9 05:46:18 2018
New Revision: 257512

URL: https://gcc.gnu.org/viewcvs?rev=257512=gcc=rev
Log:
PR c++/83659
* fold-const.c (fold_indirect_ref_1): Use VECTOR_TYPE_P macro.
Formatting fixes.  Verify first that tree_fits_poly_int64_p (op01).
Sync some changes from cxx_fold_indirect_ref.

* constexpr.c (cxx_fold_indirect_ref): Sync some changes from
fold_indirect_ref_1, including poly_*int64.  Verify first that
tree_fits_poly_int64_p (op01).  Formatting fixes.

* g++.dg/torture/pr83659.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83659.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug translation/84303] New: Styled quotes in error message may be inappropriate

[fmarchal at perso dot be]

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

Bug ID: 84303
   Summary: Styled quotes in error message may be inappropriate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In config/rs6000/rs6000.c, one can find the following code:

  if (error_p)
{
  const char *eprefix, *esuffix;

  ret = false;
  if (attr_p)
{
  eprefix = "__attribute__((__target__(";
  esuffix = ")))";
}
  else
{
  eprefix = "#pragma GCC target ";
  esuffix = "";
}

  if (cpu_opt)
error ("invalid cpu %qs for %s%qs%s", cpu_opt, eprefix,
   q, esuffix);
  else if (not_valid_p)
error ("%s%qs%s is not allowed", eprefix, q, esuffix);
  else
error ("%s%qs%s is invalid", eprefix, q, esuffix);
}
}

The "%s%qs%s" part used to be "%s\"%s\"%s". I think the old syntax was better
because it matches what the source code looks like. %qs is equivalent to « %s »
in French.

[Bug rtl-optimization/84302] New: ICE: Segmentation fault (in extract_insn) on SPE target

[asolokha at gmx dot com]

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

Bug ID: 84302
   Summary: ICE: Segmentation fault (in extract_insn) on SPE
target
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20180204 snapshot (r257367) ICEs when compiling the following
snippet w/ -O1 (-Og) -fgcse -fno-dce -fno-tree-pta --param max-cse-insns=10:

long long int rd;

void
bz (int *yj, int kz)
{
  for (;;)
{
  rd *= 3;
  if (rd == kz)
rd += *yj;
  ++rd;
}
}

% powerpc-e500v2-linux-gnuspe-gcc-8.0.0-alpha20180204 -O1 -fgcse -fno-dce
-fno-tree-pta --param max-cse-insns=10 -c trlvou7e.c
during RTL pass: subreg2
trlvou7e.c: In function 'bz':
trlvou7e.c:13:1: internal compiler error: Segmentation fault
 }
 ^
0xc48059 crash_signal
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/toplev.c:325
0xb9293a extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/recog.c:2319
0x148d5a2 decompose_multiword_subregs
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/lower-subreg.c:1474
0x148eb6c execute
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/lower-subreg.c:1741

[Bug rtl-optimization/84301] New: ICE in create_pre_exit, at mode-switching.c:451

[asolokha at gmx dot com]

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

Bug ID: 84301
   Summary: ICE in create_pre_exit, at mode-switching.c:451
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-8.0.0-alpha20180204 snapshot (r257367), 7.2, 6.3, 5.4 all ICE when
compiling the following snippet w/ -march=bdver1 -O1 -fexpensive-optimizations
-fschedule-insns -fselective-scheduling -fno-dce -fno-tree-dce --param
max-pending-list-length=0 --param selsched-max-lookahead=2 and checking
enabled:

int lr;
long int xl;

int
v4 (void)
{
  int mp;

  ++xl;
  mp = (lr - xl) > 1;
}

% gcc-8.0.0-alpha20180204 -march=bdver1 -O1 -fexpensive-optimizations
-fschedule-insns -fselective-scheduling -fno-dce -fno-tree-dce --param
max-pending-list-length=0 --param selsched-max-lookahead=2 -c fmzjfzde.c
during RTL pass: vzeroupper
fmzjfzde.c: In function 'v4':
fmzjfzde.c:11:1: internal compiler error: in create_pre_exit, at
mode-switching.c:451
 }
 ^
0x7312a3 create_pre_exit
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/mode-switching.c:438
0x7312a3 optimize_mode_switching
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/mode-switching.c:534
0x7312a3 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/mode-switching.c:892
0xfa5675 rest_of_handle_insert_vzeroupper
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/config/i386/i386.c:894
0xfa5675 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180204/work/gcc-8-20180204/gcc/config/i386/i386.c:2514

[Bug middle-end/84300] ICE in dwarf2cfi on ppc64le with -fsplit-stack -fno-omit-frame-pointer

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

--- Comment #2 from Alan Modra  ---
Testing what should be an obvious fix.

[Bug middle-end/84300] ICE in dwarf2cfi on ppc64le with -fsplit-stack -fno-omit-frame-pointer

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-09
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
The problem occurs in 296r.rtl_dce, where the insn restoring lr after the
__morestack call is deleted.  That leads to the mismatch in cfi state.

Well, OK, lr can be trashed in a function that won't return so deleting the lr
restore in itself isn't wrong.  But if we want a consistent cfi state that
can't happen without also deleting the instructions saving lr.  Which won't
occur due to hacks to stop regrename breaking things.

I think the easiest solution is to make split_stack_return depend on lr (which
of course it does!).

[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM

[akhilesh.k at samsung dot com]

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

--- Comment #5 from Akhilesh Kumar  ---
Please Mark this bug ID as invalid with the same patch I am able to run on ARM
also there was issue in My setup only (Sorry for the noise). 

Test results on ARM (gcc 6.2.1)
sh-3.2# out_of_scope
=
==3348==ERROR: AddressSanitizer: stack-use-after-scope on address 0xbe35c700 at
pc 0x000108e8 bp 0xbe35c6c4 sp 0xbe35c6bc
WRITE of size 1 at 0xbe35c700 thread T0
#0 0x108e7 in main /data2/TC/scripts/test2.c:10
#1 0x410768ab in __libc_start_main (/lib/libc.so.6+0x410768ab)

Address 0xbe35c700 is located in stack of thread T0 at offset 32 in frame
#0 0x107ef in main /data2/TC/scripts/test2.c:3

  This frame has 1 object(s):
[32, 33) 'my_char' <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: AddressSanitizer stack-use-after-scope
/data2/TC/scripts/test2.c:10 in main
Shadow bytes around the buggy address:
  0x37c6b890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b8c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b8d0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x37c6b8e0:[f8]f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x37c6b8f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37c6b930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==3348==ABORTING
sh-3.2# [SECOS][PSCI] Suspend Start CPU #0

[Bug translation/84207] Hard coded plural in gimple-fold.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-09
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Let me take care of this.  There are others like this in
gimple-ssa-warn-restrict.c that I suspect may not be fixable for GCC 8.

[Bug libstdc++/84256] Use object size checking built-ins in libstdc++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Let me confirm this.

I'd like to try to make incorporating overflow checking into user code
(including libstdc++) easier/less cumbersome and be able to provide the same
detail as in the native diagnostics including object sizes.

[Bug c++/84231] [8 Regression] cannot bind non-const lvalue reference of type ‘const char*&’ to an rvalue of type ‘const char*’

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Alexandre Oliva  ---
Patch posted:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00478.html

[Bug middle-end/84300] New: ICE in dwarf2cfi on ppc64le with -fsplit-stack -fno-omit-frame-pointer

[ian at airs dot com]

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

Bug ID: 84300
   Summary: ICE in dwarf2cfi on ppc64le with -fsplit-stack
-fno-omit-frame-pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

With a cross-compiler from x86_64-pc-linux-gnu to powerpc64le-unknown-linux-gnu
compiling this file with -g -O2 -fsplit-stack -fno-omit-frame-pointer crashes.

void trap () { __builtin_trap (); }

during RTL pass: dwarf2
/usr/local/google/home/iant/foo.c: In function 'trap':
/usr/local/google/home/iant/foo.c:1:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2348
 void trap () { __builtin_trap (); }
 ^~~~
0x791f8d maybe_record_trace_start
/tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2348
0x792524 scan_trace
/tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2541
0x7934a7 create_cfi_notes
/tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:2689
0x7934a7 execute_dwarf2_frame
/tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:3057
0x7934a7 execute
/tmp/go-build-release/gccgo-srcdir/gcc/dwarf2cfi.c:3545
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The 312r.dwarf2 file shows:

;; Function runtime.Breakpoint (runtime.Breakpoint, funcdef_no=1318,
decl_uid=22
712, cgraph_uid=829, symbol_order=13584)

Creating trace 0 : start at note 1
Creating trace 1 : start at code_label 25
Creating trace 2 : start at code_label 39
Creating trace 3 : start at note 29
Processing trace 0 : start at note 1
   saw edge from trace 0 to 2 (via jump_insn 18)
push trace 2 to worklist
   saw edge from trace 0 to 1 (via fallthru 0)
push trace 1 to worklist
Processing trace 1 : start at code_label 25
Processing trace 2 : start at code_label 39
   saw edge from trace 2 to 3 (via fallthru 0)
push trace 3 to worklist
Processing trace 3 : start at note 29
   saw edge from trace 3 to 1 (via jump_insn 40)
Inconsistent CFI state!
SHOULD have:
.cfi_def_cfa 1, 0
DO have:
.cfi_def_cfa 1, 0
.cfi_offset 65, 16

[Bug tree-optimization/84136] [6/7 Regression] ICE with goto to an && label in another function

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |goto to an && label in  |goto to an && label in
   |another function|another function

--- Comment #5 from David Malcolm  ---
Fixed on trunk for gcc 8 by r257509; still affects 6 and 7.

[Bug tree-optimization/84136] [6/7/8 Regression] ICE with goto to an && label in another function

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Fri Feb  9 01:07:11 2018
New Revision: 257509

URL: https://gcc.gnu.org/viewcvs?rev=257509=gcc=rev
Log:
Fix ICE in find_taken_edge_computed_goto (PR 84136)

PR 84136 reports an ICE within sccvn_dom_walker when handling a
C/C++ source file that overuses the labels-as-values extension.
The code in question stores a jump label into a global, and then
jumps to it from another function, which ICEs after inlining:

void* a;

void foo() {
  if ((a = &))
  return;

  l:;
}

int main() {
  foo();
  goto *a;

  return 0;
}

This appears to be far beyond what we claim to support in this
extension - but we shouldn't ICE.

What's happening is that, after inlining, we have usage of a *copy*
of the label, which optimizes away the if-return logic, turning it
into an infinite loop.

On entry to the sccvn_dom_walker we have this gimple:

main ()
{
  void * a.0_1;

   [count: 0]:
  a = 

   [count: 0]:
l:
  a.0_1 = a;
  goto a.0_1;
}

and:
  edge taken = find_taken_edge (bb, vn_valueize (val));
reasonably valueizes the:
  goto a.0_1;
after the:
  a = 
  a.0_1 = a;
as if it were:
  goto *

find_taken_edge_computed_goto then has:

2380  dest = label_to_block (val);
2381  if (dest)
2382{
2383  e = find_edge (bb, dest);
2384  gcc_assert (e != NULL);
2385}

which locates dest as a self-jump from block 3 back to itself.

However, the find_edge call returns NULL - it has a predecessor edge
from block 2, but no successor edges.

Hence the assertion fails and we ICE.

A successor edge from the computed goto could have been created by
make_edges if the label stmt had been in the function, but make_edges
only looks in the current function when handling computed gotos, and
the label only appeared after inlining.

The following patch removes the assertion, fixing the ICE.

gcc/testsuite/ChangeLog:
PR tree-optimization/84136
* gcc.c-torture/compile/pr84136.c: New test.

gcc/ChangeLog:
PR tree-optimization/84136
* tree-cfg.c (find_taken_edge_computed_goto): Remove assertion
that the result of find_edge is non-NULL.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84136.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug c++/84281] Heap grows indefinitely

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  Unless C++ has evolved more than I know the code is badly mangled,
so ice-on-invalid.  GCC also prints some error messages before it gets into a
loop so error-recovery.

[Bug c++/84287] pointer to member function type with dependent parameter cannot be mangled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.0, 4.5.4, 4.8.3, 4.9.3,
   ||5.3.0, 6.2.0, 7.1.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the C++ 98 test case below.  Not a regression.

$ cat t.C && gcc -S -Wall t.C
struct S {
  void f (const S&);
};

template
int g (T x, __typeof__ (static_cast(::f)) * = 0)
{
  return 0;
}

int x = g (S ());
t.C: In instantiation of ‘int g(T, __typeof__ (static_cast(& S::f))*) [with T = S]’:
t.C:6:5: sorry, unimplemented: mangling typeof, use decltype instead
 int g (T x, __typeof__ (static_cast(::f)) * = 0)
 ^

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
I see.  I think you are specifically talking about the case when the three
attributes are used together, as in:

  void __attribute__ ((weak, alias ("__foo"), visibility ("..."))) foo ();

  void __foo () { ... }

and not warning that __foo isn't declared weak, or with alias, or with
visibility.  Yes, warning for that wouldn't be very helpful.

[Bug c/81824] Warn for missing attributes with function aliases

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
On Thu, 8 Feb 2018, msebor at gcc dot gnu.org wrote:

> Okay, that would make sense.  But then what do you mean by "weak, alias,
> visibility attributes are expected to differ between different names and
> shouldn't be diagnosed."

Weak is a property of a symbol, not of a function - it's correct for a 
function to have both strong and weak names.

[Bug target/79242] [7/8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6029

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com
Summary|ICE in simplify_subreg, at  |[7/8 Regression] ICE in
   |simplify-rtx.c:6029 |simplify_subreg, at
   ||simplify-rtx.c:6029

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
Leslie, you'd need to bisect.  Probably something from Bin in the summer of
2017.  Not something we're likely to backport.

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Okay, that would make sense.  But then what do you mean by "weak, alias,
visibility attributes are expected to differ between different names and
shouldn't be diagnosed."

The example in comment #0 shows a potential bug: declaring an alias to be more
restrictive ("nothrow") than its target makes it possible for the target to
quietly violate the guarantee provided by the alias to its callers.  So I would
expect it to be diagnosed for the reasons of correctness.  (I realize that for
nothrow this isn't applicable to Glibc because nothing in Glibc throws.  But it
is applicable to C++ code bases.)

It's not a potential bug for an alias were less restrictive ("might throw")
than its targets.  It just means that uses of the alias may lead to suboptimal
code compared to the target, and so warning for the mismatch will help point
that out.  

So the warning would be helpful in both cases, just for different reasons.  (In
my view, this is analogous to the const/pure situation we discussed.)

I think the same argument applies to weak.

I haven't thought about visibility too much but it seems different.  I can't
think of a problem with defining an alias with a different visibility than its
target.

[Bug c++/43361] missing uninitialized warning without optimization (loop representation)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||daffra.claudio at gmail dot com

--- Comment #10 from Manuel López-Ibáñez  ---
*** Bug 84289 has been marked as a duplicate of this bug. ***

[Bug c++/84289] warning : variabile unitialized, emit right check only with O(1,2,3) optimisation level (in try/catch)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
The try-catch creates:

  # n_1 = PHI 
  # .MEM_2 = PHI <.MEM_4(3), .MEM_12(9)>
  _15 = n_1;

and PHI is only handled with optimization.

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

[Bug c++/77522] [6/7/8 Regression] ICE on invalid code C++14 code: in tsubst_decl, at cp/pt.c:12447

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #3 from Paolo Carlini  ---
In trunk we don't ICE anymore on this, I think we can safely remove the 8
Regression marker and commit a testcase. I'm wondering however why when
initialize_reference calls error_at the input_location is at the open square
bracket. Well, just a curiosity, at some point expr itself will have its own
usable location.

[Bug c/81824] Warn for missing attributes with function aliases

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
In the case most likely to appear in glibc, foo would be declared with the 
nothrow attribute and __foo would be missing it.  I see no reason not to 
diagnose the other case as well, I just think it's less likely to be 
applicable to glibc.

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Joseph S. Myers from comment #0)
> Note: this warning is only for attributes relating to the function itself,
> not to those relating to a particular name for the function.  For example,
> weak, alias, visibility attributes are expected to differ between different
> names and shouldn't be diagnosed.  It would be necessary to work out which
> existing function attributes fall in which category.

Joseph, to make sure I understand: foo in the example is an alias for __foo and
you want a warning for __foo.  What you're saying above is that if __foo were
nothrow, you wouldn't want to see a warning for foo pointing out that it's
missing the attribute.  Yes?

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[uros at gcc dot gnu.org]

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

--- Comment #37 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Feb  8 22:31:15 2018
New Revision: 257505

URL: https://gcc.gnu.org/viewcvs?rev=257505=gcc=rev
Log:
PR target/83008
* config/i386/x86-tune-costs.h (skylake_cost): Fix cost of
storing integer register in SImode.  Fix cost of 256 and 512
byte aligned SSE register store.

* config/i386/i386.c (ix86_multiplication_cost): Fix
multiplication cost for TARGET_AVX512DQ.

testsuite/ChangeLog:

PR target/83008
* gcc.target/i386/pr83008.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr83008.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/x86-tune-costs.h
trunk/gcc/testsuite/ChangeLog

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Candidate patch/RFC:
  https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00468.html

[Bug rtl-optimization/83723] [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Matthias, can you reproduce this with current trunk and if so, do you have
unreduced preprocessed testcase + options?

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #19 from Martin Sebor  ---
Patch for pr83871 that resolves this problem:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00154.html

[Bug c++/84299] New: warning: '' may be used uninitialized in this function

[bugzilla at cpockrandt dot de]

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

Bug ID: 84299
   Summary: warning: '' may be used uninitialized in
this function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla at cpockrandt dot de
  Target Milestone: ---

The warnings appeared between versions 8.0.1.s20180121 and 8.0.1.s20180128.

The attached *.ii file was produced by g++8 (FreeBSD Ports Collection) 8.0.1
20180128 (experimental)

/usr/local/bin/g++8  -DSEQAN_DISABLE_VERSION_CHECK -DSEQAN_ENABLE_TESTING=1
-DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1 -DSEQAN_HAS_OPENMP=1
-DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99=1
-D_LARGEFILE_SOURCE -I/home/mi/cpockrandt/seqan/include -save-temps  -W -Wall
-pedantic -fopenmp -O3 -DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_index_vstree.dir/test_index_vstree.cpp.o -c
/home/mi/cpockrandt/seqan/tests/index/test_index_vstree.cpp
In file included from
/home/mi/cpockrandt/seqan/include/seqan/basic/basic_iterator.h:80,
 from /home/mi/cpockrandt/seqan/include/seqan/basic.h:86,
 from /home/mi/cpockrandt/seqan/include/seqan/sequence.h:74,
 from
/home/mi/cpockrandt/seqan/tests/index/test_index_vstree.cpp:1:
/home/mi/cpockrandt/seqan/include/seqan/basic/iterator_adaptor.h: In function
'int main()':
/home/mi/cpockrandt/seqan/include/seqan/basic/iterator_adaptor.h:102:9:
warning: '' may be used uninitialized in this function
[-Wmaybe-uninitialized]
 data_iterator = TIterator();
 ^

Interestingly this error occurs only with -O3, not without optimization.

I tried to reduce the code as much as possible but wasn't very successful with
delta & co. It is still quite big, so I uploaded it elsewhere.

http://www.inf.fu-berlin.de/users/cpockrandt/test_index_vstree.ii (6.4 MB).

It might also be a duplicate:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078

[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00154.html

[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #15 from rsandifo at gcc dot gnu.org  
---
Finally fixed.  Sorry for the delay.

[Bug c/84298] New: Shared TYPE_SIZE_UNIT ends up with freed SSA names

[rsandifo at gcc dot gnu.org]

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

Bug ID: 84298
   Summary: Shared TYPE_SIZE_UNIT ends up with freed SSA names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

The testcase:

int res, a, b;
void *foo;
static void f2 (int arg) { res = ((int (*)[arg][b]) foo)[0][0][0]; }
void f1 (void) { f2 (a); }

when compiled at -O or above causes:

0xff3baf crash_signal
/work/richards/shoji/oban/src/gcc/gcc/toplev.c:325
0x12f1b0a make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
/work/richards/shoji/oban/src/gcc/gcc/tree-ssanames.c:266
0x10a4d68 make_ssa_name
/work/richards/shoji/oban/src/gcc/gcc/tree-ssanames.h:115
0x10a5ed7 remap_ssa_name
/work/richards/shoji/oban/src/gcc/gcc/tree-inline.c:241
0x10aa672 copy_tree_body_r(tree_node**, int*, void*)
/work/richards/shoji/oban/src/gcc/gcc/tree-inline.c:1091
0x13d2b8f walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*))
/work/richards/shoji/oban/src/gcc/gcc/tree.c:11390
0x13d41b4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*))
/work/richards/shoji/oban/src/gcc/gcc/tree.c:11706
0x13d41b4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*))
/work/richards/shoji/oban/src/gcc/gcc/tree.c:11706
0x10a8760 remap_type_1
/work/richards/shoji/oban/src/gcc/gcc/tree-inline.c:575
0x10a8818 remap_type(tree_node*, copy_body_data*)
/work/richards/shoji/oban/src/gcc/gcc/tree-inline.c:603

The problem is that the TYPE_SIZE_UNIT of the outer [arg][b]
array includes a MULT_EXPR that is shared with the pointer
calculation.  The pointer calculation is gimplified and
eventually the original SSA names are freed, but the gimplified
MULT_EXPR is still in TYPE_SIZE_UNIT and still refers to the
freed SSA names.

[Bug c/84298] Shared TYPE_SIZE_UNIT ends up with freed SSA names

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-08
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a fix.

[Bug target/84265] [8 Regression] ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug c++/84297] New: ICE (mmap: Invalid argument) in std::is_trivially_constructible

[smw at gcc dot gnu.org]

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

Bug ID: 84297
   Summary: ICE (mmap: Invalid argument) in
std::is_trivially_constructible
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

I expected a diagnostic, but not this one.

#include 

struct S { };

std::is_trivially_constructible<S, int&()> boom;

Fed to any verison of GCC, I get something like the following.

In file included from :1:
/opt/compiler-explorer/gcc-trunk-20180208/include/c++/8.0.1/type_traits: In
instantiation of 'struct std::is_trivially_constructible<S, int&()>':
:5:48:   required from here
/opt/compiler-explorer/gcc-trunk-20180208/include/c++/8.0.1/type_traits:1150:12:
internal compiler error: tree check: did not expect class 'type', have 'type'
(function_type) in convert_from_reference, at cp/cvt.c:548
 struct is_trivially_constructible
^~
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1

[Bug ada/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks, I'll investigate.

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

--- Comment #14 from Javier Serrano Polo 
 ---
(In reply to Adam Conrad from comment #13)
> Please stop speaking as if you speak for the Debian toolchain maintainers,
> or Debian as a whole.  You don't.

I do not represent Debian, but I state facts: multiarch interpreter names are
officially supported in Debian. This is true because:

1. Multiarch interpreters are shipped in glibc packages of the stable release.
2. Programs compiled with multiarch interpreters work in Debian without further
changes.
3. Multiarch interpreters are not the target of the traditional interpreter
symlinks, thus they are not required for traditional programs.
4. Debian ldconfig takes care not to remove the multiarch interpreters. This is
intentional, as you can read:
  /* Do not change the symlink pointer to the dynamic linker except for
 non-existing symlinks, as it might break multiarch systems.  */
5. Debian glibc maintainers are careful not to add files to their packages
because that would mean they implicitly support the provided feature.

So please have a look at the submitted patch.

[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from kelvin at gcc dot gnu.org ---
Our plan is to deprecate the -maltivec=be option.

[Bug target/81143] New test case gcc.target/powerpc/pr79799-2.c fails on powerpc BE

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Peter Bergner  ---
Closing as fixed.

[Bug target/81143] New test case gcc.target/powerpc/pr79799-2.c fails on powerpc BE

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-02/msg00465.ht
   ||ml
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from Peter Bergner  ---
Fixed in trunk.

[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #14 from Segher Boessenkool  ---
Should be fixed by r257472 (trunk) and r257501 (7 branch).  Please open a
new PR for other problems.

[Bug target/81143] New test case gcc.target/powerpc/pr79799-2.c fails on powerpc BE

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Author: bergner
Date: Thu Feb  8 20:40:32 2018
New Revision: 257504

URL: https://gcc.gnu.org/viewcvs?rev=257504=gcc=rev
Log:
PR target/81143
* gcc.target/powerpc/pr79799-2.c: Use __LITTLE_ENDIAN__.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-2.c

[Bug c++/84296] [8 Regression] ICE in finish_member_declaration

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-08
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Jason, could you please have a look?  This affects multiple packages...

[Bug c++/84296] New: [8 Regression] ICE in finish_member_declaration

[jakub at gcc dot gnu.org]

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

Bug ID: 84296
   Summary: [8 Regression] ICE in finish_member_declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

namespace b {}
namespace c {
using namespace b;
}
namespace b {
template  struct e { static const int f = d; };
}
template  struct g;
template 
struct g : h::template ab {};
struct k {
  template  struct m { typedef typename g::n o; };
};
template  struct ac;
struct r {
  typedef ac p;
};
template  struct s : k {
  template 
  struct ab : q::template t::template ab {};
};
struct ad {
  typedef int u;
};
template  struct ae;
template  struct ah {
  typedef ae ai;
  typedef typename ai::template w::o n;
};
struct x {
  template  struct ab : ah {};
};
struct y {
  struct z {
template  struct t : x {};
  };
  struct aj : s {};
};
template  struct ak {
  typedef y::aj al;
  typedef typename al::m::o o;
};
struct am {
  enum { an };
};
template  struct ao {};
template  struct ap : af::aq {};
template <> struct ae {
  template  struct w;
  template  struct w {
typedef typename as::p o;
  };
};
enum { a = b::e<0>::f };
template  class au;
template  struct ac : ao { typedef c::e aq; };
template  void ay(aw, i, ax) {
  au::f>> az();
}
void v() {
  ad a;
  void az();
  ay(az, a, v);
}

ICEs starting with r256866 with:
rh1543322.ii: In instantiation of ‘struct b::e’:
rh1543322.ii:47:31:   required from ‘struct ap’
rh1543322.ii:58:38:   required from ‘void ay(aw, i, ax) [with aw = void (*)();
i = ad; ax = void (*)()]’
rh1543322.ii:63:14:   required from here
rh1543322.ii:6:46: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3011
 template  struct e { static const int f = d; };
  ^
0xa87722 finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:3011
0xa17da2 instantiate_class_template_1
../../gcc/cp/pt.c:10697
0xa188d9 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:10915
0xacd6f6 complete_type(tree_node*)
../../gcc/cp/typeck.c:136
0xacd71b complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:148
0xacd7b9 complete_type_or_else(tree_node*, tree_node*)
../../gcc/cp/typeck.c:165
0x8d6539 xref_basetypes(tree_node*, tree_node*)
../../gcc/cp/decl.c:13765
0xa16e36 instantiate_class_template_1
../../gcc/cp/pt.c:10501
0xa188d9 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:10915
0xacd6f6 complete_type(tree_node*)
../../gcc/cp/typeck.c:136
0xa78500 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/cp/search.c:1116
0x97e25e lookup_qualified_name(tree_node*, tree_node*, int, bool, bool)
../../gcc/cp/name-lookup.c:5588
0xa2a02b tsubst_qualified_id
../../gcc/cp/pt.c:14571
0xa3a11a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17345
0xa37959 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16779
0xa18983 tsubst_template_arg
../../gcc/cp/pt.c:10933
0xa1bb45 tsubst_template_args
../../gcc/cp/pt.c:11801
0xa1c7cd tsubst_aggr_type
../../gcc/cp/pt.c:12003
0xa26349 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13645
0xa18947 tsubst_template_arg
../../gcc/cp/pt.c:10928
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The ICE is in the same spot as PR81917, but has regressed in a different
revision, so no idea if the two are related or not.

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

[patrikhuber at gmail dot com]

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

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

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

[patrikhuber at gmail dot com]

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

--- Comment #13 from Patrik Huber  ---
>> Did you try with FDO?  (-fprofile-generate, run, -fprofile-use)

I just tried this with g++-7. It didn't help, the final executable has the same
slower run time as in the attached log without the FDO.

[Bug target/81143] New test case gcc.target/powerpc/pr79799-2.c fails on powerpc BE

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-08
 CC||bergner at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
This is a test case bug.  The problem is the following code:

#if __ORDER_LITTLE_ENDIAN__
#define ELE 2
#else
#define ELE 1
#endif

vector float
foo (vector float v1, vector float v2)
{
  return vec_insert (vec_extract (v2, ELE), v1, 0);
}

The bug is that __ORDER_LITTLE_ENDIAN__ is always defined, so we pass the wrong
ELE value to vec_extract() call on big endian.  We should be testing
__LITTLE_ENDIAN__ instead.  Changing that fixes the failure.

[Bug target/84295] New: [7 Regression] glibc failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 84295
   Summary: [7 Regression] glibc failed to build
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: s390x

r257498 on gcc-7-branch caused:

/export/gnu/import/git/toolchain/build/compilers/s390x-linux-gnu/glibc/s390x-linux-gnu/libc_pic.os:
In function `__cmsg_nxthdr':
/export/ssd/git/toolchain/build/compilers/s390x-linux-gnu/glibc-src/s390x-linux-gnu/socket/../sysdeps/unix/sysv/linux/cmsg_nxthdr.c:39:
undefined reference to `__s390_indirect_jump_r1use_r14'
/export/ssd/git/toolchain/build/compilers/s390x-linux-gnu/glibc-src/s390x-linux-gnu/socket/../sysdeps/unix/sysv/linux/cmsg_nxthdr.c:39:
undefined reference to `__s390_indirect_jump_r1use_r14'
collect2: error: ld returned 1 exit status
make[4]: *** [../Makerules:765:
/export/gnu/import/git/toolchain/build/compilers/s390x-linux-gnu/glibc/s390x-linux-gnu/libc.so]
Error 1
make[4]: Leaving directory
'/export/ssd/git/toolchain/build/compilers/s390x-linux-gnu/glibc-src/s390x-linux-gnu/elf'
make[3]: *** [Makefile:215: elf/subdir_lib] Error 2
make[3]: Leaving directory
'/export/ssd/git/toolchain/build/compilers/s390x-linux-gnu/glibc-src/s390x-linux-gnu'
make[2]: *** [Makefile:9: all] Error 2
make[2]: Leaving directory
'/export/ssd/git/toolchain/build/compilers/s390x-linux-gnu/glibc/s390x-linux-gnu'

[Bug c++/84294] New: missing warning for ignored attribute on a function template declaration

[msebor at gcc dot gnu.org]

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

Bug ID: 84294
   Summary: missing warning for ignored attribute on a function
template declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With bug 81544 resolved, GCC 8 warns on distinct declarations of the same
function with mutually exclusive attributes (such as const and pure).  In the
test case below this warning detects the conflict between the two declarations
of function f (and the uses of the function in ff() show that GCC does ignore
the pure attribute on the second declaration).

However, when the same pair of mutually exclusive attributes is specified on
declarations a function template GCC issues no such warning, even though it
also ignores the conflicting attribute as in the non-template case as the dump
shows.

$ cat u.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.C
[[gnu::const]] int f ();
[[gnu::pure]] int f ();   // Wattributes, pure ignored (good)

void ff (int *p)
{
  int i0 = f ();
  *p = 123;
  int i1 = f (); 
  if (i0 != i1)// folded to false (good)
__builtin_abort ();
}

template  [[gnu::const]] T g ();
template  [[gnu::pure]] T g ();   // pure ignored, warning missing

void gg (int *p)
{
  int i0 = g();
  *p = 123;
  int i1 = g(); 
  if (i0 != i1)   // folded to false
__builtin_abort ();
}
u.C:2:22: warning: ignoring attribute ‘pure’ because it conflicts with
attribute ‘const’ [-Wattributes]
 [[gnu::pure]] int f ();   // Wattributes, pure ignored (good)
  ^
u.C:1:20: note: previous declaration here
 [[gnu::const]] int f ();
^

;; Function ff (_Z2ffPi, funcdef_no=0, decl_uid=2355, cgraph_uid=0,
symbol_order=0)

ff (int * p)
{
   [local count: 1073741825]:
  *p_2(D) = 123;
  return;

}



;; Function gg (_Z2ggPi, funcdef_no=3, decl_uid=2366, cgraph_uid=1,
symbol_order=1)

gg (int * p)
{
   [local count: 1073741825]:
  *p_2(D) = 123;
  return;

}

[Bug target/84278] claims initv4sfv2sf is available but inits through stack

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Created attachment 43383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43383=edit
i386-pc-solaris2.11 -m32 assembler output

The new test FAILs on 32-bit Solaris/x86 (with as):

+FAIL: gcc.target/i386/pr84278.c scan-assembler-not (%.sp)

[Bug c/84173] Support glibc multiarch interpreter names

[adconrad at 0c3 dot net]

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

--- Comment #13 from Adam Conrad  ---
(In reply to Javier Serrano Polo from comment #12)
> 
> Multiarch interpreter names are officially supported in Debian.

No.  No they're not.  I don't think "officially" means what you think it means.
 I've asked you many times before, but I'll ask again, please stop dragging
Debian into this.  Debian multiarch intentionally does *not* break ABI.  We
recognize this is a limitation, in that some arches can't coexist due to
conflicting ld.so paths, but that was better than the alternative.

Please stop speaking as if you speak for the Debian toolchain maintainers, or
Debian as a whole.  You don't.

[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value

[andreast at gcc dot gnu.org]

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

Andreas Tobler  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Tobler  ---
Might be, it's a few days since :)

I'll take it. Thanks!

[Bug fortran/84276] Invalid error for valid statement function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
Ugh.  Statement functions should be removed from the Standard.
The simply fix, of course, does not work if someone is clever
and uses keywords in a reference that involves a statement
function.

  subroutine step(hh, h, s, w)
  real, intent(inout) :: h, hh, s
  real, intent(out) :: w
  real :: qofs
  integer i
  qofs(s, i) = i * s
  i = 42
  w = qofs(hh, i)
  w = qofs(i = i, s = hh)
  end subroutine step

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2018-2-8
 CC||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
Confirmed.

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Checking DECL_CONTEXT of current_function_decl if non-NULL doesn't seem to work
either.

[Bug target/84227] [8 Regression] ICE in lra_set_insn_recog_data, at lra.c:998

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
I can't reproduce it either.

[Bug fortran/84273] Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-08
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Turns out the relevant check is already there, but not working.
proc_ptr_47 is rejected with this fix:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 257498)
+++ gcc/fortran/resolve.c   (working copy)
@@ -13722,7 +13722,7 @@
   return false;
 }

-  if (me_arg->attr.allocatable)
+  if (CLASS_DATA (me_arg)->attr.allocatable)
 {
   gfc_error ("Argument %qs of %qs with PASS(%s) at %L "
  "may not be ALLOCATABLE", me_arg->name, c->name,

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
With:
--- gcc/cp/cp-tree.h.jj 2018-02-07 23:28:55.750401640 +0100
+++ gcc/cp/cp-tree.h2018-02-08 20:08:49.618613211 +0100
@@ -7056,6 +7056,7 @@ extern tree cxx_copy_lang_qualifiers  (c

 extern void cxx_print_statistics   (void);
 extern bool maybe_warn_zero_as_null_pointer_constant (tree, location_t);
+extern void cp_warn_deprecated_use (tree);

 /* in ptree.c */
 extern void cxx_print_xnode(FILE *, tree, int);
--- gcc/cp/tree.c.jj2018-02-06 13:12:48.121808347 +0100
+++ gcc/cp/tree.c   2018-02-08 20:08:22.293628631 +0100
@@ -5348,6 +5348,19 @@ maybe_warn_zero_as_null_pointer_constant
 }
   return false;
 }
+
+/* Wrapper around warn_deprecated_use that doesn't warn for
+   current_class_type.  */
+
+void
+cp_warn_deprecated_use (tree node)
+{
+  if (TYPE_P (node)
+  && current_class_type
+  && TYPE_MAIN_VARIANT (node) == current_class_type)
+return;
+  warn_deprecated_use (node, NULL_TREE);
+}


 #if defined ENABLE_TREE_CHECKING && (GCC_VERSION >= 2007)
 /* Complain that some language-specific thing hanging off a tree
--- gcc/cp/decl.c.jj2018-02-07 23:28:55.731401645 +0100
+++ gcc/cp/decl.c   2018-02-08 20:09:53.655577074 +0100
@@ -10363,7 +10363,7 @@ grokdeclarator (const cp_declarator *dec
  suppress reports of deprecated items.  */
   if (type && TREE_DEPRECATED (type)
   && deprecated_state != DEPRECATED_SUPPRESS)
-warn_deprecated_use (type, NULL_TREE);
+cp_warn_deprecated_use (type);
   if (type && TREE_CODE (type) == TYPE_DECL)
 {
   typedef_decl = type;
@@ -10371,7 +10371,7 @@ grokdeclarator (const cp_declarator *dec
   if (TREE_DEPRECATED (type)
  && DECL_ARTIFICIAL (typedef_decl)
  && deprecated_state != DEPRECATED_SUPPRESS)
-   warn_deprecated_use (type, NULL_TREE);
+   cp_warn_deprecated_use (type);
 }
   /* No type at all: default to `int', and set DEFAULTED_INT
  because it was not a user-defined typedef.  */
@@ -12712,7 +12712,7 @@ grokparms (tree parmlist, tree *parms)
{
  tree deptype = type_is_deprecated (type);
  if (deptype)
-   warn_deprecated_use (deptype, NULL_TREE);
+   cp_warn_deprecated_use (deptype);
}

  /* Top-level qualifiers on the parameters are
--- gcc/cp/typeck2.c.jj 2018-02-06 13:12:48.146808267 +0100
+++ gcc/cp/typeck2.c2018-02-08 20:12:48.880478192 +0100
@@ -2056,7 +2056,7 @@ build_functional_cast (tree exp, tree pa
   if (complain & tf_warning
  && TREE_DEPRECATED (type)
  && DECL_ARTIFICIAL (exp))
-   warn_deprecated_use (type, NULL_TREE);
+   cp_warn_deprecated_use (type);
 }
   else
 type = exp;

we don't warn inside of the deprecated classes or templates (which is I think a
good thing), but do warn when defining methods for those classes or class
templates outside of the class definitions (which is I think undesirable).

Testcase:
struct __attribute__((deprecated)) C {
  C () {}
  C (const C &);
  C (const C , const C ) { C z = x; }
  void foo (const C , const C );
};

void
C::foo (const C , const C )
{
  C z = x;
}

void
bar (const C , const C )
{
  C z = x;
}

template 
struct __attribute__((deprecated)) D {
  D () {}
  D (const D &);
  D (const D , const D ) { D z = x; }
  void foo (const D , const D );
};

template 
void
D::foo (const D , const D )
{
  D z = x;
}

template 
void
baz (const D , const D )
{
  D z = x;
}

Note, clang++ seems to warn only on bar, doesn't warn inside of the class
definitions (matches the patch), doesn't warn inside of the out of class method
definitions (I'd say desirable), and doesn't warn inside of baz (that looks
like a bug to me, unless they warn only when it is instantiated).

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
(In reply to Steven Munroe from comment #4)
> BTW is there a P9 in the GCC compile farm yet?

Sadly, not yet.  We can do testing on your behalf until we can get a system out
there.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas  ---
fferent types but who knows.
> 
> I suggest to remove the caching from gfc_get_dtype.

Indeed, it is the caching that is the source of the problem. I reverted the fix
and removed the caching from gfc_get_dtype; lo and behold, the problem was
gone.

I will investigate such use as there might be of the cached dtype before
committing any changes to trans-types.c but I rather suspect that this was an
underlying (cached?) bug waiting to hit us on the nose.

Thanks for pointing this out.

Paul

[Bug c++/84281] Heap grows indefinitely

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Briefly tested on trunk, 7, 6, and 5; all of them seem to hang and consume
multiple gigabytes of memory:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND 
12459 david 20   0 44.088g 0.041t   4752 t   0.0 33.5  15:42.05 cc1plus 
12452 david 20   0 10.470g 0.010t 56 t   0.0  8.0   1:31.62 cc1plus

Seems to be stuck in cxx_eval_vec_init_1 building an initializer (or
initializers?) for a very large array of very large integers.

(gdb) call debug_tree (atype)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718ca738 precision:64 min  max 
pointer_to_this >
BLK
size  constant 274877906880>
unit-size  constant 34359738360>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a2a1f8
domain  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718ca000 precision:64 min  max >
type_6 DI size  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a2a150 precision:64 min  max >>

[Bug fortran/84276] Invalid error for valid statement function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Feb 08, 2018 at 06:53:00PM +, kargl at gcc dot gnu.org wrote:
>
> I have a patch.
> 

The patch is incomplete.  If the actual and dummy arguments
type and type parameter match then, everything works ok.
If there is a mismatch, then we get an ICE.  I'm working
on it.

  subroutine stepns(hh,h,s,w)
  real, intent(inout) :: h,hh,s
  real, intent(out)  :: w
  real :: qofs
  integer i
  qofs(s)=s
  w=qofs(hh+h)  ! OK
  i = 42
  w = qofs(i)   ! Causes ICE, but should issue error.
  end subroutine stepns

[Bug c++/83806] [6/7 Regression] Spurious -Wunused-but-set-parameter with nullptr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] Spurious |[6/7 Regression] Spurious
   |-Wunused-but-set-parameter  |-Wunused-but-set-parameter
   |with nullptr|with nullptr

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c/84293] system-header macro expansion location gives unexpected warning

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-08
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Nathan Sidwell  ---
IRC conversation with shows it's not the macro expansion stuff being confused,
but the alias checking using the wrong loc

[Bug sanitizer/84285] Fail to statically link with -fsanitize=undefined

[marcandre.lureau at gmail dot com]

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

--- Comment #4 from Marc-André Lureau  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 43371 [details]
> gcc8-pr84285.patch
> 
> Untested fix.

Thanks
patch texted successfully.

[Bug c++/83806] [6/7/8 Regression] Spurious -Wunused-but-set-parameter with nullptr

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Feb  8 18:54:39 2018
New Revision: 257502

URL: https://gcc.gnu.org/viewcvs?rev=257502=gcc=rev
Log:
/cp
2018-02-08  Paolo Carlini  

PR c++/83806
* typeck.c (decay_conversion): Use mark_rvalue_use for the special
case of nullptr too.

/testsuite
2018-02-08  Paolo Carlini  

PR c++/83806
* g++.dg/warn/Wunused-parm-11.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-parm-11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||mrs at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #40 from mrs at gcc dot gnu.org  ---
Fixed.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

--- Comment #39 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Feb  8 18:48:37 2018
New Revision: 257501

URL: https://gcc.gnu.org/viewcvs?rev=257501=gcc=rev
Log:
2018-02-08  Iain Sandoe  

PR target/84113
* config/rs6000/altivec.md (*restore_world): Remove LR use.
* config/rs6000/predicates.md (restore_world_operation): Adjust op
count, remove one USE.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/altivec.md
branches/gcc-7-branch/gcc/config/rs6000/predicates.md

[Bug c++/79393] [7/8/9 Regression] cc1plus rejects valid code with noexcept

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0
Summary|[7/8 Regression] cc1plus|[7/8/9 Regression] cc1plus
   |rejects valid code with |rejects valid code with
   |noexcept|noexcept

--- Comment #9 from Jakub Jelinek  ---
If it isn't yet a filed DR, it will be hardly resolved by GCC8 time, so
defering till GCC9.

[Bug target/84272] [8 Regression] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43382=edit
gcc8-pr84272-2.patch

Or defer deletion of all the fma_nodes until the end, whether they are root or
not.  I'd fear that even removing just non-root nodes might mean the following
processing of the children might still look at the parent nodes.

Untested as well.  I'd appreciate feedback from the pass author.

[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-08
 Ever confirmed|0   |1

[Bug target/84066] Wrong shadow stack register size is saved for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #9 from H.J. Lu  ---
Fixed.

[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs

[hjl.tools at gmail dot com]

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

Bug 84066 Summary: Wrong shadow stack register size is saved for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066

   What|Removed |Added

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

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

--- Comment #38 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Feb  8 18:39:43 2018
New Revision: 257500

URL: https://gcc.gnu.org/viewcvs?rev=257500=gcc=rev
Log:
Mark previous change with:
PR target/84113

Modified:
trunk/gcc/ChangeLog

[Bug target/84272] [8 Regression] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

[jakub at gcc dot gnu.org]

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

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

Untested patch to defer delete of root nodes.

[Bug target/84272] [8 Regression] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I would have expected that before:
  if (node->root_p ())
delete static_cast (node);
we either process all the children of that root node, or remove the root node
and replace it with one of the children.

[Bug c/84290] Internal compiler error: in tree_to_uhwi, at tree.h:4044

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is a dup of bug 81231.  Since this is not a regression, I am just going to
close it as a dup of that bug which is fixed in GCC 8.

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

[Bug c/81231] ICE with invalid argument to __atomic_*

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||xvl5190 at psu dot edu

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

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[munroesj at gcc dot gnu.org]

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

Steven Munroe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-08
 Ever confirmed|0   |1

--- Comment #5 from Steven Munroe  ---
I'll take this.

[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Duh, input_operand does _not_ allow any MEM: it allows any memory_operand.
Which apparently we do not have here.

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[munroesj at gcc dot gnu.org]

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

--- Comment #4 from Steven Munroe  ---
Yup this looks like a pasteo from the pi16 implementation which was not caught
as P9 was rare at the time.

The #if _ARCH_PWR9 clause is an optimization based on better timing for P9 (vs
P8) for GPR <-> VSR transfers.

BTW is there a P9 in the GCC compile farm yet?