[Bug target/80250] ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

2017-04-02 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80250

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug target/80250] ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

2017-04-02 Thread uros at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80250

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Apr  2 18:19:02 2017
New Revision: 246637

URL: https://gcc.gnu.org/viewcvs?rev=246637=gcc=rev
Log:
PR target/80250
* config/i386/sse.md (mov): Remove insn pattern.
(mov): New expander.
(*mov_internal): New insn and split pattern.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug c++/80288] New: Using directive injects names into a wrong namespace

2017-04-02 Thread bugger_gcc at interia dot pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80288

Bug ID: 80288
   Summary: Using directive injects names into a wrong namespace
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugger_gcc at interia dot pl
  Target Milestone: ---

Consider the following code:

namespace N1 {
int i;
namespace N2 {
int i;
}
void f();
}

void N1::f()
{
using namespace N2;
i = 0;
}

GCC complains:
: In function 'void N1::f()':
:12:5: error: reference to 'i' is ambiguous

Apparently the using directive puts N2::i into N1, causing the conflict with
N1::i. However, N2::i should be put into the global namespace and hidden by
N1::i, thus there should be no ambiguity.

According to 7.3.4/2:
"[...] the names appear as if they were declared in the nearest enclosing
namespace which contains both the using-directive and the nominated namespace.
[Note: In this context, “contains” means “contains directly or indirectly”.
—end note]"

The nearest enclosing namespace of the using directive in this case is the
global namespace, not N1, because N1::f() is defined in the global namespace
and IIUC the fact that it's a member of N1 only affects name lookup within its
body, not the containment of the using directive.

This is how Clang interprets this too: https://godbolt.org/g/LMqveL

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #98 from Bernd Edlinger  ---
I realized that my latest patch triggers a pre-existing
bug in the libstdc++ testsuite => PR80287

So the following patch would be needed on top of it:

Index: gcc/cp/class.c
===
--- gcc/cp/class.c  (revision 246605)
+++ gcc/cp/class.c  (working copy)
@@ -2060,12 +2060,14 @@
 static void
 fixup_may_alias (tree klass)
 {
-  tree t;
+  tree t, v;

   for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
   for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
 }

 /* Early variant fixups: we apply attributes at the beginning of the class

[Bug c++/80287] C++ crash with __attribute((may_alias))

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287

--- Comment #1 from Bernd Edlinger  ---
good news is, I already have a patch:

Index: gcc/cp/class.c
===
--- gcc/cp/class.c  (revision 246605)
+++ gcc/cp/class.c  (working copy)
@@ -2060,12 +2060,14 @@
 static void
 fixup_may_alias (tree klass)
 {
-  tree t;
+  tree t, v;

   for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
   for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
-TYPE_REF_CAN_ALIAS_ALL (t) = true;
+for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+  TYPE_REF_CAN_ALIAS_ALL (v) = true;
 }

 /* Early variant fixups: we apply attributes at the beginning of the class

[Bug c++/80287] New: C++ crash with __attribute((may_alias))

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287

Bug ID: 80287
   Summary: C++ crash with __attribute((may_alias))
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

the following change produces a crash:

Index: libstdc++-v3/testsuite/20_util/any/assign/2.cc
===
--- libstdc++-v3/testsuite/20_util/any/assign/2.cc  (Revision 246605)
+++ libstdc++-v3/testsuite/20_util/any/assign/2.cc  (Arbeitskopie)
@@ -39,7 +39,7 @@
   X2() = default;
   X2(const X2&) { copied = true; }
   X2(X2&& x) noexcept { moved = true; }
-};
+}__attribute((may_alias));

 void test01()
 {


2.cc: In constructor 'X2::X2(X2&&)':
2.cc:92:1: error: type variant differs by TYPE_REF_CAN_ALIAS_ALL.
 }
 ^
 
unit size 
align 8 symtab 1838508144 alias set -1 canonical type 0x7fa46d95a348
attributes 
local bindings <(nil)>>>
fields 
used nonlocal decl_4 VOID file 2.cc line 38 col 1
align 1 context  result 
   > context 
full-name "struct X2"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  reference_to_this
 chain >
asm_written static unsigned type_6 DI
size  constant 64>
unit size  constant 8>
align 64 symtab 1838508384 alias set -1 canonical type 0x7fa46d95a5e8>
 
unit size 
align 8 symtab 1838508144 alias set -1 canonical type 0x7fa46d95a348
attributes 
local bindings <(nil)>>>
fields 
used nonlocal decl_4 VOID file 2.cc line 38 col 1
align 1 context  result 
   > context 
full-name "struct X2"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  reference_to_this
 chain >
readonly unsigned DI
size  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7fa46d95a690>
2.cc:92:1: internal compiler error: verify_type failed
0x103d385 verify_type(tree_node const*)
../../gcc-7-20170326/gcc/tree.c:14207
0x9ef7a4 gen_type_die_with_usage
../../gcc-7-20170326/gcc/dwarf2out.c:24478
0x9f0f26 gen_type_die
../../gcc-7-20170326/gcc/dwarf2out.c:24704
0x9ec5bb gen_decl_die
../../gcc-7-20170326/gcc/dwarf2out.c:25371
0x9e852e gen_subprogram_die
../../gcc-7-20170326/gcc/dwarf2out.c:22371
0x9ebff9 gen_decl_die
../../gcc-7-20170326/gcc/dwarf2out.c:25284
0x9ed03e dwarf2out_decl
../../gcc-7-20170326/gcc/dwarf2out.c:25793
0x9eda2e dwarf2out_abstract_function
../../gcc-7-20170326/gcc/dwarf2out.c:21656
0x9ec716 gen_decl_die
../../gcc-7-20170326/gcc/dwarf2out.c:25239
0x9ed03e dwarf2out_decl
../../gcc-7-20170326/gcc/dwarf2out.c:25793
0x9ed4f6 dwarf2out_early_global_decl
../../gcc-7-20170326/gcc/dwarf2out.c:25450
0x972f35 symbol_table::finalize_compilation_unit()
../../gcc-7-20170326/gcc/cgraphunit.c:2613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/80281] [5/6/7 Regression] Wrong constant folding

2017-04-02 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

2017-04-02 Thread programmist.linuks at mail dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238

--- Comment #6 from Mike  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Mike from comment #4)
> > (In reply to Richard Biener from comment #3)
> > > Can you try to build in a separate object directory instead?
> > And where to put the folder
> 
> https://gcc.gnu.org/wiki/FAQ#configure

Clear. I've already demolished my distribution and put the arch, and then I
downloaded the 6.3.0 binaries dully and everything was compiled with a bang. I
left for arch Linux and I'm not likely to return here.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #5)
> Try -fno-tree-ter .

Yes, this works, too.

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

2017-04-02 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ago at gentoo dot org

--- Comment #18 from Jakub Jelinek  ---
*** Bug 80282 has been marked as a duplicate of this bug. ***

[Bug c++/80282] undefined behavior in ios_base.h

2017-04-02 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80282

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Note, GCC 4.9.x is not supported anymore.

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

[Bug target/80286] [5/6/7 regressions] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

2017-04-02 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80286

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-02
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|[4.9/5/6/7 regressions] |[5/6/7 regressions] AVX2
   |AVX2 _mm_cvtsi128_si32  |_mm_cvtsi128_si32 doesn't
   |doesn't return a proper |return a proper 32bits int
   |32bits int  |
 Ever confirmed|0   |1

[Bug target/80286] [4.9/5/6/7 regressions] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

2017-04-02 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80286

--- Comment #2 from Jakub Jelinek  ---
I think this started with r198643, but the real bug isn't there, I'd say the
bug is in the shift patterns:
(define_insn "3"
  [(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
(any_lshift:VI2_AVX2_AVX512BW
  (match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
  (match_operand:SI 2 "nonmemory_operand" "xN,vN")))]
  "TARGET_SSE2 &&  && "
  "@
   p\t{%2, %0|%0, %2}
   vp\t{%2, %1, %0|%0, %1,
%2}"
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sseishft")
   (set (attr "length_immediate")
 (if_then_else (match_operand 2 "const_int_operand")
   (const_string "1")
   (const_string "0")))
   (set_attr "prefix_data16" "1,*")
   (set_attr "prefix" "orig,vex")
   (set_attr "mode" "")])

According to the AVX/AVX2 docs, the shift count is 64-bit, not 32-bit, so we
should probably use DImode instead of SImode for the 3rd operand.
I'll have a look on Monday.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-02 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end

--- Comment #5 from Andrew Pinski  ---
Try -fno-tree-ter .

[Bug tree-optimization/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-02 Thread glisse at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Marc Glisse  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #4 from Marc Glisse  ---
IMO this should be rtl-optimization or middle-end. The .optimized dump looks
fine to me. Expansion pulls many of the vec_duplicate to the beginning of the
loop (they were interleaved with the uses before), which increases live ranges
a lot, and nothing moves them back closer to their use. I don't know if doing
the reads early, as gcc chooses to do, can ever compensate for having to spill
on this testcase, since the memory access pattern seems quite cache-friendly.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #97 from Bernd Edlinger  ---
I thought that at that point t is the type of to the outer reference.

thus in this example:
cat t1.c
#include 

union xx {
  __m64 m;
  long long l;
};

union xx t;

__m64
test(long long x)
{
 t.l=x;
 return t.m;
}

gcc -S t1.c -fdump-rtl-final

I see this in t1.c.309r.final

(insn 7 6 8 2 (set (mem/j/c:DI (symbol_ref:DI ("t") [flags 0x2]  ) [1 t.l+0 S8 A64])
(reg:DI 0 ax [89])) "t1.c":13 81 {*movdi_internal}
 (nil))
(insn 8 7 11 2 (set (reg:V2SI 0 ax [orig:87 _4 ] [87])
(mem/j/c:V2SI (symbol_ref:DI ("t") [flags 0x2]  ) [1 t.m+0 S8 A64])) "t1.c":14 1100 {*movv2si_internal}
 (nil))

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #96 from Jakub Jelinek  ---
As Richard mentioned on IRC, e.g. the x86intrin.h __m[125]* types have
may_alias attributes and such a change would slow down code that puts those
into structures/unions.

[Bug c++/80286] [4.9/5/6/7 regressions] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

2017-04-02 Thread gregory.hainaut at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80286

--- Comment #1 from gregory hainaut  ---
Of course, I forgot to say that code was compiled with the following option
g++ -O2 -c -std=c++11 -mavx2

[Bug c++/80286] New: [4.9/5/6/7 regressions] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

2017-04-02 Thread gregory.hainaut at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80286

Bug ID: 80286
   Summary: [4.9/5/6/7 regressions] AVX2 _mm_cvtsi128_si32 doesn't
return a proper 32bits int
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gregory.hainaut at gmail dot com
  Target Milestone: ---

Dear GCC developers,

It seems that G++4.9 introduced an optimization to reduce stack/memory access
that broke _mm_cvtsi128_si32 behavior. 

Note: I tested the various GCC version with godbolt.org, I don't know if GCC 7
snapshot is recent or not.
Note2: maybe the issue belong to RTL/tree optimization but I have no clue.

Here a small test case
-8<---
#include 

__m256i m;

__m128i extract(__m128i minmax)
{
int shift = _mm_cvtsi128_si32(_mm256_castsi256_si128(m));
return _mm_srli_epi16(minmax, shift);
}
->8---
It will be compiled as 2 following asm intruction (on recent GCC). The issue is
that shift operand is 64 bits. So "shift" must be zero extended to 64 bits.
Typically Clang uses vpmovzxdq

 vmovdqa m(%rip), %ymm1
 vpsrlw  %xmm1, %xmm0, %xmm0

Best Regards,
Gregory

[Bug tree-optimization/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Apparently started with r217608.

The following hacky partial revert fixes the issue:

diff --git a/gcc/config/i386/avxintrin.h b/gcc/config/i386/avxintrin.h
index b5730f842a7c..c36ebc3dce70 100644
--- a/gcc/config/i386/avxintrin.h
+++ b/gcc/config/i386/avxintrin.h
@@ -145,7 +145,7 @@ _mm256_add_pd (__m256d __A, __m256d __B)
 extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
 _mm256_add_ps (__m256 __A, __m256 __B)
 {
-  return (__m256) ((__v8sf)__A + (__v8sf)__B);
+  return (__m256) __builtin_ia32_addps256 ((__v8sf)__A, (__v8sf)__B);
 }

 extern __inline __m256d __attribute__((__gnu_inline__, __always_inline__,
__artificial__))

[Bug c++/80284] Support of associative containers with incomplete element type

2017-04-02 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80284

--- Comment #1 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #0)
> Is it intended by design?

Is what by design, the memory leak?

This is undefined, and it's not documented as supported because we don't want
to support it (and we can't support it for the unordered containers).

I don't want to constrain our implementation to make this work, so I would
prefer it stays undefined and unsupported.

[Bug c++/80282] undefined behavior in ios_base.h

2017-04-02 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80282

--- Comment #1 from Jonathan Wakely  ---
This is PR 56158.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #95 from rguenther at suse dot de  ---
On April 2, 2017 10:54:28 AM GMT+02:00, "bernd.edlinger at hotmail dot de"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
>--- Comment #94 from Bernd Edlinger 
>---
>I always wondered why get_alias_set does not use
>the may_alias attribute like this:
>
>
>Index: alias.c
>===
>--- alias.c (revision 246605)
>+++ alias.c (working copy)
>@@ -928,6 +928,9 @@ get_alias_set (tree t)
>   return 0;
> }
>
>+  if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (t)))
>+return 0;
>+
>   /* See if the language has special handling for this type.  */
>   set = lang_hooks.get_alias_set (t);
>   if (set != -1)
>
>this would fix the remaining fall-out.

Because that is not how it was designed or documented to work :)

[Bug tree-optimization/80283] [5/6/7 Regression] bad SIMD register allocation

2017-04-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Markus Trippelsdorf  changed:

   What|Removed |Added

  Known to work||4.9.3
Summary|bad SIMD register   |[5/6/7 Regression] bad SIMD
   |allocation  |register allocation
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #2 from Markus Trippelsdorf  ---
4.9.3 generates fine code, so this is a regression.

[Bug tree-optimization/80283] bad SIMD register allocation

2017-04-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-02
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Online: https://godbolt.org/g/sHOxRL

[Bug c++/80284] New: Support of associative containers with incomplete element type

2017-04-02 Thread frankhb1989 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80284

Bug ID: 80284
   Summary: Support of associative containers with incomplete
element type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z
shows that "the feature" of N4510 (except the feature-test macro) has been
supported long ago from 3.0. It is not very clear whether "the feature" is
applicable on other containers not currently required by the proposed (and
accepted by the working draft) rules of N4510 yet.

I don't find the answer in the documentation, but I still tend to guess other
containers can work in libstdc++, for several reasons:

1. N4510 mentions associative/unordered containers as well. It just not ready
to require it for all implementations.
2. N4510 mentions boost.containers in parallel, which clearly states the
support of incomplete element types for other containers in its documentation.
3. They (from libstdc++) can actually work as expected (at least for naive
cases).

The real problem raises when I meet some not-so-naive cases. Test case:

#include 
#include 

using namespace std;

struct node
{
using container_t = map;
string name;
container_t container;

node(const string& n)
: container(), name(n)
{}
node(container_t&& con, const string& s)
: container(move(con)), name(s)
{}

void
swap(node& nd) noexcept
{
name.swap(nd.name);
container.swap(nd.container);
}
};

int main()
{
node n(node::container_t{{"a", node("a")}}, "A");
n.swap(n.container.begin()->second);
}

Despite the undefined behavior caused by incomplete template argument as per
the standard, it seems well-formed. However, it leaks. I've reproduced it on
GCC 5.3 + DrMemory on Windows/GCC 6.3.1 + valgrind on Linux. It can also
reproduced with clang++ instead of g++.

Is it intended by design?

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #94 from Bernd Edlinger  ---
I always wondered why get_alias_set does not use
the may_alias attribute like this:


Index: alias.c
===
--- alias.c (revision 246605)
+++ alias.c (working copy)
@@ -928,6 +928,9 @@ get_alias_set (tree t)
   return 0;
 }

+  if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (t)))
+return 0;
+
   /* See if the language has special handling for this type.  */
   set = lang_hooks.get_alias_set (t);
   if (set != -1)

this would fix the remaining fall-out.

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

2017-04-02 Thread sch...@linux-m68k.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002

--- Comment #9 from Andreas Schwab  ---
No, it's call by descriptor that doesn't work for ilp32, which breaks tasking.

[Bug tree-optimization/80283] New: bad SIMD register allocation

2017-04-02 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

Bug ID: 80283
   Summary: bad SIMD register allocation
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Michael S reported the following testcase on
http://www.realworldtech.com/forum/?threadid=166719=166719

markus@x4 tmp % cat vec_reg.c
#include 

#define MM_FMADD(a, b, c) _mm256_add_ps(_mm256_mul_ps((a), (b)), (c))

void foo(const float *A, const __m256 *B, __m256 *C, int kSteps) {
  __m256 acc00 = _mm256_setzero_ps();
  __m256 acc10 = _mm256_setzero_ps();
  __m256 acc01 = _mm256_setzero_ps();
  __m256 acc11 = _mm256_setzero_ps();
  __m256 acc02 = _mm256_setzero_ps();
  __m256 acc12 = _mm256_setzero_ps();
  __m256 acc03 = _mm256_setzero_ps();
  __m256 acc13 = _mm256_setzero_ps();
  __m256 acc04 = _mm256_setzero_ps();
  __m256 acc14 = _mm256_setzero_ps();

  for (int k = 0; k < kSteps; ++k) {
__m256 a, b0, b1;
b0 = B[0];
b1 = B[1];
B += 2;

a = _mm256_broadcast_ss([4 * 0 + 0]);
acc00 = MM_FMADD(a, b0, acc00);
acc10 = MM_FMADD(a, b1, acc10);

a = _mm256_broadcast_ss([4 * 1 + 0]);
acc01 = MM_FMADD(a, b0, acc01);
acc11 = MM_FMADD(a, b1, acc11);

a = _mm256_broadcast_ss([4 * 2 + 0]);
acc02 = MM_FMADD(a, b0, acc02);
acc12 = MM_FMADD(a, b1, acc12);

a = _mm256_broadcast_ss([4 * 3 + 0]);
acc03 = MM_FMADD(a, b0, acc03);
acc13 = MM_FMADD(a, b1, acc13);

a = _mm256_broadcast_ss([4 * 4 + 0]);
acc04 = MM_FMADD(a, b0, acc04);
acc14 = MM_FMADD(a, b1, acc14);

b0 = B[0];
b1 = B[1];
B += 2;

a = _mm256_broadcast_ss([4 * 0 + 1]);
acc00 = MM_FMADD(a, b0, acc00);
acc10 = MM_FMADD(a, b1, acc10);

a = _mm256_broadcast_ss([4 * 1 + 1]);
acc01 = MM_FMADD(a, b0, acc01);
acc11 = MM_FMADD(a, b1, acc11);

a = _mm256_broadcast_ss([4 * 2 + 1]);
acc02 = MM_FMADD(a, b0, acc02);
acc12 = MM_FMADD(a, b1, acc12);

a = _mm256_broadcast_ss([4 * 3 + 1]);
acc03 = MM_FMADD(a, b0, acc03);
acc13 = MM_FMADD(a, b1, acc13);

a = _mm256_broadcast_ss([4 * 4 + 1]);
acc04 = MM_FMADD(a, b0, acc04);
acc14 = MM_FMADD(a, b1, acc14);

b0 = B[0];
b1 = B[1];
B += 2;

a = _mm256_broadcast_ss([4 * 0 + 2]);
acc00 = MM_FMADD(a, b0, acc00);
acc10 = MM_FMADD(a, b1, acc10);

a = _mm256_broadcast_ss([4 * 1 + 2]);
acc01 = MM_FMADD(a, b0, acc01);
acc11 = MM_FMADD(a, b1, acc11);

a = _mm256_broadcast_ss([4 * 2 + 2]);
acc02 = MM_FMADD(a, b0, acc02);
acc12 = MM_FMADD(a, b1, acc12);

a = _mm256_broadcast_ss([4 * 3 + 2]);
acc03 = MM_FMADD(a, b0, acc03);
acc13 = MM_FMADD(a, b1, acc13);

a = _mm256_broadcast_ss([4 * 4 + 2]);
acc04 = MM_FMADD(a, b0, acc04);
acc14 = MM_FMADD(a, b1, acc14);

b0 = B[0];
b1 = B[1];
B += 2;

a = _mm256_broadcast_ss([4 * 0 + 3]);
acc00 = MM_FMADD(a, b0, acc00);
acc10 = MM_FMADD(a, b1, acc10);

a = _mm256_broadcast_ss([4 * 1 + 3]);
acc01 = MM_FMADD(a, b0, acc01);
acc11 = MM_FMADD(a, b1, acc11);

a = _mm256_broadcast_ss([4 * 2 + 3]);
acc02 = MM_FMADD(a, b0, acc02);
acc12 = MM_FMADD(a, b1, acc12);

a = _mm256_broadcast_ss([4 * 3 + 3]);
acc03 = MM_FMADD(a, b0, acc03);
acc13 = MM_FMADD(a, b1, acc13);

a = _mm256_broadcast_ss([4 * 4 + 3]);
acc04 = MM_FMADD(a, b0, acc04);
acc14 = MM_FMADD(a, b1, acc14);

A += 4 * 5;
  }

  C[0] = acc00;
  C[1] = acc10;
  C[2] = acc01;
  C[3] = acc11;
  C[4] = acc02;
  C[5] = acc12;
  C[6] = acc03;
  C[7] = acc13;
  C[8] = acc04;
  C[9] = acc14;
}

with -O3 -mavx the resulting code looks bad.
clang generated a much nicer tight loop without extra spills.

The issue looks related to PR79826.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #93 from Bernd Edlinger  ---
I tried a bit more with lto
and discovered that -flto -O2 removes all the
code from test() although it is marked noinline, noclone

To work around that, I added an asm statement
initializing all these mem-refs, now the test case
looks like that:

cat t.cc
#include 
//namespace std { enum class byte: unsigned char {}; };
struct t  {
  int x;
  //std::byte kk[1];
  unsigned char k;
} __attribute__((may_alias));

t t1;
t t2;
t *t3;
t *t4;

void __attribute__((noinline, noclone))
test()
{
  t1 = t2;
  *t4 = *t3;
}

int main()
{
  asm("":"=m"(t1), "=m"(t2), "=m"(t3), "=m"(t4));
  test();
}

This prevents -flto -O2 from removing the mem-refs.
But I discovered that the asm output arguments
don't use the alias-set zero:

g++ -flto -O2 -fdump-rtl-final t.cc

has this rtl from the asm stmt:

(insn:TI 5 2 6 2 (parallel [
(set (mem/c:DI (symbol_ref:DI ("t1") [flags 0x2]  ) [2 t1+0 S8 A64])
(asm_operands:DI ("") ("=m") 0 []
 []
 [] t.cc:23))
(set (mem/c:DI (symbol_ref:DI ("t2") [flags 0x2]  ) [2 t2+0 S8 A64])
(asm_operands:DI ("") ("=m") 1 []
 []
 [] t.cc:23))
(set (mem/f/c:DI (symbol_ref:DI ("t3") [flags 0x2]  ) [1 t3+0 S8 A64])
(asm_operands:DI ("") ("=m") 2 []
 []
 [] t.cc:23))
(set (mem/f/c:DI (symbol_ref:DI ("t4") [flags 0x2]  ) [1 t4+0 S8 A64])
(asm_operands:DI ("") ("=m") 3 []
 []
 [] t.cc:23))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "t.cc":23 -1
 (expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil


Again alias set 2 for t1, and t2.
This is identical also for non-lto build.

[Bug c++/80282] New: undefined behavior in ios_base.h

2017-04-02 Thread ago at gentoo dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80282

Bug ID: 80282
   Summary: undefined behavior in ios_base.h
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ago at gentoo dot org
  Target Milestone: ---

Hello All.

During the fuzz of podofo I hit this warning:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/g++-v4/bits/ios_base.h:96:24:
runtime error: load of value 4294967035, which is not a valid value for type
'std::_Ios_Fmtflags'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/g++-v4/bits/ios_base.h:76:67:
runtime error: load of value 4294967035, which is not a valid value for type
'std::_Ios_Fmtflags'

Now, since the podofo maintainers are a bit unresponsive, I don't know at all
if the bug resides in gcc or not.
However, podofo was compiled with clang.

Details:
- the exact version of GCC;
gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4)

-the system type;
Gentoo x86_64

-the options given when GCC was configured/built;
Configured with: /tmp/portage/sys-devel/gcc-4.9.4/work/gcc-4.9.4/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.4
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.4
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.4/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.4/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/g++-v4
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.4/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.9.4 p1.0, pie-0.6.4' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-vtable-verify --enable-libvtv --enable-lto --without-cloog
--enable-libsanitizer

-the complete command line that triggers the bug;
podofoimpose $CRAFTED_PDF output.pdf /tmp/plan

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #92 from Bernd Edlinger  ---
It is an interesting fact that

g++ -flto -fdump-rtl-final t.cc

has correct rtl:
(insn 7 6 8 2 (set (mem/c:DI (symbol_ref:DI ("t1") [flags 0x2]  ) [0 t1+0 S8 A64])
(reg:DI 0 ax [90])) "t.cc":17 81 {*movdi_internal}
 (nil))

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #91 from Bernd Edlinger  ---
I mean here is [2 t1+0 S8 A64] and 2 is the alias set info in
the MEM_REF, I have expected that to be 0.


(insn:TI 7 6 14 2 (set (mem/c:DI (symbol_ref:DI ("t1") [flags 0x2]  ) [2 t1+0 S8 A64])
(reg:DI 0 ax [orig:90 MEM[(const struct t & {ref-all})] ] [90]))
"t.cc":17 81 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 0 ax [orig:90 MEM[(const struct t &
{ref-all})] ] [90])
(nil)))

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

2017-04-02 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002

--- Comment #8 from Eric Botcazou  ---
> The ICE is gone, but gnat.dg/stack_check[12].adb fail execution test.

That gnat.dg/null_pointer_deref2.adb also fails would point to unwinding.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-04-02 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #90 from rguenther at suse dot de  ---
On April 2, 2017 2:09:07 AM GMT+02:00, "bernd.edlinger at hotmail dot de"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
>Bernd Edlinger  changed:
>
>   What|Removed |Added
>
>  Attachment #41101|0   |1
>is obsolete||
>
>--- Comment #89 from Bernd Edlinger 
>---
>Created attachment 41103
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41103=edit
>updated patch
>
>should work in principle with LTO,
>but there is still another bug
>somewhere which makes __attribute__((may_alias))
>and the std::byte handling fail in the end.
>
>consider this test example:
>
>cat t.cc
>#include 
>//namespace std { enum class byte: unsigned char {}; };
>struct t  {
>  int x;
>  //std::byte kk[1];
>  unsigned char k;
>} __attribute__((may_alias));
>
>t t1;
>t t2;
>t *t3;
>t *t4;
>
>void __attribute__((noinline, noclone))
>test()
>{
>  t1 = t2;

Can't spot the issue in the RTL you quote but may_alias does not apply to this
assignment.

>  *t4 = *t3;
>}
>
>int main()
>{
>  test();
>}
>
>g++ -std=c++17 -O2 -fdump-rtl-final t.cc
>
>t.cc.309r.final:
>(insn:TI 6 2 7 2 (set (reg:DI 0 ax [orig:90 MEM[(const struct t &
>{ref-all})] ] [90])
>  (mem/c:DI (symbol_ref:DI ("t2") [flags 0x2]  t2>) [0 MEM[(const struct t & {ref-all})]+0 S8 A64])) "t.cc":17 81
>{*movdi_internal}
> (expr_list:REG_EQUIV (mem/c:DI (symbol_ref:DI ("t2") [flags 0x2] 
>) [0 MEM[(const struct t & {ref-all})]+0
>S8
>A64])
>(nil)))
>(insn:TI 7 6 14 2 (set (mem/c:DI (symbol_ref:DI ("t1") [flags 0x2] 
>0x7f973b730240 t1>) [2 t1+0 S8 A64])
>(reg:DI 0 ax [orig:90 MEM[(const struct t & {ref-all})] ] [90]))
>"t.cc":17 81 {*movdi_internal}
> (expr_list:REG_DEAD (reg:DI 0 ax [orig:90 MEM[(const struct t &
>{ref-all})] ] [90])
>(nil)))
>(insn 14 7 10 2 (set (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87])
>(mem/f/c:DI (symbol_ref:DI ("t3") [flags 0x2]  t3>) [1 t3+0 S8 A64])) "t.cc":18 81 {*movdi_internal}
>(expr_list:REG_EQUIV (mem/f/c:DI (symbol_ref:DI ("t3") [flags 0x2] 
>) [1 t3+0 S8 A64])
>(nil)))
>(insn:TI 10 14 15 2 (set (reg:DI 1 dx [orig:91 MEM[(const struct t &
>{ref-all})t3.1_1] ] [91])
>(mem:DI (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87]) [0 MEM[(const struct t &
>{ref-all})t3.1_1]+0 S8 A32])) "t.cc":18 81 {*movdi_internal}
> (expr_list:REG_DEAD (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87])
>(nil)))
>(insn 15 10 11 2 (set (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88])
>(mem/f/c:DI (symbol_ref:DI ("t4") [flags 0x2]  t4>) [1 t4+0 S8 A64])) "t.cc":18 81 {*movdi_internal}
>(expr_list:REG_EQUIV (mem/f/c:DI (symbol_ref:DI ("t4") [flags 0x2] 
>) [1 t4+0 S8 A64])
>(nil)))
>(insn:TI 11 15 23 2 (set (mem:DI (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88])
>[0
>*t4.2_2+0 S8 A32])
> (reg:DI 1 dx [orig:91 MEM[(const struct t & {ref-all})t3.1_1] ] [91]))
>"t.cc":18 81 {*movdi_internal}
> (expr_list:REG_DEAD (reg:DI 1 dx [orig:91 MEM[(const struct t &
>{ref-all})t3.1_1] ] [91])
>(expr_list:REG_DEAD (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88])
>(nil
>
>
>
>I think the access to t1 uses alias set 2, and that is wrong.
>The other accesses are ok.