[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce:
$ ./xgcc -B ./ -S -g3 -O3 -std=c99 -march=native -mavx512 pr80377.c
xgcc: error: unrecognized command line option ‘-mavx512’; did you mean
‘-mavx512f’?
$ gcc -S -g3 -O3 -std=c99 -march=native -mavx512 pr80377.c
gcc: error: unrecognized command line option ‘-mavx512’; did you mean
‘-mavx512f’?
The first one is with current gcc trunk, the second one with Fedora
gcc-6.3.1-1.fc25.x86_64.

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Inline asm clobbering "esp" is of course invalid, what the compiler could do
with that?  The inline asm needs to have the same stack pointer on entry and
exit, for anything more magic than that you need to use separate asm functions,
you can't have it inline.
That said, if there is ICE, we should error out on that instead.  Can't
reproduce myself on x86_64-liux, because the source is too djgpp specific.

[Bug tree-optimization/80374] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2384

[sylvestre at debian dot org]

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

Sylvestre Ledru  changed:

   What|Removed |Added

 CC||sylvestre at debian dot org

--- Comment #1 from Sylvestre Ledru  ---
FWIW, this is breaking one of the unit test of Firefox.

[Bug middle-end/80375] [5/6/7 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Dup of PR79788 ?  I'll have a look in any case.

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
But that makes this warning extremely hard to use.  Is it really useful for
-Wall in that case?

I came across this with a real-world use-case in the LibreOffice code base,
where some code deliberately uses snprintf to produce a fixed-size prefix, see
 "WaE: ‘%lu’ directive output may be
truncated".  (And older builds of GCC towards GCC 7 did not emit that unhelpful
warning with -Wall => -Wformat-truncation=1, but would only have emitted it
with an explicit -Wformat-truncation=2.)

Addressing false positives for this warning thus becomes an unpleasant
whack-a-mole (given different builds of the code are done with different
optimization switches), unpleasant enough so that we'll likely have to use
-Wall -Wformat-truncation=0 for LibreOffice.  Which is unfortunate, given that
casting-to-void would be a well-understood and well-accepted way to silence
false positives (but one hard to implement in GCC, if I understand you
correctly).

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-10
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||5.4.0, 6.3.0
Summary|ICE (internal compiler  |[7 Regression] ICE when
   |error) when using   |using structured bindings
   |structured bindings and |and nested generic lambdas
   |nested generic lambdas  |(tsubst_decomp_names)
   |(tsubst_decomp_names)   |
 Ever confirmed|0   |1
  Known to fail||7.0

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

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Apr 10 07:29:29 2017
New Revision: 246799

URL: https://gcc.gnu.org/viewcvs?rev=246799&root=gcc&view=rev
Log:
Evaluate a SAVE_EXPR before an UBSAN check (PR sanitizer/80350).

2017-04-10  Martin Liska  

PR sanitizer/80350
* c-ubsan.c (ubsan_instrument_shift): Evaluate RHS before
doing an UBSAN check.
2017-04-10  Martin Liska  

PR sanitizer/80350
* c-c++-common/ubsan/pr80350.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80350.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ubsan.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0.1
  Known to fail|7.0.1   |

--- Comment #5 from Martin Liška  ---
Fixed on trunk, queued for active branches.

[Bug c++/80380] New: misleading behavior with designated initializers for std::vector

[ethan at atdllc dot com]

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

Bug ID: 80380
   Summary: misleading behavior with designated initializers for
std::vector
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ethan at atdllc dot com
  Target Milestone: ---

Created attachment 41164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41164&action=edit
short example (not pre-processed)

Designated initializers are silently ignored when used in a initializer list
for a std::vector.

const std::vectorstrings = {
[ 0] = "zero",
[ 1] = "one",
[20] = "twenty",
};

This compiles silently, and results in a vector with three elements.

Using a std::array does result in an error (error: ‘[0] =’ used in a GNU-style
...), as does initializing an array of char * (sorry, unimplemented:
non-trivial designated initializers not supported).

If someone really wants a preprocessed .ii file, I can add one tuesday.

[Bug target/80324] _mm512_reduce_xxx type instrinsics are missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Implemented on the trunk, not planning to backport.

[Bug target/80325] _mm512_undefined intrinsic missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Implemented on the trunk, not planning to backport.

[Bug target/80323] _mm512_int2mask and _mm512_mask2int intrinsics are missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Implemented on the trunk, not planning to backport.

[Bug target/80322] convert intrinsics missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Implemented on the trunk, not planning to backport.

[Bug target/80327] _mm512_abs_ps intrinsic missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Implemented on the trunk, not planning to backport.

Author: jakub
Date: Fri Apr  7 19:22:00 2017
New Revision: 246774

URL: https://gcc.gnu.org/viewcvs?rev=246774&root=gcc&view=rev
Log:
PR target/80322
PR target/80323
PR target/80325
PR target/80326
* config/i386/avxintrin.h (_mm256_cvtsd_f64, _mm256_cvtss_f32): New
intrinsics.
* config/i386/avx512fintrin.h (_mm512_int2mask, _mm512_mask2int,
_mm512_abs_ps, _mm512_mask_abs_ps, _mm512_abs_pd, _mm512_mask_abs_pd,
_mm512_cvtsd_f64, _mm512_cvtss_f32): Likewise.

* gcc.target/i386/avx512f-undefined-1.c: New test.
* gcc.target/i386/avx512f-cvtsd-1.c: New test.
* gcc.target/i386/avx-cvtsd-1.c: New test.
* gcc.target/i386/avx512f-cvtss-1.c: New test.
* gcc.target/i386/avx512f-abspd-1.c: New test.
* gcc.target/i386/avx-cvtss-1.c: New test.
* gcc.target/i386/avx512f-absps-1.c: New test.
* gcc.target/i386/avx512f-int2mask-1.c: New test.
* gcc.target/i386/avx512f-mask2int-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx-cvtsd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx-cvtss-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-absps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtsd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtss-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-int2mask-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-mask2int-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-undefined-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512fintrin.h
trunk/gcc/config/i386/avxintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80304] [7 Regression] Wrong result with do concurrent

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Chinoune  ---
Created attachment 41163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41163&action=edit
the test program in c

This is an equivalent program written in c.

--- Comment #23 from Richard Biener  ---
The issue is that safelen (and IVDEP, as that uses safelen) is quite aggressive
and does not only apply to what is "memory" in the language specific sense but
also to what ends up as memory to the middle-end.  In this case dependencies
of the not inlined add2 calls which get i and j by reference are not accounted
for which makes i and j suitable to store-motion.

Now all would be fine but the call arguments are not updated by store-motion.

So using IVDEP on loops with calls with reference passing is dangerous.

There's still one bug in LIM, namely it fails to recurse to handle
UNANALYZABLE_MEM_ID for safelen.  The following testcase fixes the
last testcase.

Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 246797)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -2145,9 +2145,21 @@ ref_indep_loop_p_1 (int safelen, struct
  fprintf (dump_file, "\n");
}

+  /* We need to recurse to properly handle UNANALYZABLE_MEM_ID.  */
+  struct loop *inner = loop->inner;
+  while (inner)
+   {
+ if (!ref_indep_loop_p_1 (safelen, inner, ref, stored_p, ref_loop))
+   {
+ indep_p = false;
+ break;
+   }
+ inner = inner->next;
+   }
+
   /* Avoid caching here as safelen depends on context and refs
  are shared between different contexts.  */
-  return true;
+  return indep_p;
 }
   else
 {

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
template  struct tuple_size;
template  struct tuple_element;
template  struct tuple {};
template  struct tuple_size> { static constexpr int
value = 1; };
template  struct tuple_element<0, tuple> {
typedef T type; };
template  void get (tuple);
int
main ()
{
  [](auto) { [](tuple b) { auto [c] = b; }; }(0);
}

[Bug middle-end/80362] [5/6/7 Regression] gcc miscompiles arithmetic with signed char

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
10205 /* Convert -A / -B to A / B when the type is signed and overflow
is
10206undefined.  */
10207 if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
10208 && TREE_CODE (arg0) == NEGATE_EXPR
10209 && negate_expr_p (op1))
10210   {

where op1 is 3.  We're folding (signed char) -(unsigned char) var_1 / 3 and
arg0 is - (unsigned char) var_1 but _unsigned_.

Trivial fix:

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 246797)
+++ gcc/fold-const.c(working copy)
@@ -10205,7 +10205,7 @@ fold_binary_loc (location_t loc,
   /* Convert -A / -B to A / B when the type is signed and overflow is
 undefined.  */
   if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
- && TREE_CODE (arg0) == NEGATE_EXPR
+ && TREE_CODE (op0) == NEGATE_EXPR
  && negate_expr_p (op1))
{
  if (INTEGRAL_TYPE_P (type))

[Bug tree-optimization/80344] [7 Regression] -Wuninitialized triggering on a ctor on ARM

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 10 08:58:02 2017
New Revision: 246800

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

PR middle-end/80344
* gimplify.c (is_gimple_mem_rhs_or_call): Allow CLOBBERs.

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

[Bug tree-optimization/80344] [7 Regression] -Wuninitialized triggering on a ctor on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug c++/80381] New: AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[m...@sven-woop.de]

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

Bug ID: 80381
   Summary: AVX512: -O3, _mm512_srai_epi32, the last argument must
be an 8-bit immediate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

I again reduced the issue we ran into, this time I have a reproducer that fails
when compiling with -O3.

Code:
-

#include 

#define __forceinline inline __attribute__((always_inline))

struct vint16
{
  __forceinline vint16(const int i) 
: v(_mm512_set1_epi32(i)) {}

  __forceinline vint16(const __m512i& t) 
: v(t) {}

  friend __forceinline const vint16 operator >>( const vint16& a, const int n )
{ 
return _mm512_srai_epi32(a.v, n); 
  }

  __m512i v; 
};

vint16 test16(int shift)
{
  const vint16 blocks_add = shift;
  return blocks_add >> shift;
}

Command line:
--

g++ -mavx512f -mavx512dq -mavx512cd -mavx512bw -mavx512vl -mf16c -mavx2 -mfma
-mlzcnt -mbmi -mbmi2 -O3 test.cpp -c -o test.o

Output:
---

/home/swoop/projects/gcc/latest/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx512fintrin.h:
In function \u2018vint16 test16(int)\u2019:
/home/swoop/projects/gcc/latest/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx512fintrin.h:1318:50:
error: the last argument must be an 8-bit immediate
   return (__m512i) __builtin_ia32_psradi512_mask ((__v16si) __A, __B,
~~^~~~
 (__v16si)
 ~ 
 _mm512_undefined_epi32 (),
 ~~
 (__mmask16) -1);

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Guess at least get should return int or int & rather than void:

template  struct tuple_size;
template  struct tuple_element;
template  struct tuple {};
template  struct tuple_size> { static constexpr int
value = 1; };
template  struct tuple_element<0, tuple> {
typedef T type; };
template  int get (tuple);
int
main ()
{
  [](auto) { [](tuple b) { auto [c] = b; }; }(0);
}

[Bug c++/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Did someone check the places pointed by -Wconversion -Wsystem-headers? Some are
clearly false positive, but some seem suspicious (at least with an older
snapshot, maybe they have been fixed already).

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[vittorio.romeo at outlook dot com]

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

--- Comment #4 from Vittorio Romeo  ---
Even shorter:


template  struct tuple_size { static constexpr int value = 1; };
template  struct tuple_element { typedef int type; };
template  struct tuple {};
template  int get(T);

int
main ()
{
  [](auto) { [](tuple b) { auto [c] = b; }; }(0);
}

[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[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

--- Comment #12 from Nathan Sidwell  ---
Author: nathan
Date: Mon Apr 10 11:25:44 2017
New Revision: 246802

URL: https://gcc.gnu.org/viewcvs?rev=246802&root=gcc&view=rev
Log:
PR target/79905
* config/rs6000/rs6000.c (rs6000_vector_type): New.
(rs6000_init_builtins): Use it.

PR target/79905
* g++.dg/torture/pr79905.C: New.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr79905.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80304] [7 Regression] Wrong result with do concurrent

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #25 from Richard Biener  ---
Fixed. (hopefully)

[Bug tree-optimization/80304] [7 Regression] Wrong result with do concurrent

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 10 11:27:05 2017
New Revision: 246803

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

PR tree-optimization/80304
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Also recurse
for safelen.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80304.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Nathan Sidwell  ---
patch applied

[Bug gcov-profile/80224] gcov -i crashes with two arguments

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Apr 10 11:37:14 2017
New Revision: 246804

URL: https://gcc.gnu.org/viewcvs?rev=246804&root=gcc&view=rev
Log:
Support multiple files w/ -i option in gcov (PR gcov-profile/80224).

2017-04-10  Martin Liska  

PR gcov-profile/80224
* gcov.c (print_usage): Fix usage string.
(get_gcov_intermediate_filename): Remove.
(output_gcov_file): Use both for normal and intermediate format.
(generate_results): Do not initialize special file for
intermediate format.

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

[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

   Target Milestone|--- |8.0

[Bug gcov-profile/80224] gcov -i crashes with two arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0
  Known to fail|7.0 |

--- Comment #3 from Martin Liška  ---
Fixed on trunk, queued for backport to active branches.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #24 from Jerry DeLisle  ---
[...]
> Can you try this patch. From what I read there can be issues with char pointer
> sizes between these architectures.
>
> diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
> index 1e56b5de..daa741b4 100644
> --- a/libgfortran/io/transfer.c
> +++ b/libgfortran/io/transfer.c
> @@ -272,7 +272,7 @@ read_sf_internal (st_parameter_dt *dtp, int * length)
>return NULL;
>  }
>
> -  if (base && *base == 0)
> +  if (base && *base == '\0')
>  {
>generate_error (&dtp->common, LIBERROR_EOR, NULL);
>return NULL;

Doesn't make any difference.

Btw., I happened to notice that this "int * length" (and many more
instances throughout the file and probably all of libgfortran) is
in violation of the GNU Coding Standard: this should be "int *length"
instead.

Rainer

[Bug middle-end/80375] [5/6/7 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
You really don't need -ftrapv to get ICEs with these too high precision
expressions, e.g.
long long
foo (long long x, long long y)
{
  if (y > 1234567891234567891234567891234567812 / x)
return x;
  return 0;
}
ICEs too, again since as far as I can check.
So I really don't believe the "since 5.1" part here.

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

[jakub at gcc dot gnu.org]

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

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

Untested patch that caps the widest literal type at long long on ILP32 targets.

[Bug middle-end/80375] [5/6/7 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Patch attached to the other PR.  Note this is an ABI change, basically undoing
the ABI change for 32-bit targets made by
http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00031.html
(at that point the ABI was dependent on the host, now as we have 64-bit hwint
it is always there), but one gets pedwarn each time they use this, so hopefully
shouldn't affect much code.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Please submit a full bug report, with preprocessed source if appropriate.

[Bug target/80382] New: ICE with error: unrecognizable insn

[mpolacek at gcc dot gnu.org]

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

Bug ID: 80382
   Summary: ICE with error: unrecognizable insn
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This testcase (which took ~5 days of reducing) ICEs with -O3 -std=c++11
-mtune=power8 -mcpu=power8 -mno-lra:

test.C: In constructor ‘sbis::rpc::ProcessPool::ProcessPool(const String&,
sbis::rpc::ProcessPoolType, sbis::EventLoopService*,
sbis::EventReactionService*, const String&)’:
test.C:195:37: error: unrecognizable insn:
   mSemaphore(U(G()), edCREATE) {}
 ^
(insn 16 15 17 2 (set (reg:PTI 169)
(unspec:PTI [
(mem/v:TI (plus:DI (reg/f:DI 160 [ this ])
(const_int 8 [0x8])) [-1  S16 A128])
] UNSPEC_LSQ)) "test.C":47 -1
 (nil))
test.C:195:37: internal compiler error: in extract_insn, at recog.c:2311
0xcca398 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marek/src/gcc/gcc/rtl-error.c:108
0xcca3c9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marek/src/gcc/gcc/rtl-error.c:116
0xc9bcf1 extract_insn(rtx_insn*)
/home/marek/src/gcc/gcc/recog.c:2311
0xa689f3 instantiate_virtual_regs_in_insn
/home/marek/src/gcc/gcc/function.c:1589
0xa689f3 instantiate_virtual_regs
/home/marek/src/gcc/gcc/function.c:1957
0xa689f3 execute
/home/marek/src/gcc/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

namespace std {
template  class allocator;
template  struct char_traits;
}
typedef int size_t;
namespace std {
template  class basic_string {};
}

namespace mpl_ {}
namespace boost {
namespace mpl {
using namespace mpl_;
}
}
namespace mpl_ {
struct void_;
template  struct bool_;
typedef bool_ false_;
template  struct bool_ { static const bool value = C_; };
}
namespace boost {
namespace mpl {
template  struct if_c;
template  struct if_c {
  typedef T2 type;
};
template  struct is_not_void_ : false_ {};
}
}
namespace {
typedef std::basic_string,
  std::allocator>
String;
}

namespace mpl_ {
template  struct size_t { static const ::size_t value = N; };
}
namespace std {
typedef enum { memory_order_relaxed } memory_order;
template  struct atomic {
  _Tp _M_i;
  atomic(_Tp) {}
  _Tp load(memory_order _m) {
_Tp tmp;
__atomic_load(&_M_i, &tmp, _m);
  }
};
}

namespace boost {
namespace {
namespace detail {
using std::atomic;
using std::memory_order_relaxed;
}
using detail::atomic;
using detail::memory_order_relaxed;
}
namespace parameter {
struct void_;
template  struct optional;
template  struct parameters { template  struct bind; };
template  struct binding;
}
namespace lockfree {
namespace tag {
struct fixed_sized;
struct capacity;
}
namespace detail {
template  struct has_arg {
  typedef parameter::binding type;
  static const bool value = mpl::is_not_void_::value;
};
template  struct extract_capacity {
  static const bool has_capacity = has_arg::value;
  typedef typename mpl::if_c::type,
 mpl::size_t<0>>::type capacity_t;
  static const size_t capacity = capacity_t::value;
};
template  struct extract_allocator;
template 
struct extract_fixed_sized {
  static const bool has_fixed_sized =
  has_arg::value;
  typedef
  typename mpl::if_c::type,
 mpl::bool_>::type type;
  static const bool value = type::value;
};
template  class tagged_ptr {
  typedef size_t tag_t;
  T *ptr;
  tag_t tag;
};
template  class freelist_stack {
public:
  typedef tagged_ptr tagged_node_handle;
  template  freelist_stack(Allocator);
};
template  struct compiletime_sized_freelist_storage;
template  struct runtime_sized_freelist_storage;
template  class fixed_size_freelist;
template 
struct select_freelist {
  typedef mpl::if_c,
runtime_sized_freelist_storage>
  fixed_sized_storage_type;
  typedef typename mpl::if_c,
 freelist_stack>::type type;
};
typedef parameter::parameters>
queue_signature;
}
template  class queue {
  typedef detail::queue_signature::bind<> bound_args;
  static const bool has_capacity =
  detail::extract_capacity::has_capacity;
  static const size_t capacity =
detail::extract_capacity::capacity;
  static const bool fixed_sized =
  detail::extract_fixed_sized::value;
  static const bool compile_time_sized = has_capacity;
  struct node;
  typedef detail::extract_allocator node_allocator;
  typedef
  typename detail::select_freelist::type pool_t;
  typedef typename pool_t::tagged_node_handle tagged_node_handle;
  st

[Bug target/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This is another user error.
_mm512_srai_epi32 second argument must be a constant integer literal, n is not
a constant integer literal, nor is there any chance that even with
optimizations you get one, you pass a function argument to that.

So, if you want to pass sometimes a variable, sometimes a constant, use
_mm512_sra_epi32(a.v, _mm_set_epi64x(0, n))
instead of
_mm512_srai_epi32(a.v, n);
or perhaps
__builtin_constant_p (n) ? _mm512_srai_epi32(a.v, n) : _mm512_sra_epi32(a.v,
_mm_set_epi64x(0, n));
The optimizer will optimize the first line exactly as the second one if n is a
constant after optimizations, but it will not error out otherwise.

[Bug fortran/80291] [OOP] ICE 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 #7 from snowfed  ---
In the slightly reduced version of the test case cell is not allocated when
reaching associate structure. Maybe, allocate(cell) is worth being added. For
example, when I compile the example with ifort and run it I get SIGSEGV.

[Bug middle-end/80362] [5/6 Regression] gcc miscompiles arithmetic with signed char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1
Summary|[5/6/7 Regression] gcc  |[5/6 Regression] gcc
   |miscompiles arithmetic with |miscompiles arithmetic with
   |signed char |signed char

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

[Bug middle-end/80362] [5/6 Regression] gcc miscompiles arithmetic with signed char

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 10 13:02:12 2017
New Revision: 246805

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

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

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

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
(In reply to Richard Biener from comment #2)
> We have another bugreport that complains about SRA and Martin said he had
> patches but intended to wait for GCC 8.

My patch for PR 78687 unfortunately won't help here, that one is aimed
at making the original aggregates disappear when in fact we want to
leave the intermediate aggregate in a chain of assignments intact,
quite the opposite of a normal mode of operation.

> Note that I believe that store-merging, SRA (and bswap) are all passes that
> should be merged given they perform similar analyses and transforms.

Yeah, and I am (slowly) starting to look in that direction.

However, with the totally flow-insensitive SRA we have meanwhile, the
only remedy for this that I can think of is to throttle down total
scalarization here to never produce more than, say,
DECL_SIZE (candidate) / BITS_PER_WORD scalar replacements.

What do you think?

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #21)
> On April 7, 2017 6:57:13 PM GMT+02:00, "jakub at gcc dot gnu.org"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390
> >
> >--- Comment #20 from Jakub Jelinek  ---
> >So, Richard, any thoughts on what can be done split paths to avoid
> >this?
> 
> Invent some new heuristic that avoids splitting this case...

Index: gcc/gimple-ssa-split-paths.c
===
--- gcc/gimple-ssa-split-paths.c(revision 246803)
+++ gcc/gimple-ssa-split-paths.c(working copy)
@@ -249,13 +249,17 @@ is_feasible_trace (basic_block bb)
  imm_use_iterator iter2;
  FOR_EACH_IMM_USE_FAST (use2_p, iter2, gimple_phi_result
(stmt))
{
- if (is_gimple_debug (USE_STMT (use2_p)))
+ gimple *use_stmt = USE_STMT (use2_p);
+ if (is_gimple_debug (use_stmt))
continue;
- basic_block use_bb = gimple_bb (USE_STMT (use2_p));
+ basic_block use_bb = gimple_bb (use_stmt);
  if (use_bb != bb
  && dominated_by_p (CDI_DOMINATORS, bb, use_bb))
{
- found_useful_phi = true;
+ if (gcond *cond = dyn_cast  (use_stmt))
+   if (gimple_cond_code (cond) == EQ_EXPR
+   || gimple_cond_code (cond) == NE_EXPR)
+ found_useful_phi = true;
  break;
}
}

avoids the splitting at at least passes tree-ssa.exp testing.  Throwing it
on full testing (there are some path splitting testcases randomly placed
IIRC).

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Matthias Klose  ---
$ cat ./dpdk-16.11.1/igb_ethdev.i
typedef char a;
a b, c;
int d, e;
void f(void *g) { *(volatile int *)g; }
void j() {
  a h, i;
  for (; b; b += 2) {
d = b;
i = i >> b;
if (i)
  continue;
f(&c + (b >> 2));
h = 0;
for (; h < 8 / 2; h++)
  if (i << h)
e = 0;
  }
}

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[mpf at gcc dot gnu.org]

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

--- Comment #4 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Mon Apr 10 13:44:39 2017
New Revision: 246807

URL: https://gcc.gnu.org/viewcvs?rev=246807&root=gcc&view=rev
Log:
Update MIPS -mvirt option description

gcc/
PR target/80057
* config/mips/mips.opt (-mvirt): Update description.
* doc/invoke.texi (-mvirt): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.opt
trunk/gcc/doc/invoke.texi

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from mpf at gcc dot gnu.org ---
Fixed on trunk.

[Bug tree-optimization/80374] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2384

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Bill Schmidt  ---
The vec_xxpermdi interface is incorrectly documented in the GCC docs, and that
needs to be corrected.  Where you have:

vec_xxpermdi(a, b, j)

the use of j is not permitted.  The third argument to vec_xxpermdi must be a
constant in the range [0,3].  We still should not ICE, of course, but the code
as written is not expected to work.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/80374] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2384

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Testing a fix.

[Bug target/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[m...@sven-woop.de]

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

--- Comment #3 from Sven Woop  ---
Right, this could be considered a user bug. However, we ran into this as we are
successfully using this code sequence in our code:

#include 

#define __forceinline inline __attribute__((always_inline))

struct vint8
{
  __forceinline vint8(const int i) 
: v(_mm256_set1_epi32(i)) {}

  __forceinline vint8(const __m256i& t) 
: v(t) {}

  friend __forceinline const vint8 operator >>( const vint8& a, const int n ) { 
return _mm256_srai_epi32(a.v, n); 
  }

  __m256i v; 
};

vint8 test8(int shift)
{
  const vint8 blocks_add(shift);
  return blocks_add >> shift;
}


Which is essentially the same bug for AVX2. However, this code compiles with
every compiler that supports AVX2, be it GCC, Clang, or MSVC. Also the
corresponding sequence for SSE compiles with every compiler we tried so far.

I would have expected GCC to behave consistent for AVX-256 and AVX-512 for this
code.

[Bug target/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[m...@sven-woop.de]

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

--- Comment #4 from Sven Woop  ---
BTW, the AVX-512 version of this "bug" also compiles with ICC and Clang 4.

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

--- Comment #6 from jwjagersma at gmail dot com ---
So "esp" is not a valid register to clobber? I thought it would only make the
compiler use ebp instead to reference stack memory operands. After all
esp-relative operands wouldn't be valid after a push/pop in inline asm.

Also, I identified the minimum compiler flags required to reproduce this issue:

$ /usr/local/djgpp/bin/i586-pc-msdosdjgpp-g++ -march=pentium3 -masm=intel
-mstackrealign -O3 vbe.ii
src/vbe.cpp: In member function 'virtual void
jw::video::vbe2::set_palette(const px32*, const px32*, std::size_t, bool)':
src/vbe.cpp:647:9: internal compiler error: in print_reg, at
config/i386/i386.c:16549

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
It's difficult to completely avoid an ICE, as once we have a nested call with
an invalid value it is not simple to recover with our current design.  However,
I will put together a patch that provides better error messages when this
situation arises, and we can consider some re-design work in a later release.

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Patch under test would produce the follow errors instead:

wschmidt@pike:~/src$ $GCC_INSTALL/bin/gcc pr80376.c 
pr80376.c: In function 'main':
pr80376.c:12:5: error: argument 3 must be a 2-bit unsigned literal
 vec_vsx_st(vec_xxpermdi(a, b, j), 0, c);
 ^~
pr80376.c:12:5: internal compiler error: non-vector constant found where vector
expected
0x116cde0b gen_movv4si(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/config/rs6000/vector.md:114
0x105fd113 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/home/wschmidt/gcc/gcc-mainline-test/gcc/recog.h:301
0x1077a497 emit_move_insn_1(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:3643
0x1077ab37 emit_move_insn(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:3738
0x107826d3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:5729
0x107802a3 expand_assignment(tree_node*, tree_node*, bool)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:5321
0x1056ec0b expand_call_stmt
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:2656
0x10572b87 expand_gimple_stmt_1
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:3571
0x105734c3 expand_gimple_stmt
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:3737
0x1057cd03 expand_gimple_basic_block
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:5744
0x1057ef3b execute
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Apr 10 14:58:33 2017
New Revision: 246808

URL: https://gcc.gnu.org/viewcvs?rev=246808&root=gcc&view=rev
Log:
2017-04-10  Vladimir Makarov  

PR rtl-optimization/70478
* lra-constraints.c (curr_small_class_check): New.
(update_and_check_small_class_inputs): New.
(process_alt_operands): Update curr_small_class_check.  Disfavor
alternative insn memory operands.  Check available regs for small
class operands.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jwjagersma at gmail dot com]

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

--- Comment #7 from jwjagersma at gmail dot com ---
Created attachment 41167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41167&action=edit
test case

Here is a reduced test case that causes a similar (likely the same?) ICE on
i686-w64-mingw32. The line number in print_reg is different, but then this is a
different gcc version (6.3.0).
Interestingly, compiling with -O3 here prints a more sensible error message.

$ g++ -masm=intel -march=pentium3 -mstackrealign -O3 ice_print_reg.cpp
ice_print_reg.cpp: In function 'int main()':
ice_print_reg.cpp:19:30: error: 'asm' operand has impossible constraints
 : "esi", "esp", "cc");
  ^

$ g++ -masm=intel -march=pentium3 -mstackrealign ice_print_reg.cpp
ice_print_reg.cpp: In function 'int main()':
ice_print_reg.cpp:20:1: internal compiler error: in print_reg, at
config/i386/i386.c:16601
 }
 ^

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

ice_print_reg.cpp:20:1: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
g++.exe: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ g++ -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
--with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 6.3.0 (Rev2, Built by MSYS2 project)

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Martin Jambor from comment #3)
> (In reply to Richard Biener from comment #2)
> > We have another bugreport that complains about SRA and Martin said he had
> > patches but intended to wait for GCC 8.
> 
> My patch for PR 78687 unfortunately won't help here, that one is aimed
> at making the original aggregates disappear when in fact we want to
> leave the intermediate aggregate in a chain of assignments intact,
> quite the opposite of a normal mode of operation.
> 
> > Note that I believe that store-merging, SRA (and bswap) are all passes that
> > should be merged given they perform similar analyses and transforms.
> 
> Yeah, and I am (slowly) starting to look in that direction.
> 
> However, with the totally flow-insensitive SRA we have meanwhile, the
> only remedy for this that I can think of is to throttle down total
> scalarization here to never produce more than, say,
> DECL_SIZE (candidate) / BITS_PER_WORD scalar replacements.
> 
> What do you think?

Yeah, but that's not sth for GCC 7 either.  Note that we did get better
both in FRE and DSE so we may no longer need SRA to perform some of the
optimizations [in the early pipeline].

That said, the array cases we've seen are somewhat disturbing...  maybe
we can disable total scalarization for those?

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
Confirmed.  -msecure-plt is not required.  Happens with -O3 but not with -O2.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||pthaugen at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #4 from Bill Schmidt  ---
Fails this assert:

  gcc_assert (MODEL_REF_PRESSURE (group, point, pci) == max_pressure);

Pat, might this be related to some of the sched-pressure class changes?

[Bug libstdc++/79522] std::regex_match always returns false

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> But even in your second example the behaviour is correct, std::regex_match
> matches the entire string, not any part of it. "def" doesn't match "abcdefg"
> it only matches part of it. Use std::regex_search for that.

You didn't read this.

std::regex_match is only true if the entire sequence matches the regex, not
some subsequence. "def" is a subsequence of "abcdefg". std::regex_match is not
supposed to return true here. You need to use std::regex_search instead.

http://en.cppreference.com/w/cpp/regex/regex_match
http://en.cppreference.com/w/cpp/regex/regex_search

> (And "I don't know how C++ works" is still not a bug)

Still not a bug.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #25)
--- snip ---
> 
> Btw., I happened to notice that this "int * length" (and many more
> instances throughout the file and probably all of libgfortran) is
> in violation of the GNU Coding Standard: this should be "int *length"
> instead.
> 
>   Rainer

I noticed those too. I will try to clean them up soon. Probably a separate
patch that does only this cleanup. Not sure where it propagated from and it
does not matter at this point, so will just fix it.

Regarding the other failure. Its hard to debug without a machine. Maye set up a
virtual machine? Is this Solaris OS available for to do this with?

[Bug target/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-04-10
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

The documentation says that it should be an immediate and only mention the insn
with the immediate.
That said, the reason why GCC accepts it is that it has magic handling for the
count argument of the 2 argument shift builtins, where it basically transforms
the count as needed depending on what it is.  This patch adds the same magic
handling to the count argument of the 4 argument shift builtins (the ones that
have the mask argument and the source for values when mask is not set).

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Started with r243866.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I think there was a bug report in the last month or so asking for some builtin
to detect when we're in a constexpr context.

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

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
(In reply to Richard Biener from comment #4)
> That said, the array cases we've seen are somewhat disturbing...  

Cases?  Can you point me to the other ones, please?  What type do they
have?

> maybe we can disable total scalarization for those?

The support for total scalarization of arrays was added by Alan
Lawrence as a part of constant pool SRA and I suppose that for a good
reason (the added testcases have them at least).

However, thinking about this particular testcase a bit more, I think
the most reasonable thing to do is to disable total scalarization of
char (or generally byte-sized-element) arrays.  Those are likely just
some anonymous storage anyway:

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 02453d3ed9a..cbe9e862a2f 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -981,7 +981,7 @@ scalarizable_type_p (tree type)
   if (TYPE_DOMAIN (type) == NULL_TREE
  || !tree_fits_shwi_p (TYPE_SIZE (type))
  || !tree_fits_shwi_p (TYPE_SIZE (TREE_TYPE (type)))
- || (tree_to_shwi (TYPE_SIZE (TREE_TYPE (type))) <= 0)
+ || (tree_to_shwi (TYPE_SIZE (TREE_TYPE (type))) <= BITS_PER_UNIT)
  || !tree_fits_shwi_p (TYPE_MIN_VALUE (TYPE_DOMAIN (type
return false;
   if (tree_to_shwi (TYPE_SIZE (type)) == 0

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
That revision enabled -fsched-pressure by default, so it may have been latent
with -fsched-pressure before then.

[Bug c++/60685] exception not caught by enclosing catch

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Dave McMordie from comment #6)
> Any sense of a minimal patch to fix this issue?

At a wild guess, I'd say it might be one of r209907 or r216750, which both look
quite involved and probably not possible to backport to a gcc-4.9 tree.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
(In reply to Bill Schmidt from comment #6)
> That revision enabled -fsched-pressure by default, so it may have been
> latent with -fsched-pressure before then.

Yes, this is a latent bug in the "model" sched-pressure algorithm code. I can
reproduce it with r243865 (revision before I turned on -fsched-pressure for
powerpc) by adding -fsched-pressure --param sched-pressure-algorithm=2.

I'll do some digging.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Bill Schmidt from comment #6)
> That revision enabled -fsched-pressure by default, so it may have been
> latent with -fsched-pressure before then.

No, r243865 does not ICE with -O3 -fsched-pressure.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[palves at redhat dot com]

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

--- Comment #9 from Pedro Alves  ---
FWIW, I've tried to poke a bit more at this, to try to make it _not_ work, but
couldn't.  It seems to always do what we need.  These all work/compile too:


constexpr int constexpr_strcmp(const char *s1, const char *s2)
{
  while (*s1 != '\0' && *s1 == *s2)
{
  s1++;
  s2++;
}

  if (*s1 < *s2)
return -1;
  else if (*s1 > *s2)
return 1;
  return 0;
}

constexpr int my_strcmp(const char *s1, const char *s2)
{
  if (__builtin_constant_p (s1[0])
  && __builtin_constant_p (s2[0]))
return constexpr_strcmp (s1, s2);

  return strcmp (s1, s2);
}

constexpr bool str4()
{
  char s[4]= {};
  int i = 0;
  for (; i < 3; i++)
s[i] = i + 1;
  return ce_char_traits::length(s) == 3;
}

static_assert( str4() );

constexpr int foo (char x, char y)
{
  char a[10] = "abcde";
  a[2] = x;
  a[4] = y;
  return ce_char_traits::length(a);
}

static_assert (foo ('1', '2') == 5);
static_assert (foo ('1', '\0') == 4);

bool runtime()
{
  char s[] = "str";
  s[0] = 'l';
  s[1] = '\0';
  return ce_char_traits::length(s) == 1;
}

bool runtime2()
{
  char s[4]= {};
  int i = 0;
  for (; i < 3; i++)
s[i] = i + 1;
  return ce_char_traits::length(s) == 3;
}

bool runtime3()
{
  constexpr char s[] = "str";
  return ce_char_traits::length(s) == 1;
}

int main ()
{
  assert (runtime ());
  assert (runtime2 ());
  assert (runtime3 ());
}

static_assert (my_strcmp("hello", "hello") == 0);
static_assert (my_strcmp("hello", "hell2") > 0);
static_assert (my_strcmp("hell2", "hello") < 0);


And I confirmed that "constexpr_strlen" / "constexpr_strcmp" are NOT emitted /
called as runtime functions, both at -O0 and -O2.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Bill Schmidt from comment #6)
> > That revision enabled -fsched-pressure by default, so it may have been
> > latent with -fsched-pressure before then.
> 
> No, r243865 does not ICE with -O3 -fsched-pressure.

OK, --param-sched-pressure-algorithm=2 must also be needed.

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Apr 10 16:51:44 2017
New Revision: 246810

URL: https://gcc.gnu.org/viewcvs?rev=246810&root=gcc&view=rev
Log:
PR tree-optimization/80153
* tree-affine.c (aff_combination_to_tree): Get base pointer from
the first element of pointer type aff_tree.  Build result expr in
aff_tree's type.
(add_elt_to_tree): Convert to type unconditionally.  Remove other
fold_convert calls.
* tree-ssa-loop-ivopts.c (alloc_iv): Pass in consistent types.
(rewrite_use_nonlinear_expr): Check invariant using iv information.
gcc/testsuite
PR tree-optimization/80153
* gcc.c-torture/execute/pr80153.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr80153.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-affine.c
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Apr 10 16:54:14 2017
New Revision: 246811

URL: https://gcc.gnu.org/viewcvs?rev=246811&root=gcc&view=rev
Log:
PR tree-optimization/80153
* tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Check and 
remove POINTER_PLUS_EXPR's base part directly, rather than through
aff_tree.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
I don't think it works that well.
Consider:
int
str6 (int a)
{
  char s[] = "strabcdefgh";
  s[2] = a;
  return ce_char_traits::length(s);
}

int
str7 (int a)
{
  char s[] = "strabcdefgh";
  s[2] = a;
  return __builtin_strlen(s);
}

The latter is compiled into standard strlen sequence, depending on tuning etc.,
the former is always the constexpr_strlen loop at runtime.

[Bug target/80382] ICE with error: unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
You didn't fill in the target.  32/64-bit, little-/big-endian?

[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Mon Apr 10 17:18:15 2017
New Revision: 246812

URL: https://gcc.gnu.org/viewcvs?rev=246812&root=gcc&view=rev
Log:
PR sanitizer/80348
* typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL.  Set
ORIG_TYPE earlier and not only when shortening.

* g++.dg/ubsan/div-by-zero-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80348] [6 Regression] UBSAN: compile time crash in ubsan_instrument_division

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7 Regression] UBSAN: |[6 Regression] UBSAN:
   |compile time crash in   |compile time crash in
   |ubsan_instrument_division   |ubsan_instrument_division

--- Comment #10 from Marek Polacek  ---
Fixed on trunk so far.

[Bug target/80382] ICE with error: unrecognizable insn

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
(In reply to Bill Schmidt from comment #1)
> You didn't fill in the target.  32/64-bit, little-/big-endian?

64-bit, and I think it ICEs on both BE and LE.

[Bug target/80382] ICE with error: unrecognizable insn

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
I'll have a look.

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The warning does just what it's designed to do: point out the potential
unhandled truncation.  If the argument values are such that the truncation
cannot occur then using snprintf is unnecessary and sprintf can be used
instead.  Otherwise, if there is a combination of argument values that can
result in truncation a warning is issued.  Note that the length of output
produced by each directive can be constrained by specifying a precision for %s
(e.g., "%.24s" if arena->m_name in the LibreOffice code cannot be longer than
24 characters), or by asserting that an integer argument is in some limited
range of its type (or by using a narrower type to store it).

Like all warnings that depend on data flow analysis it is subject to false
positives but there is no evidence to suggest that on balance it's unhelpful or
difficult to use.  Quite the contrary.

[Bug target/80382] ICE with error: unrecognizable insn

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
(In reply to Marek Polacek from comment #0)
> This testcase (which took ~5 days of reducing) ICEs with -O3 -std=c++11
> -mtune=power8 -mcpu=power8 -mno-lra:

Did you use creduce or delta or ??? to reduce the test case?

[Bug target/80382] ICE with error: unrecognizable insn

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Peter Bergner from comment #4)
> (In reply to Marek Polacek from comment #0)
> > This testcase (which took ~5 days of reducing) ICEs with -O3 -std=c++11
> > -mtune=power8 -mcpu=power8 -mno-lra:
> 
> Did you use creduce or delta or ??? to reduce the test case?

Just creduce.  I think it'd be possible to reduce it a bit more, first manually
and then run creduce again, but it needs a bit of knowledge of C++.

[Bug target/80382] ICE with error: unrecognizable insn

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
(In reply to Marek Polacek from comment #5)
> Just creduce.  I think it'd be possible to reduce it a bit more, first
> manually and then run creduce again, but it needs a bit of knowledge of C++.

Ok, in that case, I'll leave it as is.  Was just making sure you hadn't used
delta.

[Bug testsuite/79867] [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results

[mrs at gcc dot gnu.org]

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

--- Comment #2 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Apr 10 17:45:35 2017
New Revision: 246813

URL: https://gcc.gnu.org/viewcvs?rev=246813&root=gcc&view=rev
Log:
2017-04-10  Daniel Santos 

PR testsuite/79867
* lib/target-libpath.exp: Merge in cygwin fix from libffi.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-libpath.exp

[Bug testsuite/79867] [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from mrs at gcc dot gnu.org  ---
Patch to fix most is now checked in.

[Bug target/80382] ICE with error: unrecognizable insn

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Note it might be nicer to replace typedef int size_t; with something not that
wrong, say typedef __SIZE_TYPE__ size_t; if it still reproduces with that (or
replace size_t with int everywhere).

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

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #12 from wilco at gcc dot gnu.org ---
There are 2 separate issues in the ARMv7 case. One is scheduling, the -S output
goes down from 437 lines to 305 lines with -fno-schedule-insns (stack size 276
rather than 448 bytes). So basically the "register pressure aware" scheduler
introduces lots of unnecessary spills.

The 2nd issue is related to use of single-element operations within vectors. If
I change the define to do an explicit dup, eg. vmulq_f32((b), vdupq_n_f32(a)),
I get 211 lines and no spills at all. Switching scheduling on again gives 326
lines so it's spilling like crazy.

Both issues seem to have been present since at least 4.8.2.

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
Confirmed.  It's strange that it doesn't ICE on LE, even though we produce the
exact same pattern there.  Maybe we're somehow disabling the pattern on BE when
we shouldn't be.

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Confirmed.  The define_expand condition is *not* checked?!  Possibly by
the pow->sqrt code (yeah I'm guessing here).

[Bug target/79712] Clang smarter about unrolling in fhourstones benchmark

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #10 from Bill Schmidt  ---
(In reply to Richard Biener from comment #9)
> Micha was looking at removing RTL unrolling and instead do sth on the GIMPLE
> level.

That would be an interesting topic for Cauldron if it's far enough along for
discussion.

[Bug target/80099] ICE in rs6000_expand_vector_extract, at config/rs6000/rs6000.c:7450

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Needs -mcpu=power8.  Confirmed.

Don't use -mno-upper-regs-sf...

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[palves at redhat dot com]

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

--- Comment #11 from Pedro Alves  ---
Ok, so s[2] is not constant, while s[0] is, in that case.

AFAICS, changing constexpr_strlen to this:

constexpr size_t constexpr_strlen(const char* s)
{
  const char *p = s;

  while (__builtin_constant_p (*p) && *p)
p++;
  if (!__builtin_constant_p (p[0]))
return p - s + __builtin_strlen (p);
  return p - s;
}

makes it work as expected.  All the previous static_assert tests compile
without
error, and, we now get a call to strlen at run-time, AFAICS (I replaced that
__builtin_strlen call with a call to an "extern_strlen" function declared in
another compile unit instead to verify).

Could you confirm?

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Doesn't ICE on x86_64-linux (-m64 nor -m32), but I can reproduce the ICE in a
cross to x86_64-mingw32, only -m32 is needed.  The ICE is because LRA does not
eliminate frame regs because "esp" is clobbered by the asm (normally they would
be eliminated to sp+offset).

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

[uros at gcc dot gnu.org]

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

--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Apr 10 18:51:42 2017
New Revision: 246816

URL: https://gcc.gnu.org/viewcvs?rev=246816&root=gcc&view=rev
Log:
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on alpha.


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

[Bug target/80367] internal compiler error: in print_reg, at config/i386/i386.c:16549

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
In PR 79804, I have a patch that makes ICE more informative, but the frame reg
problem elimination remains to be solved in LRA.

[Bug sanitizer/80349] [6/7 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #3 from Dmitry Babokin  ---
PR80348 is fixed, but this still fails.