[Bug target/82931] New: Missing Optimization for Bit-Transfer (AVR Target)

[wilhelm.me...@hs-kl.de]

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

Bug ID: 82931
   Summary: Missing Optimization for Bit-Transfer (AVR Target)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilhelm.me...@hs-kl.de
  Target Milestone: ---

Created attachment 42574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42574&action=edit
Minimum complete verifying example

The attached example produces optimal code for the AVR-target: it uses the
bst/bld assembler instructions. But this is only true for bit 0 (least
significant) in an uint8_t type. If the same instruction sequence is used to
transfer bit 1...7 less optimal code is generated.

This is unlogical to some respect since the backend recognizes the special case
for bit 0, so it should be possible to use the very same optimization for other
bits.

The same holds true if one used another datatype such as uint16_t and greater.
No optimization takes place.

[Bug target/82931] Missing Optimization for Bit-Transfer (AVR Target)

[wilhelm.me...@hs-kl.de]

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

--- Comment #1 from wilhelm.me...@hs-kl.de ---
Should compile with -Os to reproduce the result.

[Bug debug/79015] ICE in get_insn_template in gcc/final.c:2081

[allizgubccg at reallysoft dot de]

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

Ralf  changed:

   What|Removed |Added

 CC||allizgubccg at reallysoft dot 
de

--- Comment #2 from Ralf  ---
I encounter very similar internal compiler errors for several source files and
with several gcc version (tested: 5.5, 6.3 and 7.1).

The affected functions contain huge amounts of generated test code. 
Starting with gcc 7.1 the compilation times for some of these modules raised up
to several minutes, so I tried to disable optimization for the test code to
reduce compile times.

For compilations done with -O1 up to-O3 and -Wdisabled-optimization I get the
following warnings

adquery.cxx: In function 'void TEST_DB_search()':
adquery.cxx:936: warning: const/copy propagation disabled: 8163 basic blocks
and 57756 registers [-Wdisabled-optimization]
adquery.cxx:936: warning: PRE disabled: 8163 basic blocks and 57756 registers
[-Wdisabled-optimization]
adquery.cxx:936: warning: const/copy propagation disabled: 8163 basic blocks
and 57756 registers [-Wdisabled-optimization]
adquery.cxx:936: warning: const/copy propagation disabled: 8163 basic blocks
and 57756 registers [-Wdisabled-optimization]


To disable the unneeded, time-consuming optimization I've attributed the
functions where these warnings occurred with
   __attribute__((optimize("no-var-tracking")))
which caused gcc to terminate with:

adquery.cxx:936:1: internal compiler error: in get_insn_template, at
final.c:2124
0x8583f6 get_insn_template(int, rtx_def*)
../../gcc-5.5.0/gcc/final.c:2124
0x85a9ba final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-5.5.0/gcc/final.c:2986
0x85b2c9 final(rtx_insn*, _IO_FILE*, int)
../../gcc-5.5.0/gcc/final.c:2089
0x85b71b rest_of_handle_final
../../gcc-5.5.0/gcc/final.c:4488
0x85b71b execute
../../gcc-5.5.0/gcc/final.c:4563
Please submit a full bug report, ...


Adding a second attribute
   __attribute__((optimize("no-var-tracking-assignments")))
made the problem disappear reproducible.

[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables

[arjen.markus at deltares dot nl]

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

--- Comment #6 from Arjen Markus  ---
Thanks for the explanation and the adjusted example. This is clear enough.

[Bug target/82931] Missing Optimization for Bit-Transfer (AVR Target)

[wilhelm.me...@hs-kl.de]

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

wilhelm.me...@hs-kl.de changed:

   What|Removed |Added

  Attachment #42574|0   |1
is obsolete||

--- Comment #2 from wilhelm.me...@hs-kl.de ---
Created attachment 42575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42575&action=edit
Minimum complete verifying example

[Bug fortran/82932] New: [8 Regression] [OOP] ICE in update_compcall_arglist, at fortran/resolve.c:5837

[janus at gcc dot gnu.org]

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

Bug ID: 82932
   Summary: [8 Regression] [OOP] ICE in update_compcall_arglist,
at fortran/resolve.c:5837
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Consider this (invalid) test case:


module m

   implicit none

   type, abstract :: AT
   contains
  procedure(init_ifc), deferred :: sinit
  procedure(missing_ifc), deferred :: missing
  generic :: init=> sinit
   end type

   abstract interface
  subroutine init_ifc(data)
 import AT
 class(AT) :: data
  end subroutine
  subroutine missing_ifc(data)
 import AT
 class(AT) :: data
  end subroutine
   end interface

end module


program p

   use m

   implicit none

   type, extends(AT) :: ET
   contains
  procedure :: sinit
   end type

   type(ET) :: c
   call c%init()

end


With current trunk I get:

type, extends(AT) :: ET
  1
Error: Derived-type ‘et’ declared at (1) must be ABSTRACT because ‘missing’ is
DEFERRED and not overridden
f951: internal compiler error: in update_compcall_arglist, at
fortran/resolve.c:5837
0x7016e9 update_compcall_arglist
/home/janus/gcc/trunk/gcc/fortran/resolve.c:5837
0x7016e9 resolve_typebound_static
/home/janus/gcc/trunk/gcc/fortran/resolve.c:5978
0x707ec9 resolve_typebound_call
/home/janus/gcc/trunk/gcc/fortran/resolve.c:6190
0x7061ea resolve_typebound_subroutine
/home/janus/gcc/trunk/gcc/fortran/resolve.c:6492
0x7061ea gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/resolve.c:11265
0x706e5a resolve_codes
/home/janus/gcc/trunk/gcc/fortran/resolve.c:16407
0x706f66 gfc_resolve(gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/resolve.c:16442
0x6f01aa resolve_all_program_units
/home/janus/gcc/trunk/gcc/fortran/parse.c:6030
0x6f01aa gfc_parse_file()
/home/janus/gcc/trunk/gcc/fortran/parse.c:6280
0x736baf gfc_be_parse_file
/home/janus/gcc/trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


gfortran 5,6,7 give just the error message, but no ICE.

[Bug fortran/82932] [8 Regression] [OOP] ICE in update_compcall_arglist, at fortran/resolve.c:5837

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-10
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
This draft patch fixes the ICE:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 254521)
+++ gcc/fortran/resolve.c   (working copy)
@@ -5834,7 +5834,9 @@ update_compcall_arglist (gfc_expr* e)
   return true;
 }

-  gcc_assert (tbp->pass_arg_num > 0);
+  if (tbp->pass_arg_num <= 0)
+return false;
+
   e->value.compcall.actual = update_arglist_pass (e->value.compcall.actual,
po,
  tbp->pass_arg_num,
  tbp->pass_arg);

[Bug c/82933] New: valgrind error in set_cur_line_info_table with -g

[dcb314 at hotmail dot com]

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

Bug ID: 82933
   Summary: valgrind error in set_cur_line_info_table with -g
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For a valgrind version of recent gcc trunk, run over the testsuite:

$ /home/dcb/gcc/results.254440.valgrind/bin/gcc -c -g 
./gcc.dg/rtl/x86_64/into-cfglayout.c
==7666== Invalid write of size 1
==7666==at 0x767B0E: set_cur_line_info_table(section*) (dwarf2out.c:26501)
==7666==by 0xDE7942: assemble_start_function(tree_node*, char const*)
(varasm.c:1821)
==7666==by 0x803407: rest_of_handle_final (final.c:4475)
==7666==by 0x803407: (anonymous namespace)::pass_final::execute(function*)
(final.c:4551)

The line of code in question is

  table->end_label = cold_end_label;

svn blame says

171816rth table->end_label = cold_end_label;

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I've now submitted the patch upstream: https://reviews.llvm.org/D39888.
Let's see how this goes.

Rainer

[Bug middle-end/82928] glibc test-tgmath3 ICE on powerpc64le

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

  Attachment #42571|0   |1
is obsolete||

--- Comment #1 from Alan Modra  ---
Created attachment 42576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42576&action=edit
reduced testcase

[Bug fortran/82934] New: Segfault on assumed character length in allocate

[pault at gcc dot gnu.org]

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

Bug ID: 82934
   Summary: Segfault on assumed character length in allocate
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Reported by FortranFan on clf:
https://groups.google.com/forum/#!topic/comp.lang.fortran/Lg8tBwlkS6A

   character(len=42), allocatable :: foo

   call alloc( foo )

   print *, "len(foo) = ", len(foo), "; expected = 42"

contains

   subroutine alloc( bar )

  character(len=*), allocatable :: bar

  allocate( character(len=*) :: bar )

   end subroutine

end 

[pault@pc30 pr78990]$ gfortran -static-libgfortran f*.f90 -O2
fortranfan1.f90:15:0:

   allocate( character(len=*) :: bar , barbar)
 1
internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5316

GNU Fortran (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)

Goes through all the way to trunk.

Paul

[Bug target/82935] New: Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[antoshkka at gmail dot com]

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

Bug ID: 82935
   Summary: Unnecessary "sub rsp, 8", "call" and "add rsp, 8"
instructions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following code

typedef struct array_ {
int data[10202023];
} array;

void assign(array* a1, array* a2) {
*a1 = *a2;
}


Generates assembly:
assign:
sub rsp, 8< Not required
mov edx, 40808092
callmemcpy< jmp ?
add rsp, 8< Not required
ret



Clang generates much more compact assembly:
assign: # @assign
mov edx, 40808092
jmp memcpy  # TAILCALL

[Bug rtl-optimization/82597] [8 Regression] ICE at -O2 and -O3 x86_64-linux-gnu in the 32-bit mode: in extract_constrain_insn, at recog.c:2207

[asolokha at gmx dot com]

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

--- Comment #8 from Arseny Solokha  ---
Is it safe to close this PR now?

[Bug tree-optimization/82902] [7 Regression] ICE verify_ssa failed during GIMPLE pass: phiprop

[jvb at cyberscience dot com]

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

--- Comment #5 from John Buddery  ---
Thanks for the quick fix - this resolves the ICE in 8.0 for me, and applying to
7.2 fixes the invalid code generation I was seeing there.

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Why do you think these instructions are not needed?

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
> Why do you think these instructions are not needed?

Because Clang does not generate them.

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Antony Polukhin from comment #2)

> Because Clang does not generate them.

So, the Earth is flat because someone says, too?

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 10 10:31:34 2017
New Revision: 254623

URL: https://gcc.gnu.org/viewcvs?rev=254623&root=gcc&view=rev
Log:
PR bootstrap/82916
* gimple-ssa-store-merging.c
(pass_store_merging::terminate_all_aliasing_chains): For
gimple_store_p stmts also call refs_output_dependent_p.

* gcc.dg/store_merging_2.c: Only expect 2 successful mergings instead
of 3.
* gcc.dg/pr82916.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr82916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/store_merging_2.c

[Bug bootstrap/82916] [8 regression] gcc miscompiled during stagefeedback (PGO bootstrap)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
We keep

  *a1_2(D) = *a2_3(D);

and only at expansion time turn it into a call to memcpy, so the gimple pass
that detects tail calls doesn't have a chance to notice this case.

[Bug c++/82936] New: segment fault crash for non-type template parameter

[lizhenhuan1019 at qq dot com]

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

Bug ID: 82936
   Summary: segment fault crash for non-type template parameter
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lizhenhuan1019 at qq dot com
  Target Milestone: ---

Created attachment 42577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42577&action=edit
The test case.

Tried to compile the following code but gcc 7.2.0 crashed with segment fault.
Neither diagnostic message nor output file were generated.
Tested on Arch Linux x64 and windows 10 x64(using MSYS2 in Mingw-w64 mode) and
both crashed. Also tested on online compiler wandbox.org and the same occurred.
The code(small enough):
#include 

int fun(int i)
{
return 0;
}
template
struct outer;
template
struct outer
{
template
struct callable
{
template 
R operator()(T&&...t)
{
return f(std::forward(t)...);
}
};
};
int main()
{
outer::callable f;//this line triggered the bug.
return 0;
}
//the code ends.
On Arch Linux:
The command used to compile the test case was g++ main.cpp
The error output of g++ main.cpp -v -save-temps :
**begin:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0

/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -version -o
main.s
GNU C++14 (GCC) version 7.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5931a2fe3d5a5365a85e56248f3f55d7
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
** end:

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 41455.

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

[Bug rtl-optimization/41455] memcpy not tail called if it's a struct assignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

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

[Bug middle-end/41455] memcpy not tail called if it's a struct assignment

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
I suspect what we can do is "lower" assignments to memcpy in a pass right
before tail call to optimize this case.

[Bug c++/82936] segment fault crash for non-type template parameter

[lizhenhuan1019 at qq dot com]

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

--- Comment #1 from lizhenhuan1019  ---
Created attachment 42578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42578&action=edit
The preprocessed file main.ii on Arch Linux

[Bug target/82935] Unnecessary "sub rsp, 8", "call" and "add rsp, 8" instructions

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Well, clang uses a tail call, and we don't.  And the reason why we don't is
that the call is introduced only during expansion and doesn't therefore have
the
GF_CALL_TAILCALL flag set (CALL_EXPR_TAILCALL on the CALL_EXPR).

The options I see (Richard, any preferences?):
1) turn aggregate assignments during the tailcall pass if at tailcall positions
into calls and set the flag
2) introduce a flag like GF_CALL_TAILCALL on structure assignment statements or
aggregate clearing, compute it during tailcall pass and check that flag during
aggregate copy/clear expansion
3) perform the analysis the tailcall pass does during expansion of aggregate
assignment or aggregate clearing

[Bug c++/82936] segment fault crash for non-type template parameter

[lizhenhuan1019 at qq dot com]

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

--- Comment #2 from lizhenhuan1019  ---
Simplified the test case more:
int fun(int i)
{
return 0;
}
template 
struct outer;
template 
struct outer
{
template 
struct callable
{
};
};
outer::callable f;//this line triggered the bug.

[Bug c++/82936] segment fault crash for non-type template parameter

[lizhenhuan1019 at qq dot com]

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

lizhenhuan1019  changed:

   What|Removed |Added

  Attachment #42577|0   |1
is obsolete||

--- Comment #3 from lizhenhuan1019  ---
Created attachment 42579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42579&action=edit
Simplified test case main.cpp

[Bug c++/82936] segment fault crash for non-type template parameter

[lizhenhuan1019 at qq dot com]

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

--- Comment #4 from lizhenhuan1019  ---
On Windows 10, MSYS2 in Mingw-w64 mode:

The error output of g++ main.cpp -v -save-temps:
***The output begins
Using built-in specs.
COLLECT_GCC=D:\Program_Files\mysy64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 7.2.0 (Rev1, Built by MSYS2 project) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/cc1plus.exe
-E -quiet -v -iprefix
D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/
-D_REENTRANT main.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o main.ii
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0"
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0/x86_64-w64-mingw32"
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0/backward"
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/include-fixed"
ignoring duplicate directory
"D:/Program_Files/mysy64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 D:\library\global\include

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0/x86_64-w64-mingw32

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include/c++/7.2.0/backward

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/include

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../include

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/include-fixed

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

D:/Program_Files/mysy64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/cc1plus.exe
-fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64
-auxbase main -version -o main.s
* The output ends.

The simplified test case is simple enough so that no preprocess source is
needed, so I don't upload the preprocessed source on Mingw-w64.

[Bug debug/82933] valgrind error in set_cur_line_info_table with -g

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
A non-valgrind recent version of gcc does this:

$ ~/gcc/results.254608/bin/gcc -g -c gcc.dg/rtl/x86_64/into-cfglayout.c
during RTL pass: final
gcc.dg/rtl/x86_64/into-cfglayout.c: In function ‘test_1’:
gcc.dg/rtl/x86_64/into-cfglayout.c:108:1: internal compiler error: Segmentation 
fault
 }
 ^
0xd2cd0f crash_signal
../../trunk/gcc/toplev.c:325
0x914d37 set_cur_line_info_table
../../trunk/gcc/dwarf2out.c:26530
0x914d37 dwarf2out_begin_function
../../trunk/gcc/dwarf2out.c:26563
0xfe123f assemble_start_function(tree_node*, char const*)
../../trunk/gcc/varasm.c:1821

[Bug target/82927] [8 Regression] ICE in verify_flow_info building SH glibc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I'll take a look, thank you for report.

[Bug middle-end/82918] No aliasing is possible on non equal pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-10
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Currently points-to analysis is not flow-sensitive and thus we have no way to
represent this.  It's also a challenge to keep such information correct, if
attached to the memory accesses for example via MR_DEPENDENCE_{CLIQUE,BASE}
information, because it either restricts code motion across the predicate
or invalidates the info when moving across it.

So - confirmed, but "not so easy".  For this and the related PRs it's probably
best to have on-demand of extra information.

[Bug other/82925] [8 regression] gcc.dg/tree-ssa/vrp101.c fails starting with r254379

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-10
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I see counts weirdly printed _before_  now.  Please fix.

[Bug tree-optimization/82929] [8 regression] r254579 causes ICE: tree check: expected ssa_name, have array_ref in has_single_use, at ssa-iterators.h:400

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/82928] [8 Regression] glibc test-tgmath3 ICE on powerpc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|glibc test-tgmath3 ICE on   |[8 Regression] glibc
   |powerpc64le |test-tgmath3 ICE on
   ||powerpc64le

[Bug target/82927] [8 Regression] ICE in verify_flow_info building SH glibc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

[Bug debug/82933] [8 Regression] valgrind error in set_cur_line_info_table with -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|valgrind error in   |[8 Regression] valgrind
   |set_cur_line_info_table |error in
   |with -g |set_cur_line_info_table
   ||with -g

[Bug middle-end/41455] memcpy not tail called if it's a struct assignment

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
We could do that I suppose.  Of course memcpy will expand to alias-set zero
block copies while aggregate assignment can use better info.

So in the end this means doing full block-copy expansion on GIMPLE rather than
on RTL.  Which sounds messy / impossible given stuff like rep; movb;

Another option is to not use __builtin_memcpy for aggregate assignments but
some internal function call that we can hand extra parameters (for aliasing).

[Bug fortran/82937] New: [F03] associate non-standard bounds are lost for associating entity

[only_for_nouse at gmx dot de]

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

Bug ID: 82937
   Summary: [F03] associate non-standard bounds are lost for
associating entity
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: only_for_nouse at gmx dot de
  Target Milestone: ---

Created attachment 42580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42580&action=edit
Fortran 2003 program with associate construct

The attached file compiles and links fine with gfortran 7.2 compilers.
(gfortran -g -fbounds-check -O0 fortran_associate.F90)
The output of the code is
arr bounds are ( 1, 5)( 1, 8)(-3, 3)( 1,10)
myarr bounds are ( 1, 7)( 1,10)
At line 18 of file fortran_associate.F90
Fortran runtime error: Index '-3' of dimension 1 of array 'myarr' below lower
bound of 1

The code uses the associate construct to associate a subarray with an
associate name. The original array has non-standard array bounds -3:3,
but these array bounds are not retained for the associate name, although
the standard says:

Within an ASSOCIATE or SELECT  TYPE  construct,  each  associating
entity  has  the  same  rank  and  corank as its associated selector.
The lower bound of each dimension is the result of the intrinsic
function LBOUND applied  to  the  corresponding  dimension  of
selector. The  upper  bound  of  each  dimension  is  one  less
than the sum of the lower bound and the extent.

To my understanding, the array bounds of the selector should be retained
also inside the associate construct for the associating entity.

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-11-10
 Ever confirmed|0   |1
Summary|Segfault on assumed |[6/7/8 Regression] Segfault
   |character length in |on assumed character length
   |allocate|in allocate
  Known to fail||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
The test gives the expected result with gfortran 4.8 and 4.9. The change in
behavior occurred between revisions r221412 + 3 patches (2015-03-13, works) and
r2214164 + 3 patches (2015-03-16, ICE).

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Fri Nov 10 12:24:24 2017
New Revision: 254624

URL: https://gcc.gnu.org/viewcvs?rev=254624&root=gcc&view=rev
Log:
2017-11-10  Paul Thomas  

PR fortran/82934
* trans-stmt.c (gfc_trans_allocate): Remove the gcc_assert on
null string length for assumed length typespec and set
expr3_esize to NULL_TREE;

2017-11-10  Paul Thomas  

PR fortran/82934
* gfortran.dg/allocate_assumed_charlen_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
So problem is that in pass_reorder_blocks::execute we reorder blocks so that
they are separated to cold and hot partitions. Then cleanup_cfg
(CLEANUP_EXPENSIVE); is called (bb-reorder.c:2593) and we end here:

  2324  static vec
  2325  find_partition_fixes (bool flag_only)
  2326  {
  2327basic_block bb;
  2328vec bbs_in_cold_partition = vNULL;
  2329vec bbs_to_fix = vNULL;
  2330hash_set set;
  2331  
  2332/* Callers check this.  */
  2333gcc_checking_assert (crtl->has_bb_partition);
  2334  
  2335find_bbs_reachable_by_hot_paths (&set);
  2336  
  2337FOR_EACH_BB_FN (bb, cfun)
  2338  if (!set.contains (bb)
  2339  && BB_PARTITION (bb) != BB_COLD_PARTITION)
  2340{
  2341  if (flag_only)
  2342error ("non-cold basic block %d reachable only "
  2343   "by paths crossing the cold partition", bb->index);
  2344  else
  2345BB_SET_PARTITION (bb, BB_COLD_PARTITION);
  2346  bbs_to_fix.safe_push (bb);
  2347  bbs_in_cold_partition.safe_push (bb);
  2348}
  2349  
  2350return bbs_to_fix;
  2351  }

and we mark one BB in hot partition as COLD. That causes the ICE.
What about something like this:

diff --git a/gcc/basic-block.h b/gcc/basic-block.h
index 5a5ddbfcb6d..5c393efd164 100644
--- a/gcc/basic-block.h
+++ b/gcc/basic-block.h
@@ -506,6 +506,7 @@ ei_cond (edge_iterator ei, edge *p)
   insns.  */
 #define CLEANUP_CFGLAYOUT  32  /* Do cleanup in cfglayout mode.  */
 #define CLEANUP_CFG_CHANGED64  /* The caller changed the CFG.  */
+#define CLEANUP_NO_PARTITIONING128  /* Do not try to fix
partitions.  */

 /* Return true if BB is in a transaction.  */

diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index f7c1f4c971e..20e231739e3 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -2590,7 +2590,7 @@ pass_reorder_blocks::execute (function *fun)
   cfg_layout_initialize (CLEANUP_EXPENSIVE);

   reorder_basic_blocks ();
-  cleanup_cfg (CLEANUP_EXPENSIVE);
+  cleanup_cfg (CLEANUP_EXPENSIVE | CLEANUP_NO_PARTITIONING);

   FOR_EACH_BB_FN (bb, fun)
 if (bb->next_bb != EXIT_BLOCK_PTR_FOR_FN (fun))
diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 4734d3eae17..84756a542da 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -3011,7 +3011,8 @@ try_optimize_cfg (int mode)
  to detect and fix during edge forwarding, and in some cases
  is only visible after newly unreachable blocks are deleted,
  which will be done in fixup_partitions.  */
- fixup_partitions ();
+ if ((mode & CLEANUP_NO_PARTITIONING) == 0)
+   fixup_partitions ();
  checking_verify_flow_info ();
 }

[Bug target/82863] [8 Regression] ICE in verify_flow_info building SH libgcc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
Thanks for working this out! The patch looks good to me.  I wonder how we ended
up with such contradictory block at the first place? Was it introduced by
someone between the last expensive cfg cleanup and bb-reorder?

Honza

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jan Hubicka from comment #5)
> Thanks for working this out! The patch looks good to me.  I wonder how we
> ended up with such contradictory block at the first place? Was it introduced
> by someone between the last expensive cfg cleanup and bb-reorder?
> 
> Honza

Good question. The BB (16 and 17) are marked first as hot in bb-reorder, later
then identified by expensive cfg cleanup as cold. Feel free to investigate
function body.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 42581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42581&action=edit
bbro rtl dump

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> The test gives the expected result with gfortran 4.8 and 4.9. The change in
> behavior occurred between revisions r221412 + 3 patches (2015-03-13, works)
> and r2214164 + 3 patches (2015-03-16, ICE).

Oddly, the fortran ChangeLog shows nothing between these dates that one could
implicate.

As you will see, the fix was trivial. I am just about to post it on the list
and will apply it to 6- and 7-branches over the weekend. Even if not a
regression, it does prevent an ICE in a particularly robust way :-)

Thanks for investigating.

Paul

[Bug other/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Now manifests itself for LTO bootstrapped compilers.

[Bug fortran/82938] New: Speed regression in internal read

[manfred99 at gmx dot ch]

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

Bug ID: 82938
   Summary: Speed regression in internal read
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch
  Target Milestone: ---

#!/bin/sh

seq --format="%.1f" 1 100 > read.txt
cat > read.f 

[Bug preprocessor/82939] New: genmatch fills up terminal with endless printing of periods

[egallager at gcc dot gnu.org]

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

Bug ID: 82939
   Summary: genmatch fills up terminal with endless printing of
periods
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: bonzini at gnu dot org, dmalcolm at gcc dot gnu.org,
dodji at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10

While trying to build gcc trunk today as of r254623, I ran into an issue where
genmatch looped infinitely printing periods until I had to kill it. Debugging
the issue in gdb, I traced it back to line 1391 in libcpp/linemap.c; svn blame
output for that portion of the code looks like this:

 82199bonzini /* Print an include trace, for e.g. the -H option of the
preprocessor.  */
 82199bonzini 
 82199bonzini static void
223365   dmalcolm trace_include (const struct line_maps *set, const
line_map_ordinary *map)
 82199bonzini {
 82199bonzini   unsigned int i = set->depth;
 82199bonzini 
 82199bonzini   while (--i)
 82199bonzini putc ('.', stderr);
180081  dodji 
180081  dodji   fprintf (stderr, " %s\n", ORDINARY_MAP_FILE_NAME (map));
 82199bonzini }

Stepping into the loop, i turns out to be:

(gdb) p i
$2 = 1606398065

So I guess that's not actually infinite, but that's still an unreasonably large
value for i. Did it wrap around or something? 

My configure args:

../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--with-build-config=bootstrap-debug --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --enable-objc-gc
--enable-libada --enable-libssp --disable-libsanitizer CC='/usr/bin/gcc-4.2
-arch i386 -arch x86_64' CXX='/usr/bin/g++-4.2 -arch x86_64'
AR_FOR_TARGET=/opt/local/bin/ar AS_FOR_TARGET=/opt/local/bin/as
LD_FOR_TARGET=/opt/local/bin/ld NM_FOR_TARGET=/opt/local/bin/nm
RANLIB_FOR_TARGET=/opt/local/bin/ranlib STRIP_FOR_TARGET=/opt/local/bin/strip
OTOOL=/opt/local/bin/otool OTOOL64=/opt/local/bin/otool
AUTOCONF=/opt/local/bin/autoconf264 AUTOHEADER=/opt/local/bin/autoheader264
AUTOM4TE=/opt/local/bin/autom4te264 AUTORECONF=/opt/local/bin/autoreconf264
AUTOSCAN=/opt/local/bin/autoscan264 AUTOUPDATE=/opt/local/bin/autoupdate264
IFNAMES=/opt/local/bin/ifnames264 ACLOCAL=/sw/bin/aclocal-1.11
PERL=/opt/local/bin/perl CFLAGS='-pipe -g -Os' CXXFLAGS='-pipe -g -Os
-fcheck-new' CPP='/usr/bin/gcc-4.2 -E' CXXCPP='/usr/bin/g++-4.2 -E'
M4=/opt/local/bin/gm4

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Is that during stage 1 or in a later stage?

[Bug tree-optimization/82929] [8 regression] r254579 causes ICE: tree check: expected ssa_name, have array_ref in has_single_use, at ssa-iterators.h:400

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 10 14:43:13 2017
New Revision: 254628

URL: https://gcc.gnu.org/viewcvs?rev=254628&root=gcc&view=rev
Log:
PR tree-optimization/82929
* gimple-ssa-store-merging.c (struct store_immediate_info): Add
ops_swapped_p non-static data member.
(store_immediate_info::store_immediate_info): Clear it.
(imm_store_chain_info::coalesce_immediate_stores): If swapping
ops set ops_swapped_p.
(count_multiple_uses): Handle ops_swapped_p.

* gcc.dg/pr82929.c: New test.
* g++.dg/opt/pr82929.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr82929.C
trunk/gcc/testsuite/gcc.dg/pr82929.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Marc Glisse from comment #1)
> Is that during stage 1 or in a later stage?

stage 1.

Backtraces, for reference:

(gdb) bt
#0  trace_include [inlined] () at
/Users/ericgallager/gcc/libcpp/line-map.c:1390
#1  0x00010003c105 in linemap_add (set=, reason=, sysp=,
to_file=0x100500f90 "../../gcc/match.pd", to_line=1) at
../../../libcpp/line-map.c:570
#2  0x00010002c33c in _cpp_do_file_change (pfile=0x100800400, reason=, to_file=, file_line=, sysp=) at ../../../libcpp/directives.c:1125
#3  0x000100033af7 in _cpp_stack_file (pfile=0x100800400, file=0x100500e80,
import=false, loc=0) at ../../../libcpp/files.c:932
#4  0x00010003556c in cpp_read_main_file (pfile=0x100800400,
fname=0x7fff5fbfb6e1 "../../gcc/match.pd") at ../../../libcpp/init.c:647
#5  0x000100011ead in main (argc=3, argv=0x7fff5fbfb208) at
../../gcc/genmatch.c:5002
(gdb) bt full
#0  trace_include [inlined] () at
/Users/ericgallager/gcc/libcpp/line-map.c:1390
map = (const line_map_ordinary *) #1  0x00010003c105 in linemap_add
(set=, reason=, sysp=, to_file=0x100500f90 "../../gcc/match.pd",
to_line=1) at ../../../libcpp/line-map.c:570
map = (const line_map_ordinary *) #2  0x00010002c33c in
_cpp_do_file_change (pfile=0x100800400, reason=, to_file=, file_line=, sysp=) at
../../../libcpp/directives.c:1125
map = 
ord_map = 
__FUNCTION__ = "_cpp_do_file_change"
#3  0x000100033af7 in _cpp_stack_file (pfile=0x100800400, file=0x100500e80,
import=false, loc=0) at ../../../libcpp/files.c:932
buffer = 
sysp = 0
#4  0x00010003556c in cpp_read_main_file (pfile=0x100800400,
fname=0x7fff5fbfb6e1 "../../gcc/match.pd") at ../../../libcpp/init.c:647
No locals.
#5  0x000100011ead in main (argc=3, argv=0x7fff5fbfb208) at
../../gcc/genmatch.c:5002
r = (cpp_reader *) 0x100800400
gimple = true
input = 0x7fff5fbfb6e1 "../../gcc/match.pd"
cb = (cpp_callbacks *) 0x100800760
dir = (cpp_dir *) 0x100500e40
p = {
  r = 0x0, 
  active_ifs = {
m_vec = 0x9
  }, 
  active_fors = {
m_vec = 0x7fff5fc005f8
  }, 
  oper_lists_set = 0x7, 
  oper_lists = {
m_vec = 0x7fff5fc3c028
  }, 
  capture_ids = 0x7fff5fbfb228, 
  last_id = 1606398432, 
  simplifiers = {
m_vec = 0x7fff5fc016de
  }, 
  user_predicates = {
m_vec = 0x7fff5fc00020
  }, 
  parsing_match_operand = false
}
dt = {
  root = 0x7fff5fbfb208
}

[Bug gcov-profile/82702] gcov intermediate format is creating multiple 'gcov' files, it was creating a single file up to GCC 6

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Fri Nov 10 15:23:24 2017
New Revision: 254629

URL: https://gcc.gnu.org/viewcvs?rev=254629&root=gcc&view=rev
Log:
GCOV: create one intermediate file per a gcno file (PR gcov-profile/82702).

2017-11-10  Martin Liska  

PR gcov-profile/82702
* gcov.c (main): Handle intermediate files in a different
way.
(get_gcov_intermediate_filename): New function.
(output_gcov_file): Remove support of intermediate files.
(generate_results): Allocate intermediate file.
(release_structures): Clean-up properly fn_end.
(output_intermediate_file): Start iterating with line 1.

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

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||manfred99 at gmx dot ch

--- Comment #22 from Thomas Koenig  ---
*** Bug 82938 has been marked as a duplicate of this bug. ***

[Bug fortran/82938] Speed regression in internal read

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
This issue is known.

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

[Bug c/82940] New: Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc

[christophe.le...@c-s.fr]

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

Bug ID: 82940
   Summary: Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.le...@c-s.fr
  Target Milestone: ---

unsigned char g(unsigned char t[], unsigned char v)
{
return (t[v & 0x7f] & 0x7f) | (v & 0x80);
}

0008 :
   8:   54 89 06 7e clrlwi  r9,r4,25
   c:   7c 63 48 ae lbzxr3,r3,r9
  10:   54 84 00 30 rlwinm  r4,r4,0,0,24
  14:   54 63 06 7e clrlwi  r3,r3,25
  18:   7c 63 23 78 or  r3,r3,r4
  1c:   4e 80 00 20 blr


I would expect

0008 :
   8:   54 89 06 7e clrlwi  r9,r4,25
   c:   7c 63 48 ae lbzxr3,r3,r9
  10:   54 84 00 30 rlwimi  r3,r4,0,24,24
  14:   4e 80 00 20 blr

[Bug fortran/82932] [8 Regression] [OOP] ICE in update_compcall_arglist, at fortran/resolve.c:5837

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> This draft patch fixes the ICE:

... and regtests cleanly!

[Bug tree-optimization/82929] [8 regression] r254579 causes ICE: tree check: expected ssa_name, have array_ref in has_single_use, at ssa-iterators.h:400

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Fixed, thanks.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Thanks for working this out! The patch looks good to me.

No, I disagree, the patch only papers over the problem.

> I wonder how we ended up with such contradictory block at the first place?  
> Was
> it introduced by someone between the last expensive cfg cleanup and 
> bb-reorder?

Yes, that's what needs to be investigated and probably fixed.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[noloader at gmail dot com]

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

Jeffrey Walton  changed:

   What|Removed |Added

 CC||noloader at gmail dot com

--- Comment #8 from Jeffrey Walton  ---
I don't know how much of this observation applies, but:

$ ./configure --help | grep sysroot
  --with-sysroot[=DIR]Search for dependent libraries within DIR (or the
  compiler's sysroot if not specified).

The description does not say anything about headers; it only says libraries.

I am certainly not advocating for it. In fact, I came across this bug report
because a --with-sysroot (not --with-build-sysroot) is not being honored, and
headers seem to be the problem.

By the way, when compiling the compiler, I though --host and --target are used.
"Build" indicates the machine the tools are running on. So wouldn't that be
--with-host-sysroot or --with-target-sysroot?

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Fri Nov 10 16:35:26 2017
New Revision: 254630

URL: https://gcc.gnu.org/viewcvs?rev=254630&root=gcc&view=rev
Log:
PR c/81117 - Improve buffer overflow checking in strncpy

gcc/ChangeLog:

PR c/81117
* builtins.c (compute_objsize): Handle arrays that
compute_builtin_object_size likes to fail for.  Make extern.
* builtins.h (compute_objsize): Declare.
(check_strncpy_sizes): New function.
(expand_builtin_strncpy): Call check_strncpy_sizes.
* gimple-fold.c (gimple_fold_builtin_strncpy): Implement
-Wstringop-truncation.
(gimple_fold_builtin_strncat): Same.
* gimple.c (gimple_build_call_from_tree): Set call location.
* tree-ssa-strlen.c (strlen_to_stridx): New global variable.
(maybe_diag_bound_equal_length, is_strlen_related_p): New functions.
(handle_builtin_stxncpy, handle_builtin_strncat): Same.
(handle_builtin_strlen): Use strlen_to_stridx.
(strlen_optimize_stmt): Handle flavors of strncat, strncpy, and
stpncpy.
Use strlen_to_stridx.
(pass_strlen::execute): Release strlen_to_stridx.
* doc/invoke.texi (-Wsizeof-pointer-memaccess): Document enhancement.
(-Wstringop-truncation): Document new option.

gcc/ada/ChangeLog:

PR c/81117
* ada/adadecode.c (__gnat_decode): Use memcpy instead of strncpy.
* ada/argv.c (__gnat_fill_arg, __gnat_fill_env): Same.

gcc/c-family/ChangeLog:

PR c/81117
* c-common.c (catenate_strings): Use memcpy instead of strncpy.
* c-warn.c (sizeof_pointer_memaccess_warning): Handle arrays.
* c.opt (-Wstringop-truncation): New option.

gcc/fortran/ChangeLog:

PR c/81117
* gcc/fortran/decl.c (build_sym): Use strcpy instead of strncpy.

gcc/objc/ChangeLog:

PR c/81117
* objc-encoding.c (encode_type): Use memcpy instead of strncpy.

gcc/testsuite/ChangeLog:

PR c/81117
* c-c++-common/Wsizeof-pointer-memaccess3.c: New test.
* c-c++-common/Wstringop-overflow.c: Same.
* c-c++-common/Wstringop-truncation.c: Same.
* c-c++-common/Wsizeof-pointer-memaccess2.c: Adjust.
* c-c++-common/attr-nonstring-2.c: New test.
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Adjust.
* g++.dg/torture/Wsizeof-pointer-memaccess2.C: Same.
* gcc.dg/torture/pr63554.c: Same.
* gcc.dg/Walloca-1.c: Disable macro tracking.


Added:
trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess3.c
trunk/gcc/testsuite/c-c++-common/Wstringop-overflow.c
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c
trunk/gcc/testsuite/c-c++-common/attr-nonstring-1.c
trunk/gcc/testsuite/c-c++-common/attr-nonstring-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/adadecode.c
trunk/gcc/ada/argv.c
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-warn.c
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-encoding.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess2.c
trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
trunk/gcc/testsuite/gcc.dg/Walloca-1.c
trunk/gcc/testsuite/gcc.dg/builtin-stpncpy.c
trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
trunk/gcc/testsuite/gcc.dg/torture/pr63554.c
trunk/gcc/tree-ssa-strlen.c

[Bug rtl-optimization/82597] [8 Regression] ICE at -O2 and -O3 x86_64-linux-gnu in the 32-bit mode: in extract_constrain_insn, at recog.c:2207

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/82941] New: Missing vzeroupper with -mavx512f -O2

[hjl.tools at gmail dot com]

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

Bug ID: 82941
   Summary: Missing vzeroupper with -mavx512f -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: pavel.v.chupin at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

[hjl@gnu-6 vzeroupper-skx-1]$ cat bar.c
#include 

extern __m512d y, z;

void
foo ()
{
  z = y;
}
[hjl@gnu-6 vzeroupper-skx-1]$ make bar.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -march=skylake-avx512 -S
bar.c
[hjl@gnu-6 vzeroupper-skx-1]$ cat bar.s
.file   "bar.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB4897:
.cfi_startproc
vmovapd y(%rip), %zmm0
vmovapd %zmm0, z(%rip)
ret
.cfi_endproc
.LFE4897:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.0.0 20171110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 vzeroupper-skx-1]$

[Bug target/82942] New: Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

Bug ID: 82942
   Summary: Generate vzeroupper with -mavx512f -mno-avx512er -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: pavel.v.chupin at gmail dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

When AVX512F is enabled, the vzerouppoer optimization is disabled.
This is intended only for Xeon Phi, not for Skylake server which
also has AVX512F.  Since AVX512ER is unique to Xeon Phi and will
never appear in non Xeon Phi processors, the vzerouppoer optimization
should be enabled when AVX512F is enabled, but AVX512ER isn't:



[hjl@gnu-6 vzeroupper-skx-1]$ cat foo.c
#include 

extern __m512d y, z;

void
foo ()
{
  z = y;
}
[hjl@gnu-6 vzeroupper-skx-1]$ make foo.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mavx512f -mno-avx512er -O2  
-S foo.c
c[hjl@gnu-6 vzeroupper-skx-1]$ cat foo.s
.file   "foo.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB4897:
.cfi_startproc
vmovapd y(%rip), %zmm0
vmovapd %zmm0, z(%rip)
ret
.cfi_endproc
.LFE4897:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.0.0 20171110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 vzeroupper-skx-1]$

[Bug fortran/82943] New: Error derived type-bound procedure PASS(this)

[dreich at yahoo dot com]

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

Bug ID: 82943
   Summary: Error derived type-bound procedure PASS(this)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dreich at yahoo dot com
  Target Milestone: ---

Created attachment 42582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42582&action=edit
Sample program test case showing error

The attached code works without the (n) in the typedef and (n=*) or (*) in the
class line and works in Intel Fortran as submitted here. I tested this with
last night's update in svn gfortran 8 with Cygwin and Eclipse PTP Photran.
I looked through the test suite and found some test cases with NOPASS and
PASS(self) but non with an argument like this.

Error: Argument 'this' of 'foo' with PASS(this) at (1) must be of the
derived-type 'typedef'

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-10
 Blocks||82941
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82941
[Bug 82941] Missing vzeroupper with -march=skylake-avx512 -O2

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[tnfchris at gcc dot gnu.org]

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

--- Comment #9 from Tamar Christina  ---
Author: tnfchris
Date: Fri Nov 10 17:14:28 2017
New Revision: 254632

URL: https://gcc.gnu.org/viewcvs?rev=254632&root=gcc&view=rev
Log:
2017-11-10  Tamar Christina  

PR target/82641
* config/arm/arm.c
(arm_option_override): Refactor.
(arm_option_reconfigure_globals): New.
(arm_options_perform_arch_sanity_checks): New.
* config/arm/arm-protos.h (arm_option_reconfigure_globals): New
prototype.
(arm_options_perform_arch_sanity_checks): Likewise


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
class pass_insert_vzeroupper : public rtl_opt_pass
{
public:
  pass_insert_vzeroupper(gcc::context *ctxt)
: rtl_opt_pass(pass_data_insert_vzeroupper, ctxt)
  {}

  /* opt_pass methods: */
  virtual bool gate (function *)
{
  return TARGET_AVX && !TARGET_AVX512F
 && TARGET_VZEROUPPER && flag_expensive_optimizations
 && !optimize_size;
}

  virtual unsigned int execute (function *)
{
  return rest_of_handle_insert_vzeroupper ();
}

}; // class pass_insert_vzeroupper

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 42583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42583&action=edit
An untested patch

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #1)
>   return TARGET_AVX && !TARGET_AVX512F

Should !TARGET_AVX512F be changed to !TARGET_AVX152ER in gate function?

[Bug fortran/82943] Error derived type-bound procedure PASS(this)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-10
 Blocks||82173
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 42584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42584&action=edit
An untested patch

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #1)
> >   return TARGET_AVX && !TARGET_AVX512F
> 
> Should !TARGET_AVX512F be changed to !TARGET_AVX152ER in gate function?

Yes, the untested patch is updated.

[Bug other/82880] [6/7/8 Regression] gcc --help=target --help=optimizers hangs on mips

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Your patch is the right fix, when it is static on the second invocation the new
p is not stored into it, and register_pass doesn't save the address it is
passed anywhere, just remembers the pass and from the other fields determines
where to put it.
Please post it to gcc-patches with a ChangeLog entry.

[Bug middle-end/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #5 from Joseph S. Myers  ---
*** Bug 82928 has been marked as a duplicate of this bug. ***

[Bug middle-end/82928] [8 Regression] glibc test-tgmath3 ICE on powerpc64le

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #2 from Joseph S. Myers  ---
Already reported.

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

[Bug tree-optimization/82944] New: missing -Wstringop-truncation on strncpy due to system header macro

[msebor at gcc dot gnu.org]

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

Bug ID: 82944
   Summary: missing -Wstringop-truncation on strncpy due to system
header macro
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-truncation warning added in GCC 8.0 via r254630 for bug 81117 is
specifically intended to highlight likely unintended uses of the strncpy
function that truncate the terminating NUL charcter from the source string.  An
example of such a misuse given in the request is the following:

  char buf[2];

  void test (const char* str)
  {
strncpy (buf, str, strlen (str));
  }

As it turns out, although the new checker works correctly when strncpy is
declared as a function, when it's defined as a shadow macro in a system header
(as happens to be the case in in Glibc 2.24 and prior) the warning is
suppressed:

$ (set -x && cat pr81117.c && for opt in '' '--include=string.h'; do gcc -O2 -S
-Wall -Wextra $opt pr81117.c; done)
+ cat pr81117.c
extern __SIZE_TYPE__ strlen (const char*);
extern char* strncpy (char*, const char*, __SIZE_TYPE__);

char buf[2];

void test (const char* str)
{
  strncpy (buf, str, strlen (str));
}
+ for opt in ''\'''\''' ''\''--include=string.h'\'''
+ /ssd/build/gcc-svn/gcc/xgcc -B /ssd/build/gcc-svn/gcc -O2 -S -Wall -Wextra
pr81117.c
pr81117.c: In function ‘test’:
pr81117.c:8:3: warning: ‘strncpy’ output truncated before terminating nul
copying as many bytes from a string as its length [-Wstringop-truncation]
   strncpy (buf, str, strlen (str));
   ^~~~
+ for opt in ''\'''\''' ''\''--include=string.h'\'''
+ /ssd/build/gcc-svn/gcc/xgcc -B /ssd/build/gcc-svn/gcc -O2 -S -Wall -Wextra
--include=string.h pr81117.c

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82944
 Resolution|--- |FIXED

--- Comment #9 from Martin Sebor  ---
The enhancement has been committed in r254630.  With the slightly modified test
case GCC 8.0 produces the warnings below.  Unfortunately, including 
instead of explicitly declaring strncpy may suppress a number of the warnings,
including the one for the last call, when strncpy is defined as a macro in one
of the system headers (as in Glibc 2.24 and prior).

I've raised bug 82944 for the system header problem and so I'm resolving this
request as fixed.

$ cat pr81117.c && gcc -O2 -S -Wall -Wextra pr81117.c 
extern __SIZE_TYPE__ strlen (const char*);
extern char* strncpy (char*, const char*, __SIZE_TYPE__);

char buf[2];

void test (const char* str)
{
strncpy (buf, "12345", sizeof ("12345")); // 1
strncpy (buf, "12345", strlen ("12345")); // 2
strncpy (buf, str, sizeof (str)); // 3
strncpy (buf, str, strlen (str)); // 4
}
pr81117.c: In function ‘test’:
pr81117.c:8:35: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same
expression as the source; did you mean to use the size of the destination?
[-Wsizeof-pointer-memaccess]
 strncpy (buf, "12345", sizeof ("12345")); // 1
   ^
pr81117.c:10:31: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same
expression as the source; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
 strncpy (buf, str, sizeof (str)); // 3
   ^
pr81117.c:9:5: warning: ‘strncpy’ output truncated before terminating nul
copying 5 bytes from a string of the same length [-Wstringop-truncation]
 strncpy (buf, "12345", strlen ("12345")); // 2
 ^~~~
pr81117.c:8:5: warning: array subscript is above array bounds [-Warray-bounds]
 strncpy (buf, "12345", sizeof ("12345")); // 1
 ^~~~
pr81117.c:11:5: warning: ‘strncpy’ output truncated before terminating nul
copying as many bytes from a string as its length [-Wstringop-truncation]
 strncpy (buf, str, strlen (str)); // 4
 ^~~~
pr81117.c:8:5: warning: ‘__builtin_memcpy’ writing 2 bytes into a region of
size 0 overflows the destination [-Wstringop-overflow=]
 strncpy (buf, "12345", sizeof ("12345")); // 1
 ^~~~
pr81117.c:9:5: warning: ‘__builtin_memcpy’ writing 5 bytes into a region of
size 2 overflows the destination [-Wstringop-overflow=]
 strncpy (buf, "12345", strlen ("12345")); // 2
 ^~~~
pr81117.c:10:5: warning: ‘strncpy’ writing 8 bytes into a region of size 2
overflows the destination [-Wstringop-overflow=]
 strncpy (buf, str, sizeof (str)); // 3
 ^~~~

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Eric Botcazou from comment #8)
> > Thanks for working this out! The patch looks good to me.
> 
> No, I disagree, the patch only papers over the problem.
> 
> > I wonder how we ended up with such contradictory block at the first place?  
> > Was
> > it introduced by someone between the last expensive cfg cleanup and 
> > bb-reorder?
> 
> Yes, that's what needs to be investigated and probably fixed.

Hi Eric.

I'm also not happy about the patch. Can you please help me with the bbro pass.
I know you have some skill. Do you think problem is in traces how are traced
(more precisely why are the problematic blocks selected as hot)?
Or merging of the traces? I know it's problematic to reproduce as it happens in
profiled bootstrap, but I would appreciate any help ;)

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka  ---
> > No, I disagree, the patch only papers over the problem.
> > 
> > > I wonder how we ended up with such contradictory block at the first 
> > > place?  Was
> > > it introduced by someone between the last expensive cfg cleanup and 
> > > bb-reorder?
> > 
> > Yes, that's what needs to be investigated and probably fixed.
> 
> Hi Eric.
> 
> I'm also not happy about the patch. Can you please help me with the bbro pass.
> I know you have some skill. Do you think problem is in traces how are traced
> (more precisely why are the problematic blocks selected as hot)?
> Or merging of the traces? I know it's problematic to reproduce as it happens 
> in
> profiled bootstrap, but I would appreciate any help ;)

Most likely the problem is insane profile before BBro itself.  If it is indeed
cfgcleanup with CLEANUP_EXPENSIVE needed to turn the basic block cold, I would
say any pass between last invocation and bbro might have caused the pattern
(possibly becuase the profile was nonsential even earlier).  Grepping for
it:
bb-reorder.c:  cfg_layout_initialize (CLEANUP_EXPENSIVE);
bb-reorder.c:  cleanup_cfg (CLEANUP_EXPENSIVE);
bt-load.c:cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0);
cfgcleanup.c:  else if (mode & CLEANUP_EXPENSIVE)
cfgcleanup.c: if ((mode & CLEANUP_EXPENSIVE)
cfgcleanup.c: if ((mode & CLEANUP_EXPENSIVE) && !reload_completed
cfgcleanup.c:  cleanup_cfg ((optimize ? CLEANUP_EXPENSIVE : 0)
function.c:  cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0);
ifcvt.c:  cleanup_cfg (CLEANUP_EXPENSIVE);
ira.c:cleanup_cfg (CLEANUP_EXPENSIVE);

probably last cleanup was done by rest_of_handle_thread_prologue_and_epilogue
and at that time cfgcleanup did not decided yet to do the move.

IMO turning random hot block into cold is not safe operatoin after
bbro is finished and thus Martin's patch preventing it is good.  We can indeed
track down the real cause (I plan to iterate over profile updating bugs next
week)

Honza

[Bug c++/82924] gcc gives no warning for comparing unsigned integer < 0 even with -Wextra enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-10
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I think that warning is simply disabled in templates, to avoid warnings about
(x < 0) which would depend on whether T is signed or unsigned, but is not a
helpful warning in general. In this case we know that (y < 0) is always an
unsigned type.

[Bug libstdc++/82917] [8 regression] 27_io/basic_{f,if,of}stream/open/char/path.cc fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/82945] New: add warning for passing non-strings to functions that expect string arguments

[msebor at gcc dot gnu.org]

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

Bug ID: 82945
   Summary: add warning for passing non-strings to functions that
expect string arguments
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-truncation warning new in GCC 8.0 warns about calls to strncpy
and strncat that may non nul-terminate the copied string.  Attribute nonstring
was also added to make it possible to suppress the warning for character arrays
that are not meant to be nul-terminated.  However, using such arrays as
arguments to functions that expect nul-terminated string arguments is accepted
with no warning.  To detect such misuses of the non-nul terminated arrays GCC
should issue a warning when they are passed to string functions like strlen.

$ cat c.c && gcc -O2 -S -Wall c.c
char a[4];

int f (void)
{
  __builtin_strncpy (a, "1234", 4);   // -Wstringop-truncation (good)
  return __builtin_strlen (a);// because this is undefined
}

char b[4] __attribute__ ((nonstring));

int g (void)
{
  __builtin_strncpy (b, "1234", 4);   // no warning because of nonstring
  return __builtin_strlen (b);// but this is also undefined
}

c.c: In function ‘f’:
c.c:5:3: warning: ‘__builtin_strncpy’ output truncated before terminating nul
copying 4 bytes from a string of the same length [-Wstringop-truncation]
   __builtin_strncpy (a, "1234", 4);   // -Wstringop-truncation
   ^~~~

[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from Fritz Reese  ---
> https://gcc.gnu.org/ml/fortran/2017-11/msg00059.html

Fix pending review.

[Bug libstdc++/82917] [8 regression] 27_io/basic_{f,if,of}stream/open/char/path.cc fails

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Nov 10 21:43:24 2017
New Revision: 254638

URL: https://gcc.gnu.org/viewcvs?rev=254638&root=gcc&view=rev
Log:
PR libstdc++/82917 add missing returns in 

PR libstdc++/82917
* include/std/fstream (basic_ifstream::open, basic_ofstream::open)
(basic_fstream::open): Fix missing return.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/fstream

[Bug c/81117] Improve buffer overflow checking in strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Fri Nov 10 22:48:43 2017
New Revision: 254641

URL: https://gcc.gnu.org/viewcvs?rev=254641&root=gcc&view=rev
Log:

gcc/ChangeLog:

PR c/81117
* config/darwin-c.c (framework_construct_pathname): Replace strncpy
with memcpy.
(find_subframework_file): Same.


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

[Bug tree-optimization/82945] add warning for passing non-strings to functions that expect string arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-10
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I'll submit a patch for this.

[Bug libstdc++/82917] [8 regression] 27_io/basic_{f,if,of}stream/open/char/path.cc fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
fixed.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> I know you have some skill. Do you think problem is in traces how are traced
> (more precisely why are the problematic blocks selected as hot)?
> Or merging of the traces? I know it's problematic to reproduce as it happens
> in profiled bootstrap, but I would appreciate any help ;)

Yes, this could be during the connection of the traces, which involves copying
basic blocks.  When you do this, you redirect edges, which in turns changes the
dominance relationship and thus can turn a hot block into a cold block.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> IMO turning random hot block into cold is not safe operatoin after
> bbro is finished and thus Martin's patch preventing it is good.  We can
> indeed track down the real cause (I plan to iterate over profile updating 
> bugs 
> next week)

We will never track the real cause if we paper over it...

[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807

[foreese at gcc dot gnu.org]

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

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Sat Nov 11 00:47:53 2017
New Revision: 254648

URL: https://gcc.gnu.org/viewcvs?rev=254648&root=gcc&view=rev
Log:
2017-11-10  Fritz Reese 

PR fortran/82886

gcc/fortran/ChangeLog:

PR fortran/82886
* gfortran.h (gfc_build_init_expr): New prototype.
* invoke.texi (finit-derived): Update documentation.
* expr.c (gfc_build_init_expr): New, from gfc_build_default_init_expr.
(gfc_build_default_init_expr): Redirect to gfc_build_init_expr(,,false)
(component_initializer): Force building initializers using
gfc_build_init_expr(,,true).

gcc/testsuite/ChangeLog:

PR fortran/82886
* gfortran.dg/init_flag_16.f03: New testcase.


Added:
trunk/gcc/testsuite/gfortran.dg/init_flag_16.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82946] New: member pointer defeats strlen optimization involving a string literal

[msebor at gcc dot gnu.org]

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

Bug ID: 82946
   Summary: member pointer defeats strlen optimization involving a
string literal
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the program below, while GCC optimizes the strlen call in f() to a constant
it doesn't do the same for the equivalent function g().

I suspect this is caused by the same underlying assumptions as pr80944: i.e.,
that the strcpy (a->d, "123") call could change a->d if a->d pointed at or into
itself.  While that might be true in other circumstances, it's not possible
here.  Since the array at a->d is subsequently accessed by the call to strlen,
the strcpy call cannot change a->d in a valid program because "123" (or any
other string literal) cannot be a valid representation of a pointer.  (The only
way for a conforming program to obtain a valid pointer is by assigning to it
the value of another valid pointer.  Even if the bit pattern of the literal
"123" happened to match a valid address in a program, copying the literal into
a pointer and then using that pointer is undefined.)

So a->d can be assumed not to change in either function and the strlen
optimization below is safe in both.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c

char* strcpy (char*, const char*);
__SIZE_TYPE__ strlen (const char*);

struct A { char *d; };

unsigned f (struct A *a)
{
  char *d = a->d;
  strcpy (d, "123");
  return strlen (d);   // folded into 3
}

unsigned g (struct A *a)
{
  strcpy (a->d, "123");
  return strlen (a->d);   // not folded but can be
}


;; Function f (f, funcdef_no=0, decl_uid=1898, cgraph_uid=0, symbol_order=0)

f (struct A * a)
{
  char * d;

   [local count: 1]:
  d_4 = a_3(D)->d;
  __builtin_memcpy (d_4, "123", 4);
  return 3;

}



;; Function g (g, funcdef_no=1, decl_uid=1902, cgraph_uid=1, symbol_order=1)

g (struct A * a)
{
  char * _1;
  char * _2;
  long unsigned int _3;
  unsigned int _7;

   [local count: 1]:
  _1 = a_5(D)->d;
  __builtin_memcpy (_1, "123", 4);
  _2 = a_5(D)->d; 
  _3 = strlen (_2);
  _7 = (unsigned int) _3;
  return _7;

}

[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80944

--- Comment #1 from Martin Sebor  ---
I should add that a similar argument could be made in pr80944.  The difference
is that the other report deals with memset(s->a, 0, ...) which, although
strictly also prevented from creating valid pointers (including null pointers),
is commonly used by programs to create null pointers.