[Bug target/80324] _mm512_reduce_xxx type instrinsics are missing

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 10 06:53:28 2017
New Revision: 246798

URL: https://gcc.gnu.org/viewcvs?rev=246798&root=gcc&view=rev
Log:
PR target/80324
* config/i386/avx512fintrin.h (_mm512_reduce_add_epi32,
_mm512_reduce_mul_epi32, _mm512_reduce_and_epi32,
_mm512_reduce_or_epi32, _mm512_mask_reduce_add_epi32,
_mm512_mask_reduce_mul_epi32, _mm512_mask_reduce_and_epi32,
_mm512_mask_reduce_or_epi32, _mm512_reduce_min_epi32,
_mm512_reduce_max_epi32, _mm512_reduce_min_epu32,
_mm512_reduce_max_epu32, _mm512_mask_reduce_min_epi32,
_mm512_mask_reduce_max_epi32, _mm512_mask_reduce_min_epu32,
_mm512_mask_reduce_max_epu32, _mm512_reduce_add_ps,
_mm512_reduce_mul_ps, _mm512_mask_reduce_add_ps,
_mm512_mask_reduce_mul_ps, _mm512_reduce_min_ps, _mm512_reduce_max_ps,
_mm512_mask_reduce_min_ps, _mm512_mask_reduce_max_ps,
_mm512_reduce_add_epi64, _mm512_reduce_mul_epi64,
_mm512_reduce_and_epi64, _mm512_reduce_or_epi64,
_mm512_mask_reduce_add_epi64, _mm512_mask_reduce_mul_epi64,
_mm512_mask_reduce_and_epi64, _mm512_mask_reduce_or_epi64,
_mm512_reduce_min_epi64, _mm512_reduce_max_epi64,
_mm512_mask_reduce_min_epi64, _mm512_mask_reduce_max_epi64,
_mm512_reduce_min_epu64, _mm512_reduce_max_epu64,
_mm512_mask_reduce_min_epu64, _mm512_mask_reduce_max_epu64,
_mm512_reduce_add_pd, _mm512_reduce_mul_pd, _mm512_mask_reduce_add_pd,
_mm512_mask_reduce_mul_pd, _mm512_reduce_min_pd, _mm512_reduce_max_pd,
_mm512_mask_reduce_min_pd, _mm512_mask_reduce_max_pd): New intrinsics.

* gcc.target/i386/avx512f-reduce-op-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-reduce-op-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512fintrin.h
trunk/gcc/testsuite/ChangeLog

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

2017-04-09 Thread noloader at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377

--- Comment #2 from Jeffrey Walton  ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this.
> 
> Similar to PR c++/72786, and probably worked-around on trunk by r242965;
> presumably has a specific root-cause though.

Yes, thanks David. They look very similar. I kind of figured the issue surfaced
under another diagnostic message.

On thing may be different: the suggestion in this issue appears to have extra
trailing whitespace. Its slightly different than the 72786 issue, which does
not have the extra whitespace in the suggestion.

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

2017-04-09 Thread dmalcolm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

Similar to PR c++/72786, and probably worked-around on trunk by r242965;
presumably has a specific root-cause though.

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

2017-04-09 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
I think this is now fixed. Closing

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

2017-04-09 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881

--- Comment #24 from Jerry DeLisle  ---
(In reply to Christophe Lyon from comment #23)
> (In reply to Jiong Wang from comment #22)
> > (In reply to Rainer Orth from comment #15)
> > > The new testcase FAILs on 64-bit Solaris/SPARC:
> > 
> > + AArch64
> > 
> 
> For me, the tests pass on aarch64 (using qemu), but as I reported in
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01370.html
> the tests fails for arm*linux-gnueabihf and pass for arm*linux-gnueabi
> (using qemu too)

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;

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

2017-04-09 Thread dje at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
New.

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

2017-04-09 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80364

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00427.html

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

2017-04-09 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80364

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
The get_int_range function is only meant to be used for printf arguments of
type int after promotion (width and precision specified by the asterisk, and
wint_t argument to %lc).  The test case in pr72858.c that triggers the
sanitizer error is invalid (with undefined behavior) because it passes in an
argument of type long.  A test case that passes in a __int128_t triggers an ICE
(below).  Arguments of non-integer types are ignored.  Let me correct the
handling to avoid these two problems.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic a.c
void f (__int128_t x)
{
  extern char d[3];
  __builtin_sprintf (d, "%*d", x, 1);
}

a.c: In function ‘f’:
a.c:4:27: warning: field width specifier ‘*’ expects argument of type ‘int’,
but argument 3 has type ‘__int128’ [-Wformat=]
   __builtin_sprintf (d, "%*d", x, 1);
  ~^~
a.c:1:6: internal compiler error: in tree_to_shwi, at tree.c:7333
 void f (__int128_t x)
  ^
0x10b13cd tree_to_shwi(tree_node const*)
/ssd/src/gcc/git-svn/gcc/tree.c:7333
0x16e8692 get_int_range
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:946
0x16e8865 get_int_range
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:995
0x16e7f3d set_width
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:677
0x16ed310 parse_directive
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:3129
0x16ed753 compute_format_length
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:3239
0x16ee60a handle_gimple_call
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:3671
0x16ee70d execute
/ssd/src/gcc/git-svn/gcc/gimple-ssa-sprintf.c:3699
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++/60685] exception not caught by enclosing catch

2017-04-09 Thread mcmordie at viionsystems dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685

Dave McMordie  changed:

   What|Removed |Added

 CC||mcmordie at viionsystems dot 
com

--- Comment #6 from Dave McMordie  ---
Any sense of a minimal patch to fix this issue?  I have embedded systems in the
wild suffering from this rather critical issue.  Upgrading to a new compiler
version means updating the entire system...

(I am curious how this kind of wide-ranging bug could get past rudimentary unit
testing, but that is a topic for another day-- probably a day when I volunteer
to write those tests I guess.)

[Bug c++/60932] make stdatomic.h compatible with C++

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Patrick Pelissier from comment #12)
> Is the status really "wontfix"?
> 
> This makes any C library which uses stdatomic.h incompatible with g++ (and

 is not part of the C++ standard.

> more and more C code uses stdatomic.h) which is rather bothersome. clang
> doesn't have this issue.

Clang allows the C keyword _Atomic in C++. That's not part of the C++ standard
either

> What prevent stdatomic.h to detect if it is included in C++ mode and
> includes C++  instead?

Even if it did that, it wouldn't guarantee that C's atomic_int and C++'s
std::atomic_int are compatible. So you'd still need to rely on non-portable
implementation-specific assumptions.

[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

2017-04-09 Thread marco_atzeri at yahoo dot it 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030

marco atzeri  changed:

   What|Removed |Added

 CC||marco_atzeri at yahoo dot it

--- Comment #5 from marco atzeri  ---
The issue is still pending on 

$ gfortran --version
GNU Fortran (GCC) 6.3.0

 !GCC$ ATTRIBUTES DLLIMPORT :: /cb1/
   1
Error: Invalid character in name at (1)

There is any workaround that allows common block to be
exported / imported ?

[Bug c/80378] Extend alloc_size attribute for better Linux kernel checking

2017-04-09 Thread andi-gcc at firstfloor dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378

--- Comment #3 from Andi Kleen  ---
Hmm, that trick may work for the shift too. Let me try.

[Bug c/80378] Extend alloc_size attribute for better Linux kernel checking

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
For size_a + size_b can't you simply use an inline wrapper?

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

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80375

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80374

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

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

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80367

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80364

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

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

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80362

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
  Known to work||3.4.6, 4.1.2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.5
Summary|gcc miscompiles arithmetic  |[5/6/7 Regression] gcc
   |with signed char|miscompiles arithmetic with
   ||signed char
  Known to fail||4.3.6

--- Comment #2 from Richard Biener  ---
Fails with -O0 -fstrict-overflow already.  Folded to

signed char var_1 = -128;
  var_0 = var_1 / -3;
  if (var_0 > 0)

either extract_muldiv or fold_negate.  Mine.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.5

[Bug tree-optimization/80359] [7 Regression] DSE causes error: invalid reference prefix

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80359

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-09
 CC||law at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|-O3 causes error: invalid   |[7 Regression] DSE causes
   |reference prefix|error: invalid reference
   ||prefix
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
(gdb) p t
$1 = 

indeed we may not subset TMRs.  Caused by DSE (Jeffs improvements).

Note the particular TMR (just base and constant offset) could be rewritten
to a regular MEM_REF.

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

2017-04-09 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #21 from Richard Biener  ---
I will have a look, hopefully tomorrow.

[Bug c/80378] Extend alloc_size attribute for better Linux kernel checking

2017-04-09 Thread andi-gcc at firstfloor dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378

--- Comment #1 from Andi Kleen  ---
Small correction: argument 4 would need to be a constant for shifted by.

[Bug lto/80379] Redundant note: code may be misoptimized unless -fno-strict-aliasing is used

2017-04-09 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Related to pr68717 and friends: the wording of the warning is misleading.

[Bug lto/80379] New: Redundant note: code may be misoptimized unless -fno-strict-aliasing is used

2017-04-09 Thread andi-gcc at firstfloor dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379

Bug ID: 80379
   Summary: Redundant  note: code may be misoptimized unless
-fno-strict-aliasing is used
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

I get an extra

 note: code may be misoptimized unless -fno-strict-aliasing is used

note for type mismatches in LTO builds. But -fno-strict-aliasing is already
set. In this case the extra note is pointless and should be suppressed.

[Bug c/80378] New: Extend alloc_size attribute for better Linux kernel checking

2017-04-09 Thread andi-gcc at firstfloor dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378

Bug ID: 80378
   Summary: Extend alloc_size attribute for better Linux kernel
checking
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

I've been adding alloc_size attributes to the Linux kernel allocators.

However there are some allocator patterns that can currently not be correctly
described. It would be nice if the attribute could be extended with more
parameters to handle this.

One is 

void *alloc(int size_a, int size_b)

where the allocation size is size_a + size_b

The other is

void *alloc_order(int order)

where the allocation size is constant << order

This could be handled by two extra parameters to alloc_size, one to give a sum
argument and another to to give a shifted by argument. The arguments 2,3 would
also need to support a "ignore" parameter (e.g. -1)

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

2017-04-09 Thread noloader at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377

Bug ID: 80377
   Summary: gcc: error: unrecognized command line option
‘-mavx512’; did you mean ‘-mavx512 ’?
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

>From the low hanging fruit department... I stumbled upon this on Fedora 25
x86_64 with GCC 6.3.1. I'm actually looking for '-mavx512f'
(http://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options):

$  gcc -g3 -O3 -std=c99 -march=native -mavx512 rot-test.c -o rot-test.exe
gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512
’?

**

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC)

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

2017-04-09 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304

Thomas Koenig  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #20 from Thomas Koenig  ---
Hi Richard,

could you reclassify this bug?  I have reset the priority to P3
because it appears to be a middle-end bug which just happens
to be exposed by the Fortran front end.

If it is not fixed in time for the release, we should disable the
ivdep annotation of DO CONCURRENT with the patch

Index: trans-stmt.c
===
--- trans-stmt.c(Revision 246743)
+++ trans-stmt.c(Arbeitskopie)
@@ -3397,11 +3397,7 @@ gfc_trans_forall_loop (forall_info *forall_tmp, tr
   /* The exit condition.  */
   cond = fold_build2_loc (input_location, LE_EXPR, boolean_type_node,
  count, build_int_cst (TREE_TYPE (count), 0));
-  if (forall_tmp->do_concurrent)
-   cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
-  build_int_cst (integer_type_node,
- annot_expr_ivdep_kind));
-
+  
   tmp = build1_v (GOTO_EXPR, exit_label);
   tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node,
 cond, tmp, build_empty_stmt (input_location));

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

2017-04-09 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/80376] New: Some vec_xxpermdi usage lead to ICE

2017-04-09 Thread lu_zero at gentoo dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376

Bug ID: 80376
   Summary: Some vec_xxpermdi usage lead to ICE
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lu_zero at gentoo dot org
  Target Milestone: ---

Testcase:

#include 
#include 

int main(void) {

vector unsigned int a = { 1, 2, 3, 4 };
vector unsigned int b = { -1, -2, -3, -4 };
unsigned int c[4], i, j;

for (j = 0; j < 4; j++) {
printf("%d -> ", j);
vec_vsx_st(vec_xxpermdi(a, b, j), 0, c);
for (i = 0; i < 4; i++) {
printf("%d ", c[i]);
}
printf("\n");
}

return 0;
}


compiler log:

/tmp/t.c: In function ‘main’:
/tmp/t.c:12:5: internal compiler error: in copy_to_mode_reg, at explow.c:601
 vec_vsx_st(vec_xxpermdi(a, b, j), 0, c);
 ^~
0x103b737f copy_to_mode_reg(machine_mode, rtx_def*)
../../src/gcc/explow.c:601
0x10a0ae0f rs6000_expand_ternop_builtin
../../src/gcc/config/rs6000/rs6000.c:14234
0x10a0ae0f rs6000_expand_builtin
../../src/gcc/config/rs6000/rs6000.c:15658
0x1028cf9f expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../src/gcc/builtins.c:5624
0x103d12ff expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:10598
0x103dc017 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../src/gcc/expr.c:5406
0x103dd3cb expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5175
0x102aec73 expand_call_stmt
../../src/gcc/cfgexpand.c:2658
0x102aec73 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3548
0x102aec73 expand_gimple_stmt
../../src/gcc/cfgexpand.c:3714
0x102b1937 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5720
0x102b6f87 execute
../../src/gcc/cfgexpand.c:6335

[Bug middle-end/80372] non-optimal handling of copying a std::complex

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-09
  Component|c++ |middle-end
 Ever confirmed|0   |1

--- Comment #4 from Marc Glisse  ---
(using -march=skylake-avx512 which sounds recent enough)

  MEM[(struct complexD.42555 *)res_1(D) + 16B] = MEM[(const struct
complexD.42555 &)res_1(D)];

gcc often has trouble optimizing direct mem-to-mem assignments. If I write the
code as:

  res[1].real(res[0].real());
  res[1].imag(res[0].imag());

we have

  _3 = REALPART_EXPR ;
  REALPART_EXPR  = _3;
  _4 = IMAGPART_EXPR ;
  IMAGPART_EXPR  = _4;

which we vectorize (SLP)

  vect__3.9_8 = MEM[(doubleD.39 *)res_1(D)];
  MEM[(doubleD.39 *)res_1(D) + 16B] = vect__3.9_8;

and generate

vmovupd (%rdi), %xmm0
vmovups %xmm0, 16(%rdi)

If I use memcpy(res+1,res,sizeof(*res)), we get:

  __int128 unsigned _3;
  _3 = MEM[(char * {ref-all})res_1(D)];
  MEM[(char * {ref-all})res_1(D) + 16B] = _3;

vmovdqu64   (%rdi), %xmm0
vmovups %xmm0, 16(%rdi)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|rtl-optimization|middle-end
   Target Milestone|--- |5.5

[Bug c++/80372] non-optimal handling of copying a std::complex

2017-04-09 Thread no...@turm-lahnstein.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80372

--- Comment #3 from ead  ---
(In reply to Andrew Pinski from comment #2)
> What options are you using?  -O2 or -O3 ? -mcpu=native ?

It is compiled with -O3, but it is the same for -O2 or -Os. 

If compiled with -march=native, the result uses four vmovsd instead of four
movsd, which does not change much: the new version is still the same slow and
36byte large.

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

2017-04-09 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80375

Bug ID: 80375
   Summary: [5/6/7 Regression] ICE in expand_expr_real_2, at
expr.c:9382 with -ftrapv
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from 5.1, there's ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr38934.c -ftrapv -m32
-c

/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr38934.c: In function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr38934.c:14:13: warning:
integer constant is so large that it is unsigned
   if (p >= -9223372036854775808LL - (signed char) g)
 ^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr38934.c:14:35: internal
compiler error: in expand_expr_real_2, at expr.c:9382
   if (p >= -9223372036854775808LL - (signed char) g)
~~~^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

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

2017-04-09 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80374

Bug ID: 80374
   Summary: [7 Regression] ICE in fold_convert_loc, at
fold-const.c:2384
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---

Starting from r246187, we ICE on:

$ cat ice.ii
void a (const char *, const char *, int, const char *)
  __attribute__ ((__noreturn__));
template 
void
c () try
  {
throw;
  }
catch (b d)
  {
if (d)
  a ("", "", 2, __PRETTY_FUNCTION__);
  }
main ()
{
  using e = decltype (nullptr);
  c ();
}

$ g++ -O ice.ii -std=c++14
ice.ii: In function ‘void c() [with b = std::nullptr_t; int  = 1]’:
ice.ii:5:1: internal compiler error: in fold_convert_loc, at fold-const.c:2384
 c () try
 ^
0xc7540c fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2384
0x10ebd42 derive_equivalences_from_bit_ior
../../gcc/tree-ssa-dom.c:709
0x10ebf18 record_temporary_equivalences(edge_def*, const_and_copies*,
avail_exprs_stack*)
../../gcc/tree-ssa-dom.c:763
0x10ec533 record_equivalences_from_incoming_edge
../../gcc/tree-ssa-dom.c:946
0x10ecd89 dom_opt_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-dom.c:1167
0x16c69c2 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:265
0x10eb476 execute
../../gcc/tree-ssa-dom.c:459