[Bug target/85075] New: powerpc: ICE in iszero testcase

[raji at linux dot vnet.ibm.com]

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

Bug ID: 85075
   Summary: powerpc: ICE in iszero testcase
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raji at linux dot vnet.ibm.com
  Target Milestone: ---

> cat test-math-iszero.cc
#include 
int
main (void)
{
  long double q1 = 0;
  _Float128 q = 0;

  iszero (q1);
  iszero (q);
  return 0;
}

>  g++-8 test-math-iszero.cc   -mfloat128 -mabi=ieeelongdouble -Wno-psabi 
test-math-iszero.cc:11:1: error: Two symbols with same comdat_group are not
linked by the same_comdat_group list.
 }
 ^
_Z6iszeroIU10__float128EbT_/175 (bool iszero(__T) [with __T = __ieee128])
@0x7fffa4cc5a90
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_Z6iszeroIU10__float128EbT_ one_only
  previous sharing asm name: 174
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: int main()/173 
  Calls: 
_Z6iszeroIU10__float128EbT_/174 (bool iszero(__T) [with __T = long double])
@0x7fffa4cc5920
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_Z6iszeroIU10__float128EbT_ one_only
  next sharing asm name: 175
  References: 
  Referring: 
  First run: 0
  Function flags: body
  Called by: int main()/173 
  Calls: 
test-math-iszero.cc:11:1: internal compiler error: symtab_node::verify failed
0x7fffa8eb429b ???
../csu/libc-start.c:308
0x7fffa8eb4497 ???
../sysdeps/unix/sysv/linux/powerpc/libc-start.c:102
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

> g++-8 --version
g++-8 (SUSE Linux) 8.0.1 20180226 (experimental) [trunk revision 257983]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> ld --version
GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.30.0.20180226-1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

> ldd --version
ldd (GNU libc) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

[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 #32 from Pedro Alves  ---
In that case, I think the "something something" you're looking for can be 
char_trait's __constant_char_array_p:

+ if (__constant_char_array_p(__first1, __len)
+ && __constant_char_array_p(__first2, __len))
+   return __equal::equal(__first1, __last1, __first2);

I've done a quick test here, and it works AFAICT.  Below's a standalone and
slightly simplified version of std::equal with that change.  The static asserts
don't fail, and the result at run time looks right too.

At -O0, the (runtime calls to) std::equal stay around, but AFAICT, there's no
code generated for the __builtin_constant_p checks/loop in
__constant_char_array_p.

Disassembling the generated code at -O2 I see that g++ fully optimizes out the
equal1/equal2/equal2 calls to constant "1".  

Interestingly, the trick makes g++ optimize the test _better_ than the same
code _without_ the __builtin_constant_p (i.e, better than current trunk). 
Without the __builtin_char_array_p detour, we end up with calls to memcmp in
the generated code instead of constant folding out everything.  (you'll need to
comment out the static_assert calls too to try that out, of course.)
ISTR having observed something like this this too with the char_traits changes,
though I'm not sure I ever mentioned it.

I've tried to increase the size of the arrays in the test to check whether
that'd fool the optimizers, but it still works.  If you increase the size
enough, you'll hit the -fconstexpr-loop-limit limit, in the loop inside
__builtin_char_array_p, but you'd hit the exact same limit in the
__equal::equal's for loop anyway.  Bumping that limit, the test still
works, though of course compilation takes noticeably longer.


#include 
#include 
#include 

namespace my_std
{
  /* This is currently in char_traits, could/should probably move
 elsewhere.  */
  template
static _GLIBCXX_ALWAYS_INLINE constexpr bool
__constant_char_array_p(const _CharT* __a, size_t __n)
{
  size_t __i = 0;
  while (__builtin_constant_p(__a[__i]) && __i < __n)
__i++;
  return __i == __n;
}

  template
struct __equal
{
  template
static constexpr bool
equal(_II1 __first1, _II1 __last1, _II2 __first2)
{
  for (; __first1 != __last1; ++__first1, (void) ++__first2)
if (!(*__first1 == *__first2))
  return false;
  return true;
}
};

  template<>
struct __equal
{
  template
  static constexpr bool
equal(const _Tp* __first1, const _Tp* __last1, const _Tp* __first2)
{
  if (const size_t __len = (__last1 - __first1))
{
#if 1
  // new bits are here
  if (__constant_char_array_p(__first1, __len)
  && __constant_char_array_p(__first2, __len))
return __equal::equal(__first1, __last1, __first2);
#endif

  return !__builtin_memcmp(__first1, __first2, sizeof(_Tp) *
__len);
}
  return true;
}
};

  template
  constexpr inline bool
  equal(_II1 __first1, _II1 __last1, _II2 __first2)
  {
  typedef typename std::iterator_traits<_II1>::value_type _ValueType1;
  typedef typename std::iterator_traits<_II2>::value_type _ValueType2;
  const bool __simple = ((std::__is_integer<_ValueType1>::__value
  || std::__is_pointer<_ValueType1>::__value)
 && std::__is_pointer<_II1>::__value
 && std::__is_pointer<_II2>::__value
 && std::__are_same<_ValueType1,
_ValueType2>::__value);

  return my_std::__equal<__simple>::equal(__first1, __last1, __first2);
}
}

struct S
{
  constexpr bool operator==(const S& rhs)
  {
return i == rhs.i;
  }

  int i = 0;
};

template
constexpr bool equal1()
{
  T s1[400] = {1, 2, 3, 1, 2, 3};
  T s2[400] = {1, 2, 3, 1, 2, 3};

  const size_t count = sizeof (s1) / sizeof (s1[0]);

  return (my_std::equal(s1, s1 + 3, s2 + 3)
  && !my_std::equal(s1, s1 + 1, s2 + 1)
  && my_std::equal(s1, s1 + count, s2));
}

constexpr bool equal2()
{
  int i1 = 0;
  int i2 = 0;

  return (my_std::equal(,  + 1, ));
}

constexpr bool equal3()
{
  S s1[400];
  S s2[400];

  const size_t count = sizeof (s1) / sizeof (s1[0]);

  for (size_t i = 0; i < count; i++)
s1[i].i = s2[i].i = i;

  return (my_std::equal(s1, s1 + count, s2)
  && !my_std::equal(s1, s1 + 1, s2 + 1));
}

// disable if you disable the new bits above too.
#if 1
static_assert (equal1());
static_assert (equal1());
static_assert (equal1());
static_assert (equal2());
static_assert (equal3());
#endif

int
main ()
{
#define TEST(EXPR) \
  printf (#EXPR " = %d\n", (int) EXPR)

  TEST (equal1());
  TEST (equal1());
  TEST (equal1());
  TEST (equal2());
  TEST (equal3());

  return 

[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
> Switch conversion triggers for this example, which introduces 
> a function static var,

Hmm, that was my impression from PR84592 comment 5, and the comments in
tree-switch-conversion.c.

When I compile this example, the only relevant difference I can observe is
DECL_CONTEXT:
...
static int a;

void
foo (void)
{
  static int b;
}
...

For variable a, DECL_CONTEXT starts out NULL, and then becomes the translation
unit decl during parsing.  For variable, DECL_CONTEXT is foo.

When I debug an example that triggers switch conversion the DECL_CONTEXT for
CSWTCH.x is NULL, and remains like that.

So, in the end, I'm not quite sure whether I can say that CSWTCH.x is a file or
function scope static.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
Removing the size() in the print and the unneeded declaration of ,
one gets a different ICE:

  character(len=5) :: str(3)
  call f(str(:))
contains
  subroutine f(x)
   character(len=*) :: x(:)
   print *,  x(:)(1:)
  end subroutine f
end

Program received signal SIGSEGV, Segmentation fault.
gfc_conv_expr (se=0xbfffe134, expr=0x0)
at ../../trunk/gcc/fortran/trans-expr.c:7891
7891  if (expr->ts.type == BT_DERIVED && expr->ts.u.derived->ts.f90_type ==
BT_VOID

(gdb) print expr
$2 = (gfc_expr *) 0x0

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Fixed

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Thomas Koenig  ---
Now fixed (finally, I hope).

At least I didn't find anything else.

[Bug fortran/84094] several correctness issues in gfortran.dg

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094
Bug 84094 depends on bug 84381, which changed state.

Bug 84381 Summary: replace non-std 'call abort' by 'stop 1' in gfortran 
testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

--- Comment #18 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 25 16:00:52 2018
New Revision: 258846

URL: https://gcc.gnu.org/viewcvs?rev=258846=gcc=rev
Log:
2018-03-25  Thomas Koenig  

PR fortran/84381
* testsuite/libgomp.fortran/aligned1.f03: Replace non-standard
call abort by STOP n.
* testsuite/libgomp.fortran/alloc-comp-1.f90: Likewise.
* testsuite/libgomp.fortran/alloc-comp-2.f90: Likewise.
* testsuite/libgomp.fortran/alloc-comp-3.f90: Likewise.
* testsuite/libgomp.fortran/allocatable1.f90: Likewise.
* testsuite/libgomp.fortran/allocatable10.f90: Likewise.
* testsuite/libgomp.fortran/allocatable11.f90: Likewise.
* testsuite/libgomp.fortran/allocatable12.f90: Likewise.
* testsuite/libgomp.fortran/allocatable2.f90: Likewise.
* testsuite/libgomp.fortran/allocatable3.f90: Likewise.
* testsuite/libgomp.fortran/allocatable4.f90: Likewise.
* testsuite/libgomp.fortran/allocatable5.f90: Likewise.
* testsuite/libgomp.fortran/allocatable6.f90: Likewise.
* testsuite/libgomp.fortran/allocatable7.f90: Likewise.
* testsuite/libgomp.fortran/allocatable8.f90: Likewise.
* testsuite/libgomp.fortran/allocatable9.f90: Likewise.
* testsuite/libgomp.fortran/appendix-a/a.18.1.f90: Likewise.
* testsuite/libgomp.fortran/appendix-a/a.19.1.f90: Likewise.
* testsuite/libgomp.fortran/associate1.f90: Likewise.
* testsuite/libgomp.fortran/associate2.f90: Likewise.
* testsuite/libgomp.fortran/associate3.f90: Likewise.
* testsuite/libgomp.fortran/cancel-do-1.f90: Likewise.
* testsuite/libgomp.fortran/cancel-do-2.f90: Likewise.
* testsuite/libgomp.fortran/cancel-parallel-1.f90: Likewise.
* testsuite/libgomp.fortran/cancel-sections-1.f90: Likewise.
* testsuite/libgomp.fortran/cancel-taskgroup-2.f90: Likewise.
* testsuite/libgomp.fortran/character1.f90: Likewise.
* testsuite/libgomp.fortran/character2.f90: Likewise.
* testsuite/libgomp.fortran/collapse1.f90: Likewise.
* testsuite/libgomp.fortran/collapse2.f90: Likewise.
* testsuite/libgomp.fortran/collapse3.f90: Likewise.
* testsuite/libgomp.fortran/collapse4.f90: Likewise.
* testsuite/libgomp.fortran/crayptr1.f90: Likewise.
* testsuite/libgomp.fortran/crayptr2.f90: Likewise.
* testsuite/libgomp.fortran/crayptr3.f90: Likewise.
* testsuite/libgomp.fortran/declare-simd-1.f90: Likewise.
* testsuite/libgomp.fortran/declare-simd-3.f90: Likewise.
* testsuite/libgomp.fortran/declare-target-2.f90: Likewise.
* testsuite/libgomp.fortran/depend-1.f90: Likewise.
* testsuite/libgomp.fortran/depend-2.f90: Likewise.
* testsuite/libgomp.fortran/depend-3.f90: Likewise.
* testsuite/libgomp.fortran/do1.f90: Likewise.
* testsuite/libgomp.fortran/do2.f90: Likewise.
* testsuite/libgomp.fortran/doacross1.f90: Likewise.
* testsuite/libgomp.fortran/doacross2.f90: Likewise.
* testsuite/libgomp.fortran/doacross3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/array_sections-3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/array_sections-4.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/async_target-1.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/async_target-2.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/declare_target-3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/declare_target-4.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/declare_target-5.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/device-1.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/device-2.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/device-3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-1.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-2.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-4.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-5.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-6.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-7.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/simd-8.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/target-1.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/target-2.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/target-3.f90: Likewise.
* testsuite/libgomp.fortran/examples-4/target-4.f90: Likewise.
   

[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|jvdelisle at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #7 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #6)
> From the F2009 standard:
> 
> If the format is a character array, it is treated as if all of the elements
> of the array were specified in array element
> order and were concatenated. However, if a format is a character array
> element, the format specification shall be
> entirely within that array element.
> 
> So, we need a concatenation of the array elements. Sounds entirely doable.
> 
> Jerry, if you want me to do it, just say so.

Please take.

[Bug fortran/84924] Erroneous error in C_F_POINTER

[johnsonsr at ornl dot gov]

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

--- Comment #9 from Seth Johnson  ---
Thanks guys for the fast fix and review!

[Bug tree-optimization/85063] Switch conversion in openacc routine introduces unsupported construct

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 43751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43751=edit
Tentative patch that doesn't disable the switch conversion optimization

(In reply to Jakub Jelinek from comment #3)
> So just make it a file scope static var instead, instead of disabling the
> optimization?

This patch enables the optimization (without changing the scope of the var).

[Bug middle-end/85074] New: FAIL: g++.dg/torture/pr81812.C (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 85074
   Summary: FAIL: g++.dg/torture/pr81812.C (test for excess
errors)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../xg++
-B/
home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../
/home/dave/gnu/gcc/gcc/gcc/te
stsuite/g++.dg/torture/pr81812.C -fno-diagnostics-show-caret
-fdiagnostics-color
=never -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/inclu
de/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/includ
e -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libst
dc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-f
message-length=0 -O0 -S -o pr81812.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr81812.C:6:8: error:
generi
c thunk code fails for method 'virtual void
ChildNode::_ZTv0_n12_NK9ChildNode5er
rorEz(...) const' which uses '...'
compiler exited with status 1
FAIL: g++.dg/torture/pr81812.C   -O0  (test for excess errors)

[Bug fortran/84693] scalar DT not broadcast across an array in an initialization expression

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
Does not appear to be a regression.

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 25 12:46:31 2018
New Revision: 258845

URL: https://gcc.gnu.org/viewcvs?rev=258845=gcc=rev
Log:
2018-03-24  Thomas Koenig  

PR fortran/84381
* gfortran.dg/bound_simplification_3.f90: Replace "abort" by
"_gfortran_stop" in scan-tree-dump-times directive.
* gfortran.dg/bound_simplification_4.f90: Likewise.
* gfortran.dg/bound_simplification_5.f90: Likewise.
* gfortran.dg/bound_simplification_6.f90: Likewise.
* gfortran.dg/complex_intrinsic_7.f90: Likewise.
* gfortran.dg/dot_product_2.f90: Likewise.
* gfortran.dg/iso_fortran_env_5.f90: Likewise.
* gfortran.dg/minmaxloc_12.f90: Likewise.
* gfortran.dg/minmaxloc_13.f90: Likewise.
* gfortran.dg/parameter_array_element_3.f90: Likewise.
* gfortran.dg/shape_7.f90: Likewise.
* gfortran.dg/storage_size_4.f90: Likewise.
* gfortran.dg/string_length_2.f90: Likewise.

Modified:
trunk/gcc/testsuite/gfortran.dg/bound_simplification_3.f90
trunk/gcc/testsuite/gfortran.dg/bound_simplification_4.f90
trunk/gcc/testsuite/gfortran.dg/bound_simplification_5.f90
trunk/gcc/testsuite/gfortran.dg/bound_simplification_6.f90
trunk/gcc/testsuite/gfortran.dg/complex_intrinsic_7.f90
trunk/gcc/testsuite/gfortran.dg/dot_product_2.f90
trunk/gcc/testsuite/gfortran.dg/iso_fortran_env_5.f90
trunk/gcc/testsuite/gfortran.dg/shape_7.f90
trunk/gcc/testsuite/gfortran.dg/storage_size_4.f90
trunk/gcc/testsuite/gfortran.dg/string_length_2.f90

[Bug fortran/84094] several correctness issues in gfortran.dg

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094
Bug 84094 depends on bug 84381, which changed state.

Bug 84381 Summary: replace non-std 'call abort' by 'stop 1' in gfortran 
testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #16 from Dominique d'Humieres  ---
> Fixed (completely this time, one can hope).

Nope: see comments 9 and 10.

[Bug fortran/84094] several correctness issues in gfortran.dg

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094
Bug 84094 depends on bug 84381, which changed state.

Bug 84381 Summary: replace non-std 'call abort' by 'stop 1' in gfortran 
testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Thomas Koenig  ---
Fixed (completely this time, one can hope).

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 25 12:23:58 2018
New Revision: 258844

URL: https://gcc.gnu.org/viewcvs?rev=258844=gcc=rev
Log:
2018-03-25  Thomas Koenig  
Neil Carlson 

PR fortran/84381
* gfortran.dg/literal_character_constant_1.inc: Replace
call abort by STOP n.
* gfortran.dg/overload_1.f90: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/literal_character_constant_1.inc
trunk/gcc/testsuite/gfortran.dg/overload_1.f90

[Bug target/85073] New: [x86] extra check after BLSR

[wojciech_mula at poczta dot onet.pl]

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

Bug ID: 85073
   Summary: [x86] extra check after BLSR
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech_mula at poczta dot onet.pl
  Target Milestone: ---

GCC is able to use the BLSR instruction in place of expression (x - 1) & x
[which is REALLY nice, thank you :)], but does not utilize CPU flags set by the
instruction. Below is a simple example.

--bmi1.c--
int popcount(unsigned x) {
int c = 0;
while (x) {
c += 1;
x = (x - 1) & x;
}

return c;
}
--eof--

$ gcc --version
gcc (Debian 7.3.0-11) 7.3.0

$ gcc -march=skylake -O3 -s bmi1.c && cat bmi1.s

popcount:
.LFB0:
xorl%eax, %eax
testl   %edi, %edi
je  .L4
.L3:
addl$1, %eax
blsr%edi, %edi <<< HERE
testl   %edi, %edi <<< and HERE
jne .L3
ret
.L4:
ret

BLSR sets the ZF flag if the result is zero. The subsequent TEST instruction is
not needed.

[Bug c++/85072] New: g++ -O1 consumes all memory

[fabian.loeschner at live dot de]

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

Bug ID: 85072
   Summary: g++ -O1 consumes all memory
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian.loeschner at live dot de
  Target Milestone: ---

Created attachment 43750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43750=edit
Example code to reproduce issue, extracts to approx. 5.3MB

Compiling the attached code (uncompressed: 5MB) consumes more than 12GB memory
with -O1 optimization. I cannot test it with more memory at the moment. Using
-O0 does not result in this issue.

The code is generated code (automated solution of partial differential
equations, FEniCS framework) and consists of 1936 subsequent assignment
statements of the form

A[i++] = some_double_literal * B[some_index] + other_double_literal *
B[some_index] + ...

with around 90 summands per assignment (> 3000 characters per line).

It is not clear to me which optimizer is specifically responsible for the
issue, as adding all -fno flags that are supposedly different from -O0
(determined using -Q --help=optimizers), i.e.:

-fno-tree-ter -fno-tree-sra -fno-tree-slsr -fno-tree-sink -fno-tree-pta
-fno-tree-fre -fno-tree-dse -fno-tree-dominator-opts -fno-tree-dce
-fno-tree-copy-prop -fno-tree-coalesce-vars -fno-tree-ch -fno-tree-ccp
-fno-tree-builtin-call-dce -fno-tree-bit-ccp -fno-ssa-phiopt
-fno-split-wide-types -fno-shrink-wrap -fno-reorder-blocks
-fno-omit-frame-pointer -fno-move-loop-invariants -fno-ipa-reference
-fno-ipa-pure-const -fno-ipa-profile -fno-inline-functions-called-once
-fno-if-conversion2 -fno-if-conversion -fno-guess-branch-probability
-fno-forward-propagate -fno-defer-pop -fno-cprop-registers -fno-compare-elim
-fno-combine-stack-adjustments -fno-branch-count-reg

only results in slower grow of memory consumption but it still does not
terminate with a sensible amount of memory.

[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
From the F2009 standard:

If the format is a character array, it is treated as if all of the elements of
the array were specified in array element
order and were concatenated. However, if a format is a character array element,
the format specification shall be
entirely within that array element.

So, we need a concatenation of the array elements. Sounds entirely doable.

Jerry, if you want me to do it, just say so.

[Bug fortran/84924] Erroneous error in C_F_POINTER

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
Closing as FIXED.

[Bug fortran/84924] Erroneous error in C_F_POINTER

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Mar 25 11:30:24 2018
New Revision: 258843

URL: https://gcc.gnu.org/viewcvs?rev=258843=gcc=rev
Log:
2018-03-25  Seth Johnson 
Dominique d'Humieres  

PR fortran/84924
* check.c (gfc_check_c_f_pointer): Allow scalar noninteroperable
scalar derived type with -std=f2003 and -std=f2008.

2018-03-25  Seth Johnson 
Dominique d'Humieres  

PR fortran/84924
* gfortran.dg/scalar_pointer_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/scalar_pointer_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85071] New: The g++ delete the memory alloced by new operator before I manually delete it.

[141242068 at smail dot nju.edu.cn]

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

Bug ID: 85071
   Summary: The g++ delete the memory alloced by new operator
before I manually delete it.
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The code is too long, but I have tried my best to simplify the codes. Raw code
is 14000 lines and now is 218 lines, and the bug can only be triggered under
complicated codes logic.

Firstly, the IntrusiveRefCntPtr, to avoid my own mistakes on this template
class, I copy it from llvm/ADT/IntrusiveRefCntPtr.h:

$ cat IntrusiveRefCntPtr.h
#ifndef INTRUSIVEREFCNTPTR_H
#define INTRUSIVEREFCNTPTR_H

// IntrusiveRefCntPtr
template  class RefCountedBase {
mutable unsigned RefCount = 0;

public:
RefCountedBase() = default;
RefCountedBase(const RefCountedBase &) {}

void Retain() const { ++RefCount; }

void Release() const {
assert(RefCount > 0 && "Reference count is already zero.");
if (--RefCount == 0)
delete static_cast(this);
}
};


template  struct IntrusiveRefCntPtrInfo {
static void retain(T *obj) { obj->Retain(); }
static void release(T *obj) { obj->Release(); }
};

template  class IntrusiveRefCntPtr {
T *Obj = nullptr;

public:
using element_type = T;

explicit IntrusiveRefCntPtr() = default;
IntrusiveRefCntPtr(T *obj) : Obj(obj) { retain(); }
IntrusiveRefCntPtr(const IntrusiveRefCntPtr ) : Obj(S.Obj) {
retain(); }
IntrusiveRefCntPtr(IntrusiveRefCntPtr &) : Obj(S.Obj) { S.Obj =
nullptr; }

template 
IntrusiveRefCntPtr(IntrusiveRefCntPtr &) : Obj(S.get()) {
S.Obj = nullptr;
}

template 
IntrusiveRefCntPtr(const IntrusiveRefCntPtr ) :
Obj(S.get()) {
retain();
}

~IntrusiveRefCntPtr() { release(); }

IntrusiveRefCntPtr =(IntrusiveRefCntPtr S) {
swap(S);
return *this;
}

T *() const { return *Obj; }
T *operator->() const { return Obj; }
T *get() const { return Obj; }
explicit operator bool() const { return Obj; }

void swap(IntrusiveRefCntPtr ) {
T *tmp = other.Obj;
other.Obj = Obj;
Obj = tmp;
}

void reset() {
release();
Obj = nullptr;
}

void resetWithoutRelease() { Obj = nullptr; }

private:
void retain() {
if (Obj)
IntrusiveRefCntPtrInfo::retain(Obj);
}

void release() {
if (Obj)
IntrusiveRefCntPtrInfo::release(Obj);
}

template  friend class IntrusiveRefCntPtr;
};

#endif


And then is the header.h:

$ cat Header.h
#ifndef HEADER_H
#define HEADER_H

#include 
#include 
#include 
#include 
#include 

#include "IntrusiveRefCntPtr.h"

class Block;
class Context;
class Function;
class Module;
class Scope;
using BlockPtr = std::shared_ptr;
using ScopePtr = std::shared_ptr;

#define errs() \
(std::clog << "\e[31m[ERR]\e[0m:" << __FILE__ << ":" << __LINE__ << ":")
#define logs() \
(std::clog << "\e[34m[LOG]\e[0m:" << __FILE__ << ":" << __LINE__ << ":")

class SyntaxElement {
public:
SyntaxElement() = default;

virtual void onEnter(Context *context)
{ /* do something by derived class */ }

virtual ~SyntaxElement() = default;
};

class Function : public RefCountedBase, public SyntaxElement {
ScopePtr scope;

public:

Function() = default;

void details() const {
logs() << "scope info: ptr=" << scope.get()
<< ", count=" << scope.use_count() << "\n";
}

void onEnter(Context *context) override;

~Function()
{ errs() << "destructor called@" << this << "\n"; }
};

using FunctionPtr = IntrusiveRefCntPtr;

class Block : public SyntaxElement {
FunctionPtr func;
public:
Block(FunctionPtr func) : func(func) { }
};

class Context {
Module *M;
Function *F;
public:
Context() = default;
void setAvailableCallees();
void setModule(Module *M);
void setFunction(Function *F);
};

class Module : public SyntaxElement {
public:
Module() = default;
bool hasCalleesFor(IntrusiveRefCntPtr func) const
{ return true; }
};


class Scope { };

#endif


Finally plus the main.cc:

$ cat main.cc
#include "Header.h"
#include 

static Context cxt;
void Context::setModule(Module *M) { this->M = M; }
void Context::setFunction(Function *F) { this->F = F; 

[Bug c++/85070] New: ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409

[su at cs dot ucdavis.edu]

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

Bug ID: 85070
   Summary: ICE on C++ code: in lazily_declare_fn, at
cp/method.c:2409
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180324 (experimental) [trunk revision 258835] (GCC) 
$ 
$ g++tk -std=c++11 tmp.cpp -c
$ 
$ g++tk -std=c++14 tmp.cpp -c
tmp.cpp:8:8: error: ‘constexpr A& A::operator=(const A&)’ cannot be overloaded
with ‘constexpr A& B::operator=(const A&)’
 struct A : B
^
tmp.cpp:5:17: note: previous declaration ‘constexpr A& B::operator=(const A&)’
   constexpr A & operator= (const A &);
 ^~~~
tmp.cpp:11:11: internal compiler error: in lazily_declare_fn, at
cp/method.c:2409
 } a { a = a };
   ^
0x7dadb5 lazily_declare_fn(special_function_kind, tree_node*)
../../gcc-source-trunk/gcc/cp/method.c:2409
0x7e2bdc get_class_binding(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/name-lookup.c:1309
0x8b7a75 lookup_field_r
../../gcc-source-trunk/gcc/cp/search.c:977
0x8b688e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc-source-trunk/gcc/cp/search.c:1410
0x8b6a51 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc-source-trunk/gcc/cp/search.c:1134
0x8b6e13 lookup_fnfields(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/search.c:1330
0x6d2006 build_new_op_1
../../gcc-source-trunk/gcc/cp/call.c:5694
0x6d2e1e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:6058
0x91d707 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8055
0x91ecec build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8301
0x8036ee cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9532
0x804513 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9772
0x8049f7 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21931
0x804b3d cp_parser_initializer_list
../../gcc-source-trunk/gcc/cp/parser.c:22198
0x804b3d cp_parser_braced_list
../../gcc-source-trunk/gcc/cp/parser.c:21969
0x8079b6 cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21887
0x82a6f1 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19686
0x82c1c8 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13067
0x82d04f cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12885
0x838910 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


struct A;

struct B
{
  constexpr A & operator= (const A &); 
};

struct A : B
{
  using B::operator=;
} a { a = a };

[Bug driver/82806] New: Stabilize paths in assembler and dumps

[vries at gcc dot gnu.org]

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

Bug ID: 82806
   Summary: Stabilize paths in assembler and dumps
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Recently I've run  into the following issues:

1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 "Bug 82415 - FAIL:
gcc.target/i386/naked-1.c scan-assembler-not ret".
I build and tested gcc in a directory with "ret" in the path, and an assembler
scan triggered on that.

2. https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00055.html.
I build and tested gcc in a directory with "while" in the path, and a tree-dump
scan triggered on that.

I wonder if we can add a gcc option -fstrip-path[=] that strips (or
replaces with a constant string) paths in compiler output such as dumps and
assembler.

By using by default fstrip-path="stripped-path" or some such in the testsuite,
we can stabilize compiler output and reduce noise in the testsuite.

--- Comment #1 from Tom de Vries  ---
3. https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01357.html
vrp104.c scan-tree-dump-times "switch"
I build and tested gcc in a directory with switch in the path, and an tree-dump
scan triggered on that.