[Bug tree-optimization/85003] New: Inline built-in fdim for -fno-math-errno

[jsm28 at gcc dot gnu.org]

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

Bug ID: 85003
   Summary: Inline built-in fdim for -fno-math-errno
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

GCC should support inline code generation for the fdim / fdimf / fdiml
functions, given -fno-math-errno.

glibc's bits/mathinline.h headers for powerpc and sparc (only) have inlines of
the form:

__MATH_INLINE double
__NTH (fdim (double __x, double __y))
{
  return __x <= __y ? 0 : __x - __y;
}

We're moving away from such inlines in glibc, preferring to leave it to the
compiler to inline standard functions under appropriate conditions.  Now, the
above (which lacks a -fno-math-errno conditional) isn't actually correct; you
need to use an unordered comparison, so the appropriate expansion (given
-fno-math-errno) is of the form (considered as an inline not a macro, so
avoiding multiple evaluations of arguments):

__builtin_islessequal (x, y) ? 0 : x - y

Note: as well as -fno-math-errno, for correctness this also requires that, if
standard-conforming excess precision has been requested, the back end does not
add any implicit excess precision for the type in question, as specified by the
targetm.c.excess_precision hook (so it's not correct to do this inline
expansion for 32-bit x86 with x87 floating point for float or double if
-fexcess-precision=standard, in particular).

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Also:

#define _GLIBCXX_DEBUG
#include 
int main()
{
  std::vector b;
  std::hash h;
  return h(b);
}

And a number of other debug mode failures related to access. I suspect FE
improvements to lookup have made some of our friend declarations stop working
as intended.

[Bug c++/85004] New: ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers

[msebor at gcc dot gnu.org]

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

Bug ID: 85004
   Summary: ambiguous diagnostic: passing ‘const S’ as ‘this’
argument discards qualifiers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When invoking a non-const member function from a const one, GCC issues an error
message like those below.  The error message is ambiguous: it doesn't make is
clear which this it refers to.  In the first case, underling the first "this"
would help.  In the second case rephrasing the error to say something like
"passing ‘const S’ as the implicit ‘this’ argument discards qualifiers" would
help avoid the confusion.

$ cat u.C && gcc -S -Wall u.C
struct S {
  void f (const S*);

  void g () const
  {
this->f (this);   // which 'this?'

f (this); // ditto
  }
};
u.C: In member function ‘void S::g() const’:
u.C:6:18: error: passing ‘const S’ as ‘this’ argument discards qualifiers
[-fpermissive]
 this->f (this);   // which 'this?'
  ^
u.C:2:8: note:   in call to ‘void S::f(const S*)’
   void f (const S*);
^
u.C:8:12: error: passing ‘const S’ as ‘this’ argument discards qualifiers
[-fpermissive]
 f (this); // ditto
^
u.C:2:8: note:   in call to ‘void S::f(const S*)’
   void f (const S*);
^

[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

[ktkachov at gcc dot gnu.org]

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

--- Comment #52 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 20 17:13:16 2018
New Revision: 258687

URL: https://gcc.gnu.org/viewcvs?rev=258687=gcc=rev
Log:
This PR shows that we get the load/store_lanes logic wrong for arm big-endian.
It is tricky to get right. Aarch64 does it by adding the appropriate
lane-swapping
operations during expansion.

I'd like to do the same on arm eventually, but we'd need to port and validate
the VTBL-generating
code and add it to all the right places and I'm not comfortable enough doing it
for GCC 8, but I am keen
in getting the wrong-code fixed.
As I say in the PR, vectorisation on armeb is already severely restricted (we
disable many patterns on BYTES_BIG_ENDIAN)
and the load/store_lanes patterns really were not working properly at all, so
disabling them is not
a radical approach.

The way to do that is to return false in ARRAY_MODE_SUPPORTED_P for
BYTES_BIG_ENDIAN.

Bootstrapped and tested on arm-none-linux-gnueabihf.
Also tested on armeb-none-eabi.


 PR target/82518
 * config/arm/arm.c (arm_array_mode_supported_p): Return false for
 BYTES_BIG_ENDIAN.

 * lib/target-supports.exp (check_effective_target_vect_load_lanes):
 Disable for armeb targets.
 * gcc.target/arm/pr82518.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr82518.c
Modified:
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug middle-end/84997] New: Optimize integer operations on floating point constants without -ffast-math

[antoshkka at gmail dot com]

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

Bug ID: 84997
   Summary: Optimize integer operations on floating point
constants without -ffast-math
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

If it is known at compile time that changing the floating point constant to
integral constant results in exactly the same value, then replace the floating
point operation with integral operation.

For example

int test2(int lhs) {
lhs += 2.0;
return lhs;
}

clang optimizes to the following assembly

test2(int): # @test2(int)
  lea eax, [rdi + 2]
  ret

, while GCC produces a suboptimal assembly:

test(int):
pxorxmm0, xmm0
cvtsi2sdxmm0, edi
addsd   xmm0, QWORD PTR .LC0[rip]
cvttsd2si   eax, xmm0
ret
.LC0:
.long   0
.long   1073741824




More complex examples (where clang fails):

#include 

int test2(int lhs) {
lhs += 2.001;
return lhs;
}

int test3(int lhs) {
constexpr auto fp = 2.001;
constexpr int max = std::numeric_limits::max();
constexpr int min = std::numeric_limits::min();

// Checking that the result is same even with max * epsilon
static_assert(
static_cast(fp + max - fp) == max
&& static_cast(fp + min - fp) == min,
""
);

return fp + lhs - fp;
}

[Bug target/82518] [6/7 Regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 regression]  |[6/7 Regression]
   |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex
   |ecute/in-pack.f90 fails on  |ecute/in-pack.f90 fails on
   |armeb   |armeb

--- Comment #53 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 8. Will backport fix to branches later if no problems

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #18 from Peter Bergner  ---
Author: bergner
Date: Tue Mar 20 17:25:09 2018
New Revision: 258688

URL: https://gcc.gnu.org/viewcvs?rev=258688=gcc=rev
Log:
PR target/83789
* config/rs6000/altivec.md (altivec_lvx__2op): Delete
define_insn.
(altivec_lvx__1op): Likewise.
(altivec_stvx__2op): Likewise.
(altivec_stvx__1op): Likewise.
(altivec_lvx_): New define_expand.
(altivec_stvx_): Likewise.
(altivec_lvx__2op_): New define_insn.
(altivec_lvx__1op_): Likewise.
(altivec_stvx__2op_): Likewise.
(altivec_stvx__1op_): Likewise.
* config/rs6000/rs6000-p8swap.c (rs6000_gen_stvx): Use new expanders.
(rs6000_gen_lvx): Likewise.
* config/rs6000/rs6000.c (altivec_expand_lv_builtin): Likewise.
(altivec_expand_stv_builtin): Likewise.
(altivec_expand_builtin): Likewise.
* config/rs6000/vector.md: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/config/rs6000/rs6000-p8swap.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vector.md

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Adding +0.0 and -0.0 produces +0.0 except in FE_DOWNWARD mode.  I.e., 
optimizing away an addition of +0.0 requires -fno-signed-zeros (not the 
default), as well as -fno-signaling-nans (which is the default).  And if 
you pass -fno-signed-zeros, this code (the first test in this bug) is 
*already* optimized.

It's true that if you add +0.0 to a value that cannot be -0.0 or a 
signaling NaN - such as a value resulting from a conversion from integer 
type - then it's a no-op regardless of compilation options.  So the second 
test could be better optimized.

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #19 from Peter Bergner  ---
Fixed on trunk.

[Bug libstdc++/84998] New: [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

Bug ID: 84998
   Summary: [8 Regression] std::hash fails in
Debug Mode
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#define _GLIBCXX_DEBUG
#include 
int main()
{
  std::bitset<1> b;
  std::hash> h;
  return h(b);
}

In file included from bs.cc:2:
/home/jwakely/gcc/8/include/c++/8.0.1/bitset: In instantiation of 'std::size_t
std::hash >::operator()(const
std::__cxx1998::bitset<_Nb>&) const [with long unsigned int _Nb = 1;
std::size_t = long unsigned int]':
/home/jwakely/gcc/8/include/c++/8.0.1/debug/bitset:421:56:   required from
'std::size_t std::hash >::operator()(const
std::__debug::bitset<_Nb>&) const [with long unsigned int _Nb = 1; std::size_t
= long unsigned int]'
bs.cc:7:13:   required from here
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:1568:30: error: 'const _WordT*
std::__cxx1998::_Base_bitset<1>::_M_getdata() const' is inaccessible within
this context
  return std::_Hash_impl::hash(__b._M_getdata(), __clength);
 ~^
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:415:7: note: declared here
   _M_getdata() const noexcept
   ^~
/home/jwakely/gcc/8/include/c++/8.0.1/bitset:1568:30: error:
'std::__cxx1998::_Base_bitset<1>' is not an accessible base of 'const
std::__cxx1998::bitset<1>'
  return std::_Hash_impl::hash(__b._M_getdata(), __clength);
 ~^

[Bug libstdc++/84998] [8 Regression] std::hash<std::bitset> fails in Debug Mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-20
  Known to work||7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0.1

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #20 from Peter Bergner  ---
Kaushik, remind me, you're seeing the same ICE in GCC 7 as well, so we need a
backport of the patch committed to trunk?

[Bug c/84999] New: [7/8 Regression] ICE in make_vector_type, at tree.c:9561

[gs...@t-online.de]

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

Bug ID: 84999
   Summary: [7/8 Regression] ICE in make_vector_type, at
tree.c:9561
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed before 20171019, ICEs with option -m32 :


$ cat z1.c
void
foo (void)
{
  __attribute__ ((__vector_size__ (4 * sizeof (unsigned __float128 a;
  0 != a;
}


$ gcc-7-20170226 -c z1.c -m64
$ gcc-7-20170226 -c z1.c -m32
$
$ gcc-8-20180318 -c z1.c -m64
$ gcc-8-20180318 -c z1.c -m32
z1.c: In function 'foo':
z1.c:5:3: internal compiler error: Segmentation fault
   0 != a;
   ^
0xaec94f crash_signal
../../gcc/toplev.c:325
0xd3619e make_vector_type
../../gcc/tree.c:9561
0xd367bc build_opaque_vector_type(tree_node*, poly_int<1u, long>)
../../gcc/tree.c:10536
0x68bef3 build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, bool)
../../gcc/c/c-typeck.c:11668
0x68d9d4 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc/c/c-typeck.c:3635
0x6a2b3a c_parser_binary_expression
../../gcc/c/c-parser.c:7037
0x6a31f5 c_parser_conditional_expression
../../gcc/c/c-parser.c:6645
0x6a3780 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6562
0x6a3a02 c_parser_expression
../../gcc/c/c-parser.c:9292
0x6a4f09 c_parser_expression_conv
../../gcc/c/c-parser.c:9325
0x6b4941 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5540
0x6b0bda c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5078
0x6b12e6 c_parser_compound_statement
../../gcc/c/c-parser.c:4912
0x6b29e0 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2341
0x6b8623 c_parser_external_declaration
../../gcc/c/c-parser.c:1644
0x6b9099 c_parser_translation_unit
../../gcc/c/c-parser.c:1524
0x6b9099 c_parse_file()
../../gcc/c/c-parser.c:18411
0x6fbd55 c_common_parse_file()
../../gcc/c-family/c-opts.c:1132

[Bug middle-end/84997] Optimize integer operations on floating point constants without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Tue, 20 Mar 2018, antoshkka at gmail dot com wrote:

> For example
> 
> int test2(int lhs) {
> lhs += 2.0;
> return lhs;
> }

That would need -fno-trapping-math, because if the addition results in a 
double value larger than INT_MAX, under Annex F the conversion back to int 
is defined to raise FE_INVALID along with producing an unspecified value.

> int test2(int lhs) {
> lhs += 2.001;
> return lhs;
> }

That's not correct to optimize unless you generate separate code for lhs 
>= -2 and lhs < -2; conversion from double to int truncates, so test2 (-3) 
== 0.

[Bug c/85000] New: ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:895

[gs...@t-online.de]

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

Bug ID: 85000
   Summary: ICE in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:895
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 :


$ cat z1.c
void
foo (void)
{
  #pragma omp parallel
  {
int n;
int bar (void) { return n; }
n++;
  }
}


$ gcc-8-20180318 -c z1.c -O2
$ gcc-8-20180318 -c z1.c -O2 -fopenmp
during GIMPLE pass: fre
z1.c: In function 'foo._omp_fn.0':
z1.c:10:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:895
 }
 ^
0xc5b7a3 copy_reference_ops_from_ref
../../gcc/tree-ssa-sccvn.c:895
0xc5c665 valueize_shared_reference_ops_from_ref
../../gcc/tree-ssa-sccvn.c:1536
0xc5eb1a vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../gcc/tree-ssa-sccvn.c:2492
0xc637ed visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:3754
0xc637ed visit_use
../../gcc/tree-ssa-sccvn.c:4101
0xc65886 process_scc
../../gcc/tree-ssa-sccvn.c:4332
0xc65886 extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:4434
0xc65886 DFS
../../gcc/tree-ssa-sccvn.c:4484
0xc65d8f sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:4926
0x112cd0f dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xc66849 run_scc_vn(vn_lookup_kind)
../../gcc/tree-ssa-sccvn.c:5033
0xc66f6a execute
../../gcc/tree-ssa-sccvn.c:6015

[Bug c/85000] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:895

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Configured with --enable-checking=yes :


$ gcc-8-20180318 -c z1.c -O2 -fopenmp
during GIMPLE pass: omplower
z1.c: In function 'foo':
z1.c:8:6: internal compiler error: in scan_omp_1_op, at omp-low.c:3014
 n++;
 ~^~
0xb3f192 scan_omp_1_op
../../gcc/omp-low.c:3014
0xf66e22 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11387
0xf67276 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11703
0x9c00f0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:203
0x9c072c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:586
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb3e169 scan_omp
../../gcc/omp-low.c:3205
0xb4a50a scan_omp_parallel
../../gcc/omp-low.c:1796
0xb4a50a scan_omp_1_stmt
../../gcc/omp-low.c:3123
0x9c06fa walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9c07d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9c0918 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb3e169 scan_omp
../../gcc/omp-low.c:3205
0xb5460a execute_lower_omp
../../gcc/omp-low.c:8999
0xb5460a execute
../../gcc/omp-low.c:9056

[Bug target/84828] ICE in verify_flow_info at gcc/cfghooks.c:265

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

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

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Iirc it can't due to signaling nans.

[Bug tree-optimization/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #2 from Jakub Jelinek  ---
C testcase:

/* PR tree-optimization/84960 */
/* { dg-do compile } */
/* { dg-options "-O2 -fwrapv" } */

void
foo (int a, float b, void *c)
{
lab:
  if ((b - (a %= 0) < 1) * -1)
;
  else
{
  long f = a;
  __builtin_unreachable ();
  __builtin_prefetch (&);
}
  goto *c;
}

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|Missing accessor hint for   |Missing accessor hint for
   |private field at -O1 and|private field at -O1 and
   |above   |above when -g is enabled

--- Comment #2 from David Malcolm  ---
Adding -v shows that godbolt.org is silently injecting "-g"; this is also
needed to show the issue i.e. the problem occurs at -O1 and above when -g is
enabled.

[Bug lto/84995] New: Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins

[dilyan.palauzov at aegee dot org]

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

Bug ID: 84995
   Summary: Documentation gcc-ar and gcc-ranlib vs
{libdir}/bfd-plugins
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

While ar, ranlib and nm work with LTO, if the plugin is installed in
{libdir}/bfd-plugin, the gcc manual (Optimizing options) recommends the use of
gcc-ar and gcc-ranlib.

Why doesn't the manual recommend installing instead the plugin under
/bfd-plugin?  

Providing that both gcc and clang offer LTO and provide linker plugins, none of
them installs by default the plugins under {libdir}/bfd-plugins, gcc recommends
the usage of gcc-ar/gcc-ranlib, clang installs instead clang-ar/clang-ranlib,
how are ./configure scripts supposed to be written in portable way to enable
LTO compilation?

If several gcc versions are installed on a system and hence
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so.0.0.0 and
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0
co-exist, will gcc-ar always use
/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0, if the code is compiled
with x86_64-pc-linux-gnu-gcc-6.4.1?

[Bug lto/84934] Installing the lto plugin where binutils will look for it

[dilyan.palauzov at aegee dot org]

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

--- Comment #4 from Дилян Палаузов  ---
Oh, I have typed on this matter already in the past:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345

[Bug rtl-optimization/84989] [8 Regression] _mm512_broadcast_f32x4 triggers ICE in simplify_const_unary_operation, at simplify-rtx.c:1731

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 43721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43721=edit
gcc8-pr84989.patch

Untested fix.  VEC_DUPLICATE is very unlike other unary ops.

[Bug middle-end/84996] New: Adding or substracting 0.0 could be optimized away even without -ffast-math

[antoshkka at gmail dot com]

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

Bug ID: 84996
   Summary: Adding or substracting 0.0 could be optimized away
even without -ffast-math
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The code 

float test(float lhs) { return lhs + 0.0; }

generates suboptimal assembly

test(float):
addss   xmm0, DWORD PTR .LC0[rip]
ret
.LC0:
.long   0



Optimal assembly would be 

test(float): # @test(float)
  ret

[Bug middle-end/84996] Adding or substracting 0.0 could be optimized away even without -ffast-math

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
Then let's change the example to 

int test(int lhs) {
return 0.0 + lhs;
}

In that case no signaling Nan is possible, but the code still does additions

test(int):
pxorxmm0, xmm0
cvtsi2sdxmm0, edi
addsd   xmm0, QWORD PTR .LC0[rip]
cvttsd2si   eax, xmm0
ret

[Bug target/83660] ICE with vec_extract inside expression statement

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #7 from Will Schmidt  ---
The ICE is triggered on the gcc_unreachable() at the bottom of the
switch(gimple_code(stmt)) clause in gimple-low.c: lower_stmt().

We enter the switch with our gimple_code(stmt) == GIMPLE_WITH_CLEANUP_EXPR.

# cfun at this point is:
(gdb) pcfun
get_word (__vector __bool int v)
{
  unsigned int D.3236;

  {
const unsigned int _B2;

_B2 = 32;
D.3235 = v;
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

retval.0 = BIT_FIELD_REF ;
  }
  D.3236 = retval.0;
  return D.3236;
}


Doing some code-browsing, I see some logic to handle GIMPLE_WITH_CLEANUP_EXPR
in remap_gimple_stmt() and in gimple_copy() , but not in lower_stmt().

However, at gimplify.c: gimplify_cleanup_point_expr() i see the comment:

/* Gimplify a CLEANUP_POINT_EXPR.  Currently this works by adding
   GIMPLE_WITH_CLEANUP_EXPRs to the prequeue as we encounter cleanups while
   gimplifying the body, and converting them to TRY_FINALLY_EXPRs when we
   return to this function.

Debug on the logic there...
  for (iter = gsi_start (body_sequence); !gsi_end_p (iter); )
{
  gimple *wce = gsi_stmt (iter);
  if (gimple_code (wce) == GIMPLE_WITH_CLEANUP_EXPR)

does not show any matches with GIMPLE_WITH_CLEANUP_EXPR. (one GIMPLE_ASSIGN, 3
GIMPLE_BIND).  so we're not catching and generating TRY_FINALLY_EXPRS on the
way out like we want or need to.

(I can scratch and dig around some more,.. but could use a hint or do a
hand-off to someone..  :-)   



Additional debug, possibly not relevant:
During (first?) gimple pass, we get to gimple_build_wce by way of multiple
calls through ..  hard to paraphrase, heres the bt. 

(gdb) bt
#0  0x1088da08 in gimple_build_wce (cleanup=0x109e00f0) at
gimple.c:742
#1  0x108e9984 in gimple_push_cleanup (var=0x10080a20,
cleanup=, eh_only=false, pre_p=0x3fffd7a0,
force_uncond=true) at gimplify.c:6528
#2  0x108f7cbc in gimplify_target_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390) at gimplify.c:6611
#3  0x108e3410 in gimplify_expr (expr_p=0x106b0d38,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x1089b130
, 
fallback=) at gimplify.c:11815
#4  0x108e2f28 in gimplify_expr (expr_p=0x108c8e50,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d1660
, 
fallback=1) at gimplify.c:11739
#5  0x108f9cdc in gimplify_modify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, want_value=false) at
gimplify.c:5626
#6  0x108e3430 in gimplify_expr (expr_p=0x106ff598,
pre_p=0x3fffd7a0, post_p=0x3fffd390, gimple_test_f=0x108d6cc0
, fallback=0)
at gimplify.c:11435
#7  0x108e7288 in gimplify_stmt (stmt_p=,
seq_p=0x3fffd7a0) at gimplify.c:6658
#8  0x108e402c in gimplify_statement_list (pre_p=,
expr_p=0x106b0c80) at gimplify.c:1767
#9  gimplify_expr (expr_p=0x106b0c80, pre_p=0x3fffd7a0,
post_p=0x3fffd5c0, gimple_test_f=0x108d6cc0 ,
fallback=0) at gimplify.c:11863
#10 0x108e72dc in gimplify_stmt (stmt_p=0x106b0c80,
seq_p=0x3fffd7a0) at gimplify.c:6658
#11 0x108e8b8c in gimplify_bind_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0) at gimplify.c:1335
#12 0x108e31ec in gimplify_expr (expr_p=0x108c8e00,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d1660
, 
fallback=1) at gimplify.c:11635
#13 0x108f9cdc in gimplify_modify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, want_value=false) at
gimplify.c:5626
#14 0x108e3430 in gimplify_expr (expr_p=0x3fffde70,
pre_p=0x3fffe0d0, post_p=0x3fffdc20, gimple_test_f=0x108d6cc0
, fallback=0)
at gimplify.c:11435
#15 0x108e72dc in gimplify_stmt (stmt_p=0x3fffde70,
seq_p=0x3fffe0d0) at gimplify.c:6658
#16 0x108e3cc0 in gimplify_and_add (seq_p=0x3fffe0d0, t=) at gimplify.c:441
#17 gimplify_return_expr (pre_p=0x3fffe0d0, stmt=) at
gimplify.c:1571
#18 gimplify_expr (expr_p=0x109b4bd8, pre_p=0x3fffe0d0,
post_p=0x3fffde50, gimple_test_f=0x108d6cc0 ,
fallback=0) at gimplify.c:11695
#19 0x108e72dc in gimplify_stmt (stmt_p=,
seq_p=0x3fffe0d0) at gimplify.c:6658
#20 0x108e3050 in gimplify_cleanup_point_expr (pre_p=,
expr_p=0x106b0cb0) at gimplify.c:6400
#21 gimplify_expr (expr_p=0x106b0cb0, pre_p=0x3fffe260,
post_p=0x3fffe080, gimple_test_f=0x108d6cc0 

[Bug target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Oops I think I missed the artificial defs. Then the liveness makes sense.
> Out of curiosity why are all the argument register defined? This function
> for instance does not need 4 argument register.

Historical quirk inherited from the original flow.c I presume.

[Bug c/84999] [7/8 Regression] ICE in make_vector_type, at tree.c:9561

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-20
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.0.1

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

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres  ---
> Dominique, can you check whether it also fixes the other -fdefault-real-8 -m32
> issues caused by r256284?

Preliminary tests show that all the failures reported in comment 0 are fixed by
the patch except:

% gfc -m32 -fdefault-integer-8
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/assumed_rank_1.f90
/opt/gcc/p_work/gcc/testsuite/gfortran.dg/assumed_rank_1_c.c
cc1: warning: command line option '-fdefault-integer-8' is valid for Fortran
but not for C
% ./a.out   
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Full test scheduled for tonight. Thanks for the patch.