[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #1 from Maxim Ostapenko  ---
This bug also happens on current trunk. Consider slightly reduced testcase
(just part of Christof's one):

#include 
#include 

struct Simple {
  int value;
};

int f(struct Simple simple) {
  return simple.value;
}


int main() {
  int *pint = (int *) malloc(sizeof(int));
  *pint = 24;
  free(pint);
  printf("%d\n", g(*pint));
  return 0;
}

Corresponding gimple dump:

main ()
{
  int D.3060;
  int D.3061;

  {
struct Simple * psimple;

psimple = malloc (4);
psimple->value = 42;
free (psimple);
D.3060 = f (*psimple);   <===
printf ("%d\n", D.3060);
D.3061 = 0;
return D.3061;
  }
  D.3061 = 0;
  return D.3061;
}

Here, GCC propagates *psimple directly to f() without creating temporary
variable and ASan is unable to check it because it doesn't sanitize gimple
calls arguments.
I think the easiest way to fix this would be adding arguments checks in
maybe_instrument_call, something like this:

@@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
   return true;
 }

-  return false;
+  bool instrumented = false;
+  HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
+  for (int i = 0; i < args_num; ++i)
+{
+  if (is_arg_deref_p (TREE_CODE (gimple_call_arg (stmt, i
+   {
+ instrument_derefs (iter, gimple_call_arg (stmt, i),
+gimple_location (stmt), false);
+ instrumented = true;
+   }
+}
+  if (instrumented)
+gsi_next (iter);
+  return instrumented;

[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
At -O0 indeed the dereferences in function argument list are not instrumented:
  [ab.c:24:3] _7 = f ([ab.c:24:3] *psimple_3);
doesn't have corresponding ASAN_CHECK added.
At -O2, everything is reported, but there is another issue, we lose the
location
of the first read - before einline we have:
  [ab.c:24:3] _7 = f ([ab.c:24:3] *psimple_3);
  [ab.c:24:3] __builtin_printf ([ab.c:24:21] "%d\n", _7);
but after einline:
  simple = [ab.c:24:3] *psimple_3;
  [ab.c:8:16] _14 = [ab.c:8:16] simple.value;
  _18 = _14;
  [ab.c:24:3] _7 = _18;
  [ab.c:24:3] __builtin_printf ([ab.c:24:21] "%d\n", _7);
as the simple = *psimple_3; statement has gimple_location UNKNOWN_LOCATION,
we actually end up reporting it at the spot of the second invalid memory access
(because it inherits the location from the previous statement, which is the
other __asan_report_store4 call).  In this case, we could either also look at
EXPR_LOCATION of the MEM_REF if gimple_location is UNKNOWN_LOCATION, or we'd
need to look at the inliner and figure out what location we want for the
parameter read.

[Bug target/70542] New: [6 Regression] Wrong code with -O3 -mavx2.

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 70542
   Summary: [6 Regression] Wrong code with -O3 -mavx2.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Created attachment 38187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38187&action=edit
Reproducer.

Test case produces incorrect result with -O3 -mavx2 (and -march=knl and
-march=skylake-avx512. Everything works fine with gcc version 4.9.4 20160401
(prerelease) (Revision=234686) and gcc version 5.3.1 20160401
(Revision=234686).

Output:
g++ -O2 -mavx2 repr.cpp; ./a.out
1540
> g++ -O3 -mavx2 repr.cpp; ./a.out
1204

GCC version:
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/export/users/vlivinsk/gcc-trunk/bin/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/vlivinsk/gcc-trunk/gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --enable-checking=release --enable-languages=c,c++,lto
--with-gmp=/export/users/vlivinsk/gcc-trunk/gmp-6.1.0/bin
--with-mpfr=/export/users/vlivinsk/gcc-trunk/mpfr-3.1.3/bin
--with-mpc=/export/users/vlivinsk/gcc-trunk/mpc-1.0.3/bin
--prefix=/export/users/vlivinsk/gcc-trunk/bin
Thread model: posix
gcc version 6.0.0 20160404 (experimental) (Revision=234705)

Test:
#include 

int a[520];
short b[482];
short c[480];
int d[963];
short e[320];

int main() {
for (int i = 0; i < 520; ++i)
a[i] = -636544305;

for (int i = 0; i < 386; ++i)
b[i] = -31804;

for (long i = 1; i <= 112; ++i) {
c[i] = b[i] >> ((a[i] & 1587842570) - 1510214139);
if (a[i])
d[i] = i;
e[i] = 7 << ((2312631697 - b[i]) - 2312663500);
}

unsigned long long g = 0;
for (int i = 0; i < 111; ++i) {
g = e[i] + g;
}

if (g != 1540)
abort();
}

[Bug target/70542] [6 Regression] Wrong code with -O3 -mavx2.

[vsevolod.livinskij at frtk dot ru]

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

Vsevolod Livinskiy  changed:

   What|Removed |Added

  Attachment #38187|0   |1
is obsolete||

--- Comment #1 from Vsevolod Livinskiy  ---
Created attachment 38188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38188&action=edit
Correct reproducer.

I've mixed up reproducers.

[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Maxim Ostapenko from comment #1)
> @@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
>return true;
>  }

If the function call returns a struct, then your patch wouldn't instrument it.
You need the bool instrumented = false; already above
  if (gimple_store_p (stmt))
and set instrumented = true; there instead of gsi_next (iter); return true;

> -  return false;
> +  bool instrumented = false;
> +  HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
> +  for (int i = 0; i < args_num; ++i)
> +{
> +  if (is_arg_deref_p (TREE_CODE (gimple_call_arg (stmt, i

I'm not aware of any is_arg_deref_p predicate.
IMHO you should test:
  if (!is_gimple_reg (gimple_call_arg (stmt, i)))

> +   {
> + instrument_derefs (iter, gimple_call_arg (stmt, i),
> +gimple_location (stmt), false);
> + instrumented = true;
> +   }
> +}
> +  if (instrumented)
> +gsi_next (iter);
> +  return instrumented;

As for the location_t thing, the fix would be to do in instrument_derefs
something like:
  if (location == UNKNOWN_LOCATION)
location = EXPR_LOCATION (t);
after the early bail outs.

[Bug tree-optimization/70499] internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:266

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Apr  5 08:05:06 2016
New Revision: 234738

URL: https://gcc.gnu.org/viewcvs?rev=234738&root=gcc&view=rev
Log:
2016-04-05  Richard Biener  

PR middle-end/70499
* gimplify-me.c (gimple_regimplify_operands): Do not rewrite
non-register type temporaries into SSA.

* g++.dg/torture/pr70499.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr70499.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify-me.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70525] generating 'vpandn' without the mode suffix, gnu as fails to assemble (-mavx512bw)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 08:15:09 2016
New Revision: 234739

URL: https://gcc.gnu.org/viewcvs?rev=234739&root=gcc&view=rev
Log:
PR target/70525
* config/i386/sse.md (*andnot3): Simplify assertions.
Use vpandn for V16SI/V8DImode, vpandnq for
V32HI/V64QImode, don't use , fix up formatting.
(*andnot3_mask): Remove insn with VI12_AVX512VL iterator.

* gcc.target/i386/pr70525.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70525.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Kirill Yukhin from comment #1)
> > will take a look.
> 
> I have patch in testing:
> 
Oh, great! Thanks!

[Bug target/70525] generating 'vpandn' without the mode suffix, gnu as fails to assemble (-mavx512bw)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 08:23:46 2016
New Revision: 234740

URL: https://gcc.gnu.org/viewcvs?rev=234740&root=gcc&view=rev
Log:
PR target/70525
* config/i386/sse.md (*andnot3): Simplify assertions.
Use vpandn for V16SI/V8DImode, vpandnq for
V32HI/V64QImode, don't use , fix up formatting.
(*andnot3_mask): Remove insn with VI12_AVX512VL iterator.

* gcc.target/i386/pr70525.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70525.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70525] generating 'vpandn' without the mode suffix, gnu as fails to assemble (-mavx512bw)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 5.4+ (4.9 didn't support AVX512-BW at all).

[Bug target/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Looking into this.

[Bug middle-end/70499] internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:266

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|tree-optimization   |middle-end
  Known to work||6.0

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

[Bug target/70117] ppc long double isinf() is wrong?

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Alan Modra from comment #14)
> > if (fmt == &ibm_extended_double)
> 
> No, there is mips_extended_format too.

As said above the best is to provide optabs for all three fns and optimal
implementations in the backend - that will disable the folding as well.
Emitting a comparison as we do now is stupid and inefficient given that
only the value of one of the double matters anyway.

[Bug c++/70543] New: [6 Regression] wrong non-const error for enable_if and constexpr function

[olegendo at gcc dot gnu.org]

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

Bug ID: 70543
   Summary: [6 Regression] wrong non-const error for enable_if and
constexpr function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---

The code below compiles fine on GCC 5 (with -std=c++11 or -std=c++14), while on
GCC 6 (r234732) it says:

error: size of array 'foo' is not an integral constant-expression
   char foo[value];



#include 
#include 

template  struct X
{
  template  static constexpr
  typename std::enable_if::value,
  unsigned int>::type
  calc (void)
  {
return 0;
  }

  template  static constexpr
  typename std::enable_if::value,
  unsigned int>::type
  calc (void)
  {
return sizeof (typename std::tuple_element::type)
   + calc ();
  }

  static constexpr unsigned int value = calc ();

  char foo[value];
};

[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
A slightly reduced version:

#include 

template  struct X
{
  template  static constexpr
  typename std::enable_if< I == 5, unsigned int>::type
  calc (void)
  {
return 0;
  }

  template  static constexpr
  typename std::enable_if< I != 5, unsigned int>::type
  calc (void)
  {
return 1 + calc ();
  }

  static constexpr unsigned int value = calc (); // <<<

  char foo[value];
};


If the marked line is changed to

  static constexpr unsigned int value = calc<0> ();

it compiles fine.

[Bug c++/70544] New: Overload resolution with explicitly specified template arguments

[roman.perepelitsa at gmail dot com]

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

Bug ID: 70544
   Summary: Overload resolution with explicitly specified template
arguments
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.perepelitsa at gmail dot com
  Target Milestone: ---

When compiling this program:

  template 
  void F(Args&&...);

  template 
  int F(Args&&...);

  int main() {
int{F(0)};
  }

Expected behavior: compile error (call to `F` is ambiguous).
Actual behaviour: compiles successfully.

Comment from Richard Smith: "I suspect this might be fallout from GCC's
workaround for core issue 1395 (after substituting explicitly-specified
template arguments, the first 'F' has one pack element deduced and the second
'F' has none, so I suspect the second may look more specialized under GCC's
approach to 1395 but not Clang's)."

Note that the following program gets rejected by GCC (as expected):

  template 
  void F(T);

  template 
  void F(U);

  int main() {
F(0);
  }

[Bug target/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r233068.
Slightly cleaned up testcase:
int a[113], d[113];
short b[113], c[113], e[113];

int
main ()
{
  int i;
  long j;
  unsigned long long g = 0;
  for (i = 0; i < 113; ++i)
{
  a[i] = -636544305;
  b[i] = -31804;
}
  for (j = 1; j <= 112; ++j)
{
  c[j] = b[j] >> ((a[j] & 1587842570) - 1510214139);
  if (a[j])
d[j] = j;
  e[j] = 7 << ((2312631697 - b[j]) - 2312663500);
}
  for (i = 0; i < 111; ++i)
g = e[i] + g;
  if (g != 1540)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/70545] New: [openacc] gfortran.dg/goacc/kernels-loop-n.f95 not parallelized

[vries at gcc dot gnu.org]

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

Bug ID: 70545
   Summary: [openacc] gfortran.dg/goacc/kernels-loop-n.f95 not
parallelized
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this testcase (gfortran.dg/goacc/kernels-loop-n.f95):
...
module test
contains
  subroutine foo(n)
implicit none
integer :: n
integer, dimension (0:n-1) :: a, b, c
integer:: i, ii
do i = 0, n - 1
   a(i) = i * 2
end do

do i = 0, n -1
   b(i) = i * 4
end do

!$acc kernels copyin (a(0:n-1), b(0:n-1)) copyout (c(0:n-1))
do ii = 0, n - 1
   c(ii) = a(ii) + b(ii)
end do
!$acc end kernels   

do i = 0, n - 1
   if (c(i) .ne. a(i) + b(i)) call abort
end do

  end subroutine foo
end module test
...

Note that the n parameter of foo translates to a restrict reference:
...
foo (integer(kind=4) & restrict n)
...

Parallelization fails because these statement cannot be disambiguated:
...
Stmt *_9 = 0;
conflicts with entry/exit stmt: _7 = *_6;
entry/exit not ok: FAILED
...

Looking at the first basic block, we can see the stmts:
...
  :
  # VUSE <.MEM_3(D)>
  _5 = *.omp_data_i_4(D).n;
  # VUSE <.MEM_3(D)>
  _6 = *_5;
  # VUSE <.MEM_3(D)>
  _7 = *_6;
  _8 = _7 + -1;
  # VUSE <.MEM_3(D)>
  _9 = *.omp_data_i_4(D).ii;
  # .MEM_10 = VDEF <.MEM_3(D)>
  *_9 = 0;
  if (_8 >= 0)
goto ;
  else
goto ;
...

The '*_9 = 0' is a store to the iteration counter ii, and '_7 = *_6' is a load
of 'n'.

AFAIU, They are not disambiguated because fipa-pta ignores restrict (see
PR68787 - fipa-pta to interpret restrict).

The store has the expected points-to information in pta:
...
_9 = { D.3639 }
...

But the load does not translate back to the load from restrict reference:
...
_7 = { ESCAPED NONLOCAL }
...

[Bug tree-optimization/68787] fipa-pta to interpret restrict

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> This is in particular problematic for fortran and fopenmp/fopenacc, where
> the non-aliasing of parameters arrays in fortran is implemented by annotated
> those parameters with restrict in the fortran frontend.

See f.i. PR70545 - '[openacc] gfortran.dg/goacc/kernels-loop-n.f95 not
parallelized'

[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
(In reply to Oleg Endo from comment #1)
> 
> If the marked line is changed to
> 
>   static constexpr unsigned int value = calc<0> ();
> 
> it compiles fine.

However, if doing that "trick" in the bigger production code, there is some new
error:

c++/6.0.0/type_traits:868:48: error: constructor required before non-static
data member for '...' has been parsed
 template
^~~~

[Bug tree-optimization/68787] fipa-pta to interpret restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
One possibility would be to re-run non-IPA PTA just to compute restrict info,
that is, instead of bailing out when cfun->gimple_df->ipa_pta just not update
SSA pointer-info but still call compute_dependence_clique.  Requires
splitting of compute_points_to_sets into the actual compute and SSA
pointer-info
update parts.

[Bug libstdc++/66693] [C++17] std::tuple_size fails with const std::array

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Jonathan Wakely  ---
This was fixed (thanks, Ville).

[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |6.0

[Bug target/70542] [6 Regression] Wrong code with -O3 -mavx2.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug c++/70540] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P5

[Bug c++/70536] g++ doesn't emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Please post patches to gcc-patc...@gcc.gnu.org and make sure they pass
bootstrap & regtest

[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer

[m.ostapenko at samsung dot com]

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

--- Comment #4 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > @@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
> >return true;
> >  }
> 
> If the function call returns a struct, then your patch wouldn't instrument
> it.
> You need the bool instrumented = false; already above
>   if (gimple_store_p (stmt))
> and set instrumented = true; there instead of gsi_next (iter); return true;
> 
> > -  return false;
> > +  bool instrumented = false;
> > +  HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
> > +  for (int i = 0; i < args_num; ++i)
> > +{
> > +  if (is_arg_deref_p (TREE_CODE (gimple_call_arg (stmt, i
> 
> I'm not aware of any is_arg_deref_p predicate.
> IMHO you should test:
>   if (!is_gimple_reg (gimple_call_arg (stmt, i)))
> 
> > +   {
> > + instrument_derefs (iter, gimple_call_arg (stmt, i),
> > +gimple_location (stmt), false);
> > + instrumented = true;
> > +   }
> > +}
> > +  if (instrumented)
> > +gsi_next (iter);
> > +  return instrumented;
> 

Thanks, looks better now?

diff --git a/gcc/asan.c b/gcc/asan.c
index 47bfdcd..c51e629 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1766,6 +1766,8 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,

   tree type, base;
   HOST_WIDE_INT size_in_bytes;
+  if (location == UNKNOWN_LOCATION)
+location = EXPR_LOCATION (t);

   type = TREE_TYPE (t);
   switch (TREE_CODE (t))
@@ -2049,6 +2051,7 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
   gsi_insert_before (iter, g, GSI_SAME_STMT);
 }

+  bool instrumented = false;
   if (gimple_store_p (stmt))
 {
   tree ref_expr = gimple_call_lhs (stmt);
@@ -2056,11 +2059,22 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
 gimple_location (stmt),
 /*is_store=*/true);

-  gsi_next (iter);
-  return true;
+  instrumented = true;
 }

-  return false;
+  HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
+  for (int i = 0; i < args_num; ++i)
+{
+  if (!is_gimple_reg (gimple_call_arg (stmt, i)))
+   {
+ instrument_derefs (iter, gimple_call_arg (stmt, i),
+gimple_location (stmt), false);
+ instrumented = true;
+   }
+}
+  if (instrumented)
+gsi_next (iter);
+  return instrumented;
 }

> As for the location_t thing, the fix would be to do in instrument_derefs
> something like:
>   if (location == UNKNOWN_LOCATION)
> location = EXPR_LOCATION (t);
> after the early bail outs.

Hm, even with if (location == UNKNOWN_LOCATION) location = EXPR_LOCATION (t); I
don't see reasonable line in -O2 case:

  1 #include 
  2 #include 
  3 
  4 struct Simple {
  5   int value;
  6 };
  7 
  8 int f(struct Simple simple) {
  9   return simple.value;
 10 }
 11 
 12 int g(int value) {
 13   return value;
 14 }
 15 
 16 int main() {
 17   struct Simple *psimple = (struct Simple *) malloc(sizeof(struct Simple));
 18   psimple->value = 42;
 19   free(psimple);
 20   printf("%d\n", f(*psimple));
 21   return 0;
 22 }

$ ./a.out

==29898==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020eff0
at pc 0x004055a6 bp 0x7ffc6b5632c0 sp 0x7ffc6b5632a0
READ of size 4 at 0x6020eff0 thread T0
#0 0x4055a5 in main /tmp/test2.c:22
#1 0x7f8e6df32ec4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
#2 0x4055f9  (/tmp/a.out+0x4055f9)


$ cat test2.c.126t.asan1

main ()
{
  int simple$value;
  struct Simple * psimple;

  :
  [test2.c:17:18] psimple_3 = malloc (4);
  [test2.c:17:18] # DEBUG psimple => psimple_3
  [test2.c:19:3] free (psimple_3);
  ASAN_CHECK (6, psimple_3, 4, 8);
  simple$value_6 = MEM[(struct Simple *)psimple_3];
  # DEBUG simple$value => simple$value_6
  [test2.c:20:3] printf ([test2.c:20:10] "%d\n", simple$value_6);
  return 0;
}

Perhaps we indeed should look at the inliner.

[Bug rtl-optimization/70526] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2016-04-05
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Let me have a look - the source looks good to me (yeah, maybe some placement
new is missing, but as that is a no-op it doesn't matter to the middle-end).

[Bug tree-optimization/70546] New: ifconvert if(cond) ++count; to count += cond;

[glisse at gcc dot gnu.org]

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

Bug ID: 70546
   Summary: ifconvert if(cond) ++count; to count += cond;
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

In the example from http://stackoverflow.com/q/36414959/1918193 we fail to
vectorize f0 (using g++ -O3) because of the condition in the loop. However, if
I manually change the condition as in the #else case, the vectorizer is happy
and we get a very nice performance boost. Could ifconvert (or some other phi
optimization pass) handle this transformation? n is a local variable, so we
shouldn't even need -ftree-loop-if-convert-stores. At -O1, it is also a clear
win with the random distribution, but it becomes a slight loss if the vector v
is sorted in increasing order and a big loss for the decreasing order, so I
don't know for sure under which condition this should be done.

#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;
using namespace std::chrono;

vector v(1'000'000);

int f0()
{
  int n = 0;

  for (int i = 1; i < v.size()-1; ++i) {
int a = v[i-1];
int b = v[i];
int c = v[i+1];

#ifndef IMPROVED
if (a < b  &&  b < c) ++n;
#else
n += (a < b  &&  b < c);
#endif
  }

  return n;
}


int f1()
{
  int n = 0;

  for (int i = 1; i < v.size()-1; ++i)
if (v[i-1] < v[i]  &&  v[i] < v[i+1])
  ++n;

  return n;
}


int main()
{
  auto benchmark = [](int (*f)()) {
const int N = 100;

volatile long long result = 0;
vector  timings(N);

for (int i = 0; i < N; ++i) {
  auto t0 = high_resolution_clock::now();
  result += f();
  auto t1 = high_resolution_clock::now();

  timings[i] = duration_cast(t1-t0).count();
}

sort(timings.begin(), timings.end());
cout << fixed << setprecision(6) << timings.front()/1'000'000.0 << "ms
min\n";
cout << timings[timings.size()/2]/1'000'000.0 << "ms median\n" << "Result:
" << result/N << "\n\n";
  };

  mt19937generator   (31415);   // deterministic seed
  uniform_int_distribution<> distribution(0, 1023);

  for (auto& e: v)
e = distribution(generator);

  benchmark(f0);
  benchmark(f1);

  cout << "\ndone\n";

  return 0;
}

[Bug fortran/70235] [4.9/5 Regression] Incorrect output with PF format

[dominiq at gcc dot gnu.org]

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

--- Comment #27 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Apr  5 09:44:17 2016
New Revision: 234741

URL: https://gcc.gnu.org/viewcvs?rev=234741&root=gcc&view=rev
Log:
2016-04-05  Jerry DeLisle  
Dominique d'Humieres  

PR libgfortran/70235
* io/write_float.def: Fix PF format for negative values of the scale
factor.

2016-04-05  Dominique d'Humieres  
Jerry DeLisle  

* gfortran.dg/fmt_pf.f90: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/fmt_pf.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/write_float.def

[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing ".../xgcc -dumpspecs"

[vcunat at gmail dot com]

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

--- Comment #11 from Vladimír Čunát  ---
OK, I'm abandoning this problem, regardless of which package actually causes
the problem. I can't see how to progress and I've got some workarounds for my
case: either downgrading to binutils-2.25.1 or upgrading the whole toolchain
(including gcc).

[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #1)
> So, either use the GNU extension modes (-std=gnu++11, -std=gnu++14), or wait
> for -std=c++17.

According to the manual, if an extension is not incompatible with the base
standard, it should not be disabled:

"When a base standard is specified, the compiler accepts all programs following
that standard plus those using GNU extensions that do not contradict it."

If one wants to distinguish between exponents with sign and without, it would
be better if libcpp parses the hext-float while keeping track of the location_t
of the sign (or UNKNOWN_LOCATION if not present). Then give a pedwarn
(conditional on -Wpedantic) if location_t != UNKNOWN_LOCATION for the relevant
standards. Having the location of the sign also will allow gcc to give a more
precise warning:

warning: signed exponent in hexadecimal float is a GNU extension [-Wpedantic]
 auto d = 0x123p-2;
^

[Bug fortran/70235] [4.9/5 Regression] Incorrect output with PF format

[dominiq at gcc dot gnu.org]

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

--- Comment #28 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Apr  5 10:01:17 2016
New Revision: 234742

URL: https://gcc.gnu.org/viewcvs?rev=234742&root=gcc&view=rev
Log:
2016-04-05  Jerry DeLisle  
Dominique d'Humieres  

PR libgfortran/70235
* io/write_float.def: Fix PF format for negative values of the scale
factor.

2016-04-05  Dominique d'Humieres  
Jerry DeLisle  

* gfortran.dg/fmt_pf.f90: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/fmt_pf.f90
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/write_float.def

[Bug target/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This goes wrong during the REE pass.

[Bug tree-optimization/70547] New: Optimize multiplication of booleans to bit_and

[glisse at gcc dot gnu.org]

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

Bug ID: 70547
   Summary: Optimize multiplication of booleans to bit_and
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

int f(int a,int b,int c,int d){
  return (a

[Bug tree-optimization/68787] fipa-pta to interpret restrict

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 38189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38189&action=edit
patch to recompute restrict info after ipa-pta

(In reply to Richard Biener from comment #4)
> One possibility would be to re-run non-IPA PTA just to compute restrict info,
> that is, instead of bailing out when cfun->gimple_df->ipa_pta just not update
> SSA pointer-info but still call compute_dependence_clique.  Requires
> splitting of compute_points_to_sets into the actual compute and SSA
> pointer-info
> update parts.

That sound similar to what I've tried here:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01257.html .

Attaching a more minimal version.

But it doesn't affect the testcase, and I'm not sure how it could (perhaps it
will affect another test-case, I'm not sure).

For the listed testcase, after ipa-pta we have:
...
__attribute__((noclone, noinline))
bar (intD.6 * aD.1755, intD.6 * bD.1756)
{
  # PT = nonlocal
  intD.6 * a_2(D) = aD.1755;
  # PT = nonlocal
  intD.6 * b_4(D) = bD.1756;
  intD.6 _6;
  intD.6 _7;
...

There's nothing to take advantage of by trying to reannotate with restrict.

[Bug rtl-optimization/70526] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Looks like a SRA bug to me replacing

  D.2447 = MEM[(const struct Register &)&D.2394];
  D.2404 = D.2447;
  _5 = D.2404.reg_;

with

  SR.8_3 = MEM[(struct TypedOrValueRegister *)&D.2394];
  SR.7_4 = SR.8_3;
  _5 = SR.7_4;

notice how it changes the alias type of the access of D.2394.

Will attempt to totally scalarize D.2447 (UID: 2447):
...
Created a replacement for D.2447 offset: 0, size: 32: SR.8

Access trees for D.2447 (UID: 2447):
access { base = (2447)'D.2447', offset = 0, size = 32, expr = D.2447.reg_, type
= uint32_t, non_addressable = 0, reverse = 0, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 1,
grp_scalar_write = 0, grp_total_scalarization = 1, grp_hint = 1, grp_covered =
1, grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs =
0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0, grp_maybe_modified =
0, grp_not_necessarilly_dereferenced = 0

notice the bogus ->expr, possibly created from the D.2404 accesses.

Created a replacement for D.2404 offset: 0, size: 32: SR.7

Access trees for D.2404 (UID: 2404):
access { base = (2404)'D.2404', offset = 0, size = 32, expr = D.2404.reg_, type
= uint32_t, non_addressable = 0, reverse = 0, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 1,
grp_scalar_write = 0, grp_total_scalarization = 0, grp_hint = 0, grp_covered =
1, grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs =
0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0, grp_maybe_modified =
0, grp_not_necessarilly_dereferenced = 0


Indeed the issue seems to be a simple typo and the following fixes it:

Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c  (revision 234736)
+++ gcc/tree-sra.c  (working copy)
@@ -1673,7 +1673,7 @@ build_ref_for_offset (location_t loc, tr
 }
   else
 {
-  off = build_int_cst (reference_alias_ptr_type (base),
+  off = build_int_cst (reference_alias_ptr_type (prev_base),
   base_offset + offset / BITS_PER_UNIT);
   base = build_fold_addr_expr (unshare_expr (base));
 }

[Bug fortran/70235] [4.9/5 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
As reported in bugzilla the patch fixes the issue. What is your plan about it?

TIA

Dominique

> Le 31 mars 2016 à 11:26, m.ostapenko at samsung dot com 
>  a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70474
> 
> --- Comment #1 from Maxim Ostapenko  ---
> Created attachment 38143
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38143&action=edit
> Proposed patch.
> 
> Does this patch fix the problem?
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug tree-optimization/70546] ifconvert if(cond) ++count; to count += cond; fails because of mergephi and failed loop header copying

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
Summary|ifconvert if(cond) ++count; |ifconvert if(cond) ++count;
   |to count += cond;   |to count += cond; fails
   ||because of mergephi and
   ||failed loop header copying
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think the issue is that the increment of n is in the latch block and that
we didn't properly copy the loop header:

;; Function int f0() (_Z2f0v, funcdef_no=3715, decl_uid=71164, cgraph_uid=957,
symbol_order=963)

fix_loop_structure: fixing up loops for function
Disambiguating loop 1 with multiple latches
Merged latch edges of loop 1

It is mergephi that merges the header and latch PHIs:

  :
  # n_1 = PHI <0(2), n_2(6)>
  # i_3 = PHI <1(2), _22(6)>
  _8 = (long unsigned int) i_3;
  _33 = MEM[(int * *)&v];
...
  if (_29 != 0)
goto ;
  else
goto ;

  :
  n_30 = n_1 + 1;

  :
  # n_2 = PHI 
  goto ;

to

  :
  # n_1 = PHI <0(2), n_30(5), n_1(4)>
  # i_3 = PHI <1(2), _22(5), _22(4)>
  _8 = (long unsigned int) i_3;
...
  if (_29 != 0)
goto ;
  else
goto ;

  :
  n_30 = n_1 + 1;
  goto ;

creating multiple latches.  We still fail to copy loop headers properly
for -fdisable-tree-mergephi[123] though.

So the issues are elsewhere and tree ifcvt should handle this fine
already.

[Bug fortran/52788] -fbounds-check fails for 2-rank allocatable arrays when reading

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
> Duplicate of pr30802?

No objection, thus marked as duplicate.

*** This bug has been marked as a duplicate of bug 30802 ***

[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||Edouard.Canot at irisa dot fr

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 52788 has been marked as a duplicate of this bug. ***

[Bug fortran/27766] [meta-bug] -fbounds-check related bugs

[dominiq at lps dot ens.fr]

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

Bug 52788 Summary: -fbounds-check fails for 2-rank allocatable arrays when 
reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52788

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

[Bug libfortran/69788] FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug tree-optimization/68787] fipa-pta to interpret restrict

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 5 Apr 2016, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68787
> 
> --- Comment #5 from vries at gcc dot gnu.org ---
> Created attachment 38189
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38189&action=edit
> patch to recompute restrict info after ipa-pta
> 
> (In reply to Richard Biener from comment #4)
> > One possibility would be to re-run non-IPA PTA just to compute restrict 
> > info,
> > that is, instead of bailing out when cfun->gimple_df->ipa_pta just not 
> > update
> > SSA pointer-info but still call compute_dependence_clique.  Requires
> > splitting of compute_points_to_sets into the actual compute and SSA
> > pointer-info
> > update parts.
> 
> That sound similar to what I've tried here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01257.html .
> 
> Attaching a more minimal version.
> 
> But it doesn't affect the testcase, and I'm not sure how it could (perhaps it
> will affect another test-case, I'm not sure).
> 
> For the listed testcase, after ipa-pta we have:
> ...
> __attribute__((noclone, noinline))
> bar (intD.6 * aD.1755, intD.6 * bD.1756)
> {
>   # PT = nonlocal
>   intD.6 * a_2(D) = aD.1755;
>   # PT = nonlocal
>   intD.6 * b_4(D) = bD.1756;
>   intD.6 _6;
>   intD.6 _7;
> ...
> 
> There's nothing to take advantage of by trying to reannotate with restrict.

True.  If there's a IPA effect of restrict to be exposed it won't help.

Note that the issue with IPA PTA is that if you enable restrict tags
to be used you can end up with

static foo (int *p) { ... }
bar (int * __restrict p) { ... foo (p); /* p is restrict */  ... }
baz (int * p) { ... foo (p); /* p is not restrict */ ... }

and this breaks down having p in foo be { NONLOCAL, restrict-tag }
and the current handling making p in foo restrict (well, the current
handling can't assign cliques to functions in IPA mode, but you
see one of several issues).  Similarly recursion of bar will not
properly handle restrict I believe.

The current restrict tag handling is quite (too) conservative so
it might work in its current state only handling the 
must-point-to-restrict (or NULL) case.  You can always try ...

[Bug tree-optimization/68787] fipa-pta to interpret restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Oh, and with LTO you _should_ see all pointed-to objects and thus restrict
should be no longer necessary... (well, in theory)

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[m.ostapenko at samsung dot com]

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

--- Comment #5 from Maxim Ostapenko  ---
Eh, just forgot about this one, sorry. Will post the patch shortly.

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|target  |rtl-optimization

[Bug fortran/68226] [4.9/5/6 Regression] [OOP] ICE on assignment of pointer-valued function to allocatable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.9.4

[Bug tree-optimization/70341] [4.9/5/6 Regression] Code size increase due to earlier switch case lowering.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2
   Host|linux   |
   Target Milestone|--- |4.9.4

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P2
   Target Milestone|--- |4.9.4

[Bug fortran/65438] Unnecessary ptr check

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
No feedback after more than a year. Closing as INVALID.

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Apr  5 11:31:30 2016
New Revision: 234743

URL: https://gcc.gnu.org/viewcvs?rev=234743&root=gcc&view=rev
Log:
PR libstdc++/70437
* include/bits/stl_pair.h (_ConstructiblePair,
_ImplicitlyConvertiblePair, _MoveConstructiblePair,
_ImplicitlyMoveConvertiblePair): Add shortcut conditions
for same-type cases.
* testsuite/20_util/pair/70437.cc: New.

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

[Bug tree-optimization/70526] [6 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|rtl-optimization|tree-optimization
   Target Milestone|--- |6.0
Summary|GCC 6 miscompiles Firefox   |[6 Regression] GCC 6
   |JIT compiler|miscompiles Firefox JIT
   ||compiler

--- Comment #7 from Richard Biener  ---
The issue is actually older so I'll backport this with my next batch(es).

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[chefmax at gcc dot gnu.org]

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

--- Comment #6 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Tue Apr  5 11:52:34 2016
New Revision: 234744

URL: https://gcc.gnu.org/viewcvs?rev=234744&root=gcc&view=rev
Log:
Cherry-pick r224315,221379 and r241487 from upstream.

libsanitizer/

PR sanitizer/70474
* asan/asan_mac.cc (GetMacosVersionInternal): Cherry pick
upstream r241487, 221379 and r224315.
(void MaybeReexec): Cherry pick upstream r241487.
* asan/asan_mac.h (enum MacosVersion): Cherry pick upstream r224315.

Modified:
branches/gcc-4_9-branch/libsanitizer/ChangeLog
branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.cc
branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.h

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed.

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug rtl-optimization/70542] [6 Regression] Wrong code with -O3 -mavx2.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 38191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38191&action=edit
gcc6-pr70542.patch

Perhaps better fix.  Looking at PR64286, the comment is right, if we change
somehow the definition for VECTOR_MODE_P, we need to make sure all uses are
modified, or none.  But there is tons of reasons why some of them could fail,
e.g. for the copy_needed case there is lots of tests that can fail, but even
for the !copy_needed case it could fail to get recognized etc., and we are
unable to handle all the uses as a single transaction.

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
It has been fixed upstream by

commit 5e263ef18766b562a05aa6736d6c7ea3c8af3b4e
Author: Reid Kleckner 
Date:   Mon Apr 4 18:27:32 2016 +

Apply suggestion from HJ Lu to avoid misaligned stack in test

Fixes PR27191

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@265322
91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/test/asan/TestCases/Linux/clone_test.cc
b/test/asan/TestCases/Linux/clone_test.cc
index e9c1f16..f6eb261 100644
--- a/test/asan/TestCases/Linux/clone_test.cc
+++ b/test/asan/TestCases/Linux/clone_test.cc
@@ -22,7 +22,7 @@ int Child(void *arg) {

 int main(int argc, char **argv) {
   const int kStackSize = 1 << 20;
-  char child_stack[kStackSize + 1];
+  char __attribute__((aligned(16))) child_stack[kStackSize + 1];
   char *sp = child_stack + kStackSize;  // Stack grows down.
   printf("Parent: %p\n", sp);
   pid_t clone_pid = clone(Child, sp, CLONE_FILES | CLONE_VM, NULL);

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That is very weird placement of the attribute, then it is array of overaligned
chars rather than aligned array of normal chars.

[Bug c++/70539] New: ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[webrown.cpp at gmail dot com]

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

Bug ID: 70539
   Summary: ICE on invalid code on x86_64-linux-gnu in
cxx_incomplete_type_diagnostic, at cp/typeck2.c:569
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

The following code causes an ICE when compiled with the current GCC trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 5.3.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160404 (experimental) [trunk revision 234712] (GCC) 
$ 
$ g++-5.3 -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:4:8: error: ‘f’ does not name a type
   auto f = [&] { return f; };
^
$ 
$ g++-trunk -c small.cpp
small.cpp: In lambda function:
small.cpp:4:25: error: use of ‘f’ before deduction of ‘auto’
   auto f = [&] { return f; };
 ^
small.cpp:4:25: error: use of ‘foo()’ before deduction
of ‘auto’
small.cpp:4:28: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:569
   auto f = [&] { return f; };
^
0x6ce8e3 cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*,
diagnostic_t)
../../gcc-source-trunk/gcc/cp/typeck2.c:569
0x765f99 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/typeck.c:150
0x7c37fc apply_deduced_return_type(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:9226
0x7342a2 cp_parser_lambda_body
../../gcc-source-trunk/gcc/cp/parser.c:10256
0x7342a2 cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9756
0x734c9c cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4933
0x736d26 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6690
0x73fe6c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7988
0x7406c7 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8665
0x740cc5 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8767
0x7415b0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9055
0x7419ea cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9323
0x742174 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:20793
0x74391b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:20734
0x752bce cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18604
0x7532b0 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12379
0x7535c1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12248
0x754018 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11860
0x7326db cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10528
0x732ffc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


void
foo ()
{
  auto f = [&] { return f; };
}

[Bug c++/70539] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Dup?

*** This bug has been marked as a duplicate of bug 70540 ***

[Bug c++/70540] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
*** Bug 70539 has been marked as a duplicate of this bug. ***

[Bug testsuite/70520] Incorrect child stack alignment in c-c++-common/asan/clone-test-1.c

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

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

--- Comment #4 from Andreas Schwab  ---
Does this really make a difference?  I think the attribute still applies to the
object, not the type.

[Bug libstdc++/70548] New: gdb pretty printers hang and spin cpu in gdb session.

[smark at datto dot com]

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

Bug ID: 70548
   Summary: gdb pretty printers hang and spin cpu in gdb session.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smark at datto dot com
  Target Milestone: ---

Created attachment 38192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38192&action=edit
stack trace for spinning gdb.

At first I opened this bug, 

https://sourceware.org/bugzilla/show_bug.cgi?id=19894

because I had no idea who owned the pretty printers, they referred me here

gdb spins a cpu and hangs, and the stack trace shows its buried in the pretty
printer. When I disable the pretty printer, I have no problem except that I
can't see my variables in the debugger. :-)

The stack trace is attached.
Thanks.

[Bug libstdc++/70503] [4.9/5/6 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr  5 13:35:32 2016
New Revision: 234746

URL: https://gcc.gnu.org/viewcvs?rev=234746&root=gcc&view=rev
Log:
Ensure std::thread helpers have internal linkage

PR libstdc++/70503
* src/c++11/thread.cc (execute_native_thread_routine,
execute_native_thread_routine_compat): Give internal linkage.
* testsuite/30_threads/thread/70503.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/70503.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/thread.cc

[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #8 from Bill Seurer  ---
This affects powerpc64 little endian as well but not apparently big endian.

[Bug c/70475] -Wmisleading-indentation quetionable in Eigen

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-05
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Patrick Palka  ---
It doesn't make much sense that we warn for:

if (a) do_stuff();
   do_other_stuff();

but not for

if (a) do_stuff();
do_other_stuff();

or for

if (a) do_stuff();
  do_other_stuff();

So I agree that the warning is questionable.  I'll propose a patch.

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|target  |libstdc++

--- Comment #9 from Jonathan Wakely  ---
Changing component to libstdc++ since it's not limited to any single target, or
family of targets.

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

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

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

--- Comment #10 from Andreas Schwab  ---
It really affects all targets and is not a new problem.  You can find thousands
of hits on gcc-testresults.

[Bug tree-optimization/70526] [5 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Apr  5 14:26:59 2016
New Revision: 234749

URL: https://gcc.gnu.org/viewcvs?rev=234749&root=gcc&view=rev
Log:
2016-04-05  Richard Biener  

PR tree-optimization/70526
* tree-sra.c (build_ref_for_offset): Use prev_base to
extract the alias pointer type.

* g++.dg/torture/pr70526.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr70526.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/70526] [5 Regression] GCC 6 miscompiles Firefox JIT compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||6.0
   Target Milestone|6.0 |5.4
Summary|[6 Regression] GCC 6|[5 Regression] GCC 6
   |miscompiles Firefox JIT |miscompiles Firefox JIT
   |compiler|compiler

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

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon  ---
How do people handle this in practice? I mean it's creating a lot of noise when
you are trying to track regressions.

That's the main reason why I refrained from automating sending regression
warnings :)

[Bug libstdc++/70503] [4.9/5 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 Regression] extern |[4.9/5 Regression] extern
   |"C" functions in|"C" functions in
   |src/c++11/thread.cc are |src/c++11/thread.cc are
   |global in libstdc++.a   |global in libstdc++.a
  Known to fail|6.0 |

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Yes, I'm pretty sure it's not a regression.

[Bug c/70475] -Wmisleading-indentation quetionable in Eigen

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|UNCONFIRMED
   Assignee|ppalka at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Ever confirmed|1   |0

--- Comment #4 from Patrick Palka  ---
The fix to PR c/68187 made resolving this PR a bit more complicated.  I'll let
David handle it :)

[Bug c++/70539] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Marek Polacek from comment #1)
> Dup?
> 
> *** This bug has been marked as a duplicate of bug 70540 ***

Sorry for the noise; it wasn't intentional. The server somehow wasn't
responding, and I clicked submit a second time.

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think I see what's happening.  I should have a fix soon.

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[6 regression] FAIL:|FAIL:
   |20_util/shared_ptr/thread/d |20_util/shared_ptr/thread/d
   |efault_weaktoshared.cc  |efault_weaktoshared.cc
   |execution test  |execution test

--- Comment #13 from Jeffrey A. Law  ---
Based on c#10 and c#11, removing regression marker.  If Jon can get this fixed,
he'd have final say on whether or not to include the fix in gcc-6.

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This would shift the address right to remove the bits that are always zero:

--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -41,7 +41,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 const unsigned char invalid = mask + 1;

 inline unsigned char key(const void* addr)
-{ return _Hash_impl::hash(addr) & mask; }
+{
+  const int zero_bits = __builtin_ctz(alignof(shared_ptr));
+  return _Hash_impl::hash(addzero_bitsaligned) & mask; }

 /* Returns different instances of __mutex depending on the passed address
  * in order to limit contention.

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, clipboard fail, that's not what I thought I was pasting, this is:

--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -41,7 +41,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 const unsigned char invalid = mask + 1;

 inline unsigned char key(const void* addr)
-{ return _Hash_impl::hash(addr) & mask; }
+{
+  const int zero_bits = __builtin_ctz(alignof(shared_ptr));
+  return _Hash_impl::hash(uintptr_t(addr) >> zero_bits) & mask;
+}

 /* Returns different instances of __mutex depending on the passed address
  * in order to limit contention.

[Bug c++/70549] New: insn does not satisfy its constraints aarch64 gcc-4.8

[softadmin.lesia at obspm dot fr]

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

Bug ID: 70549
   Summary: insn does not satisfy its constraints aarch64 gcc-4.8
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: softadmin.lesia at obspm dot fr
  Target Milestone: ---

Hello 

i m hitting that

error: insn does not satisfy its constraints

(insn 1160 16 17 33 (set (reg:SF 1 x1)
(const_double:SF 1.0e+0 [0x0.8p+1])) sparse-iter/src/ccg_res.cpp:71 37
{*movsf_aarch64}
 (nil))

sparse-iter/src/ccg_res.cpp:209:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


on 

Processor   : AArch64 Processor rev 1 (aarch64)
processor   : 0
model name  : APM X-Gene Mustang board
cpu MHz : 2400.00
fpu : yes

with
gcc (Debian/Linaro 4.8.4-1) 4.8.4


and this command line

g++ -O3 -fPIC -DADD_ -Wall -fopenmp  -std=c++11 -DHAVE_CUBLAS
-DMIN_CUDA_ARCH=200 -I/usr/local/cuda/include -I./include -I./control
-I./sparse-iter/include -I./sparse-iter/control -c -o sparse-iter/src/cbicg.o
sparse-iter/src/cbicg.cpp
sparse-iter/src/ccg_res.cpp: In function ‘magma_int_t
magma_ccg_res(magma_c_matrix, magma_c_matrix, magma_c_matrix*,
magma_c_solver_par*, magma_queue_t)’:

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[softadmin.lesia at obspm dot fr]

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

--- Comment #1 from softadmin.lesia at obspm dot fr ---
Created attachment 38193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38193&action=edit
preprocessed source

[Bug libstdc++/69331] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #14 from Uroš Bizjak  ---
Also fails on alpha [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00299.html

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64
 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
  Known to work||4.9.4, 5.3.1, 6.0
 Resolution|--- |WONTFIX
  Known to fail||4.8.5

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I can reproduce with 4.8 but not with 4.9 or higher.
4.8 is no longer maintained, please try a more recent release.

[Bug c/70550] New: -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

Bug ID: 70550
   Summary: -Wuninitialized false positives in OpenMP code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#ifdef __SIZEOF_INT128__
typedef __int128 T;
#else
typedef long long T;
#endif

void bar (T);
#pragma omp declare target (bar)

void
foo (void)
{
  {
int i;
#pragma omp target defaultmap(tofrom:scalar)/* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target defaultmap(tofrom:scalar)/* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target  /* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target  /* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target firstprivate (i) /* { dg-warning "is
used uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target firstprivate (j) /* { dg-warning "is
used uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
  {
int i;
#pragma omp target private (i)  /* { dg-bogus "is used
uninitialized in this function" } */
{
  i = 26;
  bar (i);
}
  }
  {
T j;
#pragma omp target private (j)  /* { dg-bogus "is used
uninitialized in this function" } */
{
  j = 37;
  bar (j);
}
  }
}

shows some warnings that are IMNSHO desirable (explicit uses of firstprivate
clause with uninitialized var), and others where it is undesirable (mostly
implicit clauses).

[Bug c/70550] -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-05
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[julien.brule at obspm dot fr]

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

--- Comment #3 from julien.brule at obspm dot fr ---
Le 05/04/2016 17:24, ktkachov at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70549
>
> ktkachov at gcc dot gnu.org changed:
>
> What|Removed |Added
> 
>   Target||aarch64
>   Status|UNCONFIRMED |RESOLVED
>   CC||ktkachov at gcc dot gnu.org
>Known to work||4.9.4, 5.3.1, 6.0
>   Resolution|--- |WONTFIX
>Known to fail||4.8.5
>
> --- Comment #2 from ktkachov at gcc dot gnu.org ---
> I can reproduce with 4.8 but not with 4.9 or higher.
> 4.8 is no longer maintained, please try a more recent release.
>

sorry to bother you but i'm stuck with the 4.8
is there a way to make it work ?

thanks

[Bug middle-end/70550] -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 38194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38194&action=edit
gcc6-pr70550.patch

Untested fix.

[Bug c++/70513] [4.9/5/6 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
No, I misunderstood, that would make us accept the code.  But at least I have
simpler testcase:

struct S
{
  enum E : int;
  enum S::E : int { foo } e;
};

[Bug target/70510] ICE: output_operand: invalid %-code with -mavx512bw -masm=intel when emitting vpbroatcast

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Apr  5 16:26:40 2016
New Revision: 234752

URL: https://gcc.gnu.org/viewcvs?rev=234752&root=gcc&view=rev
Log:
PR target/70510
* config/i386/sse.md (iptr): Add V64QI, V32HI, V16SI and V8DI modes.

testsuite/ChangeLog:

PR target/70510
* gcc.target/i386/pr70510.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70510.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmm, I can't seem to find a particular commit or PR from a quick scan of the
logs.
But then again, the "insn does not satisfy its constraints" is a fairly common
ICE.

your GCC reports "gcc (Debian/Linaro 4.8.4-1) 4.8.4"
Therefore I'd report it to Linaro.
Christophe, can you help with this?

[Bug c++/70551] New: member function of template instantiated even though only declaration is needed

[rbock at eudoxos dot de]

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

Bug ID: 70551
   Summary: member function of template instantiated even though
only declaration is needed
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

This code fails to compile:

template
struct X
{
  X(X&&) { static_assert(sizeof(T) < 1, "Intentional Failure"); }
};

auto impl() -> X;
auto test() -> decltype(impl())
{
  return impl();
}

int main()
{
  test();
}

My understanding is that it should compile just fine. I admit, I started a
discussion on stackoverflow for this (see
http://stackoverflow.com/questions/36371571/clang-and-gcc-vs-msvc-and-icc-is-a-static-assert-in-the-copy-move-constructor-r)

Citing from the answer I deem correct:

Copy elision requires declaration of copy/move constructors but doesn't require
definition.
Member function definitions of templates are not instantiated unless their
definitions are required.
If a definition is not instantiated it cannot be tested for being ill-formed.
References:

14.7.1.1 …The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the definitions,
default arguments, or exception-specifications of the class member functions…

14.7.1.2 Unless a member of a class template… has been explicitly instantiated
or explicitly specialized, the specialization of the member is implicitly
instantiated when the specialization is referenced in a context that requires
the member definition to exist…

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #10 from Patrick Palka  ---
Author: ppalka
Date: Tue Apr  5 16:40:00 2016
New Revision: 234753

URL: https://gcc.gnu.org/viewcvs?rev=234753&root=gcc&view=rev
Log:
Fix PR c++/70452 (regression in C++ parsing performance)

gcc/cp/ChangeLog:

PR c++/70452
* constexpr.c (struct fundef_copy): New struct.
(struct fundef_copies_table_t): New struct.
(fundef_copies_table): New static variable.
(maybe_initialize_fundef_copies_table): New static function.
(get_fundef_copy): New static function.
(save_fundef_copy): New static function.
(cxx_eval_call_expression): Use get_fundef_copy, and
save_fundef_copy.
(constexpr_call_table): Add "deletable" GTY marker.

gcc/testsuite/ChangeLog:

PR c++/70452
* g++.dg/ext/constexpr-vla4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/70463] always use first element of mutex pool in src/c++11/shared_ptr.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> From https://bugzilla.redhat.com/show_bug.cgi?id=1315388
> 
> 
> const unsigned char mask = 0xf;
> 
> inline unsigned char key(const void* addr)
> { return _Hash_impl::hash(addr) & mask; }
> 
> This always returns 0 when addresses are 4-byte aligned.

Bah, no it doesn't. That's what std::hash does, but not
_Hash_impl::hash.

[Bug tree-optimization/70509] wrong code with extract from a v64qi

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  5 16:58:50 2016
New Revision: 234754

URL: https://gcc.gnu.org/viewcvs?rev=234754&root=gcc&view=rev
Log:
PR tree-optimization/70509
* tree-ssa-forwprop.c (simplify_bitfield_ref): Use bitsize_int instead
of the vector base type for index.

* gcc.target/i386/avx512bw-pr70509.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr70509.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug c++/67376] [5 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 regression] Comparison |[5 regression] Comparison
   |with pointer to |with pointer to
   |past-the-end of array fails |past-the-end of array fails
   |inside constant expression  |inside constant expression
  Known to fail|6.0 |

--- Comment #19 from Martin Sebor  ---
With the change committed in r234698 this is no longer a GCC 6 regression so
I'm adjusting the regression marker but leaving it for 5 since the change
hasn't been backported to the 5.x branch.