[Bug tree-optimization/71987] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: tree check: expected ssa_name, have addr_expr in get_ops, at tree-ssa-reassoc.c:3269

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
 CC||kuganv at linaro dot org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O1|[7 Regression] ICE on valid
   |and above on|code at -O1 and above on
   |x86_64-linux-gnu: tree  |x86_64-linux-gnu: tree
   |check: expected ssa_name,   |check: expected ssa_name,
   |have addr_expr in get_ops,  |have addr_expr in get_ops,
   |at tree-ssa-reassoc.c:3269  |at tree-ssa-reassoc.c:3269
 Ever confirmed|0   |1

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

[Bug tree-optimization/71987] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: tree check: expected ssa_name, have addr_expr in get_ops, at tree-ssa-reassoc.c:3269

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Having a candidate patch, will be sent to ML soon..

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-12/msg00253.ht
   ||ml

--- Comment #5 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00253.html

[Bug c++/71988] New: [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)

[marxin at gcc dot gnu.org]

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

Bug ID: 71988
   Summary: [7 Regression] ICE in dump_simple_decl
(gcc/cp/error.c:965)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

Starting from r238558, we ICE in the following command:

$ g++ -fdump-ipa-cgraph tc.ii

c1plus: internal compiler error: Segmentation fault
0x115f024 crash_signal
../../gcc/toplev.c:335
0x92d8c1 dump_simple_decl
../../gcc/cp/error.c:965
0x92e4f2 dump_decl
../../gcc/cp/error.c:1071
0x937289 decl_as_string(tree_node*, int)
../../gcc/cp/error.c:2880
0x937361 lang_decl_name(tree_node*, int, bool)
../../gcc/cp/error.c:2914
0xa38962 cxx_printable_name_internal
../../gcc/cp/tree.c:2165
0xa38ba9 cxx_printable_name(tree_node*, int)
../../gcc/cp/tree.c:2201
0xc0a369 symtab_node::name() const
../../gcc/symtab.c:523
0xc0a268 symtab_node::asm_name() const
../../gcc/symtab.c:507
0xc278eb analyze_functions
../../gcc/cgraphunit.c:1044
0xc2c2c6 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2545

where
$ cat tc.ii

struct A
{
} constexpr a;

[Bug c++/71988] [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[nico at josuttis dot de]

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

--- Comment #10 from Nicolai Josuttis  ---
OK, thanks for the discussion and especially for the FAQ entry.

I still find it a bit unfortunate that clang and VC++ give an error
while gcc does not.
Especially as std::initializer_lists<> AFAIK were specifically designed
to make narrowing ill-formed (for which I always thought that
an error is appropriate, especially when using --pedantic)

I'll document this in my trainings and will add
-pedantic-errors
to my Makefiles.

Best. Nico

[Bug gcov-profile/68080] gcov returns negative counts

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Well, the test-case is very interesting as it exposes 2 issues:

1) Majority of instrumented profiling code is not thread-safe, for instance
edge profiler:

  PROF_edge_counter_11 =
__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0];
  PROF_edge_counter_12 = PROF_edge_counter_11 + 1;
  __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] =
PROF_edge_counter_12;

2) As the test-case does not properly join created threads and original thread
reaches gcov_exit, we get messed profile. One thread is writing to disk while
the others are still modifying counters.

I'm going to discuss the aforementioned problem on GCC mailing list.

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/71986] Bug bug when compiling gammu-1.37.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-25
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please attach preprocessed source.

[Bug bootstrap/71989] New: aarch64 bootstrap fails for out-of-tree builds

[timo.teras at iki dot fi]

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

Bug ID: 71989
   Summary: aarch64 bootstrap fails for out-of-tree builds
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timo.teras at iki dot fi
  Target Milestone: ---

Observed with 6.1.0 release, and gcc 6-stable 20160721 snapshot.

In-tree bootstrap build succeeds, but out-of-tree bootstrap build fails with
the following configure for me:

$ "$srcdir"/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --build=aarch64-alpine-linux-musl
--host=aarch64-alpine-linux-musl --target=aarch64-alpine-linux-musl
--with-pkgversion="Alpine 6.1.1" --enable-checking=release
--disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls
--disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie
--enable-cloog-backend --enable-languages=c,c++ --with-arch=armv8-a
--with-abi=lp64 --disable-libquadmath --disable-libssp --disable-libmpx
--disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads
--enable-tls --with-system-zlib

The error is:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/simplify-rtx.o differs
gcc/tree-call-cdce.o differs
gcc/tree-vect-slp.o differs
gcc/dfp.o differs
gcc/tsan.o differs
gcc/opts.o differs
gcc/tree-vect-data-refs.o differs
gcc/omp-simd-clone.o differs
gcc/cp/cxx-pretty-print.o differs
gcc/cp/constexpr.o differs
gcc/cp/cp-array-notation.o differs
gcc/cp/typeck.o differs
gcc/cp/cvt.o differs
gcc/cp/logic.o differs
gcc/gimple-low.o differs
gcc/combine-stack-adj.o differs
gcc/insn-dfatab.o differs
gcc/gimple-fold.o differs
gcc/tree-vect-loop.o differs
gcc/jump.o differs
gcc/tree-ssa-scopedtables.o differs
gcc/gimple-pretty-print.o differs
gcc/insn-latencytab.o differs
gcc/insn-output.o differs
gcc/diagnostic-show-locus.o differs
gcc/mcf.o differs
gcc/optabs.o differs
gcc/fixed-value.o differs
gcc/double-int.o differs
gcc/ipa-icf-gimple.o differs
gcc/valtrack.o differs
gcc/cfgbuild.o differs
gcc/tree-streamer-out.o differs
gcc/hsa-regalloc.o differs
gcc/c/c-array-notation.o differs
gcc/shrink-wrap.o differs
gcc/insn-emit.o differs
gcc/c-family/c-omp.o differs
gcc/c-family/c-cilkplus.o differs
gcc/stmt.o differs

[Bug rtl-optimization/71984] [7 Regression] wrong code with -O -mavx512cd

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/71981] [6/7 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu (internal compiler error: in get_dynamic_type, at ipa-polymorphic-call.c:1667)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Alexander Monakov from comment #3)
> On 6/trunk, this issue is fixed or made latent by r230667 that added
> 
> +  STRIP_NOPS (t1);
> +  STRIP_NOPS (t2);
> 
> to tree-vect-data-refs.c:compare_tree (patch submission here:
> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02444.html ).
> Should this change be backported to 4.9/5 now that an ICE is demonstrated?

Yes, backporting this change is fine.

[Bug c++/71972] [6/7 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71971] Destructor of a global static variable in a shared library is not called on dlclose

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Note that after dlclose whether the library is really unloaded depends on the
runtime linker in glibc.  ISTR another bug where a library using specific
features
are never unloaded where I pointed out the feature in question (but can't find
it right now).

This is not a compiler issue.

[Bug gcov-profile/64874] gcov's magic number possibly increasing too quickly with new gcc version numbering scheme.

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Mon Jul 25 08:42:42 2016
New Revision: 238702

URL: https://gcc.gnu.org/viewcvs?rev=238702&root=gcc&view=rev
Log:
Adapt the numbering scheme (PR gcov-profile/64874)

PR gcov-profile/64874
* gcov-io.h: Update command about file format.
* gcov-iov.c (main): Adapt the numbering scheme.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov-io.h
trunk/gcc/gcov-iov.c

[Bug gcov-profile/64874] gcov's magic number possibly increasing too quickly with new gcc version numbering scheme.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug lto/60779] -fcx-fortran-rules ignored when using -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Yes.  But only -fcx-limited-range is looked at by the inliner,
-fcx-fortran-rules is not (via flag_complex_method).  And flag_complex_method
is _not_ saved
per-function, only -fcx-limited-range or -fcx-fortran-rules are but it looks
like flag_complex_method is the "master copy" here.

[Bug rtl-optimization/71976] insn-combiner deletes a live 64-bit shift

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
Summary|[avr] insn-combiner deletes |insn-combiner deletes a
   |a live 64-bit shift |live 64-bit shift
 Ever confirmed|0   |1

--- Comment #6 from Georg-Johann Lay  ---
This also happens on current trunk r238700 from today (2016-07-25).

After substitution from
   (ashiftrt:DI (reg:DI 18 r18)
(reg:QI 16 r16))
to
(ashiftrt:DI (reg:DI 18 r18)
 (const_int 40))

combine calls

simplify_shift_const_1 (code=ASHIFTRT, result_mode=DImode,
varop=0x7734ee70, orig_count=40) at
../../../gcc.gnu.org/trunk/gcc/combine.c:10181

(gdb) p varop
$95 = (rtx) 0x7734ee70
(gdb) pr
(reg:DI 18 r18)

And then there is this piece of code:

  /* An arithmetic right shift of a quantity known to be -1 or 0
 is a no-op.  */
  if (code == ASHIFTRT
  && (num_sign_bit_copies (varop, shift_mode)
  == GET_MODE_PRECISION (shift_mode)))
{
  count = 0;
  break;
}

How can it conclude the quantity to be shifted (reg:DI 18) is always 0 or -1?
This is simply not the case.

[Bug c++/71971] Destructor of a global static variable in a shared library is not called on dlclose

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Alexander Monakov  ---
The library is not unloaded on glibc due to STB_GNU_UNIQUE binding on get::i.
You can opt-out of creating symbols with that binding using -fno-gnu-unique.

But note there was never any guarantee that destructors would be invoked on
dlclose. On musl libc, dlclose is a no-op, and all unloading/destruction
happens on program exit (see the rationale here:
http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Unloading_libraries
). For portable code, you cannot assume that dlclose causes immediate
unloading.

[Bug rtl-optimization/71976] insn-combiner deletes a live 64-bit shift

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
...hmmm this place might be correct.  combine defines

#define RTL_HOOKS_REG_NUM_SIGN_BIT_COPIES  reg_num_sign_bit_copies_for_combine

and this function comes up with

reg_num_sign_bit_copies_for_combine (x=0x7734ee70, mode=DImode,
known_x=0x0, known_mode=VOIDmode, known_ret=0, result=0x7fff8fb0) at
../../../gcc.gnu.org/trunk/gcc/combine.c:9928

(gdb) p x
$112 = (const_rtx) 0x7734ee70
(gdb) pr
(reg:DI 18 r18)

and get_last_value (x) returns 0.

Before combine we have

(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 44 43 45 2 (set (reg:QI 19 r19 [+1 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 45 44 46 2 (set (reg:QI 20 r20 [+2 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 46 45 47 2 (set (reg:QI 21 r21 [+3 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 47 46 48 2 (set (reg:QI 22 r22 [+4 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 48 47 49 2 (set (reg:QI 23 r23 [+5 ])
(reg:QI 65 [ _3+5 ])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 49 48 50 2 (set (reg:QI 24 r24 [+6 ])
(reg:QI 66 [ _3+6 ])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 50 49 51 2 (set (reg:QI 25 r25 [+7 ])
(reg:QI 67 [ _3+7 ])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
 (nil))
(insn 52 51 61 2 (set (reg:DI 18 r18)
(ashiftrt:DI (reg:DI 18 r18)
(reg:QI 16 r16))) bug-combin.c:29 1417 {ashrdi3_insn}
 (expr_list:REG_DEAD (reg:QI 16 r16)
(nil)))

Note that we have hard reg DI 18 in insn 52 and a set of hard reg QI 18 in insn
43!

get_last_value is called for DI 18 bit only looks at the LSB byte in QI 18 and
hence returns 0 which is a bug.

[Bug c++/66830] Problem with C++ unique symbols in plugins

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jeremyaouad at gmail dot com

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

[Bug c++/71971] Destructor of a global static variable in a shared library is not called on dlclose

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #3 from Richard Biener  ---
dup

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

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #9 from Renlin Li  ---
g++.dg/init/elide5.C fails on target whose SIZE_TYPE is not "long unsigned
int".

testsuite/g++.dg/init/elide5.C:4:42: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter [-fpermissive]

I have checked, for most 32 bit architectures or ABI, the SIZE_TYPE is
"unsigned int". arm is one of them.

To make this test case portable, __SIZE_TYPE__ should be better in this case,
instead of "unsigned long" as first argument of new operator.


> void* operator new(unsigned long, void* p) { return p; }

[Bug tree-optimization/71987] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: tree check: expected ssa_name, have addr_expr in get_ops, at tree-ssa-reassoc.c:3269

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Jul 25 10:50:30 2016
New Revision: 238704

URL: https://gcc.gnu.org/viewcvs?rev=238704&root=gcc&view=rev
Log:
Call get_ops just for SSA_NAMEs (PR tree-optimization/71987)

PR tree-optimization/71987
* tree-ssa-reassoc.c (maybe_optimize_range_tests): Call get_ops
just for SSA_NAMEs. Fix GNU coding style.
* gcc.dg/torture/pr71987.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71987.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/71987] [7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: tree check: expected ssa_name, have addr_expr in get_ops, at tree-ssa-reassoc.c:3269

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/71868] internal compiler error: in compute_working_sets, at gcov-io.c:1006

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Mon Jul 25 10:56:08 2016
New Revision: 238706

URL: https://gcc.gnu.org/viewcvs?rev=238706&root=gcc&view=rev
Log:
Handle loops with loop->latch == NULL (PR gcov-profile/71868)

PR gcov-profile/71868
* cfgloopanal.c (expected_loop_iterations_unbounded): When we
have a function with multiple latches, count them all.

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

[Bug gcov-profile/71868] internal compiler error: in compute_working_sets, at gcov-io.c:1006

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71990] New: Function multiversioning prohibits inlining

[sgunderson at bigfoot dot com]

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

Bug ID: 71990
   Summary: Function multiversioning prohibits inlining
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Hi,

I'm trying to write a library that uses F16C instructions in certain places,
and since they're not really universally accessible (and ld.so hardware
capabilities seem to have been long abandoned), I've tried to use function
multiversioning for it. However, trying to combine it with inlining seems to
draw a blank; a very simplified example:

klump:~> /usr/lib/gcc-snapshot/bin/g++ -v 
Using built-in specs.  
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20160707-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-7-snap-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-7-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-7-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--disable-werror --enable-checking=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (Debian
20160707-1) 

klump:~> cat test.cc 
#include 

__attribute__ ((target("default")))
inline int foo()
{
return 0;
}

__attribute__ ((target("avx")))
inline int foo()
{
return 1;
}

int bar()
{
int sum = 0;
for (int i = 0; i < 100; ++i) {
sum += foo();
}
return sum;
}

int main(void)
{
printf("%d\n", bar());
}

klump:~> /usr/lib/gcc-snapshot/bin/g++ -O2 -o test test.cc
klump:~> nm --demangle test | egrep 'foo|bar' 
00400c40 i _Z3foov.ifunc()
00400bf0 T bar()
00400c20 W foo()
00400c30 W foo() [clone .avx]
00400c40 W foo() [clone .resolver]

Of course, in reality, my foo() would do something more complicated, like call
_cvtss_sh() or similar; this is a toy example. But it illustrates that the
function multiversioning blocks inlining.

If I compile with -mavx, the entire multiversioning goes away (only the AVX
version is emitted), so I hoped that I could use target cloning on bar():

__attribute__ ((target_clones("avx", "default")))
int bar()
{
// same code...

but unfortunately, no. There's a bar() clone for AVX emitted, but it still
calls the resolving function for foo(); no inlining.

So I really can't find any usable way of using this feature if your
architecture switch is in inlined functions (in my case, convert to/from fp16).

[Bug c++/71988] [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/71988] [7 Regression] ICE in dump_simple_decl (gcc/cp/error.c:965)

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We crash because 'a' isn't DECL_LANG_SPECIFIC.

[Bug tree-optimization/71990] Function multiversioning prohibits inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
The features are mutually exclusive right now, we don't know how to "inline"
the
ifunc resolver.  I guess auto-multi-versioning callers instead would make more
sense (thus, push the mv upward to allow inlining).

[Bug tree-optimization/71990] Function multiversioning prohibits inlining

[sgunderson at bigfoot dot com]

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

--- Comment #2 from sgunderson at bigfoot dot com ---
Would pushing the mv automatically upwards into callers really help? There's
still no way that I can see to inline the function; I mean, pushing upwards is
what I've been trying to do here manually with the target clones.

[Bug gcov-profile/70993] [auto-fdo] ICE with gcov and lto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug lto/71991] New: Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation

[marxin at gcc dot gnu.org]

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

Bug ID: 71991
   Summary: Inconsistency for __attribute__ ((__always_inline__))
among LTO and non-LTO compilation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

As mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=77580#c6, we
behave differently in case of LTO and non-LTO build for the following code
snippet:

$ cat tc.i
static __attribute__ ((__always_inline__)) int fn1 () { return 0; }
static __attribute__ ((target ("inline-all-stringops"))) int fn2 () { fn1 (); }

int main()
{
  fn2();
}

$ gcc -O2 tc.i
tc.i:1:48: warning: always_inline function might not be inlinable
[-Wattributes]
 static __attribute__ ((__always_inline__)) int fn1 () { return 0; }

$ gcc -O2 tc.i -flto
tc.i:1:48: warning: always_inline function might not be inlinable
[-Wattributes]
 static __attribute__ ((__always_inline__)) int fn1 () { return 0; }
^~~
tc.i: In function ‘fn2’:
tc.i:1:48: error: inlining failed in call to always_inline ‘fn1’: target
specific option mismatch
tc.i:2:71: note: called from here
 static __attribute__ ((target ("inline-all-stringops"))) int fn2 () { fn1 ();
}
   ^~

[Bug tree-optimization/71992] New: Missed BB SLP vectorization in GCC

[vekumar at gcc dot gnu.org]

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

Bug ID: 71992
   Summary: Missed BB SLP vectorization in GCC
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vekumar at gcc dot gnu.org
  Target Milestone: ---

The below test case fails to vectorize.
gcc version 7.0.0 20160724 (experimental) (GCC)

gcc -Ofast -mavx -fvect-cost-model=unlimited slp.c -S -fdump-tree-slp-all

struct st
{
double x;
double y;
double z;
double p;
double q;
}*obj;

double a,b,c;

void slp_test()
{

obj->x = a*a+3.0;
obj->y= b*b+c;
obj->z= a+b*3.0;
obj->p= a+b*3.0;
obj->q =a+b+c;

}

LLVM is able to SLP vectorize looks like it is creating vector of [a,c]  and
[b*3.0,b*b] and does vector add.

GCC is not SLP vectorizing.  Group slitting also not working. I expected it to
get split and vectorize these statements.

  obj->z= a+b*3.0;
  obj->p= a+b*3.0;

Another case 

struct st
{
double x;
double y;
double z;
double p;
double q;
}*obj;

double a,b,c;

void slp_test()
{

obj->x = a*b;
obj->y= b+c;
obj->z= a+b*3.0;
obj->p= a+b*3.0;
obj->q =a+b+c;

}


LLVM forms vector [b*3.0,a+b] [a,c] and does vector addition.

[Bug tree-optimization/71990] Function multiversioning prohibits inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to sgunderson from comment #2)
> Would pushing the mv automatically upwards into callers really help? There's
> still no way that I can see to inline the function; I mean, pushing upwards
> is what I've been trying to do here manually with the target clones.

Well, you'd effectively generate two target clones for bar() and call
the respective foo overload directly so it can be inlined.

[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
  Component|lto |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The testcase misses an 'inline' on fn1 (thus all the warnings).  But yes,
confirmed.  And I think the error is somewhat correct though I think it
is due to some defect in target attribute handling somewhere - it works
with "sse3" for example.

[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #8 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-07/msg00123.html

Awaiting review.

[Bug tree-optimization/71990] Function multiversioning prohibits inlining

[sgunderson at bigfoot dot com]

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

--- Comment #4 from sgunderson at bigfoot dot com ---
OK, so it would have to be a special kind of cloning, not the one you can do
yourself from code as of today?

As a user, I suppose there's no really good way of dealing with this currently,
right? Short of maybe doing manual multiversioning with
__builtin_cpu_supports() and hoping that the compiler can hoist that out of all
the loops.

[Bug tree-optimization/71992] Missed BB SLP vectorization in GCC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
Version|tree-ssa|7.0
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think doing it as

 [a, b, b, b] * [a, b, 3., 3.] + [3., c, a, a]

would be "optimal" (not factoring in vector construction cost of course).

The issue is how SLP construction works and the number of swaps / builds
from scalars do.

One issue is that we even try with a group-size of 5.  Fixing that
doesn't fix it though as we do not consider building a vector from scalars
until we tried to swap the parent op (and if that fails we don't go back
building children from scalars).  Only trying with a group size of 4
would also regress the case where we'd have split after the first element.

That said, the whole SLP discovery needs a different algorithmic approach
to fix cases like this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/55610] cc1 is calling munmap() on part of itself on darwin

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #6)
> Does this work now?

It looks like Mike's suggestion works, but I don't recall seeing a patch - and
the code for the unmap is present in trunk.  

@Jack, did you post a patch?

[Bug target/55610] cc1 is calling munmap() on part of itself on darwin

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Does this work now?
> 
> It looks like Mike's suggestion works, but I don't recall seeing a patch -
> and the code for the unmap is present in trunk.  

maybe we can arrange for this block to be placed last in the address map (it
should be a .zerofill segment which are placed at the end anyway).  Not sure if
that would be enough to make dyld happy.

[Bug c++/71974] Warning: uninitialized variable with OpenMP nested loops

[register at rgug dot ch]

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

--- Comment #1 from Rafael Guglielmetti  ---
With gcc 6.1.1, the above code gives rise to the error:
error: condition expression refers to iteration variable ‘i’

So I suppose my syntax was incorrect. It is annoying tough.

[Bug target/71993] New: __builtin_cpu_supports() does not support "f16c"

[sgunderson at bigfoot dot com]

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

Bug ID: 71993
   Summary: __builtin_cpu_supports() does not support "f16c"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

As the summary says. You just get:

lib.cc:4:1: error: Parameter to builtin not valid: f16c

Tested with:

gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (Debian
20160707-1)

[Bug tree-optimization/71994] New: [7 Regression] ICE: verify_gimple failed

[asolokha at gmx dot com]

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

Bug ID: 71994
   Summary: [7 Regression] ICE: verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

1. gcc-7.0.0-alpha20160724 ICEs when compiling the following reduced snippet w/
-O2, -O3, -Ofast, or -Os:

int om, h6;

void
eo (void)
{
  const int tl = 1;
  int ln;

  h6 = (om + tl) > 0;
  ln = om && (om & h6);
  h6 = om;
  om = ln < h6;
}


% gcc-7.0.0-alpha20160724 -O2 -c xwelypci.c 
xwelypci.c: In function 'eo':
xwelypci.c:4:1: error: incompatible types in PHI argument 1
 eo (void)
 ^~
_Bool

int

_13 = PHI <0(2), 1(3)>
xwelypci.c:4:1: internal compiler error: verify_gimple failed

2. Changing the value of ``tl'' from 1 to 0 gives the following:

% gcc-7.0.0-alpha20160724 -O2 -c dobxoaf2.c 
dobxoaf2.c: In function 'eo':
dobxoaf2.c:4:1: error: non-trivial conversion at assignment
 eo (void)
 ^~
_Bool
int
_13 = _14;
dobxoaf2.c:4:1: internal compiler error: verify_gimple failed

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  profile-arcs is not supposed to be used in optimize pragmas or
> attributes and GCC should emit an error here but somehow it does not.

Starting from your commit r237174, we properly show warning and
the code is not instrumented:

/home/marxin/Programming/testcases/pr68025-2.c:2:9: warning: bad option
-fprofile-arcs to pragma attribute [-Wpragmas]
 #pragma GCC optimize("profile-arcs")
 ^~~
/home/marxin/Programming/testcases/pr68025-2.c:5:1: warning: bad option
-fprofile-arcs to optimize attribute [-Wattributes]
 {

[Bug rtl-optimization/71984] [7 Regression] wrong code with -O -mavx512cd

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Uh.  This is because the existing GET_MODE_UNIT_SIZE is wrong, it should have
used GET_MODE_SIZE - for CONCAT that doesn't make a difference of course but
for vectors it does.

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Yuan Pengfei from comment #2)
> (In reply to Richard Biener from comment #1)
> > Confirmed.  profile-arcs is not supposed to be used in optimize pragmas or
> > attributes and GCC should emit an error here but somehow it does not.
> 
> If so, how can I achieve function-level instrumentation control?

May I please ask you for motivation of having such a control?

Thanks,
Martin

[Bug tree-optimization/71994] [7 Regression] ICE: verify_gimple failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug c/71986] Bug bug when compiling gammu-1.37.3

[nequx at yandex dot ru]

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

--- Comment #2 from nequx  ---
Created attachment 38959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38959&action=edit
Here they are

http://dropmefiles.com/lklnt

[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> The testcase misses an 'inline' on fn1 (thus all the warnings).  But yes,
> confirmed.  And I think the error is somewhat correct though I think it
> is due to some defect in target attribute handling somewhere - it works
> with "sse3" for example.

Ah, okey, this would be better sample:

$cat xf86-video/tc.i
static __attribute__ ((__always_inline__)) inline int fn1 () { return 0; }
static __attribute__ ((target("inline-all-stringops"))) inline int fn2 () { fn1
(); }

int main()
{
  fn2();
}

$ gcc xf86-video/tc.i -O2
$ gcc xf86-video/tc.i -O2 -flto
xf86-video/tc.i: In function ‘fn2’:
xf86-video/tc.i:1:55: error: inlining failed in call to always_inline ‘fn1’:
target specific option mismatch
 static __attribute__ ((__always_inline__)) inline int fn1 () { return 0; }
   ^~~
xf86-video/tc.i:2:77: note: called from here
 static __attribute__ ((target("inline-all-stringops"))) inline int fn2 () {
fn1 (); }


sse3 works because ix86_can_inline_p returns true:

  /* Callee's isa options should a subset of the caller's, i.e. a SSE4
function
 can inline a SSE2 function but a SSE2 function can't inline a SSE4
 function.  */
  if ((caller_opts->x_ix86_isa_flags & callee_opts->x_ix86_isa_flags)
  != callee_opts->x_ix86_isa_flags)
ret = false;


However following snippet is rejected w/ and w/o LTO:

cat xf86-video/tc2.i
static __attribute__ ((__always_inline__, target("sse4"))) inline int fn1 () {
return 0; }
static __attribute__ ((target("sse2"))) inline int fn2 () { fn1 (); }

int main()
{
  fn2();
}

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
(In reply to James Greenhalgh from comment #2)
> 
> So I have two questions.
> 
> First, where did the DImode paradoxical subreg come from in the first place,
> and why wasn't it a zero-extend?
> 
> Second, why did reload decide it was safe to choose a memory location for a
> paradoxical subreg and widen the size of the memory access?
> 

the memory access is to a spill slot, but lra is apparently confused by
the paradoxical subreg and does only save 32 bits there while it expects
to read back 64 bits (the widenend &isl_obj_map_vtable):

@@ -4256,29 +4256,28 @@
add w20, w25, :lo12:isl_obj_set_vtable
adrpx28, isl_obj_map_vtable
uxtwx20, w20
-   add w0, w28, :lo12:isl_obj_map_vtable
+   add w28, w28, :lo12:isl_obj_map_vtable
mov x21, 0
-   str w0, [x29, 112]
-   uxtwx0, w0
-   str x0, [x29, 96]
+   uxtwx0, w28
+   str x0, [x29, 104]
.p2align 2
...
 .L903:
ldr w0, [x19]
-   ldr x20, [x29, 112]
-   stp w4, w3, [x29, 104]
+   ldr x20, [x29, 104]
+   str w4, [x29, 112]
+   str w3, [x29, 124]
orr x1, x20, x21, lsl 32
bl  to_union

- = without patch
+ = with patch

so it looks as if the stack slot x29+112 was only half filled
then read back with stack content
and with the patch from comment#9 it uses less stack slots,
and does uxtw before saving the value to x29+104

So could someone try to boot-strap and reg-test my patch on an aarch64 please?

[Bug bootstrap/71989] aarch64 bootstrap fails for out-of-tree builds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||Aarch64-musl

--- Comment #1 from Andrew Pinski  ---
Works for me with glibc.

[Bug c/71986] Bug bug when compiling gammu-1.37.3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Please read https://gcc.gnu.org/bugs/ . It will tell you exactly what
information is needed.

[Bug gcov-profile/67924] Gcov statistics branches error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
(In reply to deng from comment #0)
> Created attachment 36479 [details]
> gcov statistics error
> 
> When I use the gcc version is 5.2.0,the gcov statistics branches error.
> When I use the gcc version is 4.1.1,the gcov statistics functions error.
> Specific content please see attachment

Hi, can you please specify particular statistics are wrong?
Which version provides the right stats?

Thanks,
Martin

[Bug gcov-profile/67924] Gcov statistics branches error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-25
 Ever confirmed|0   |1

[Bug c++/71995] New: ~36% compile-time performance regression for C++ in gcc HEAD vs gcc-6-branch HEAD

[tom at honermann dot net]

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

Bug ID: 71995
   Summary: ~36% compile-time performance regression for C++ in
gcc HEAD vs gcc-6-branch HEAD
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
  Target Milestone: ---

A compile-time performance degradation in gcc HEAD (r238592) vs gcc-6-branch
HEAD (r238587) was observed while verifying performance improvements for bug
67565.  Though that bug was specific to C++ concepts, the performance
regression is not.

In my tests both the gcc and gcc-6-branch compilers were built using the Ubuntu
15.10 x86_64 distribution of gcc 5.2.1:

$ gcc --version
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
...

Both gcc builds were configured and built with:
  $ ./configure \
CC=gcc \
CXX=g++ \
--prefix /path/to/install/... \
--disable-multilib \
--disable-bootstrap \
--enable-languages=c,c++
  $ make
  $ make install

The following code was used for testing:

$ cat t.cpp
/*
 * Test adapted from:
 * https://randomascii.wordpress.com/2014/03/10/making-compiles-slow
 */
#if !defined(SCALE_FACTOR)
#define SCALE_FACTOR 23
#endif
template
struct slow_fibonacci {
static constexpr int value =
slow_fibonacci::value +
slow_fibonacci::value;
};
template
struct slow_fibonacci {
static constexpr int value = 1;
};
template
struct slow_fibonacci {
static constexpr int value = 1;
};
constexpr int x = slow_fibonacci<0,SCALE_FACTOR>::value;

The test was performed three times at each of three scale factors for each
compiler build, the times averaged for each scale factor, and then percentages
calculated.

Compile times using the gcc trunk build:
# default SCALE_FACTOR=23
$ time g++ -c -std=c++11 t.cpp
real0m02.079s  |  real0m02.089s  |  real0m02.070s
user0m02.004s  |  user0m02.016s  |  user0m02.000s
sys 0m00.068s  |  sys 0m00.068s  |  sys 0m00.064s
# SCALE_FACTOR=25
$ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp
real0m05.401s  |  real0m05.431s  |  real0m05.428s
user0m05.224s  |  user0m05.272s  |  user0m05.224s
sys 0m00.172s  |  sys 0m00.156s  |  sys 0m00.204s
# SCALE_FACTOR=27
$ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp
real0m14.268s  |  real0m14.379s  |  real0m14.654s
user0m13.912s  |  user0m13.900s  |  user0m14.332s
sys 0m00.356s  |  sys 0m00.480s  |  sys 0m00.320s

Compile times using the gcc-6-branch build:
# default SCALE_FACTOR=23
$ time g++ -c -std=c++11 t.cpp
real0m01.466s  |  real0m01.432s  |  real0m01.441s
user0m01.384s  |  user0m01.320s  |  user0m01.356s
sys 0m00.076s  |  sys 0m00.108s  |  sys 0m00.080s
# SCALE_FACTOR=25
$ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp
real0m04.076s  |  real0m04.072s  |  real0m04.366s
user0m03.868s  |  user0m03.920s  |  user0m04.208s
sys 0m00.204s  |  sys 0m00.148s  |  sys 0m00.152s
# SCALE_FACTOR=27
$ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp
real0m10.658s  |  real0m10.701s  |  real0m10.779s
user0m10.096s  |  user0m10.292s  |  user0m10.368s
sys 0m00.560s  |  sys 0m00.408s  |  sys 0m00.412s

-+---+--+-+
SCALE_FACTOR | gcc trunk avg | gcc-6-branch avg | % change|
-+---+--+-+
23   |2.079s |   1.446s | +43.776% / -30.447% |
25   |5.420s |   4.171s | +29.945% / -23.044% |
27   |   14.434s |  10.713s | +34.734% / -25.779% |
-+---+--+-+

Averaging the percentages suggests ~36% performance overhead for gcc trunk vs
gcc-6-branch.

[Bug c++/71995] ~36% compile-time performance regression for C++ in gcc HEAD vs gcc-6-branch HEAD

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-25
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you add --enable-checking=release and try again for the trunk?

[Bug c++/71972] [6/7 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/65970] [C++14] Endless loop with constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

Gleb Natapov  changed:

   What|Removed |Added

 CC||gleb at scylladb dot com

--- Comment #10 from Gleb Natapov  ---
I've just sent  https://sourceware.org/ml/libc-alpha/2016-07/msg00613.html to
the mailing list that should solve this issue (or at least make it much more
scalable). I did not notice that Jakub already proposed the fix for old-style
registry and implemented it differently, but in the end both of them fix the
same problem in similar way.

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-25
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Works find current trunk, can you please re-verify that it's still valid?

[Bug c++/71995] ~36% compile-time performance regression for C++ in gcc HEAD vs gcc-6-branch HEAD

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

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

--- Comment #2 from Tom Honermann  ---
(In reply to Andrew Pinski from comment #1)
> Can you add --enable-checking=release and try again for the trunk?

Thanks, that explains it:

Compile times using the gcc trunk build:
# default SCALE_FACTOR=23
$ time g++ -c -std=c++11 t.cpp
real0m01.427s  |  real0m01.442s  |  real0m01.430s
user0m01.328s  |  user0m01.384s  |  user0m01.356s
sys 0m00.092s  |  sys 0m00.052s  |  sys 0m00.068s
# SCALE_FACTOR=25
$ time g++ -c -std=c++11 -DSCALE_FACTOR=25 t.cpp
real0m03.969s  |  real0m03.978s  |  real0m04.008s
user0m03.816s  |  user0m03.804s  |  user0m03.900s
sys 0m00.148s  |  sys 0m00.168s  |  sys 0m00.104s
# SCALE_FACTOR=27
$ time g++ -c -std=c++11 -DSCALE_FACTOR=27 t.cpp
real0m10.735s  |  real0m10.757s  |  real0m10.873s
user0m10.340s  |  user0m10.272s  |  user0m10.420s
sys 0m00.392s  |  sys 0m00.484s  |  sys 0m00.452s

Times are now close enough to gcc-6-branch times that I'm not going to bother
calculating percentages.

Closing as resolved/invalid.

[Bug fortran/71961] [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org,
   ||seurer at gcc dot gnu.org

--- Comment #5 from Pat Haugen  ---
Also occurring on powerpc64.

[Bug target/71989] aarch64 musl bootstrap fails for out-of-tree builds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |target
Summary|aarch64 bootstrap fails for |aarch64 musl bootstrap
   |out-of-tree builds  |fails for out-of-tree
   ||builds

--- Comment #2 from Andrew Pinski  ---
Are we sure this is not a musl issue?

[Bug target/71989] aarch64 musl bootstrap fails for out-of-tree builds

[timo.teras at iki dot fi]

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

--- Comment #3 from Timo Teräs  ---
(In reply to Andrew Pinski from comment #2)
> Are we sure this is not a musl issue?

Same source code / out-of-tree bootstrap in musl environment works for
triplets:
 armhf-alpine-linux-muslgnueabihf
 i586-alpine-linux-musl
 x86_64-alpine-linux-musl

But it is possible there's something in musl aarch64 specific headers, or in
the build process that triggers only in musl/busybox environment. For example,
it could be also some sed/awk script that depends on GNU extensions, or even
busybox bug.

I'll try to compare in-tree and out-of-tree builds see if I can pinpoint this
to something specific.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[tamar.christina at arm dot com]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #11 from Tamar Christina  ---
The patch seems to also fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70903
where it's also confused about the paradoxical subreg.

I'll bootstrap and reg-test on aarch64.

[Bug c++/71837] [4.9/5/6/7 Regression] ICE on valid C++14 code with initialized lambda capture: in tsubst_pack_expansion, at cp/pt.c:10905

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
What is the point of a variadic template that is only valid when the pack
happens to have a single element?

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

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

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

--- Comment #12 from Andreas Schwab  ---
Sucessfully bootstrapped on aarch64_ilp32 and the ISL testsuite passes.

[Bug ipa/71981] [6/7 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu (internal compiler error: in get_dynamic_type, at ipa-polymorphic-call.c:1667)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #2 from Martin Jambor  ---
ipa_polymorphic_call_context constructor returns

MEM[(char * *)""]

in *INSTANCE.  That does not look right.

[Bug c++/71833] [4.9/5/6/7 regression] ICE on valid C++11 code with nested variadic templates: tree check: accessed elt 0 of tree_vec with 1 elts in coerce_template_parameter_pack, at cp/pt.c:7439

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/30277] bit-field: wrong overload resolution

[tom at honermann dot net]

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

--- Comment #4 from Tom Honermann  ---
We recently got bit by this.  It is still an issue in latest gcc trunk:

$ cat t.cpp
enum E : int {
 e1 = 1
};
constexpr E operator-(E, E) {
 return (E)99;
}
typedef struct {
 E e;
 E ebf : 16;
} S;
constexpr S s = { e1, e1 };
static_assert(99 == (int)(s.e-s.e),"Overload resolution failed for
non-bit-field");
static_assert(99 == (int)(s.ebf-s.ebf),"Overload resolution failed for
bit-field");

$ g++ --version
g++ (GCC) 7.0.0 20160721 (experimental)
...

$ g++ -c -std=c++11 t.cpp
t.cpp:9:14: warning: â::ebfâ is too small to hold all values
of âenum Eâ
  E ebf : 16;
  ^~
t.cpp:13:1: error: static assertion failed: Overload resolution failed for
bit-field
 static_assert(99 == (int)(s.ebf-s.ebf),"Overload resolution failed for
bit-field");
 ^

(I would love to be able to disable that warning as well: bug 51242)

[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||grumpy76 at web dot de

--- Comment #6 from Jason Merrill  ---
*** Bug 70632 has been marked as a duplicate of this bug. ***

[Bug c++/70632] [4.9/5/6/7 Regression] Wrong function name resolution using variadic template and additional template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Duplicate.

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

[Bug middle-end/71732] FAIL: gcc.dg/torture/pr71532.c at -O2 and above

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Author: danglin
Date: Mon Jul 25 17:32:44 2016
New Revision: 238727

URL: https://gcc.gnu.org/viewcvs?rev=238727&root=gcc&view=rev
Log:
PR middle-end/71732
* cselib.c (cselib_process_insn): Invalidate argument slots for
const/pure calls.


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

[Bug c++/71837] [4.9/5/6/7 Regression] ICE on valid C++14 code with initialized lambda capture: in tsubst_pack_expansion, at cp/pt.c:10905

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/71732] FAIL: gcc.dg/torture/pr71532.c at -O2 and above

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #11 from John David Anglin  ---
Fixed on trunk.

[Bug libgcc/68468] frv/bfin toolchain build error

[wbx at openadk dot org]

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

--- Comment #5 from Waldemar Brodkorb  ---
The FDPIC code for FR-V was added in 2004:

commit 3e7f6cce419f02371585642d38a34cff8494eaff
Author: aoliva 
Date:   Tue Feb 24 16:58:39 2004 +

[Bug libgcc/68468] frv/bfin toolchain build error

[wbx at openadk dot org]

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

--- Comment #6 from Waldemar Brodkorb  ---
When trying to build Blackfin FDPIC toolchain:
/home/wbx/openadk/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:
In function '_Unwind_IteratePhdrCallback':
/home/wbx/openadk/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:189:13:
error: incompatible types when assigning to type '_Unwind_Ptr {aka unsigned
int}' from type 'struct elf32_fdpic_loadaddr'
   load_base = info->dlpi_addr;
 ^
In file included from
/home/wbx/openadk/target_sim-bfin_uclibc-ng_bf512_fdpic/usr/include/link.h:78:0,
 from
/home/wbx/openadk/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:87:
/home/wbx/openadk/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:274:6:
error: request for member 'map' in something not a structure or union
  __RELOC_POINTER (phdr->p_vaddr, load_base);
  ^
/home/wbx/openadk/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:323:5:
error: request for member 'map' in something not a structure or union
 __RELOC_POINTER (p_eh_frame_hdr->p_vaddr, load_base);
 ^
make[8]: *** [unwind-dw2-fde-dip.o] Error 1

Full build log here:
http://debug.openadk.org/bfin/make.log

Just changing __FRV_FDPIC__ into __FDPIC__ results in:
/home/wbx/bfin-c++/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:
In function '_Unwind_IteratePhdrCallback':
/home/wbx/bfin-c++/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:221:15:
error: incompatible types when assigning to type 'struct elf32_fdpic_loadaddr'
from type '_Unwind_Ptr {aka unsigned int}'
 load_base = cache_entry->load_base;
   ^
/home/wbx/bfin-c++/toolchain_build_sim-bfin_uclibc-ng_bf512_fdpic/w-gcc-6.1.0-1/gcc-6.1.0/libgcc/unwind-dw2-fde-dip.c:309:39:
error: incompatible types when assigning to type '_Unwind_Ptr {aka unsigned
int}' from type 'struct elf32_fdpic_loadaddr'
   frame_hdr_cache_head->load_base = load_base;
   ^
make[8]: *** [unwind-dw2-fde-dip.o] Error 1

[Bug c++/71972] [6/7 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 18:32:06 2016
New Revision: 238729

URL: https://gcc.gnu.org/viewcvs?rev=238729&root=gcc&view=rev
Log:
PR c++/71972 - constexpr array self-modification

* constexpr.c (cxx_eval_array_reference): Handle looking for the
value of an element we're currently modifying.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-array5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/65970] [C++14] Endless loop with constexpr

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 18:32:13 2016
New Revision: 238730

URL: https://gcc.gnu.org/viewcvs?rev=238730&root=gcc&view=rev
Log:
PR c++/65970 - constexpr infinite loop

gcc/c-family/
* c.opt (fconstexpr-loop-limit): New.
gcc/cp/
* constexpr.c (cxx_eval_loop_expr): Count iterations.
* cp-gimplify.c (genericize_cp_loop): Use start_locus even for
infinite loops.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop6.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/doc/invoke.texi

[Bug c++/54440] [c++11] g++ prematurely applying rule that a template parameter pack cannot be followed by a template parameter

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 19:10:41 2016
New Revision: 238731

URL: https://gcc.gnu.org/viewcvs?rev=238731&root=gcc&view=rev
Log:
PR c++/71833 - member template with two parameter packs

PR c++/54440
* pt.c (coerce_template_parameter_pack): Fix logic for
pack index.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-nested1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71833] [4.9/5/6/7 regression] ICE on valid C++11 code with nested variadic templates: tree check: accessed elt 0 of tree_vec with 1 elts in coerce_template_parameter_pack, at cp/pt.c:7439

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 19:10:41 2016
New Revision: 238731

URL: https://gcc.gnu.org/viewcvs?rev=238731&root=gcc&view=rev
Log:
PR c++/71833 - member template with two parameter packs

PR c++/54440
* pt.c (coerce_template_parameter_pack): Fix logic for
pack index.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-nested1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71837] [4.9/5/6/7 Regression] ICE on valid C++14 code with initialized lambda capture: in tsubst_pack_expansion, at cp/pt.c:10905

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 19:16:16 2016
New Revision: 238733

URL: https://gcc.gnu.org/viewcvs?rev=238733&root=gcc&view=rev
Log:
PR c++/71837 - pack expansion in init-capture

* lambda.c (add_capture): Leave a pack expansion in a TREE_LIST.
(build_lambda_object): Call build_x_compound_expr_from_list.
* pt.c (tsubst) [DECLTYPE_TYPE]: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init15.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init15a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c

[Bug c++/71833] [4.9/5/6/7 regression] ICE on valid C++11 code with nested variadic templates: tree check: accessed elt 0 of tree_vec with 1 elts in coerce_template_parameter_pack, at cp/pt.c:7439

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Jul 25 19:17:43 2016
New Revision: 238734

URL: https://gcc.gnu.org/viewcvs?rev=238734&root=gcc&view=rev
Log:
PR c++/71833 - member template with two parameter packs

* pt.c (coerce_template_parameter_pack): Fix logic for
pack index.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/variadic-nested1.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Bill Schmidt  ---
Confirmed.  Will have a look soon.

[Bug c/71996] New: -fdump-translation-unit fails to dump string literals of type char16_t/char32_t/wchar_t

[b.r.longbons at gmail dot com]

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

Bug ID: 71996
   Summary: -fdump-translation-unit fails to dump string literals
of type char16_t/char32_t/wchar_t
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

$ cat dump.c
#include 
#include 

char string1[] = "1string";
wchar_t string2[] = L"2string";
char16_t string3[] = u"3string";
char32_t string4[] = U"4string";

# Output for a little-endian host.
$ gcc dump.c -fdump-translation-unit=stdout -c -o /dev/null | grep string_cst
@2810   string_cst   type: @2808   strg: 1string  lngt: 8   
@2823   string_cst   type: @2821   strg: 2lngt: 32  
@2831   string_cst   type: @2829   strg: 3lngt: 16  
@2837   string_cst   type: @2836   strg: 4lngt: 32  

###

Some decisions also should be made about what exactly lngt should mean (bytes
or characters) - and what to do about string values that contain embedded
newlines, nonprintable characters, or NULs.

Personally, I would prefer the strings to be escaped all the way to something
similar to the input, including the L"" - and the lngt moved before it, if not
removed entirely.

[Bug c++/72009] New: USA/CANADA-Hpχ1∽8∽4∽4∽3∽0∽5∽5∽5∽6∽5χprinter support service center number

[teresadoris41 at gmail dot com]

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

Bug ID: 72009
   Summary: USA/CANADA-Hpχ1∽8∽4∽4∽3∽0∽5∽5∽5∽6∽5χprinter support
service center number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: teresadoris41 at gmail dot com
  Target Milestone: ---

TALK @@@ 1844 305 5565(USA), hp Printer Support Phone Number Canada hp
Printer customer care phone number Call @@@ 1 844 305 5565 hp
Printer Support Phone Number Canada hp Printer customer care phone number Call
@ ((hp Printer 1844 305 5565 hp Printer Tech Support Phone Number
Canada hp Printer customer service number $$$@@hp Printer 1844 305 5565 hp
Printer Tech Support Phone Number Canada hp Printer customer service number $hp
Printer 1844 305 5565 hp Printer Tech Support Phone Number Canada hp Printer
customer service number hp Printer SUPPORT USA(((1844 305 5565(USA),
1844-305-5565(UK) 1844-305-5565(AUS)!!FREE hp Printer support phone
number,hp Printer customer service number @SUPPORT
Canada!((1844-305-5565))!!FREE hp Printer support phone number,hp
Printer customer service number** !Help hp Printer Tech support phone
number!!1844 305 5565(USA) hp Printer Customer Service hp Printer Customer
support phone number USA 1844 305 5565(USA), hp Printer tech support phone
number , hp Printer customer support phone number !!!hp Printer tech
support phone number @1844 305 5565@ hp Printer Tech Support Phone Number Call
wireless hp Printer Tech Support Phone Number Canada hp Printer customer
service number1844 305 5565 hp Printer support phone number, hp Printer
support, hp Printer support, hp Printer tech support, hp Printer technical
support, hp Printer customer service number, hp Printer customer service, hp
Printer tech support phone number, ##hp Printer support center##, hp Printer
support phone number, hewlett packard support, hp Printer contact number, hp
Printer phone number, hp Printer help and support, hp Printer customer support,
hp Printer help, hp Printer technical support phone number, hp Printer support
phone number, hewlett packard customer service, hp printer support, hp Printer
customer service phone number, hp Printer number, hp Printer customer care, hp
Printer contact, hp Printer tech support phone number, hp Printer support chat,
hp Printer customer support phone number, hp Printer customer care number,
contact hp Printer support, hp Printer help, hp Printer phone, hp Printer
support phone number, hp Printer customer support phone number, hp Printer tech
support, hp Printer phone support, hp Printer technical support phone number,
hp Printer laptop support phone number, hewlett packard printer support, hp
Printer helpline, hp Printer telephone support, hp Printer online support, hp
Printer support contact, hp Printer chat support, hewlett packard phone number,
hp Printer customer service, hp Printer tech support phone number, hp Printer
product support, hewlett packard customer service phone number, hp Printer
computer support phone number, hp Printer support contact number, hp Printer
support printer, hp Printer computer support, hp Printer tech support chat, hp
Printer helpline number, hp Printer laptop support, hewlett packard tech
support, hp Printer online chat, hewlett packard technical support, hp Printer
help line, phone number for hp Printer support, hewlett packard support phone
number, hp Printer technical support, hewlett packard customer service number,
hp Printer service number, hewlett packard helpline, hp Printer customer care
no, hp Printer customer service number, hp Printer help number, hp Printer
customer service phone number, hp Printer 1844  number, hp Printer support
phone, hp Printer support line, hewlett packard contact number, hp Printer tech
support phone number, hp Printer customer support phone number, hp printer
help, call hp Printer support, ##hp Printer support## chat, hewlett packard
support phone number, hewlett packard tech support phone number, hp Printer
support telephone number, hewlett packard tech support phone number, call hp
Printer, hp Printer contact support, hewlett packard technical support phone
number, hp Printer support centre, hewlett packard customer support, hp Printer
desktop support, hp Printer laptop customer service, contact hp Printer
support, hp Printer pc support, hp Printer laptop customer care number, hp
Printer support for printer, hp Printer customer care, hp Printer customer care
phone number, hewlett packard help, phone number for hp Printer, hp Printer
online help, hp Printer laptop customer care, hp Printer helpline phone number,
hp Printer customer support, hp Printer technical support chat, hp Printer
computer help, hp Printer support phone numbers, hp Printer technical support
contact number, hp Printer 

[Bug c++/72009] USA/CANADA-Hpχ1∽8∽4∽4∽3∽0∽5∽5∽5∽6∽5χprinter support service center number

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Spam.

[Bug debug/72012] New: Technical Support CE@Ll ~*@*$@@I8007909186+++ CAnon Printer c.u.s.t.o.m.e.r s.e.r.v.i.c...

[adcss at dayrep dot com]

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

Bug ID: 72012
   Summary: Technical Support CE@Ll ~*@*$@@I8007909186+++ CAnon
Printer c.u.s.t.o.m.e.r s.e.r.v.i.c...
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adcss at dayrep dot com
  Target Milestone: ---

Technical Support CE@Ll ~*@*$@@I8007909186+++ CAnon Printer c.u.s.t.o.m.e.r
s.e.r.v.i.c...

((moti))Call @@@++ USA I80079O9186 CAnon p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t
p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CAnon h.e.l.p d.e.s.k n.u.m.b.e.r
n.u.m.b.e.r C.a.n.a.d.a CAnon s.u.p.p.o.r.t p.h.o.n.

((moti))Call @@@++ USA I80079O9186 CAnon p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t
p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l CAnon h.e.l.p d.e.s.k n.u.m.b.e.r
n.u.m.b.e.r C.a.n.a.d.a CAnon s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1
I80079O9186 CAnon p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r
u.s.a. C.a.l.l CAnon h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a CAnon
s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1800-790-9186 USA, CAnon printer
Tech Support phone number,CAnon technical support phone number 1 I80079O9186
.CAnon Tech Support Number CAnon Tech CAnon tech support, CAnon tech support
number, CAnon tech support phone number, CAnon technical support, CAnon
technical support number, CAnon technical support phone number, CAnon tech
support number, CAnon support number, CAnon Tech support phone number, CAnon
support phone number, CAnon technical support phone number, CAnon technical
support number,Support Phone Number for CAnon printer Phone Number for CAnon
CustomerService Technical Support Telephone Number CAnon printer support number
CAnon CAnon printer tech support number CAnon CAnon printer technical support
number CAnon CAnon printer technical support phone number CAnon CAnon printer
customer service number CAnon CAnon internet security technical support CAnon
technical support phone number CAnon CAnon tech support phone number CAnon
CAnon customer support phone number I-800-790-9186 CAnon CAnon printer support
phone number CAnon CAnon support phone CAnon tech support CAnon customer
support CAnon phone support CAnon support number CAnon CAnon technical support
CAnon printer customer support phone number CAnon CAnon printer tech support
phone number CAnon contact CAnon support CAnon printer technical support phone
number ~!~I8007909186++ CAnon CAnon phone number CAnon tech support CAnon
support ticket CAnon customer support number CAnon CAnon tech support number
CAnon CAnon technical support number CAnon CAnon support center CAnon telephone
support call CAnon support CAnon printer support support CAnon CAnon billing
support CAnon printer technical support number CAnon support CAnon printer
CAnon online support CAnon contact support CAnon printer support number CAnon
CAnon printer customer support number CAnon CAnon printer tech support number
CAnon support for CAnon CAnon phone number CAnon CAnon customer service phone
number CAnon CAnon contact phone number CAnon CAnon printer phone number CAnon
CAnon printer customer service phone number CAnon phone number CAnon for CAnon
customer service CAnon software phone number CAnon phone number CAnon for CAnon
CAnon customer service telephone number CAnon CAnon helpline phone number CAnon
CAnon contact number CAnon CAnon customer service number CAnon CAnon customer
service phone number ~!~I8007909186++ CAnon us CAnon customer service phone
number CAnon usa CAnon telephone number CAnon CAnon phone number CAnon usa
CAnon printer contact number CAnon CAnon number CAnon CAnon contact number
CAnon usa CAnon printer helpline number CAnon CAnon helpline number CAnon CAnon
customer number CAnon CAnon printer customer service number CAnon CAnon contact
telephone number CAnon contact number CAnon for CAnon CAnon software contact
number CAnon CAnon toll free number CAnon CAnon telephone number CAnon uk CAnon
registration number CAnon CAnon toll free number CAnon usa CAnon customer
service CAnon software customer service contact CAnon customer service CAnon
customer service phone CAnon printer customer service CAnon service CAnon
printer technical support CAnon printer customer support CAnon technical
support reviews telephone CAnon printer CAnon tech support phone number CAnon
CAnon printer tech support phone number CAnon CAnon printer customer service
CAnon technical support phone number CAnon CAnon printer free printer support
CAnon customer service billing CAnon customer service email address CAnon
customer service reviews contact CAnon customer service CAnon tech support
number CAnon usa CAnon printer support number CAnon CAnon printer contact
number CAnon CAnon customer service phone number CAnon CAnon technical support
usa CAnon technical support number CAnon CAnon tech support phone

[Bug c++/71837] [4.9/5/6 Regression] ICE on valid C++14 code with initialized lambda capture: in tsubst_pack_expansion, at cp/pt.c:10905

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |7.0
Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5/6 Regression] ICE on
   |on valid C++14 code with|valid C++14 code with
   |initialized lambda capture: |initialized lambda capture:
   |in tsubst_pack_expansion,   |in tsubst_pack_expansion,
   |at cp/pt.c:10905|at cp/pt.c:10905

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 7.  The testcase is strange enough that I'm not thinking to
backport the fix.

[Bug c++/71972] [6 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |"-std=c++14" on |"-std=c++14" on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: |compiler error:
   |Segmentation fault, |Segmentation fault,
   |cxx_eval_store_expression)  |cxx_eval_store_expression)

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 7 so far.

[Bug c++/71833] [4.9/5 regression] ICE on valid C++11 code with nested variadic templates: tree check: accessed elt 0 of tree_vec with 1 elts in coerce_template_parameter_pack, at cp/pt.c:7439

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 regression] ICE  |[4.9/5 regression] ICE on
   |on valid C++11 code with|valid C++11 code with
   |nested variadic templates:  |nested variadic templates:
   |tree check: accessed elt 0  |tree check: accessed elt 0
   |of tree_vec with 1 elts in  |of tree_vec with 1 elts in
   |coerce_template_parameter_p |coerce_template_parameter_p
   |ack, at cp/pt.c:7439|ack, at cp/pt.c:7439

--- Comment #4 from Jason Merrill  ---
Fixed for 6.2/7 so far.

[Bug c++/70709] [4.9/5 Regression] gcc hangs on valid C++ code on x86_64-linux-gnu

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression] gcc  |[4.9/5 Regression] gcc
   |hangs on valid C++ code on  |hangs on valid C++ code on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #6 from Jason Merrill  ---
Fixed for 6.2 and 7 so far.

[Bug c++/72050] New: USA CANADA@@@@*18OO445279O***+ Norton antivirus tech Support PHONe Number, Norton 360 phone number

[maine at yopmail dot com]

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

Bug ID: 72050
   Summary: USA CANADA*18OO445279O***+ Norton antivirus tech
Support PHONe Number, Norton 360 phone number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maine at yopmail dot com
  Target Milestone: ---

USA CANADA*18OO445279O***+ Norton antivirus tech Support PHONe Number,
Norton 360 phone number

CAnaDA+++1 800 445 2790++Norton Antivirus Technical Support Number, Norton
internet security phone number hereCAnaDA+++1 800 445 2790++Norton Antivirus
Technical Support Number, Norton internet security phone number Dial Norton
antivirus Technical Support contact number for instant assistance So whenever
you get stuck with Norton antivirus, don’t worry, simply just take advantage of
our support service by reaching directly to us through Norton antivirus
Technical Support contact number 1 (800 445_2790 and let us resolve your
technical problems %%%1 800 445 2790 %%% Norton Antivirus Technical Support
Contact Number %%%1 800 445 2790 %%% Norton technical support phone number %%%1
800 445 2790 %%% Norton tech support phone number %%%1 800 445 2790 %%% Norton
technical support %%%1 800 445 2790 %%% Norton customer support phone number
%%%1 800 445 2790 %%% Norton customer support phone number %%%1 800 445 2790
%%% Norton customer services email %%%1 800 445 2790 %%% Norton customer
support phone number %%%1 800 445 2790 %%% Norton 360 customer support phone
number %%%1 800 445 2790 %%% Norton 360 technical support phone number %%%1 800
445 2790 %%% Norton antivirus contact phone number in usa %%%1 800 445 2790 %%%
Norton antivirus customer service telephone number %%%1 800 445 2790 %%% Norton
antivirus customer support phone number %%%1 800 445 2790 %%% Norton antivirus
customer support phone number %%%1 800 445 2790 %%% Norton antivirus technical
support help desk phone number %%%1 800 445 2790 %%% Norton antivirus technical
support number %%%1 800 445 2790 %%% Norton antivirus technical support phone
number %%%1 800 445 2790 %%% Norton security phone number customer service %%%1
800 445 2790 %%% Norton technical support number %%%1 800 445 2790 %%% Norton
technical support phone number %%%1 800 445 2790 %%% phone number for Norton
customer service %%%1 800 445 2790 %%% phone number for symantec customer
service %%%1 800 445 2790 %%% symantec phone number customer service %%%1 800
445 2790 %%% contact Norton antivirus customer service phone number %%%1 800
445 2790 %%% Norton Antivirus Technical Support Number

Dial Norton antivirus Technical Support contact number for instant assistance

So whenever you get stuck with Norton antivirus, don’t worry, simply just take
advantage of our support service by reaching directly to us through Norton
antivirus Technical Support contact number 1 (800 445_2790 and let us resolve
your technical problems

%%%1 800 445 2790 %%% Norton Antivirus Technical Support Contact Number

%%%1 800 445 2790 %%% Norton technical support phone number

%%%1 800 445 2790 %%% Norton tech support phone number

%%%1 800 445 2790 %%% Norton technical support

%%%1 800 445 2790 %%% Norton customer support phone number

%%%1 800 445 2790 %%% Norton customer support phone number

%%%1 800 445 2790 %%% Norton customer services email

%%%1 800 445 2790 %%% Norton customer support phone number

%%%1 800 445 2790 %%% Norton 360 customer support phone number

%%%1 800 445 2790 %%% Norton 360 technical support phone number

%%%1 800 445 2790 %%% Norton antivirus contact phone number in usa

%%%1 800 445 2790 %%% Norton antivirus customer service telephone number

%%%1 800 445 2790 %%% Norton antivirus customer support phone number

%%%1 800 445 2790 %%% Norton antivirus customer support phone number

%%%1 800 445 2790 %%% Norton antivirus technical support help desk phone number

%%%1 800 445 2790 %%% Norton antivirus technical support number

%%%1 800 445 2790 %%% Norton antivirus technical support phone number

%%%1 800 445 2790 %%% Norton security phone number customer service

%%%1 800 445 2790 %%% Norton technical support number

%%%1 800 445 2790 %%% Norton technical support phone number

%%%1 800 445 2790 %%% phone number for Norton customer service

%%%1 800 445 2790 %%% phone number for symantec customer service

%%%1 800 445 2790 %%% symantec phone number customer service

%%%1 800 445 2790 %%% contact Norton antivirus customer service phone number

USA CANADA*18OO445279O***+ Norton antivirus tech Support PHONe Number,
Norton 360 phone number

CAnaDA+++1 800 445 2790++Norton Antivirus Technical Support Number, Norton
internet security phone number hereCAnaDA+++1 800 445 2790++Norton Antivirus
Technical Support Number, Norton internet security phone number Dial Norton
antivirus Technical Support contact num

[Bug fortran/72051] New: gfortran bug - internal compiler error

[wadud.miah at nag dot co.uk]

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

Bug ID: 72051
   Summary: gfortran bug - internal compiler error
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wadud.miah at nag dot co.uk
  Target Milestone: ---

I am using gfortran 5.3.1 and I am getting an internal compiler error:

[miahw@bengal pFUnit]$ gfortran --version
GNU Fortran (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)

gfortran -c  -I/home/miahw/pFUnit/include -I/home/miahw/pFUnit/source -g -O0
-fbacktrace -fbounds-check -fcheck=mem -I../include -DBUILD_ROBUST -DGNU
-DLinux -I/home/miahw/pFUnit/include -DLONG_PTR -DGNU -o Exception.o
Exception.F90
Exception.F90:321:0:

   allocate(this%exceptions(0))
 1
internal compiler error: in wide_int_to_tree, at tree.c:1464
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

any help will be appreciated.

Best regards,
Wadud.

[Bug c++/71350] [4.9/5/6/7 regression] ICE on trailing return type declaration with initializer list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |6.2

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

[Bug ada/72056] New: $@$@^^18557092847@$$@$$^^*** Epson printer technical support number

[sunnyhooda76 at gmail dot com]

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

Bug ID: 72056
   Summary: $@$@^^18557092847@$$@$$^^*** Epson printer technical
support number
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sunnyhooda76 at gmail dot com
  Target Milestone: ---

Created attachment 38962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38962&action=edit
((moti))Call @@@++ USA I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t
p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r
n.u.m.b.e.r C.a.n.a.d.a EPSON s.u.p.p.o.r.t p.h.o.n.

((moti))Call @@@++ USA I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t
p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r
n.u.m.b.e.r C.a.n.a.d.a EPSON s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1
I8557O92847 EPSON p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r
u.s.a. C.a.l.l EPSON h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a EPSON
s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, EPSON printer
Tech Support phone number,EPSON technical support phone number 1 I8557O92847
.EPSON Tech Support Number EPSON Tech EPSON tech support, EPSON tech support
number, EPSON tech support phone number, EPSON technical support, EPSON
technical support number, EPSON technical support phone number, EPSON tech
support number, EPSON support number, EPSON Tech support phone number, EPSON
support phone number, EPSON technical support phone number, EPSON technical
support number,Support Phone Number for EPSON printer Phone Number for EPSON
CustomerService Technical Support Telephone Number EPSON printer support number
EPSON EPSON printer tech support number EPSON EPSON printer technical support
number EPSON EPSON printer technical support phone number EPSON EPSON printer
customer service number EPSON EPSON internet security technical support EPSON
technical support phone number EPSON EPSON tech support phone number EPSON
EPSON customer support phone number I-855-709-2847 EPSON EPSON printer support
phone number EPSON EPSON support phone EPSON tech support EPSON customer
support EPSON phone support EPSON support number EPSON EPSON technical support
EPSON printer customer support phone number EPSON EPSON printer tech support
phone number EPSON contact EPSON support EPSON printer technical support phone
number ~!~I8557092847++ EPSON EPSON phone number EPSON tech support EPSON
support ticket EPSON customer support number EPSON EPSON tech support number
EPSON EPSON technical support number EPSON EPSON support center EPSON telephone
support call EPSON support EPSON printer support support EPSON EPSON billing
support EPSON printer technical support number EPSON support EPSON printer
EPSON online support EPSON contact support EPSON printer support number EPSON
EPSON printer customer support number EPSON EPSON printer tech support number
EPSON support for EPSON EPSON phone number EPSON EPSON customer service phone
number EPSON EPSON contact phone number EPSON EPSON printer phone number EPSON
EPSON printer customer service phone number EPSON phone number EPSON for EPSON
customer service EPSON software phone number EPSON phone number EPSON for EPSON
EPSON customer service telephone number EPSON EPSON helpline phone number EPSON
EPSON contact number EPSON EPSON customer service number EPSON EPSON customer
service phone number ~!~I8557092847++ EPSON us EPSON customer service phone
number EPSON usa EPSON telephone number EPSON EPSON phone number EPSON usa
EPSON printer contact number EPSON EPSON number EPSON EPSON contact number
EPSON usa EPSON printer helpline number EPSON EPSON helpline number EPSON EPSON
customer number EPSON EPSON printer customer service number EPSON EPSON contact
telephone number EPSON contact number EPSON for EPSON EPSON software contact
number EPSON EPSON toll free number EPSON EPSON telephone number EPSON uk EPSON
registration number EPSON EPSON toll free number EPSON usa EPSON customer
service EPSON software customer service contact EPSON customer service EPSON
customer service phone EPSON printer customer service EPSON service EPSON
printer technical support EPSON printer customer support EPSON technical
support reviews telephone EPSON printer EPSON tech support phone number EPSON
EPSON printer tech support phone number EPSON EPSON printer customer service
EPSON technical support phone number EPSON EPSON printer free printer support
EPSON customer service billing EPSON customer service email address EPSON
customer service reviews contact EPSON customer service EPSON tech support
number EPSON usa EPSON printer support number EPSON EPSON printer contact
number EPSON EPSON customer service phone number EPSON EPSON technical support
usa EPSON technical support number EPSON EPSON tech support phone EPSON tech
supp

[Bug c++/71515] [4.9/5/6 Regression] ICE on valid C++ code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression] ICE  |[4.9/5/6 Regression] ICE on
   |on valid C++ code on|valid C++ code on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus)|cc1plus)

--- Comment #4 from Jason Merrill  ---
Fixed for gcc 7 so far.