[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Or of course aarch64 could replace not just futex.h, but wait.h if it has
something smarter.  This needs to be done by somebody who knows the ISA though
(i.e. not me).

[Bug tree-optimization/79777] [7 Regression] ICE on -Os and above in on aarch64-linux-gnu (internal compiler error: in VN_INFO_GET, at tree-ssa-sccvn.c:407 })

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  2 07:53:42 2017
New Revision: 245830

URL: https://gcc.gnu.org/viewcvs?rev=245830=gcc=rev
Log:
2017-03-02  Richard Biener  

PR tree-optimization/79777
* tree-ssa-pre.c (eliminate_insert): Give up if we simplify
the to insert expression to sth existing.

* gcc.dg/torture/pr79777.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79777.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Wfe kinda works. But yield might be better.  Though one most implementions
yield is just a nop.  Even on the (4thread/core) hyperthread CN99xx, it is a
nop.

[Bug libstdc++/79798] [7 Regression] std::bind loses cv-qualifiers in result_of type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/79789] [6 Regression] non-reserved names in headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[6/7 Regression]|[6 Regression] non-reserved
   |non-reserved names in   |names in headers
   |headers |

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk, there are cases to fix on the branches still.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||krisk0.2017.02.27@protonmai
   ||l.com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 79743 has been marked as a duplicate of this bug. ***

[Bug libstdc++/79743] std::experimental::optional constructor broken in gcc 6.2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Денис Крыськов from comment #0)
> all files mentioned in bug-report

No, because you haven't provided a standalone program that can be compiled,
because it includes gtest headers.

Here's a standalone version, which fails with 6.2 and passes with 6.3:

#include 
#include 
#include 

class Bread_and_butter {
public:
std::string bread;
std::experimental::optional butter;

Bread_and_butter(Bread_and_butter&& source);
Bread_and_butter() noexcept : bread(), butter() {};
Bread_and_butter(const Bread_and_butter&) = delete;
Bread_and_butter& operator=(const Bread_and_butter&) = delete;
Bread_and_butter& operator=(Bread_and_butter&&) = delete;
};

Bread_and_butter::Bread_and_butter(Bread_and_butter&& source) :
bread(source.bread),
butter(source.butter) {
if(bread.size() >= 5) {
butter = true;
}
if(bread.size() >= 10) {
butter = false;
}
}

int main() {
Bread_and_butter s0;
auto s1 = std::move(s0);
assert(!s1.butter);
}

I think this is a dup of PR 77288

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

[Bug middle-end/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #5)
> Maybe we should use our own pushxf expander?

No. Middle end should be fixed. x86 does not define any of HAVE_PRE_MODIFY
macros.

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[cbz at baozis dot org]

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

--- Comment #7 from Chen Baozi  ---
Created attachment 40867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40867=edit
synchronization test case

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
BTW, aarch64 doesn't override cpu_relax, does the HW have any instruction
similar to __builtin_ia32_pause () that could be used for spinning?

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #4)
> Or the case the futex syscall is returning right away ...

The spinning is completely configurable, see the documented OMP_WAIT_POLICY
(standard) and GOMP_SPINCOUNT environment variables.  How much spinning is
desirable depends on the workload, how many cores/threads are busy in the app,
how many cores/threads there are, what other programs are running on the box. 
Decreasing the spincount can result in severe latency degradation.

And, if some threads don't have anything to do anymore and are just waiting for
other threads, then spending time in the spinning loops or waiting on futex
depending on the above mentioned setting is the only thing it can do, so
obviously you see a lot of that.

[Bug middle-end/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
We go through:

  if (STACK_GROWS_DOWNWARD)
/* ??? This seems wrong if STACK_PUSH_CODE == POST_DEC.  */
dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
  gen_int_mode (-(HOST_WIDE_INT) rounded_size,
Pmode));
  else
/* ??? This seems wrong if STACK_PUSH_CODE == POST_INC.  */
dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
  gen_int_mode (rounded_size, Pmode));

  dest_addr = gen_rtx_PRE_MODIFY (Pmode, stack_pointer_rtx, dest_addr);

Maybe we should use our own pushxf expander?

[Bug other/79792] configuring a nvptx-none build with --program-suffix=-7 results in a misnamed installed binary

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
--program-prefix= and --program-suffix= are never passed into the gcc subdir,
but are transformed to a --program-transform-name.

the toplevel (expanded from an autoconf macro) has:

# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
  test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
  program_prefix=${target_alias}-

so the new program_prefix is ignored when --program-suffix= is passed. A work
around is to explicitly use --program-prefix=-.

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Or the case the futex syscall is returning right away ...

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
I wonder if the case we are spinning too much in user space before hitting the
futex syscall.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Testcase for likely the same bug, at least hang starts at r221983.

-fPIC -O2 -m32 -march=i686 -fno-omit-frame-pointer rh1406093.i

long long *a, *b, c;
int d, e;
int baz (void);

static inline long long
foo (long long *x)
{
  return __sync_val_compare_and_swap (x, 0, 0);
}

void
bar ()
{
  int f = baz ();
  c = foo ([f]);
  if (c)
e = d;
  a = b;
}

[Bug middle-end/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Gerhard Steinmetz from comment #0)
> > (insn 10 9 11 2 (set (mem:XF (pre_modify:DI (reg/f:DI 7 sp)
> > (plus:DI (reg/f:DI 7 sp)
> > (const_int -16 [0xfff0]))) [2  S12 A32])
> > (reg:XF 87 [ _1 ])) "pr46251.c":3 118 {*pushxf}
> >  (expr_list:REG_DEAD (reg:XF 87 [ _1 ])
> > (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
> > (nil
> 
> This doesn't look like a valid RTL to me.

A bit of debugging shows:

Breakpoint 1, gen_movxf (operand0=0x2e8f3318, operand1=0x2e8daf90) at
../../git/gcc/gcc/config/i386/i386.md:3185
3185  return standard_sse_constant_opcode (insn, operands[1]);
(gdb) p debug_rtx (operand1)
(reg:XF 87 [ _1 ])
$3 = void
(gdb) p debug_rtx (operand0)
(mem:XF (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0]))) [2  S12 A32])
$4 = void
(gdb) bt
#0  gen_movxf (operand0=0x2e8f3318, operand1=0x2e8daf90) at
../../git/gcc/gcc/config/i386/i386.md:3185
#1  0x007e23ef in operator() (a1=0x2e8daf90, a0=0x2e8f3318,
this=) at ../../git/gcc/gcc/recog.h:301
#2  emit_move_insn_1 (x=0x2e8f3318, y=0x2e8daf90) at
../../git/gcc/gcc/expr.c:3643
#3  0x007e2745 in emit_move_insn (x=x@entry=0x2e8f3318,
y=y@entry=0x2e8daf90) at ../../git/gcc/gcc/expr.c:3738
#4  0x007e4433 in emit_single_push_insn_1 (type=0x2e7c8498,
x=0x2e8daf90, mode=) at ../../git/gcc/gcc/expr.c:4185
#5  emit_single_push_insn (mode=, x=0x2e8daf90,
type=0x2e7c8498) at ../../git/gcc/gcc/expr.c:4197
#6  0x007e817b in emit_push_insn (x=0x2e8daf90, mode=XFmode,
type=0x2e7c8498, size=0x0, align=64, partial=0, reg=0x0, extra=0, 
args_addr=0x0, args_so_far=0x2e7b0480, reg_parm_stack_space=0,
alignment_pad=0x2e7b0480, sibcall_p=true)
at ../../git/gcc/gcc/expr.c:4536
...
(gdb) f 4
#4  0x007e4433 in emit_single_push_insn_1 (type=0x2e7c8498,
x=0x2e8daf90, mode=) at ../../git/gcc/gcc/expr.c:4185
4185  emit_move_insn (dest, x);
(gdb) p debug_rtx (dest)
(mem:XF (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0]))) [2  S12 A32])
$12 = void
(gdb) list
4180   outgoing arguments and we cannot allow reordering of reads
4181   from function arguments with stores to outgoing arguments
4182   of sibling calls.  */
4183set_mem_alias_set (dest, 0);
4184}
4185  emit_move_insn (dest, x);
4186}
4187
4188/* Emit and annotate a single push insn.  */
4189

So, it is middle end that generates invalid RTX.

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I should note I have seen some scalability issues with GOMP compared to LLVM's
openmp implementation on ThunderX 2 CN99xx (and on ThunderX 1 CN88xx).  I don't
know if this is related to this or not because I have not start to debugged
that yet.  Also this was reported to me by a few other folks too.

[Bug target/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Gerhard Steinmetz from comment #0)
> (insn 10 9 11 2 (set (mem:XF (pre_modify:DI (reg/f:DI 7 sp)
> (plus:DI (reg/f:DI 7 sp)
> (const_int -16 [0xfff0]))) [2  S12 A32])
> (reg:XF 87 [ _1 ])) "pr46251.c":3 118 {*pushxf}
>  (expr_list:REG_DEAD (reg:XF 87 [ _1 ])
> (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
> (nil

This doesn't look like a valid RTL to me.

[Bug libstdc++/79789] [6/7 Regression] non-reserved names in headers

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar  2 03:43:49 2017
New Revision: 245828

URL: https://gcc.gnu.org/viewcvs?rev=245828=gcc=rev
Log:
PR libstdc++/79789 fix non-reserved names in headers

PR libstdc++/79789
* include/bits/hashtable_policy.h (__clp2): Use reserved names for
parameters and local variables.
* include/bits/ios_base.h (make_error_code, make_error_condition):
Likewise.
* include/bits/list.tcc (list::sort): Likewise.
* include/bits/mask_array.h (mask_array): Likewise.
* include/bits/regex.h (regex_token_iterator): Likewise.
* include/bits/slice_array.h (slice_array): Likewise.
* include/bits/stl_algo.h (__sample): Likewise.
* include/std/memory (undeclare_no_pointers): Likewise.
* include/std/type_traits (is_callable_v, is_nothrow_callable_v):
Likewise.
* libsupc++/exception_ptr.h (__dest_thunk): Likewise.
* testsuite/17_intro/headers/names.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/17_intro/headers/names.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable_policy.h
trunk/libstdc++-v3/include/bits/ios_base.h
trunk/libstdc++-v3/include/bits/list.tcc
trunk/libstdc++-v3/include/bits/mask_array.h
trunk/libstdc++-v3/include/bits/regex.h
trunk/libstdc++-v3/include/bits/slice_array.h
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/std/memory
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/libsupc++/exception_ptr.h

[Bug libstdc++/79798] [7 Regression] std::bind loses cv-qualifiers in result_of type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar  2 03:43:36 2017
New Revision: 245827

URL: https://gcc.gnu.org/viewcvs?rev=245827=gcc=rev
Log:
PR 79798 Fix incorrect use of std::result_of in std::bind

PR libstdc++/79798
* include/std/functional (bind::_Res_type_impl): Fix incorrect use of
result_of that loses top-level cv-qualifiers.
* testsuite/20_util/bind/79798.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/bind/79798.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug c++/79713] \f missing from c++14, at least

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
What are you talking about? \f is not "missing" and works as it should.

[Bug c++/79741] errors about struct members being of type size_t when it's not, other strange errors. cached source too.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jim Michaels from comment #0)
> strange. a compiler should not cache the source code.

It doesn't.

> all these bugs I have
> fixed with static casts and the same errors are still reported.

Then you didn't fix all the bugs!

> source code
> not necessary.

Wrong.

> atoi64.cpp:265:12: error: 'egrep' is not a member of 
> 'std::regex_constants::syntax_option_type'
>  RGXC ropts=std::regex_constants::syntax_option_type::egrep;

This should be std::regex_constants::egrep

"I don't know how to fix my code" is not a GCC bug.

[Bug c++/79741] errors about struct members being of type size_t when it's not, other strange errors. cached source too.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
As usual, I'm fairly sure you're mistaken. Without a testcase showing a problem
we can't help you.

[Bug libstdc++/79714] error on assigning from char

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not an assignment, it's an initialization, i.e. constructor call, and
there is no std::string constructor from char. There never has been.

http://en.cppreference.com/w/cpp/string/basic_string/basic_string

If you want a std::string containing a single character then you want:

  ST sSignsDot(1, c);

[Bug libstdc++/79789] [6/7 Regression] non-reserved names in headers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
And this fails since 5.1.0 with C++11 or later:

#define e 1
#include 

And this fails for all versions at least as far back as 4.3 (although it's only
valid in C++98 and C++03 because C++11 adds member functions called a() in
):

#define a 1
#include 

There are a few other problems too.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #11 from Bernd Schmidt  ---
Investigating (but not entirely sure yet I'm getting somewhere).

[Bug c++/79767] inline namespace and unqualified definition

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Keywords|rejects-valid   |accepts-invalid

--- Comment #1 from Nathan Sidwell  ---
I thihnk this too is invalid (see 79766).  The definition of 'P' should find
Y::X::P and then complain in the same way 79766 should complain about Y::Q

[Bug c++/79774] gcc -fsanitize=address with error

[zhoujun48 at huawei dot com]

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

--- Comment #3 from xuliqun  ---
by the way, when compile,used gcc for arm64,not x86_64

[Bug rtl-optimization/79801] Disable ira.c:add_store_equivs for some targets?

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/79801] New: Disable ira.c:add_store_equivs for some targets?

[amodra at gmail dot com]

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

Bug ID: 79801
   Summary: Disable ira.c:add_store_equivs for some targets?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

On powerpc, the equivalences created by add_store_equivs in ira.c seem like
they might not be very effective.

For reg1 not being assigned a hard reg, they allow lra/reload to transform the
following example sequence
 (set (reg1) (mem1))
  ..
 (set (mem2) (reg1))
  ..
 (set (reg2) (reg1))

to
 (set (mem2) (mem1))
  ..
 (nop)
  ..
 (set (reg2) (mem2))

PowerPC doesn't have mem-mem move insns, so of course the transformed sequence
is really
 (set (rtmp) (mem1))
 (set (mem2) (rtmp))
  ..
 (nop)
  ..
 (set (reg2) (mem2))

Net result is poor scheduling (possibly fixed by sched2).  It may look like
you've reduced register pressure (reg1 has disappeared) but that is not
necessarily the case except when mem2 is a stack variable, because the lifetime
of the reg needed to load mem2 has likely been extended.

[Bug c++/79774] gcc -fsanitize=address with error

[zhoujun48 at huawei dot com]

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

--- Comment #2 from xuliqun  ---
Makefile like this :

NATIVE_CAMERA_LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MULTILIB := first

LOCAL_PATH := $(NATIVE_CAMERA_LOCAL_PATH)

LOCAL_SRC_FILES := \
CameraManagerImpl.cpp \
CameraParametersManagerImpl.cpp \
CameraManager.cpp

LOCAL_SHARED_LIBRARIES := \
libcutils \
libutils \
liblog \
libbinder \
libhardware \
libui \
libgui \
libcamera_metadata \
libcamera_client \
libHWCamCfgSvr \
libvconf \
libc_secshared

LOCAL_C_INCLUDES += \
bionic \
$(TOP)/frameworks/multimedia/av/include/ \
$(TOP)/frameworks/api/include/ \
$(TOP)/frameworks/api/camera/include/ \
$(TOP)/vendor/hisi/ap/hardware/camera3/include/ \
$(TOP)/external/vconf/include \
$(TOP)/external/vconf-internal-keys/include \
$(TOP)/vendor/huawei/chipset_common/modules/libc_sec/include

LOCAL_CXX_STL := libc++
LOCAL_CFLAGS := -lasan -fsanitize=address -DLOG_TAG=\"Camera\"
LOCAL_MODULE:= libcameramanager
LOCAL_MODULE_TAGS:= optional

include $(BUILD_SHARED_LIBRARY)


for LOCAL_CFLAGS := -lasan -fsanitize=address -DLOG_TAG=\"Camera\"

if I add -lasan -fsanitize=address ,then appears such error: undefined
reference to '__asan_report_load8'
if I get rid of -lasan -fsanitize=address ,then there is no errors.

[Bug libstdc++/79789] [6/7 Regression] non-reserved names in headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work|6.3.0   |5.4.0
Summary|[7 Regression] non-reserved |[6/7 Regression]
   |names in   |non-reserved names in
   ||headers
  Known to fail||6.3.0, 7.0

--- Comment #1 from Jonathan Wakely  ---
And this fails in C++11 or later, with GCC 6.1.0 or later:

#define T 1
#include 

[Bug c++/79766] inline namespace and ::

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Keywords|rejects-valid   |accepts-invalid

--- Comment #1 from Nathan Sidwell  ---
Looking at [7.3.1]/7 I think the use of 'Y::Q' to define Y::X::Q is ill-formed.
 Naming 'Q' in 'Y' for its definition is not one of the permitted uses.

[Bug tree-optimization/79800] wrong snprintf result range with precision in a narrow negative-positive range

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-02
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a patch.

[Bug tree-optimization/79800] New: wrong snprintf result range with precision in a narrow negative-positive range

[msebor at gcc dot gnu.org]

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

Bug ID: 79800
   Summary: wrong snprintf result range with precision in a narrow
negative-positive range
   Product: gcc
   Version: 7.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: ---

As mentioned in the patch for bug 79692
(https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01564.html), the return value of
a call to snprintf with a floating directive, a non-constant floating argument,
and with precision specified by the asterisk whose argument's range includes
both negative and non-negative values (and the upper bound is low), is in the
wrong range.

The following test case shows the problem.  A negative precision must be
treated as if no precision were specified.  The result of formatting 1.23456789
using %a is 0x1.3c0ca4283de1bp+0, which is 20 bytes.  However, the
-fprintf-return-value optimization sets the range of the return value to [6,
15], causing the test program to print "20 < 20" when it should print "20 >=
20" instead.

$ cat z.c && gcc -O2 -Wall -Wextra -Wpedantic z.c && ./a.out 
volatile double x = 1.23456789;

void f (int p)
{
  if (p < -1 || 0 < p)
p = -1;

  char d[30];
  int n = __builtin_sprintf (d, "%.*a", p, x);
  const char *s = n < 20 ? "< 20" : ">= 20";

  __builtin_printf ("%i %s\n%zu: \"%s\"\n", n, s, __builtin_strlen (d), d);
}

volatile int i;

int main ()
{
  volatile int i = -1;
  f (i);
}

20 < 20
20: "0x1.3c0ca4283de1bp+0"

[Bug target/79799] New: Improve vec_insert of float on Power9

[meissner at gcc dot gnu.org]

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

Bug ID: 79799
   Summary: Improve vec_insert of float on Power9
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

At the moment, we do not have special code on power9 to have vec_insert of
single precision floating point.

So for:

vector float insert_0 (vector float vf, float f) { return vec_insert (f, vf,
0); }

we currently generate:

insert_0:
.LCF2:
0:  addis 2,12,.TOC.-.LCF2@ha
addi 2,2,.TOC.-.LCF2@l
.localentry insert_0,.-insert_0
addis 9,2,.LC0@toc@ha
addi 10,1,-16
stfs 1,-16(1)
addi 9,9,.LC0@toc@l
lvewx 0,0,10
lxv 33,0(9)
vpermr 2,0,2,1
blr
.section.rodata.cst16,"aM",@progbits,16
.align 4
.LC0:
.byte   16
.byte   17
.byte   18
.byte   19
.byte   4
.byte   5
.byte   6
.byte   7
.byte   8
.byte   9
.byte   10
.byte   11
.byte   12
.byte   13
.byte   14
.byte   15

Instead we should generate a convert to XSCVDPSPN, right shift 32-bits, and
XXINSERTW.

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00059.html

[Bug libstdc++/79798] [7 Regression] std::bind loses cv-qualifiers in result_of type

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
We need to add && to the arg types in the result_of argument, so that top-level
cv qualifiers aren't lost in the function type that result_of requires us to
use:

--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -502,7 +502,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)

   template
using _Res_type_impl
- = typename result_of< _Fn&(_Mu_type<_BArgs, _CallArgs>...) >::type;
+ = typename result_of< _Fn&(_Mu_type<_BArgs, _CallArgs>&&...) >::type;

   template
using _Res_type = _Res_type_impl<_Functor, _CallArgs, _Bound_args...>;

This would be fixed by adopting the proposed invoke_result and using that
instead of result_of, which we've agreed to deprecate.

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[pthaugen at gcc dot gnu.org]

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

--- Comment #14 from Pat Haugen  ---
(In reply to amker from comment #13)
> We should create another PR for additional copy instructions after my patch
> and close this one.  IMHO they are two different issues.

Yes, I agree. Yuri, can you take care of that?

Additional info, it's really just one copy introduced, but becomes 4 after
unrolling. This is the loop from the first testcase without -funroll-loops.
Looks like we could get rid of the vmovaps by making zmm2 the dest on the
vpermps (assuming I'm understanding the asm correctly).

.L26:
vpermps (%rcx), %zmm10, %zmm1
leal1(%rsi), %esi
vmovaps %zmm1, %zmm2
vmaxps  (%r15,%rdx), %zmm3, %zmm1
vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2
cmpl%esi, %r8d
leaq-64(%rcx), %rcx
vmaxps  %zmm1, %zmm2, %zmm1
vmovups %zmm1, (%rdi,%rdx)
leaq64(%rdx), %rdx
ja  .L26

[Bug libstdc++/79798] [7 Regression] std::bind uses wrong value category with result_of

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||6.3.0
   Keywords||rejects-valid
   Last reconfirmed||2017-03-01
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug libstdc++/79798] New: [7 Regression] std::bind uses wrong value category with result_of

[redi at gcc dot gnu.org]

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

Bug ID: 79798
   Summary: [7 Regression] std::bind uses wrong value category
with result_of
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Another case like PR 79486, this fails to compile with trunk:

#include 

struct X { };
const X f(int);

struct Y {
  void operator()(X&&) = delete;
  int operator()(const X&&);
};

auto b = std::bind(Y(), std::bind(f, std::placeholders::_1));
auto i = b(1);


x.cc:12:13: error: no match for call to ‘(std::_Bind)>) (int)’
 auto i = b(1);
 ^

[Bug c/79692] [7 Regression] -Wformat-overflow false positive with unknown width

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Wed Mar  1 23:39:59 2017
New Revision: 245822

URL: https://gcc.gnu.org/viewcvs?rev=245822=gcc=rev
Log:
PR middle-end/79692 - [7 Regression] -Wformat-overflow false positive

gcc/ChangeLog:

PR middle-end/79692
* gimple-ssa-sprintf.c
(directive::known_width_and_precision): New function.
(format_integer): Use it.
(get_mpfr_format_length): Consider the full range of precision
when computing %g output with the # flag.  Set the likely byte
count to 3 rather than 1 when precision is indeterminate.
(format_floating): Correct the lower bound of precision.

gcc/testsuite/ChangeLog:

PR middle-end/79692
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Correct %#g.
* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-3.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-10.c

[Bug c/79692] [7 Regression] -Wformat-overflow false positive with unknown width

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fix committed in r245822.

[Bug sanitizer/79783] [7 Regression] ICE on valid C++ with -fsanitize=address

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||reichelt at gcc dot gnu.org
  Known to work||6.1.0
 Ever confirmed|0   |1
  Known to fail||7.0.1

--- Comment #1 from Volker Reichelt  ---
Even simpler testcase, crashes with -O -fsanitize=address -fno-tree-dce :

=
struct A
{
  static void foo(const char&) {}
};

struct B
{
  B() { A::foo(char()); }
};

struct C
{
  virtual void bar() const { B b; }
};

C c;
=

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-01
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Let me fix this in gimple-ssa-sprintf.c for now.

[Bug c++/79797] New: [5/6/7 Regression] ICE with NSDMI, this pointer and constexpr

[reichelt at gcc dot gnu.org]

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

Bug ID: 79797
   Summary: [5/6/7 Regression] ICE with NSDMI, this pointer  and
constexpr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (valid?) code snippet (compiled with -std=c++1y) triggers an ICE
since GCC 5.1.0:

=
struct A
{
  A* x[1]{(A*)this};
};

constexpr A a{};
=

bug.cc:6:15: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:4477
 constexpr A a{};
   ^
0x83eb95 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4477
0x83bad3 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4119
0x83d1ca cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4343
0x83ceb3 cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.c:2686
0x83ceb3 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4316
0x83ceb3 cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.c:2686
0x83ceb3 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4316
0x8422fe cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4615
0x6b6862 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:817
0x61242b check_initializer
../../gcc/gcc/cp/decl.c:6365
0x63cc3c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7037
0x71b333 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19375
0x73f3ec cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12772
0x740195 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12597
0x7455a4 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12495
0x7471cb cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12371
0x7474aa cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4366
0x7474aa c_parse_file()
../../gcc/gcc/cp/parser.c:38418
0x8a6ad3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report, [etc.]

The code was rejected with a "sorry" message in GCC 4.8 / 4.9:

bug.cc:6:15:   in constexpr expansion of 'A()'
bug.cc:6:15: sorry, unimplemented: use of the value of the object being
constructed in a constant expression
 constexpr A a{};

[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

--- Comment #2 from Marek Polacek  ---
Started with r216750.

[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/79796] New: [5/6/7 Regression] ICE with NSDMI and this pointer

[reichelt at gcc dot gnu.org]

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

Bug ID: 79796
   Summary: [5/6/7 Regression] ICE with NSDMI and this pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with -std=c++1y) triggers
an ICE since GCC 5.1.0:

=
struct A
{
  A* p = this;
};

void foo()
{
  A a;
  a = A({});
}
=

bug.cc: In function 'void foo()':
bug.cc:9:5: internal compiler error: in gimplify_expr, at gimplify.c:11950
   a = A({});
   ~~^~~
0xaeacfc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11950
0xae80e0 gimplify_addr_expr
../../gcc/gcc/gimplify.c:5859
0xae80e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11238
0xaf17c0 gimplify_init_ctor_preeval
../../gcc/gcc/gimplify.c:4241
0xaf1778 gimplify_init_ctor_preeval
../../gcc/gcc/gimplify.c:4227
0xaf225c gimplify_init_constructor
../../gcc/gcc/gimplify.c:4796
0xaf3096 gimplify_modify_expr_rhs
../../gcc/gcc/gimplify.c:5082
0xaf9dd0 gimplify_modify_expr
../../gcc/gcc/gimplify.c:5417
0xae897c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11191
0xaeb8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6478
0xae7a7a gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:6230
0xae7a7a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11567
0xaeb8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6478
0xae71cb gimplify_statement_list
../../gcc/gcc/gimplify.c:1716
0xae71cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11619
0xaeb8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6478
0xaec9a8 gimplify_bind_expr
../../gcc/gcc/gimplify.c:1290
0xae7b7a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11391
0xaeb8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6478
0xaed911 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:12388
Please submit a full bug report, [etc.]

[Bug middle-end/79794] unnecessary copy from target to target results in poor code for aarch64

[wilson at gcc dot gnu.org]

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

--- Comment #1 from Jim Wilson  ---
Patch posted here
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00058.html

[Bug fortran/79795] [5/6/7 Regression] Fortran ICE in resolve_symbol starting with r163221

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||domob at gcc dot gnu.org
   Target Milestone|--- |5.5

[Bug fortran/79795] New: [5/6/7 Regression] Fortran ICE in resolve_symbol starting with r163221

[jakub at gcc dot gnu.org]

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

Bug ID: 79795
   Summary: [5/6/7 Regression] Fortran ICE in resolve_symbol
starting with r163221
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

subroutine foo (a)
  dimension a(*,*)
end

is rejected before r163221 with:
rh1386361.f90:2.17:

  dimension a(*,*)
 1
Error: Bad specification for assumed size array at (1)
and ICEs after it.

[Bug middle-end/79794] New: unnecessary copy from target to target results in poor code for aarch64

[wilson at gcc dot gnu.org]

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

Bug ID: 79794
   Summary: unnecessary copy from target to target results in poor
code for aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

I noticed this while looking at Maxim's testcase in bug 18438 in comment 9,
which is extracted from SPEC CPU2006 462.libquantum.  The testcase is

struct node_struct
{
  float _Complex gap;
  unsigned long long state;
};

struct reg_struct
{
  int size;
  struct node_struct *node;
};

void
func(int target, struct reg_struct *reg)
{
  int i;

  for(i=0; isize; i++)
reg->node[i].state ^= ((unsigned long long) 1 << target);
}

The code generated is 
.L4:
ld2 {v0.2d - v1.2d}, [x1]
add w2, w2, 1
cmp w2, w7
eor v0.16b, v2.16b, v0.16b
umovx4, v0.d[1]
st1 {v0.d}[0], [x1]
add x1, x1, 32
str x4, [x1, -16]
bcc .L4
One half of the result is stored from vector regs (st1), and one half gets
moved to general regs and then stored (umov/str), which is curious.

The problem occurs when generating RTL.  The final tree dump has
  _51 = BIT_FIELD_REF ;
  MEM[base: vectp.8_39, offset: 16B] = _51;
which is OK, but the RTL generated for this is
(insn 69 68 70 6 (set (reg:DI 144)
(plus:DI (reg/f:DI 130 [ vectp.8 ])
(const_int 16 [0x10]))) "tmp.c":19 -1
 (nil))
(insn 70 69 71 6 (set (mem:DI (reg:DI 144) [4 MEM[base: vectp.8_39, offset:
16B\
]+0 S8 A64])
(vec_select:DI (reg:V2DI 134 [ vect__7.13 ])
(parallel [
(const_int 1 [0x1])
]))) "tmp.c":19 -1
 (nil))
(insn 71 70 72 6 (set (reg:DI 145)
(mem:DI (reg:DI 144) [4 MEM[base: vectp.8_39, offset: 16B]+0 S8 A64]))
\
"tmp.c":19 -1
 (nil))
(insn 72 71 73 6 (set (mem:DI (plus:DI (reg/f:DI 130 [ vectp.8 ])
(const_int 16 [0x10])) [4 MEM[base: vectp.8_39, offset: 16B]+0
\
S8 A64])
(reg:DI 145)) "tmp.c":19 -1
 (nil))
What happened here is that we called extract_bit_field with a vector register
source and a MEM target using a reg+offset addressing mode.  Aarch64 does have
an instruction to store part of a vector register, but it only accepts a
register addressing mode.  So we have to fix the address and generate the
store.  We then return to expand_expr which does a test
 ! rtx_equal_p (temp, target)
sees that the RTL is different because the addressing mode changed, and
proceeds to copy from the target into a temp reg and back out to the target
again.  Later, the DSE pass removes the first (good) store, leaving the second
(bad) store, forcing the register allocator to emit an instruction to copy the
value from a vector reg to a general reg.

With a tentative patch to fix this, I instead get this code
.L4:
ld2 {v0.2d - v1.2d}, [x1]
add x2, x1, 16
add w3, w3, 1
cmp w3, w5
eor v0.16b, v2.16b, v0.16b
st1 {v0.d}[0], [x1]
add x1, x1, 32
st1 {v0.d}[1], [x2]
bcc .L4
and w4, w4, -2
which looks better, as both halves of the result are stored with vector stores
(st1).  It is the same number of instructions, with the umov replaced with an
address add.

Preliminary testing shows that this is faster on some aarch64 machines (e.g.
xgene1), and the same speed on others (e.g. kryo).  It depends on the speed of
the umov instruction, which is slower than an add on some aarch64 parts.

[Bug target/79105] Autovectorized NEON code slower than vfpv4 on Cortex A5

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

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

--- Comment #3 from PeteVine  ---
Closing in favour of PR79581.

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #5 from Pat Haugen  ---
Fixed.

[Bug target/79793] New: Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

Bug ID: 79793
   Summary: Incorrect stack alignment for interrupt handler in
64-bit
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
  Target Milestone: ---
Target: x86-64

Section I6.14.2 64-Bit Mode Stack Frame in Intel SDM Vol 3 has

In IA-32e mode, the RSP is aligned to a 16-byte boundary before pushing the
stack
frame. The stack frame itself is aligned on a 16-byte boundary when the
interrupt
handler is called.

static unsigned int
ix86_minimum_incoming_stack_boundary (bool sibcall)
{
  unsigned int incoming_stack_boundary;

  /* Stack of interrupt handler is always aligned to MIN_STACK_BOUNDARY.
   */
  if (cfun->machine->func_type != TYPE_NORMAL)
incoming_stack_boundary = MIN_STACK_BOUNDARY;

is incorrect for 64-bit mode.

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
Author: pthaugen
Date: Wed Mar  1 21:18:18 2017
New Revision: 245819

URL: https://gcc.gnu.org/viewcvs?rev=245819=gcc=rev
Log:
PR target/79544
* rs6000/rs6000-c.c (struct altivec_builtin_types): Use VSRAD for
arithmetic shift of unsigned V2DI.

* gcc.target/powerpc/pr79544.c: New.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr79544.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
Author: pthaugen
Date: Wed Mar  1 21:17:46 2017
New Revision: 245818

URL: https://gcc.gnu.org/viewcvs?rev=245818=gcc=rev
Log:
PR target/79544
* rs6000/rs6000-c.c (struct altivec_builtin_types): Use VSRAD for
arithmetic shift of unsigned V2DI.

* gcc.target/powerpc/pr79544.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr79544.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug other/79792] New: configuring a nvptx-none build with --program-suffix=-7 results in a misnamed installed binary

[doko at gcc dot gnu.org]

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

Bug ID: 79792
   Summary: configuring a nvptx-none build with
--program-suffix=-7 results in a misnamed installed
binary
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

configuring a nvptx-none build with --program-suffix=-7 results in a misnamed
installed binary. Such a build installs a binary called

debian/tmp-nvptx/usr/bin/gcc-7

[Bug c++/79791] New: -Werror=write-strings ignored with -Wpedantic

[federico.kircheis at gmail dot com]

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

Bug ID: 79791
   Summary: -Werror=write-strings ignored with -Wpedantic
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

Given following program:

int main(){
  char* str = "hello world!";
  (void)str;
}

When compiling with "-Werror=write-strings", the expected output would be a
compiler error. This is what happens when compiling with:
"g++ -Werror=write-strings main.cpp"
The output on the command line contains (an no executable is produced):
"error: ISO C++ forbids converting a string constant to ‘char*’
[-Werror=write-strings]"

The problem is that apparently "-Wpedantic" overwrites "-Werror=write-strings",
even if that option is given after pedantic:

g++ -v -Wpedantic -Werror=write-strings main.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-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 --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170205 (Debian 6.3.0-6) 
COLLECT_GCC_OPTIONS='-v' '-Wpedantic' '-Werror=write-strings' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=generic -march=x86-64
-auxbase main -Wpedantic -Werror=write-strings -version -o /tmp/ccPbVEN2.s
GNU C++14 (Debian 6.3.0-6) version 6.3.0 20170205 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170205, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/6"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/x86_64-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (Debian 6.3.0-6) version 6.3.0 20170205 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170205, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f4480661534e17ad26830674f037f8fe
main.cpp: In function ‘int main()’:
main.cpp:2:14: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wpedantic]
  char* str = "hello world!";
  ^~
COLLECT_GCC_OPTIONS='-v' '-Wpedantic' '-Werror=write-strings' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccE9VOo8.o /tmp/ccPbVEN2.s
GNU assembler version 2.27.90 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.27.90.20170124
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wpedantic' '-Werror=write-strings' '-shared-libgcc'

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[jochen.goert...@uni-konstanz.de]

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

--- Comment #3 from Jochen Görtler  ---
This is the error:

template_class_deduction.cpp: In function ‘int main()’:
template_class_deduction.cpp:4:29: error: class template argument deduction
failed:
 std::array test = {1,2,3};
 ^
template_class_deduction.cpp:4:29: internal compiler error: Segmentation fault
0xd6c37f crash_signal
../../gcc-bug/gcc/toplev.c:337
0x61021e print_error_for_call_failure
../../gcc-bug/gcc/cp/call.c:4170
0x610e3a build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-bug/gcc/cp/call.c:4224
0x68be54 do_class_deduction
../../gcc-bug/gcc/cp/pt.c:25217
0x68be54 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc-bug/gcc/cp/pt.c:25270
0x648972 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-bug/gcc/cp/decl.c:6835
0x727c53 cp_parser_init_declarator
../../gcc-bug/gcc/cp/parser.c:19375
0x74bd0c cp_parser_simple_declaration
../../gcc-bug/gcc/cp/parser.c:12772
0x74cab5 cp_parser_block_declaration
../../gcc-bug/gcc/cp/parser.c:12597
0x74d569 cp_parser_declaration_statement
../../gcc-bug/gcc/cp/parser.c:12207
0x725893 cp_parser_statement
../../gcc-bug/gcc/cp/parser.c:10694
0x72692d cp_parser_statement_seq_opt
../../gcc-bug/gcc/cp/parser.c:11026
0x7269ff cp_parser_compound_statement
../../gcc-bug/gcc/cp/parser.c:10980
0x726b93 cp_parser_function_body
../../gcc-bug/gcc/cp/parser.c:21427
0x726b93 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-bug/gcc/cp/parser.c:21465
0x727411 cp_parser_function_definition_after_declarator
../../gcc-bug/gcc/cp/parser.c:26252
0x7280fd cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-bug/gcc/cp/parser.c:26164
0x7280fd cp_parser_init_declarator
../../gcc-bug/gcc/cp/parser.c:19154
0x74bd0c cp_parser_simple_declaration
../../gcc-bug/gcc/cp/parser.c:12772
0x74cab5 cp_parser_block_declaration
../../gcc-bug/gcc/cp/parser.c:12597
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[jochen.goert...@uni-konstanz.de]

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

--- Comment #2 from Jochen Görtler  ---
The bug can also be reproduced in the compiler explorer:
https://godbolt.org/g/3NBvoL

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[jochen.goert...@uni-konstanz.de]

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

--- Comment #1 from Jochen Görtler <jochen.goert...@uni-konstanz.de> ---
Using built-in specs.
COLLECT_GCC=../gcc-bug/bin/g++
COLLECT_LTO_WRAPPER=/home/jochen/Developer/gcc-bug/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-bug/configure --prefix=/home/jochen/Developer/gcc-bug
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 7.0.1 20170301 (experimental) (GCC)

[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-01
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Patch I'm going to bootstrap/regtest on powerpc64-linux.

[Bug c++/79790] New: [C++17] ICE class template argument deduction failed

[jochen.goert...@uni-konstanz.de]

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

Bug ID: 79790
   Summary: [C++17] ICE class template argument deduction failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jochen.goert...@uni-konstanz.de
  Target Milestone: ---

Created attachment 40865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40865=edit
Minimal test case

[Bug target/79752] incorrect code generation for __divkf3 with -O2 -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Wed Mar  1 19:58:05 2017
New Revision: 245817

URL: https://gcc.gnu.org/viewcvs?rev=245817=gcc=rev
Log:
2017-03-01  Aaron Sawdey  

PR target/79752
* config/rs6000/rs6000.md (peephole2 for udiv/umod): Should emit
udiv rather than div since input pattern is unsigned.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug libstdc++/79789] [7 Regression] non-reserved names in

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-01
  Known to work||6.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug libstdc++/79789] New: [7 Regression] non-reserved names in

[redi at gcc dot gnu.org]

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

Bug ID: 79789
   Summary: [7 Regression] non-reserved names in 
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails to compile in C++17 mode:

#define T 1
#include 

[Bug target/79773] Missing documentation for -mabi={ms,sysv}

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Ah, I grepped wrongly. Thanks!

[Bug ipa/79772] [6/7 Regression][CHKP] ICE on invalid code in chkp_process_stmt (tree-chkp.c:4034)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I wrote a simple Python script (read fuzzer) which reads GCC's options via
--help=x and randomly selects set of options which are use to compile a random
test-case in LLVM and GCC test-suite. If you are interested, please take a
look: https://github.com/marxin/script-misc/blob/master/gcc-option-juggler.py

[Bug libgomp/79784] Synchronization overhead is thrashing on Aarch64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-01
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
We need a buildable testcase.  Furthermore, we need to know more about your
run-time environment (system, number of cores, OS) etc to have any chance of
understanding what might be going on here.

[Bug middle-end/79756] [5/6/7 Regression] ICE in execute_todo, at passes.c:2011

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Wed, 1 Mar 2017, rguenth at gcc dot gnu.org wrote:

> but note that convert_vector_to_array_for_subscript will return
> VIEW_CONVERT_EXPR  (MAYBE_CONST (...)) then.  Maybe proper
> operation is to instead return

Returning that is fine.  The following principles apply:

* Anything inside a C_MAYBE_CONST_EXPR must already have been fully 
folded.

* Anything wrapped around a C_MAYBE_CONST_EXPR must be handled in 
c_fully_fold_internal with recursion to its operands, to avoid a 
C_MAYBE_CONST_EXPR ending up nested inside the output of 
c_fully_fold_internal.

VIEW_CONVERT_EXPR is handled in c_fully_fold_internal, so it's OK to wrap 
one around a C_MAYBE_CONST_EXPR.

[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register

[meissner at gcc dot gnu.org]

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

--- Comment #10 from Michael Meissner  ---
Author: meissner
Date: Wed Mar  1 18:33:21 2017
New Revision: 245813

URL: https://gcc.gnu.org/viewcvs?rev=245813=gcc=rev
Log:
[gcc]
2017-03-01  Michael Meissner  

PR target/79439
* config/rs6000/predicates.md (current_file_function_operand): Do
not allow self calls to be local if the function is replaceable.

[gcc/testsuite]
2017-03-01  Michael Meissner  

PR target/79439
* gcc.target/powerpc/pr79439.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79439.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[jamborm at gcc dot gnu.org]

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

--- Comment #20 from Martin Jambor  ---
Created attachment 40864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40864=edit
A small self-contained testcase

I have finally managed to put together a small self-contained
testcase.  Compile with -O2 -fno-ipa-sra to trigger the bug (under
Wine), add -fno-ipa-cp to make it disappear.

[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Bernd Schmidt  ---
So the verification triggers before the dead blocks get removed?

I think I'd keep the seen_uncond_trap and just delete_insn inside the if
statement if it's already true.

[Bug c/79788] ICE in expand_expr_real_2, at expr.c:9557

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c/79787] ICE in remove_unreachable_nodes, at ipa.c:469

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  GCC 5 ICEs too.

[Bug c++/79786] ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  G++ 6 ICEs too and 5 doesn't have -miamcu.

[Bug c++/79785] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|ICE in gimplify_expr, at|[5/6/7 Regression] ICE in
   |gimplify.c:11950|gimplify_expr, at
   ||gimplify.c:11950

[Bug c++/79785] ICE in gimplify_expr, at gimplify.c:11950

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Even g++ 4.6 ICEs.


$ g++34 -c int128-3.C -m32
int128-3.C:6: error: integer constant is too large for "long" type
int128-3.C:7: error: overflow in enumeration values at `e2'
int128-3.C:12: error: `__int128' was not declared in this scope

[Bug c/79788] New: ICE in expand_expr_real_2, at expr.c:9557

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

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

Bug ID: 79788
   Summary: ICE in expand_expr_real_2, at expr.c:9557
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With testfile ./gcc.dg/pr38934.c :


$ gcc-7-20170226 -m32 -mmpx -fcheck-pointer-bounds -ftrapv -c pr38934.c
pr38934.c: In function 'f':
pr38934.c:14:13: warning: integer constant is so large that it is unsigned
   if (p >= -9223372036854775808LL - (signed char) g)
 ^
pr38934.c: In function 'f.chkp':
pr38934.c:14:35: internal compiler error: in expand_expr_real_2, at expr.c:9557
   if (p >= -9223372036854775808LL - (signed char) g)
~~~^
0x8dccd2 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9557
0x7b71e2 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3676
0x7b71e2 expand_gimple_stmt
../../gcc/cfgexpand.c:3737
0x7b998e expand_gimple_basic_block
../../gcc/cfgexpand.c:5744
0x7bfa56 execute
../../gcc/cfgexpand.c:6357

[Bug c/79787] New: ICE in remove_unreachable_nodes, at ipa.c:469

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

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

Bug ID: 79787
   Summary: ICE in remove_unreachable_nodes, at ipa.c:469
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With testfiles ./gcc.target/i386/bmi-1.c and ./gcc.target/i386/bmi-2.c
at -Os|1|2|3 :


$ gcc-7-20170226 -O2 -mmpx -fcheck-pointer-bounds -c bmi-1.c
In file included from
.../lib64/gcc/x86_64-pc-linux-gnu/7.0.1/include/immintrin.h:81:0,
 from
.../lib64/gcc/x86_64-pc-linux-gnu/7.0.1/include/x86intrin.h:48,
 from bmi-1.c:10:
bmi-1.c: In function 'func_tzcnt32_2.chkp':
.../lib64/gcc/x86_64-pc-linux-gnu/7.0.1/include/bmiintrin.h:104:1: error:
inlining failed in call to always_inline '_tzcnt_u32.chkp': target specific
option mismatch
 _tzcnt_u32 (unsigned int __X)
 ^~
bmi-1.c:77:10: note: called from here
   return _tzcnt_u32(X);
  ^
bmi-1.c: At top level:
bmi-1.c:78:1: internal compiler error: in remove_unreachable_nodes, at
ipa.c:469
 }
 ^
0xa29c05 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.c:469
0xb1aaf8 execute_todo
../../gcc/passes.c:2030

[Bug c++/79786] New: ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263

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

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

Bug ID: 79786
   Summary: ICE tree check: expected class 'type', have
'declaration' (var_decl) in iamcu_alignment, at
config/i386/i386.c:30263
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Over 400 testfiles from ./gcc/testsuite/g++.dg/*
expose a symptom with options "-m32 -miamcu"
and version 6/7 (-miamcu not implemented before) :
  ./g++.dg/rtti/anon-ns1.C
  ./g++.dg/opt/inline1.C
  ./g++.dg/abi/inline1.C
  ./g++.dg/abi/rtti3.C
  ./g++.dg/eh/throw3.C
  ./g++.dg/abi/vtt1.C
  ./g++.dg/opt/vt1.C
  ...


$ cat vt1.C   # for example
struct S
{
  virtual void vm (void) {};
} x;


$ gcc-7-20170226 -m32 -miamcu -c vt1.C
vt1.C:4:4: internal compiler error: tree check: expected class 'type', have
'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263
 } x;
^
0x1090287 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9866
0x538 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3187
0x538 iamcu_alignment
../../gcc/config/i386/i386.c:30263
0x115203b ix86_data_alignment(tree_node*, int, bool)
../../gcc/config/i386/i386.c:30317
0x7d2cff emit_tinfo_decl(tree_node*)
../../gcc/cp/rtti.c:1616
0x777894 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4568

[Bug c++/79785] New: ICE in gimplify_expr, at gimplify.c:11950

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

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

Bug ID: 79785
   Summary: ICE in gimplify_expr, at gimplify.c:11950
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With testfile ./g++.dg/ext/int128-3.C
down to version 4.9 :


$ gcc-7-20170226 -c int128-3.C
$ gcc-7-20170226 -m32 -c int128-3.C
int128-3.C:7:3: error: overflow in enumeration values at 'e2'
   e2, e3
   ^~
int128-3.C:12:27: error: expected primary-expression before '__int128'
 SA(1, sizeof(E) == sizeof(__int128));
   ^
int128-3.C:10:27: note: in definition of macro 'SA'
 #define SA(I,X) int a##I[(X)? 1 : -1]
   ^
int128-3.C:12:27: error: expected ')' before '__int128'
 SA(1, sizeof(E) == sizeof(__int128));
   ^
int128-3.C:10:27: note: in definition of macro 'SA'
 #define SA(I,X) int a##I[(X)? 1 : -1]
   ^
int128-3.C:12:37: error: expected ')' before ';' token
 SA(1, sizeof(E) == sizeof(__int128));
 ^
int128-3.C:12:37: error: expected ']' before ';' token
int128-3.C: In function 'void __static_initialization_and_destruction_0(int,
int)':
int128-3.C:8:3: internal compiler error: in gimplify_expr, at gimplify.c:11950
 } e = e3;
   ^
0xb7b2fa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11950
0xb8723f gimplify_modify_expr
../../gcc/gimplify.c:5457
0xb79a7d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11192
0xb7d226 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0xb79d21 gimplify_cleanup_point_expr
../../gcc/gimplify.c:6230
0xb79d21 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11567
0xb7d226 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0xb785e3 gimplify_statement_list
../../gcc/gimplify.c:1716
0xb785e3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11619
0xb7d226 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0xb83249 gimplify_cond_expr
../../gcc/gimplify.c:3971
0xb79ab4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11148
0xb7d226 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0xb83249 gimplify_cond_expr
../../gcc/gimplify.c:3971
0xb79ab4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11148
0xb7d226 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0xb808e9 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12388
0xb80f84 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12546
0x9e6fe7 cgraph_node::analyze()
../../gcc/cgraphunit.c:657
0x9ea753 analyze_functions
../../gcc/cgraphunit.c:1118

[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
--- cprop.c.jj2 2017-02-13 22:55:30.0 +0100
+++ cprop.c 2017-03-01 17:36:36.123518656 +0100
@@ -1829,7 +1829,6 @@ one_cprop_pass (void)
  EXIT_BLOCK_PTR_FOR_FN (cfun),
  next_bb)
{
- bool seen_uncond_trap = false;
  rtx_insn *insn;

  /* Reset tables used to keep track of what's still valid [since
@@ -1852,13 +1851,10 @@ one_cprop_pass (void)
if (! NOTE_P (insn) && ! insn->deleted ())
  mark_oprs_set (insn);

-   if (!was_uncond_trap && !seen_uncond_trap
+   if (!was_uncond_trap
&& GET_CODE (PATTERN (insn)) == TRAP_IF
&& XEXP (PATTERN (insn), 0) == const1_rtx)
- {
-   seen_uncond_trap = true;
-   uncond_traps.safe_push (insn);
- }
+ uncond_traps.safe_push (insn);
  }
}

fixes the ICE for me.  I bet the reason for the seen_uncond_trap is that
further splitting of dead code doesn't buy us much.  So another alternative
would be to simply delete the second and further unconditional trap instead of
splitting it.

[Bug c++/79672] ICE with -Wduplicated-branches -fopenmp

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
inchash::add_expr can't handle TREE_VECs so it seems the fix is to teach it to
deal with it.

[Bug libstdc++/59075] python pretty printer does not work at OS X

[manuelrciosici at gmail dot com]

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

--- Comment #9 from manuelrciosici at gmail dot com ---
Just to be sure this ticket doesn't get considered out of date, I want to
confirm that this is still an issue on OS X 10.12.3 using GCC 6.3 (compiled
from Homebrew) and GDB 7.12.1 (compiled from Homebrew). Alexander Timin's
suggestion still fixes issues for some collections like vector, but not for
others like unordered sets or other structures like strings.

(In reply to Jonathan Wakely from comment #8)
> Odd, on GNU/Linux I get:
> 
> type = class std::vector > :
> protected std::_Vector_base > {
> 
> 
> i.e. it has std:: qualification, and doesn't have the [with _Tp = ...] stuff
> which G++ outputs in diagnostics, but doesn't belong in the debug info if I
> understand correctly.
> 
> Iain, I don't know how to read the DWARF in the attachments, do you? And do
> you know anything about why the DWARF info is different in this way?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
(In reply to Jürgen Reuter from comment #27)
> Well, the valgrind output actually exactly that the comparison is optimized
> away. 
> I actually would have to regenerate all the debug output, but the point is
> that for the first appearance in the random seed chain, the code must not
> run into the second part of the if clause:
>   else if (prt%child1%is_quark ()) then
>  !!! 1: q->qg
>  prt%type = prt%child1%type
>  prt%child2%type = GLUON
>  prt%child2%t = abs(prt%t)
>  call integral_over_z_part_isr &
>   (shower, prt,otherprt, shat, minz, maxz, integral, final)
>  if (integral > final) then
> return
>  else
> !!! 2: g->qqbar
> prt%type = GLUON
> prt%child2%type = -prt%child1%type
> prt%child2%t = abs(prt%t)
> call integral_over_z_part_isr &
>  (shower, prt,otherprt, shat, minz, maxz, integral, final)
>  end if
>   end if
> so the return should be executed. We checked explicitly that the condition
> integral > final was fulfilled, for the value of final as calculated inside
> the routine integral_over_z_part_isr, but then the if clause did not
> correctly execute the return, and the reason seemed to be that the value of
> integral was not available anymore.

It is of course possible that in the debugger you see some variables as no
longer available, especially if they aren't used afterwards.
But, as integral_over_z_part_isr is not inlined into this function (while the
containing function is inlined ultimately into
shower_generate_next_isr_branching, if you add a breakpoint on the call
integral_over_z_part_isr insn and on the insn immediately after it and on the
call you stepi into the function, as both final and integral are passed by
reference, you should see the arguments (i.e. address where the final long
double value is stored and address into which integral will be stored).  Then
immediately after the call returns, you can again inspect both, and on the
fucomi instruction see if it compares the values you expect, and then where it
branches afterwards.  As the current function is inlined into others, the
return doesn't actually mean return from function, but just branching to code
that does something from other inlined functions.

[Bug c++/79766] inline namespace and ::

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-01
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #27 from Jürgen Reuter  ---
Well, the valgrind output actually exactly that the comparison is optimized
away. 
I actually would have to regenerate all the debug output, but the point is that
for the first appearance in the random seed chain, the code must not run into
the second part of the if clause:
  else if (prt%child1%is_quark ()) then
 !!! 1: q->qg
 prt%type = prt%child1%type
 prt%child2%type = GLUON
 prt%child2%t = abs(prt%t)
 call integral_over_z_part_isr &
  (shower, prt,otherprt, shat, minz, maxz, integral, final)
 if (integral > final) then
return
 else
!!! 2: g->qqbar
prt%type = GLUON
prt%child2%type = -prt%child1%type
prt%child2%t = abs(prt%t)
call integral_over_z_part_isr &
 (shower, prt,otherprt, shat, minz, maxz, integral, final)
 end if
  end if
so the return should be executed. We checked explicitly that the condition
integral > final was fulfilled, for the value of final as calculated inside the
routine integral_over_z_part_isr, but then the if clause did not correctly
execute the return, and the reason seemed to be that the value of integral was
not available anymore.

[Bug c++/79767] inline namespace and unqualified definition

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-01
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/79782] [7 Regression] ICE: tree check: expected tree_list, have void_type in emit_mem_initializers, at cp/init.c:1225

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/79773] Missing documentation for -mabi={ms,sysv}

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from H.J. Lu  ---
From GCC 6:

'-mabi=NAME'
 Generate code for the specified calling convention.  Permissible
 values are 'sysv' for the ABI used on GNU/Linux and other systems,
 and 'ms' for the Microsoft ABI. The default is to use the Microsoft
 ABI when targeting Microsoft Windows and the SysV ABI on all other
 systems.  You can control this behavior for specific functions by
 using the function attributes 'ms_abi' and 'sysv_abi'.  *Note
 Function Attributes::.

[Bug ipa/79772] [6/7 Regression][CHKP] ICE on invalid code in chkp_process_stmt (tree-chkp.c:4034)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  chkp_process_stmt in tree-chkp.c isn't prepared to handle flexible
array members (after the change to a null domain).  Let me see if I can patch
this up.  Out of curiosity, how did you discover this?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #26 from Jakub Jelinek  ---
I can see the mlm_matching_isr FAIL with current trunk, but certainly don't see
the integral > final comparison being optimized out.
   0x757978e1
<__shower_core_MOD_shower_generate_next_isr_branching+4529>:  callq 
0x7578e160 <__shower_core_MOD_integral_over_z_part_isr>
   0x757978e6
<__shower_core_MOD_shower_generate_next_isr_branching+4534>:  fldt  
0x1f0(%rsp)
   0x757978ed
<__shower_core_MOD_shower_generate_next_isr_branching+4541>:  pop%r10
   0x757978ef
<__shower_core_MOD_shower_generate_next_isr_branching+4543>:  pop%r11
   0x757978f1
<__shower_core_MOD_shower_generate_next_isr_branching+4545>:  fld%st(0)
   0x757978f3
<__shower_core_MOD_shower_generate_next_isr_branching+4547>:  fldt  
0x40(%rsp)
   0x757978f7
<__shower_core_MOD_shower_generate_next_isr_branching+4551>:  fxch   %st(2)
=> 0x757978f9
<__shower_core_MOD_shower_generate_next_isr_branching+4553>:  fucomi
%st(2),%st
   0x757978fb
<__shower_core_MOD_shower_generate_next_isr_branching+4555>:  fstp   %st(2)
   0x757978fd
<__shower_core_MOD_shower_generate_next_isr_branching+4557>:  fldt  
0x70(%rsp)
   0x75797901
<__shower_core_MOD_shower_generate_next_isr_branching+4561>:  fldt  
0x80(%rsp)
   0x75797908
<__shower_core_MOD_shower_generate_next_isr_branching+4568>:  ja
0x7579752a <__shower_core_MOD_shower_generate_next_isr_branching+3578>

That fucomi is the comparison of integral and final.  I have no idea what the
code is meant to do and in which occurence of this call + comparison do you
expect to see the return part (if I put a breakpoint on this spot, I see more
than hundred cases).
At least on the first one the final value integral_over_z_part_isr is called
with is one of the comparison operands,
final is 8.0709805577720652785753130409318601 and integral is
1.2830660500802092213986273722913488e-06
info float
  R7: Valid   0x40028122bc8264869727 +8.070980557772065279  
  R6: Valid   0x3febac35d05484382d81 +1.283066050080209221e-06  
=>R5: Valid   0x3febac35d05484382d81 +1.283066050080209221e-06  
  R4: Empty   0xc009d3234afd757eb870
  R3: Empty   0x3ffc9d2933f75a096595
  R2: Empty   0x4007bfa6d946f18e35f7
  R1: Empty   0xc009d32c3121bd4b4150
  R0: Empty   0x3ffc9d2933f75a096595
on the fucomi.
So, what values of integral or final do you expect the return on?

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #28 from Damian Rouson  ---
Below is a reduced version of attachment 38089 from the Comment 27.  gfortran
7.0.1 20170205 produces an ICE on whatever is the first line unless the
penultimate line is removed.

$ cat chester.f90 
  type var_tables
 real, pointer :: rvar(:)
  end type 
  type real_vars
 real r
  end type 
  type(var_tables) vtab_r
  type(real_vars),  target :: x(1)
  vtab_r%rvar => x%r ! deleting this pointer association eliminates the ICE
end 

$ gfortran chester.f90 
chester.f90:1:0:

   type var_tables

internal compiler error: Segmentation fault: 11

chester.f90:1:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

$ $ gfortran --version
GNU Fortran (MacPorts gcc7 7-20170205_0) 7.0.1 20170205 (experimental)

[Bug target/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
With -m96bit-long-double pr79514.c -mno-accumulate-outgoing-args it goes all
the way back to r95000 (still ICEs), but r9 doesn't ICE.
We get a pre_modify and perhaps that is what the backend doesn't like.

[Bug libgomp/79784] New: Synchronization overhead is thrashing on Aarch64

[cbz at baozis dot org]

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

Bug ID: 79784
   Summary: Synchronization overhead is thrashing on Aarch64
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbz at baozis dot org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I have recently been running several programs (caffe, mxnet, openblas, =
blis...) on aarch64.  And I found performance regression when libgomp (gcc
implementation of OpenMP) is used and OMP_NUM_THREADS is set to be >2. Almost
half of the execution time is consumed either in gomp_barrier_wait_end() or
gomp_team_barrier_wait_end(). Then I run EPCC OpenMP micro-benchmark suite to
get the overhead of synchronization mechanism of GOMP on Aarch64. And it looks
pretty bad. The PARALLEL overhead varies from ~1ms to ~2000ms.

I used linux perf to analyze hot spots of the program. And I find most of
execution time is taken in the loop of barrier waiting for other threads to
synchronize. In gomp_barrier_wait_end(), it is the following section:

 do
   do_wait ((int *) >generation, state);
 while (__atomic_load_n (>generation, MEMMODEL_ACQUIRE) == state);

I'm not quite sure whether it is a known issue on Aarch64. If so, is there any
way to fix it?

[Bug c++/79782] [7 Regression] ICE: tree check: expected tree_list, have void_type in emit_mem_initializers, at cp/init.c:1225

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-01
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with Jakub's revision r245802.