[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug c++/80272] g++ runs out of memory and crashes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog

--- Comment #1 from Richard Biener  ---
There's a duplicate for this somewhere.  The issue is the large constructor
being built.

Note GCC 4.9 is no longer maintained.

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

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Thanks for the fix!

[Bug tree-optimization/80275] [6/7 Regression] Poor (but valid) code generated by optimizer passing optimizer list to function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
  Known to work||5.4.1
   Keywords||missed-optimization
   Last reconfirmed||2017-04-03
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|Poor (but valid) code   |[6/7 Regression] Poor (but
   |generated by optimizer  |valid) code generated by
   |passing optimizer list to   |optimizer passing optimizer
   |function|list to function
   Target Milestone|--- |6.4

--- Comment #1 from Richard Biener  ---
Confirmed.  In GCC 5 cunrolli is able to compute number of iterations of the
loop(s) and unrolls them so we can optimize away the stuff.

niter issue.  trunk gets

Analyzing # of iterations of loop 1
  exit condition [(const int *) &D.15512 + 4, + , 4](no_overflow) != &MEM[(void
*)&D.15512 + 12B]
  bounds on difference of bases: -18446744073709551615 ... 18446744073709551611
Applying pattern match.pd:148, generic-match.c:7290
  result:
# of iterations ((unsigned long) &MEM[(void *)&D.15512 + 12B] - (unsigned
long) ((const int *) &D.15512 + 4)) /[ex] 4 & 4611686018427387903, bounded by
4611686018427387902
...
Loop 1 iterates at most -2 times.
Loop 1 likely iterates at most -2 times.

IL is quite similar.  So we fail to simplify &MEM[&D.15512 + 12B] - (unsigned
long) ((const int *) &D.15512 + 4)) for a start.  I would guess at the
associate
case in fold-const.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Closing then.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |5.5

[Bug ipa/80277] ipa-icf overlooking functions with identical assemble and semantics

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-03
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine, I'm planning to revisit the pass in next stage1. This provides
interesting set of test-cases ;)

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
 /* A + (-B) -> A - B */
 (simplify
  (plus:c (convert1? @0) (convert2? (negate @1)))
  /* Apply STRIP_NOPS on @0 and the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
   && tree_nop_conversion_p (type, TREE_TYPE (@1))
   && !TYPE_OVERFLOW_SANITIZED (type))
   (minus (convert @0) (convert @1

(gdb) p debug_generic_expr (captures[1])
(unsigned int) b
$9 = void
(gdb) p debug_generic_expr (captures[0])
c

so that results in c + (int)-(unsigned)b -> c - (int)(unsigned)b.  Similar
code was in tree-ssa-forwprop.c before but that didn't trigger for the testcase
because we first constant propagated.

> gcc-4.8 t.c -O2 -fdisable-tree-ccp1
> ./a.out
Aborted (core dumped)

so probably latent since quite some time.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
We need to keep the type of the negation, thus

 c + (int)-(unsigned)b  ->  (int)((unsigned) c - (unsigned) b)

 /* A + (-B) -> A - B */
 (simplify
  (plus:c (convert1? @0) (convert2? (negate @1)))
  /* Apply STRIP_NOPS on @0 and the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
   && tree_nop_conversion_p (type, TREE_TYPE (@1))
   && !TYPE_OVERFLOW_SANITIZED (type))
   (with { tree t1 = TREE_TYPE (@1); }
(convert (minus (convert:t1 @0) @1)

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> No, it's call by descriptor that doesn't work for ilp32, which breaks
> tasking.

I see, it's indeed totally untested in this configuration, although I don't
think there is any fundamental issue which cannot be solved.

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

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Richard Biener from comment #6)
> We need to keep the type of the negation, thus

If the addition was unsigned, you don't want to turn it into a signed
subtraction either.

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Another testcase:
typedef int V __attribute__((vector_size (4 * sizeof (int;

__attribute__((noinline, noclone)) V
foo (V x, V y)
{
  return x << y[0];
}

int
main ()
{
  V x = { 1, 2, 3, 4 };
  V y = { 5, 6, 7, 8 };
  V z = foo (x, y);
  V e = { 1 << 5, 2 << 5, 3 << 5, 4 << 5 };
  if (__builtin_memcmp (&z, &e, sizeof (V)))
__builtin_abort ();
  return 0;
}

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

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Hmm, with that associate: endlessly recurses for

(size_t) ivtmp.389_3136 + (size_t) (1 - (sizetype) "[abi:")

(I'm having a Deja-Vu on this).

[Bug tree-optimization/80275] [6/7 Regression] Poor (but valid) code generated by optimizer passing optimizer list to function

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
On the GCC 5 branch we go via

case MINUS_EXPR:
  /* Pointer simplifications for subtraction, simple reassociations. */
...
  /* PTR0 - (PTR1 p+ A) -> (PTR0 - PTR1) - A, assuming PTR0 - PTR1
 simplifies. */
  else if (TREE_CODE (arg1) == POINTER_PLUS_EXPR)
{
  tree arg10 = fold_convert_loc (loc, type,
 TREE_OPERAND (arg1, 0));
  tree arg11 = fold_convert_loc (loc, type,
 TREE_OPERAND (arg1, 1));
  tree tmp = fold_binary_loc (loc, MINUS_EXPR, type,
  fold_convert_loc (loc, type, arg0),
  arg10);
  if (tmp)
return fold_build2_loc (loc, MINUS_EXPR, type, tmp, arg11);

and then simplify &MEM[(void *)&D.15614 + 12B] - &D.15614 via
ptr_difference_const.

On trunk the former is no longer in place and we directly fall through to
associate:

We can improve ptr_difference_const to catch this case.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Marc Glisse from comment #7)
> (In reply to Richard Biener from comment #6)
> > We need to keep the type of the negation, thus
> 
> If the addition was unsigned, you don't want to turn it into a signed
> subtraction either.

Suggestion?  Apart from disabling the transform when the negate was unsigned
but the plus will be signed for the original pattern?  This set of patterns was
supposed to be safe regardless of overflow... (which they are unless we factor
in conversions...)

So maybe if TYPE_OVERFLOW_WRAPS of the plus and the negate doesn't agree use an
unsigned type throughout?

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yet another testcase, showing that we can generate very inefficient code:
typedef short V __attribute__((vector_size (8 * sizeof (short;

__attribute__((noinline, noclone)) V
foo (V x, V y)
{
  return x << y[0];
}

int
main ()
{
  V x = { 1, 2, 3, 4, 5, 6, 7, 8 };
  V y = { 5, 6, 7, 8, 9, 10, 11, 12 };
  V z = foo (x, y);
  V e = { 1 << 5, 2 << 5, 3 << 5, 4 << 5, 5 << 5, 6 << 5, 7 << 5, 8 << 5 };
  if (__builtin_memcmp (&z, &e, sizeof (V)))
__builtin_abort ();
  return 0;
}

vpextrw $0, %xmm1, %eax
cwtl
movl%eax, -12(%rsp)
vmovd   -12(%rsp), %xmm2
vpsllw  %xmm2, %xmm0, %xmm0

For SSE4.1+, we could as well emit vpmovsxwq for the sign-extension followed
immediately by vpsllw.  For say SSE2 at least for the unsigned int -> unsigned
long zero extension we could use pxor (to get 0) and punpck*.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
So

 /* A + (-B) -> A - B */
 (simplify
  (plus:c (convert1? @0) (convert2? (negate @1)))
  /* Apply STRIP_NOPS on @0 and the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
   && tree_nop_conversion_p (type, TREE_TYPE (@1))
   && !TYPE_OVERFLOW_SANITIZED (type))
   (with
{
 tree t1 = type;
 if (TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
   t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
}
(convert (minus (convert:t1 @0) (convert:t1 @1))

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

[frankhb1989 at gmail dot com]

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

frankhb1989 at gmail dot com changed:

   What|Removed |Added

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

--- Comment #2 from frankhb1989 at gmail dot com ---
Glad to see the clarification and the decision (though the author of N4510 told
me that libstdc++ did have some considerations on the feature).

And I realized it would also not even work for `vector`. I'm OK to also rule
such cases out of support in the standard library; however, I did not find the
rule in the standard. Now the question should better go to std-discussion, not
remains here. So closed.

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

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

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

--- Comment #11 from Andreas Schwab  ---
It appears that there is indeed some problem with unwinding.

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[krebbel at gcc dot gnu.org]

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

--- Comment #14 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Apr  3 10:57:41 2017
New Revision: 246645

URL: https://gcc.gnu.org/viewcvs?rev=246645&root=gcc&view=rev
Log:
Don't xfail on s390.

The attached patch removes the XFAIL in attr-alloc_size-11.c on
s390.  (PR 79356).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356

gcc/testsuite/ChangeLog:

2017-04-03  Dominik Vogt  

PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on s390.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c

[Bug tree-optimization/80275] [6 Regression] Poor (but valid) code generated by optimizer passing optimizer list to function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1
Summary|[6/7 Regression] Poor (but  |[6 Regression] Poor (but
   |valid) code generated by|valid) code generated by
   |optimizer passing optimizer |optimizer passing optimizer
   |list to function|list to function
  Known to fail||6.3.1

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/80275] [6 Regression] Poor (but valid) code generated by optimizer passing optimizer list to function

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Apr  3 12:22:22 2017
New Revision: 246648

URL: https://gcc.gnu.org/viewcvs?rev=246648&root=gcc&view=rev
Log:
2017-04-03  Richard Biener  

PR tree-optimization/80275
* fold-const.c (split_address_to_core_and_offset): Handle
POINTER_PLUS_EXPR.

* g++.dg/opt/pr80275.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr80275.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78734] [C++17] P0145R3: function arguments are indeterminately sequenced

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I'm not sure it's wrong.  In
 Jason says

In other news, I convinced the committee to drop function arguments
from the order of evaluation paper, so we don't have to worry about
that hit on PUSH_ARGS_REVERSED targets.

Also, looking at op_is_ordered, I see nothing re CALL_EXPRs.

[Bug c++/78734] [C++17] P0145R3: function arguments are indeterminately sequenced

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Never mind, I see what you mean now.

[Bug c++/80290] New: g++ uses unreasonable amount of memory compiling nested string maps

[andrew at aj dot id.au]

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

Bug ID: 80290
   Summary: g++ uses unreasonable amount of memory compiling
nested string maps
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at aj dot id.au
  Target Milestone: ---

Created attachment 41107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41107&action=edit
Source file demonstrating bad behaviour

g++ uses an unreasonable amount of memory (greater than 5GB) when compiling the
attached code. A source archive is attached, and the test can be run with
`make`. Testing suggests this issue occurs with x86_64 g++s 5.4 and 6.2 from
Ubuntu Yakkety, and both 6.3 and 7.0.1 built from source. The bug was
originally encountered under a Yocto/Poky build cross-compiling from x86_64 to
ARMv6 (targeting an ARM1176 core).

Alan Modra's tests indicate g++ 4.8 performs better than any of the previously
mentioned versions. Behaviour in clang 3.8 also appears reasonable.

GCCs built from source were built with a configure line derived from Ubuntu
Yakkety's g++ builds, with minor modifications to restrict the supported
languages and architectures, and to change prefixes.

Test case is built with `g++ -std=c++11 fru-gen.ii -o fru-gen.o`

$ ~/gcc/master/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/andrew/gcc/master/bin/g++
COLLECT_LTO_WRAPPER=/home/andrew/gcc/master/libexec/gcc/x86_64-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure -v --enable-languages=c,c++
--prefix=/home/andrew/gcc/master --enable-shared --enable-linker-build-id
--without-included-gettext --enable-threads=posix --enable-nls
--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-gtk-cairo
--with-arch-directory=amd64 --disable-werror --disable-multilib --with-abi=m64
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --enable-bootstrap
Thread model: posix
gcc version 7.0.1 20170401 (experimental) (GCC)

[Bug fortran/80291] New: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662

[snowfed at mail dot ru]

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

Bug ID: 80291
   Summary: internal compiler error: in gfc_conv_expr_descriptor,
at fortran/trans-array.c:6662
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: snowfed at mail dot ru
  Target Milestone: ---

Created attachment 41108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41108&action=edit
This small program reproduces the compiler bug.

Dear gfortran developers!


I stumbled upon this compiler bug which is quite easy to reproduce (source code
attached). Don't know if it's been fixed in future releases of the compiler
although I doubt it because it wouldn't be a common problem to occur.



Example (Ubuntu 16.04)

$ gfortran bug_gfortran.f90 -ggdb
bug_gfortran.f90:67:0:

 vertices = cell%get_vertex(pack([1,2,3,4], cell%get_mask([1,2,3,4])))
 1
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6662
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Fedor

[Bug fortran/80291] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/80291] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662

[snowfed at mail dot ru]

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

--- Comment #2 from snowfed  ---
Created attachment 41109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41109&action=edit
This small program reproduces the compiler bug (SIMPLIFIED).

This new test program is much more simple than the previous one. It's slightly
different though.

[Bug tree-optimization/80292] New: __m64 type-attribute may_alias ignored

[bernd.edlinger at hotmail dot de]

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

Bug ID: 80292
   Summary: __m64 type-attribute may_alias ignored
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

In the following program both may_alias attribute
on j, k and the may_alias type-attribute is ignored:

cat t1.c
#include 

__m64 j __attribute__((may_alias)), k __attribute__((may_alias));
long  *jj,*kk;

__m64 __attribute__((noinline, noclone))
test()
{
 j = k;
 *jj = *kk;
 return j;
}

int main()
{
  asm("":"=m"(j), "=m"(k), "=m"(jj), "=m"(kk));
  test();
}

gcc -O3 -S t1.c

compiler output:

test:
.LFB4953:
.cfi_startproc
movqkk(%rip), %rax
movqk(%rip), %xmm0
movq%xmm0, j(%rip)
movq(%rax), %rdx
movqjj(%rip), %rax
movq%rdx, (%rax)
ret
.cfi_endproc

but *kk may alias j, thus value in xmm0 is stale.

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #11 from Nathan Sidwell  ---
I'll take a look.

Before I forget, I noticed that the canonical type hasher gets given a bespoke
hash code by the type creator.  I think the aim is to avoid a generic hasher.
This leads to various interesting ways the hash is generated. The attribute
variant creator contains a generic hasher anyway. I have patches on the
c++-modules branch to canonicalize this hashing.

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

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Well, I've made a small tweak to the patch I have for PR78972, and I've got
what at a glance looks like optimal code (no spills).

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Mon Apr  3 16:15:00 2017
New Revision: 246652

URL: https://gcc.gnu.org/viewcvs?rev=246652&root=gcc&view=rev
Log:
PR target/80246
* gcc.target/powerpc/pr80246.c: Require hard_dfp.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr80246.c

[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Apr  3 16:30:58 2017
New Revision: 246653

URL: https://gcc.gnu.org/viewcvs?rev=246653&root=gcc&view=rev
Log:
PR libstdc++/79141
* include/bits/stl_pair.h (__nonesuch_no_braces): New.
(operator=(typename conditional<
__and_,
is_copy_assignable<_T2>>::value,
const pair&, const __nonesuch&>::type)): Change __nonesuch
to __nonesuch_no_braces.
(operator=(typename conditional<
__not_<__and_,
is_copy_assignable<_T2>>>::value,
const pair&, const __nonesuch&>::type)): Likewise.
(operator=(typename conditional<
__and_,
is_move_assignable<_T2>>::value,
pair&&, __nonesuch&&>::type)): Likewise.
* testsuite/20_util/pair/79141.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/79141.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
Fixed on trunk so far, backporting...

[Bug c++/80293] New: g++ 5.4 -> 6.1 regression: unnecessary code at -O2 (-O1 is fine)

[alex at weej dot com]

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

Bug ID: 80293
   Summary: g++ 5.4 -> 6.1 regression: unnecessary code at -O2
(-O1 is fine)
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex at weej dot com
  Target Milestone: ---

Created attachment 41110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41110&action=edit
repro.cpp

Apologies for the poor summary, I really can't think of a good way to describe
this.

I'm using a couple of functions to conduit through an `std::array`
representation of variable's memory (similar to type-punning through
`std::memcpy`), the compiler even in -O2 is emitting a lot of unnecessary
garbage.

---

// g++ repro.cpp -c -o repro.o -std=gnu++11 -O2 -save-temps

#include 
#include 
#include 
#include 

// Return a copy of the underlying memory of an arbitrary value.
template <
typename T,
typename = typename
std::enable_if::value>::type
>
auto getMem(
T const & value
) -> std::array {
auto ret = std::array{};
std::memcpy(ret.data(), &value, sizeof(T));
return ret;
}

template <
typename T,
typename = typename
std::enable_if::value>::type
>
auto fromMem(
std::array const & buf
) -> T {
auto ret = T{};
std::memcpy(&ret, buf.data(), sizeof(T));
return ret;
}

double foo1(std::uint64_t arg) {
return fromMem(getMem(arg));
}

double foo2(std::uint64_t arg) {
return *reinterpret_cast(&arg);
}

double foo3(std::uint64_t arg) {
double ret;
std::memcpy(&ret, &arg, sizeof(arg));
return ret;
}

---

In GCC 5.4 and older, as well as all versions of clang that I tested, all three
`foo*` functions emit identical and extremely short code. But in GCC 6.1 and
newer, `foo1` emits a load of extra instructions *only when -O2 or above is
used*.

---

Disassembly of section .text:

 <_Z4foo1m>:
   0:   48 83 ec 28 sub$0x28,%rsp
   4:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
   b:   00 00 
   d:   48 89 44 24 18  mov%rax,0x18(%rsp)
  12:   31 c0   xor%eax,%eax
  14:   89 f8   mov%edi,%eax
  16:   66 c1 e8 08 shr$0x8,%ax
  1a:   89 c1   mov%eax,%ecx
  1c:   89 f8   mov%edi,%eax
  1e:   c1 e8 18shr$0x18,%eax
  21:   89 c2   mov%eax,%edx
  23:   31 c0   xor%eax,%eax
  25:   40 88 f8mov%dil,%al
  28:   0f b6 d2movzbl %dl,%edx
  2b:   88 cc   mov%cl,%ah
  2d:   48 89 f9mov%rdi,%rcx
  30:   48 c1 e2 18 shl$0x18,%rdx
  34:   81 e1 00 00 ff 00   and$0xff,%ecx
  3a:   48 25 ff ff 00 ff   and$0xff00,%rax
  40:   48 09 c8or %rcx,%rax
  43:   48 b9 ff ff ff 00 ffmovabs $0x00ff,%rcx
  4a:   ff ff ff 
  4d:   48 21 c8and%rcx,%rax
  50:   48 b9 ff ff ff ff 00movabs $0xff00,%rcx
  57:   ff ff ff 
  5a:   48 09 d0or %rdx,%rax
  5d:   48 ba 00 00 00 00 ffmovabs $0xff,%rdx
  64:   00 00 00 
  67:   48 21 faand%rdi,%rdx
  6a:   48 21 c8and%rcx,%rax
  6d:   48 b9 ff ff ff ff ffmovabs $0x00ff,%rcx
  74:   00 ff ff 
  77:   48 09 d0or %rdx,%rax
  7a:   48 ba 00 00 00 00 00movabs $0xff00,%rdx
  81:   ff 00 00 
  84:   48 21 faand%rdi,%rdx
  87:   48 21 c8and%rcx,%rax
  8a:   48 b9 ff ff ff ff ffmovabs $0xff00,%rcx
  91:   ff 00 ff 
  94:   48 09 d0or %rdx,%rax
  97:   48 ba 00 00 00 00 00movabs $0xff,%rdx
  9e:   00 ff 00 
  a1:   48 21 faand%rdi,%rdx
  a4:   48 c1 ef 38 shr$0x38,%rdi
  a8:   48 21 c8and%rcx,%rax
  ab:   48 c1 e7 38 shl$0x38,%rdi
  af:   48 09 d0or %rdx,%rax
  b2:   48 89 famov%rdi,%rdx
  b5:   48 bf ff ff ff ff ffmovabs $0xff,%rdi
  bc:   ff ff 00 
  bf:   48 21 c7and%rax,%rdi
  c2:   48 09 d7or %rdx,%rdi
  c5:   48 8b 44 24 18  mov0x18(%rsp),%rax
  ca:   64 48 33 04 25 28 00xor%fs:0x28,%rax
  d1:   00 00 
  d3:   48 89 7c 24 08  mov%rdi,0x8(%rsp)
  d8:   f2 0f 10 44 24 08   movsd  0x8(%rsp),%xmm0
  de:   75 05   jnee5 <_Z4foo1m+0xe5>
  e0:   48 83 c4 28 add$0x28,%rsp
  e4:   c3  retq   
  e5:   e8 00 00 00 00  callq  ea <_Z4foo1m+0xea>
  ea:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

00f0 <_Z4foo2m>:
  f0:   48 89 7c 24 f8   

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 4
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4&action=edit
gcc7-pr80286.patch

Untested fix for the correctness part.  Now if the shift count comes from
memory or XMM register, it would be certainly faster and shorter to emit
v?pmovzxdq
before the shift (for SSE4.1+) or pxor; punpck* for SSE2, wonder how to do that
best though; first of all it would be nice to transform sign-extension followed
by shift using the sign-extended count into zero-extension followed by shift,
because if the shift count is negative, the insn will handle it as very large
count no matter if it is zero or sign extended.  The second question is if
zero_extendsidi2 etc. instruction should have a =v/vm alternative at least for
sse4 isa, but it already has some alternative with x and uses ? to make it not
likely to be used.

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
Author: bergner
Date: Mon Apr  3 17:10:57 2017
New Revision: 246654

URL: https://gcc.gnu.org/viewcvs?rev=246654&root=gcc&view=rev
Log:
PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Require hard_dfp, not
powerpc_vsx_ok.
(std, ld): Limit scan-assembler-times check to lp64.
(stwu, stw, lwz): Add scan-assembler-times check for ilp32.
* gcc.target/powerpc/dfp-builtin-2.c: Require hard_dfp, not
powerpc_vsx_ok.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c
trunk/gcc/testsuite/gcc.target/powerpc/dfp-builtin-2.c

[Bug c++/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-03
 CC||alan.lawrence.arm at gmail dot 
com
   ||, jakub at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|g++ 5.4 -> 6.1 regression:  |[6/7 Regression]
   |unnecessary code at -O2 |unnecessary code at -O2
   |(-O1 is fine)   |(-O1 is fine)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r227901, the complete scalarization is not really helpful here,
and unfortunately gimple-ssa-store-merging.c only merges now adjacent constant
stores, not adjacent loads followed by adjacent stores of the loaded values to
undo the damage.
Not sure what would be easier here, if some heuristics during SRA whether the
scalarization is helpful or not, or improving gimple-ssa-store-merging.c.

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
Author: bergner
Date: Mon Apr  3 17:40:53 2017
New Revision: 246659

URL: https://gcc.gnu.org/viewcvs?rev=246659&root=gcc&view=rev
Log:
Backport from mainline
2017-04-03  Peter Bergner  

PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Require hard_dfp, not
powerpc_vsx_ok.
(std, ld): Limit scan-assembler-times check to lp64.
(stwu, stw, lwz): Add scan-assembler-times check for ilp32.
* gcc.target/powerpc/dfp-builtin-2.c: Require hard_dfp, not
powerpc_vsx_ok.

PR target/80246
* gcc.target/powerpc/pr80246.c: Require hard_dfp.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80246.c

[Bug target/80246] Builtin's for POWER's dxex[q] and diex[q] use the wrong types

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
Author: bergner
Date: Mon Apr  3 18:06:52 2017
New Revision: 246660

URL: https://gcc.gnu.org/viewcvs?rev=246660&root=gcc&view=rev
Log:
Backport from mainline
2017-04-03  Peter Bergner  

PR target/80246
* gcc.target/powerpc/dfp-builtin-1.c: Require hard_dfp, not
powerpc_vsx_ok.
(std, ld): Limit scan-assembler-times check to lp64.
(stwu, stw, lwz): Add scan-assembler-times check for ilp32.
* gcc.target/powerpc/dfp-builtin-2.c: Require hard_dfp, not
powerpc_vsx_ok.

PR target/80246
* gcc.target/powerpc/pr80246.c: Require hard_dfp.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/dfp-builtin-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr80246.c

[Bug target/70321] [6/7/8 Regression] STV generates less optimized code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0
Summary|[6/7 Regression] STV|[6/7/8 Regression] STV
   |generates less optimized|generates less optimized
   |code|code

--- Comment #15 from Jakub Jelinek  ---
I think it is too late to change this for GCC7, we shall try to do that in
early stage1.

[Bug c++/80294] New: ICE with constexpr and inheritance

[maikel.nadolski at googlemail dot com]

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

Bug ID: 80294
   Summary: ICE with constexpr and inheritance
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maikel.nadolski at googlemail dot com
  Target Milestone: ---

The following code is accepted in clang but causes an ICE in gcc.

Here are more information including links to wandbox:
https://github.com/ericniebler/range-v3/issues/627
https://wandbox.org/permlink/GG89578DXNKbhqgj

--

#include "range/v3/utility/invoke.hpp"
#include "range/v3/utility/compressed_pair.hpp"

namespace foo
{
  template 
  struct Throws_if_false
  {
template 
constexpr void
operator()(P pred, A&& ...args) const
{
  if (!ranges::invoke(pred, std::forward(args)...)) {
throw Exception("Some Error occured");
  }
}
  };

  template >
  class GreaterThan: private ranges::box>
  {
using base = ranges::box>;
using base::get;
  public:
using base::base;

template 
  constexpr bool operator()(const T& x) const
  {
return get()(N, x);
  }
  };

  template >
  class Constrained: private ranges::compressed_pair
  {
  private:
using base_type = ranges::compressed_pair;
T value_;

constexpr T enforce_constraint(T value) const
{
  ranges::invoke(executor(), predicate(), value);
  assert(ranges::invoke(predicate(), value));
  return value;
}

  public:
constexpr Constrained(const T& value)
: Constrained(value, P(), E()) {}

template 
  constexpr Constrained(T_&& value, P predicate, E executor)
  : base_type{std::move(predicate), std::move(executor)}
  , value_{enforce_constraint(std::forward(value))}
  {}

constexpr const P& predicate() const& noexcept
{ return base_type::first(); }

constexpr const E& executor() const& noexcept
{ return base_type::second(); }
  };
}

int main()
{
  using Positive = foo::Constrained>;
  constexpr Positive n [[maybe_unused]] = 1;
}

--

Error message:

prog.cc: In function 'int main()':
prog.cc:69:43:   in constexpr expansion of 'foo::Constrained >(1)'
prog.cc:50:34:   in constexpr expansion of '((foo::Constrained >*)this)->foo::Constrained
>::Constrained(value, (foo::GreaterThan<0>(),
foo::GreaterThan<0>()), (foo::Throws_if_false<>(), foo::Throws_if_false<>()))'
prog.cc:55:34:   in constexpr expansion of '((foo::Constrained >*)this)->foo::Constrained
>::enforce_constraint(((int)std::forward(value)))'
prog.cc:43:21:   in constexpr expansion of
'ranges::v3::function_objects::invoke.ranges::v3::invoke_fn::operator()&, const foo::GreaterThan<0, std::less >&,
int&>(((const foo::Constrained
>*)this)->foo::Constrained >::executor(), ((const
foo::Constrained >*)this)->foo::Constrained >::predicate(), value)'
prog.cc:69:43: internal compiler error: Segmentation fault
   constexpr Positive n [[maybe_unused]] = 1;
   ^
0xad407f crash_signal
../../source/gcc/toplev.c:337
0x6d0099 reduced_constant_expression_p(tree_node*)
../../source/gcc/cp/constexpr.c:1709
0x6d00f1 reduced_constant_expression_p(tree_node*)
../../source/gcc/cp/constexpr.c:1719
0x6d0184 verify_constant
../../source/gcc/cp/constexpr.c:1742
0x6d5443 cxx_eval_indirect_ref
../../source/gcc/cp/constexpr.c:3161
0x6d5443 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4146
0x6d503a cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4067
0x6d3d91 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4209
0x6d1f7f cxx_bind_parameters_in_call
../../source/gcc/cp/constexpr.c:1265
0x6d1f7f cxx_eval_call_expression
../../source/gcc/cp/constexpr.c:1535
0x6d33fd cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4007
0x6d303a cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4124
0x6d303a cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4124
0x6d39e8 cxx_eval_statement_list
../../source/gcc/cp/constexpr.c:3740
0x6d39e8 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4468
0x6d28f6 cxx_eval_call_expression
../../source/gcc/cp/constexpr.c:1642
0x6d33fd cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4007
0x6d303a cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4124
0x6d303a cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:4124
0x6d39e8 cxx_eval_statement_list
../../source/gcc/cp/constexpr.c:3740
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++/80294] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-03
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Please attach a (compressed) preprocessed file. See: https://gcc.gnu.org/bugs/

[Bug middle-end/80295] New: ICE in __builtin_update_setjmp_buf expander

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

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

Bug ID: 80295
   Summary: ICE in __builtin_update_setjmp_buf expander
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

$ cat builtin-update-setjmp-buf.c
void f (void *b) { __builtin_update_setjmp_buf (b); }
$ gcc -mabi=ilp32 builtin-update-setjmp-buf.c
builtin-update-setjmp-buf.c: In function ‘f’:
builtin-update-setjmp-buf.c:1:20: internal compiler error: in plus_constant, at
explow.c:88
 void f (void *b) { __builtin_update_setjmp_buf (b); }
^~~
0x84a3f7 plus_constant(machine_mode, rtx_def*, long, bool)
../../gcc/gcc/explow.c:88
0x72edbb expand_builtin_update_setjmp_buf(rtx_def*)
../../gcc/gcc/builtins.c:1198
0x7367b3 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:6838
0x8638c3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10822
0x75b197 expand_expr
../../gcc/gcc/expr.h:276
0x75b197 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2658
0x75b197 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3571
0x75b197 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3737
0x76108f expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5744
0x762d87 execute
../../gcc/gcc/cfgexpand.c:6357

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #20 from Michael Meissner  ---
Trunk fixed on March 16th, gcc 6 branch on March 29th.

[Bug c++/80294] ICE with constexpr and inheritance

[maikel.nadolski at googlemail dot com]

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

--- Comment #2 from Maikel  ---
Created attachment 41112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41112&action=edit
Result of "g++ -save-temps ice.cpp -I third-party/range-v3/include/ -std=c++1z"

Used commands:

g++ -save-temps ice.cpp -I third-party/range-v3/include/ -std=c++1z
bzip2 ice.ii

[Bug tree-optimization/80292] __m64 type-attribute may_alias ignored

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
No, that looks like misunderstanding what may_alias attribute is.
It only does something for accesses through pointers, if the pointed type has
may_alias attribute.
That is not what you have in your test, the only pointers in there are long *
and the pointed type does not have may_alias attribute, so it works as if there
were no may_alias attributes at all.

[Bug fortran/80291] [5/6/7 Regression] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|internal compiler error: in |[5/6/7 Regression] internal
   |gfc_conv_expr_descriptor,   |compiler error: in
   |at  |gfc_conv_expr_descriptor,
   |fortran/trans-array.c:6662  |at
   ||fortran/trans-array.c:6662

--- Comment #3 from Jakub Jelinek  ---
r163260 rejected it:
Error: Incompatible ranks 0 and 1 in assignment at (1)
and r163270 already ICEs like everything later.
In that range only r163263 mentions gfc_conv_procedure_call where the ICE
occurred at that point.

[Bug c++/80294] [C++1z] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|ICE with constexpr and  |[C++1z] ICE with constexpr
   |inheritance |and inheritance

--- Comment #3 from Markus Trippelsdorf  ---
Thanks. Confirmed. Reducing.

[Bug tree-optimization/80292] __m64 type-attribute may_alias ignored

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Oh, well, thanks for clarifying.

[Bug c++/80296] New: Broken diagnostic 'unary_plus_expr' not supported by expression

[reichelt at gcc dot gnu.org]

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

Bug ID: 80296
   Summary: Broken diagnostic 'unary_plus_expr' not supported by
expression
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

GCC gives a broken daignostic for the following invalid code snippet
since GCC 4.7.0:

=
template  struct A {};

template  using B = A<+N...>;

B b;
=

bug.cc:5:6: error: type/value mismatch at argument 1 in template parameter list
for 'template using B = A<#'unary_plus_expr' not supported by
expression#...>'
 B b;
  ^
bug.cc:5:6: note:   expected a constant of type 'int', got 'int'

[Bug c++/80296] Broken diagnostic 'unary_plus_expr' not supported by expression

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-03
 Ever confirmed|0   |1

--- Comment #1 from Volker Reichelt  ---
I've got a patch.

[Bug c++/80296] Broken diagnostic 'unary_plus_expr' not supported by expression

[reichelt at gcc dot gnu.org]

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

--- Comment #2 from Volker Reichelt  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00111.html

[Bug c/35441] pretty-printer cannot handle some expressions

[reichelt at gcc dot gnu.org]

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

--- Comment #10 from Volker Reichelt  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00498.html

[Bug c++/80294] [C++1z] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Created attachment 41113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41113&action=edit
Somewhat reduced testcase

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[C++1z] ICE with constexpr  |[5/6/7 Regression] ICE with
   |and inheritance |constexpr and inheritance

--- Comment #5 from Markus Trippelsdorf  ---
5/6/7 all segfault with -std=c++14, 4.9 rejects the testcase.
Clang and icpc accept the code.

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Mon Apr  3 21:15:36 2017
New Revision: 246662

URL: https://gcc.gnu.org/viewcvs?rev=246662&root=gcc&view=rev
Log:
PR sanitizer/79993 - ICE with VLA initialization from string

PR c++/69487 - wrong VLA initialization from string
* init.c (finish_length_check): Split out from build_vec_init.
(build_vec_init): Handle STRING_CST.
* typeck2.c (split_nonconstant_init): Handle STRING_CST.
(digest_init_r): Don't give a STRING_CST VLA type.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr78201.C
trunk/gcc/testsuite/g++.dg/ext/vla17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Apr  3 21:15:36 2017
New Revision: 246662

URL: https://gcc.gnu.org/viewcvs?rev=246662&root=gcc&view=rev
Log:
PR sanitizer/79993 - ICE with VLA initialization from string

PR c++/69487 - wrong VLA initialization from string
* init.c (finish_length_check): Split out from build_vec_init.
(build_vec_init): Handle STRING_CST.
* typeck2.c (split_nonconstant_init): Handle STRING_CST.
(digest_init_r): Don't give a STRING_CST VLA type.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr78201.C
trunk/gcc/testsuite/g++.dg/ext/vla17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c

[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload

[ville at gcc dot gnu.org]

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

--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Apr  3 21:20:23 2017
New Revision: 246663

URL: https://gcc.gnu.org/viewcvs?rev=246663&root=gcc&view=rev
Log:
PR libstdc++/79141

Backport from mainline
2017-04-03  Ville Voutilainen  

PR libstdc++/79141
* include/bits/stl_pair.h (__nonesuch_no_braces): New.
(operator=(typename conditional<
__and_,
is_copy_assignable<_T2>>::value,
const pair&, const __nonesuch&>::type)): Change __nonesuch
to __nonesuch_no_braces.
(operator=(typename conditional<
__not_<__and_,
is_copy_assignable<_T2>>>::value,
const pair&, const __nonesuch&>::type)): Likewise.
(operator=(typename conditional<
__and_,
is_move_assignable<_T2>>::value,
pair&&, __nonesuch&&>::type)): Likewise.
* testsuite/20_util/pair/79141.cc: New.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/79141.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #6 from Ville Voutilainen  ---
Fixed.

[Bug regression/80297] New: Compiler time crash: type mismatch in binary expression

[babokin at gmail dot com]

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

Bug ID: 80297
   Summary: Compiler time crash: type mismatch in binary
expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Top of the tree gcc crashes when compiler the following test case. Gcc 4.8
works well.

> cat f.cpp
extern const unsigned long int var_14;
extern const long long int var_15;
void foo() {
  if (0)
int a = 809 >> -(var_14 & !var_15) + var_14 - (long long)(var_14 &
!var_15);
}


> g++ -std=c++11 -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:3:6: error: type mismatch in binary expression
 void foo() {
  ^~~
unsigned int

unsigned int

bool

_8 = _6 - _7;
f.cpp:3:6: internal compiler error: verify_gimple failed
0xdae8dd verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:4934
0xafe1cd gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:12500
0xafe534 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:12590
0x96e90f cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:657
0x9718f9 analyze_functions
../../gcc/gcc/cgraphunit.c:1118
0x9729b2 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/79947] [6 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Author: meissner
Date: Mon Apr  3 22:57:32 2017
New Revision: 246665

URL: https://gcc.gnu.org/viewcvs?rev=246665&root=gcc&view=rev
Log:
[gcc]
2017-04-03  Michael Meissner  

Back port from the trunk
2017-03-14  Michael Meissner  

PR target/79947
* config/rs6000/rs6000.h (TARGET_FRSQRTES): Add check for
-mpowerpc-gfxopt.

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

Back port from the trunk
2017-03-14  Michael Meissner  

PR target/79947
* gcc.target/powerpc/pr79947.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr79947.c
  - copied unchanged from r246661,
trunk/gcc/testsuite/gcc.target/powerpc/pr79947.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/79947] [6 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #7 from Michael Meissner  ---
Fixed in the trunk with subversion id 246150, and back ported to GCC 6 with
subversion id 246150.

[Bug target/80298] New: incompatible with -mno-sse

[roland at gnu dot org]

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

Bug ID: 80298
   Summary:  incompatible with -mno-sse
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at gnu dot org
  Target Milestone: ---

For any x86_64 target, try:

gcc -mno-sse -S -o - -xc <(echo '#include ')

It fails with various errors about SSE being disabled.

Many of the components of x86intrin.h make special efforts to ensure that they
can be compiled without the associated code-generation features being enabled
on the command line, but some of them fail to do so.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #24 from Segher Boessenkool  ---
Author: segher
Date: Tue Apr  4 00:10:02 2017
New Revision: 24

URL: https://gcc.gnu.org/viewcvs?rev=24&root=gcc&view=rev
Log:
simplify-rtx: Fix compare of comparisons (PR60818)

The function simplify_binary_operation_1 has code that does
/* Convert (compare (gt (flags) 0) (lt (flags) 0)) to (flags).  */
but this transformation is only valid if "flags" has the same machine
mode as the outer compare.  This fixes it.


PR rtl-optimization/60818
* simplify-rtx.c (simplify_binary_operation_1): Do not replace
a compare of comparisons with the thing compared if this results
in a different machine mode.

gcc/testsuite/
PR rtl-optimization/60818
* gcc.c-torture/compile/pr60818.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr60818.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80299] New: No ordinary unqualified lookup for operators from default template arguments

[kaballo86 at hotmail dot com]

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

Bug ID: 80299
   Summary: No ordinary unqualified lookup for operators from
default template arguments
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com
  Target Milestone: ---

The following snippet results in a compilation error:

struct X {};

namespace ns {
  bool operator==(X const&, X const&);

  template 
  void check() {} // note: substitution failed, no 'operator=='
}

int main() {
  ns::check(); // error: no match
}

Unqualified lookup is not being done for `operator==`.

This other snippet further shows that the kind of lookups being done depends on
the context; within a default template argument only argument dependent lookup
is being done, while within the function template body unqualified lookup finds
a better match.

struct B {};
struct X : B {};

void operator==(B const&, B const&);

namespace ns {
  bool operator==(X const&, X const&);

  template 
  void check(T v) {
decltype(T{} == T{}) rb = (v == v); // ok, bool
R rv = (v == v); // error, void
  }
}

int main() { 
  X x;
  ns::check(x);
}

Neither snippet fails if using function call syntax, `operator==(T{}, T{})`,
instead.

[Bug sanitizer/79993] [5/6 Regression] ICE in tree_to_uhwi, at tree.c:7344

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |tree_to_uhwi, at|tree_to_uhwi, at
   |tree.c:7344 |tree.c:7344

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-04
  Component|regression  |c++
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Compiler time crash: type   |[6/7 Regression] Compiler
   |mismatch in binary  |time crash: type mismatch
   |expression  |in binary expression
   Target Milestone|--- |6.4

--- Comment #1 from Jakub Jelinek  ---
Started with r229360.  Debugging.

[Bug debug/80300] New: One of the DW_TAG_formal_parameters is missing if the function has an inner function

[andrei.moscow at mail dot ru]

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

Bug ID: 80300
   Summary: One of the DW_TAG_formal_parameters is missing if the
function has an inner function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrei.moscow at mail dot ru
  Target Milestone: ---

Please see full bug description, discussion and steps to reproduce in the
Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1343988

The issue is that one of the function parameters is missing in the debug info
generated by GCC if function has an inner function.

Reproduced with GCC 4.9, 5.1.0, 5.3.1. Not tested with the latest GCC releases
yet.

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So far this looks like some tree sharing issue.
  *expr_p = gimple_boolify (*expr_p);
  if (!useless_type_conversion_p (org_type,
  TREE_TYPE (*expr_p)))
{
  *expr_p = fold_convert_loc (input_location,
  org_type, *expr_p);
  ret = GS_OK;
}
changes in place unsigned int type into bool and then wraps into cast to
unsigned int, but that now bool EQ_EXPR appears somewhere else too.

[Bug c/80301] New: Sub-optimal code with an array of structs offsetted inside a struct global on x86/x86_64 at -O2

[mednafen at sent dot com]

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

Bug ID: 80301
   Summary: Sub-optimal code with an array of structs offsetted
inside a struct global on x86/x86_64 at -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at sent dot com
  Target Milestone: ---

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

gcc -fno-asynchronous-unwind-tables -S -O2 -o test.s -c test.c

The displacement should be coded in the memory access instructions, but instead
a separate addition instruction is being generated.

Assembly is from 4.9.2, but the issue shows up on at least 5.3.0, 6.1.0, and a
relatively recent 7.0 build.
[...]
func:
movl%edi, %edx
addq$2, %rdx
movlm(,%rdx,8), %eax
cmpl%edi, %eax
je  .L2
movlm+4(,%rdx,8), %eax
.L2:
rep ret
[...]

[Bug c/80301] Sub-optimal code with an array of structs offsetted inside a struct global on x86/x86_64 at -O2

[mednafen at sent dot com]

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

--- Comment #1 from mednafen at sent dot com ---
Created attachment 41115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41115&action=edit
correct test code

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So, it is indeed that
/* Fold (A & ~B) - (A & B) into (A ^ B) - B.  */
(simplify
 (minus (bit_and:cs @0 (bit_not @1)) (bit_and:cs @0 @1))
  (minus (bit_xor @0 @1) @1))
pattern which uses @1 more than once.  For normal generic folding it wouldn't
be as big problem, because we unshare everything before gimplification.
Except that in this case it triggers late, already during gimplification:
#0  generic_simplify_87 (loc=2147483653, type=, op0=, 
op1=, captures=0x7fffb6b0) at
generic-match.c:3644
#1  0x016f22d1 in generic_simplify_MINUS_EXPR (loc=2147483653,
code=MINUS_EXPR, type=, 
op0=, op1=) at
generic-match.c:12824
#2  0x017406be in generic_simplify (loc=2147483653, code=MINUS_EXPR,
type=, 
op0=, op1=) at
generic-match.c:33944
#3  0x00d3a0ab in fold_binary_loc (loc=2147483653, code=MINUS_EXPR,
type=, 
op0=, op1=) at
../../gcc/fold-const.c:9157
#4  0x00d4a1d5 in fold_build2_stat_loc (loc=2147483653,
code=MINUS_EXPR, type=, 
op0=, op1=) at
../../gcc/fold-const.c:12285
#5  0x00bef110 in convert_to_integer_1 (type=, expr=, dofold=true)
at ../../gcc/convert.c:850
#6  0x00befb32 in convert_to_integer_maybe_fold (type=, expr=, 
dofold=true) at ../../gcc/convert.c:978
#7  0x00971dc6 in ocp_convert (type=, expr=, convtype=143, flags=17, 
complain=3) at ../../gcc/cp/cvt.c:812
#8  0x00974646 in convert (type=, expr=) at ../../gcc/cp/cvt.c:1590
#9  0x00adfc72 in c_gimplify_expr (expr_p=0x7fffefc51318,
pre_p=0x7fffd988, post_p=0x7fffd2a0)
at ../../gcc/c-family/c-gimplify.c:247
#10 0x00a4ae60 in cp_gimplify_expr (expr_p=0x7fffefc51318,
pre_p=0x7fffd988, post_p=0x7fffd2a0) at ../../gcc/cp/cp-gimplify.c:863
#11 0x00df0bdd in gimplify_expr (expr_p=0x7fffefc51318,
pre_p=0x7fffd988, post_p=0x7fffd2a0, 
gimple_test_f=0xdc4cde , fallback=1) at
../../gcc/gimplify.c:11145
#12 0x00dd5b63 in gimplify_modify_expr (expr_p=0x7fffd3b8,
pre_p=0x7fffd988, post_p=0x7fffd2a0, want_value=false)
at ../../gcc/gimplify.c:5465

So, either we need to unshare_expr in GENERIC every time some operand is used
multiple times, or have some flag we set after unsharing fn body and is set
until expansion in case GENERIC folding is used during gimple optimizations
(fold_build* etc.).
So far genmatch.c uses unshare_expr only for COND_EXPR or VEC_COND_EXPR
conditions.
Dunno how many patterns are affected:
(simplify
 (mult (abs@1 @0) @1)
 (mult @0 @0))

(for copysigns (COPYSIGN)
 (simplify
  (mult (copysigns@2 @0 @1) @2)
  (mult @0 @0)))

(simplify
 (bit_ior:c (bit_and:cs @0 (bit_not @2)) (bit_and:cs @1 @2))
 (bit_xor (bit_and (bit_xor @0 @1) @2) @0))

(for cmp (eq ge le)
 (simplify
  (cmp @0 @0)
  (if (! FLOAT_TYPE_P (TREE_TYPE (@0))
   || ! HONOR_NANS (@0))
   { constant_boolean_node (true, type); }
   (if (cmp != EQ_EXPR)
(eq @0 @0)

(for cmp (unlt ungt)
 (simplify
  (cmp @0 @0)
  (unordered @0 @0)))

   (if (! HONOR_NANS (@0))
{ constant_boolean_node (true, type); }
/* x <= +Inf is the same as x == x, i.e. !isnan(x).  */
(eq @0 @0)))

(simplify
 (minus (bit_and:cs @0 (bit_not @1)) (bit_and:cs @0 @1))
  (minus (bit_xor @0 @1) @1))
(simplify
 (minus (bit_and:s @0 INTEGER_CST@2) (bit_and:s @0 INTEGER_CST@1))
 (if (wi::bit_not (@2) == @1)
  (minus (bit_xor @0 @1) @1)))

(simplify
 (minus (bit_and:cs @0 @1) (bit_and:cs @0 (bit_not @1)))
  (minus @1 (bit_xor @0 @1)))

are what I found.  So shall genmatch.c watch for captures used multiple times
and in GENERIC emit unshare_expr for the second and further uses in there?

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

[bernd.edlinger at hotmail dot de]

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

--- Comment #99 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #95)
> >
> >this would fix the remaining fall-out.
> 
> Because that is not how it was designed or documented to work :)

So yes, it seems I misunderstood what may_alias should do.

It is defined on the type, however it has only meaning on the
pointers to that type, but not on the instances.

But I wanted to have an attribute to express in the tree
that instances and pointers to that type may alias anything.

How about adding a new type attribute, that does what I meant,
like always_alias for instance?