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

[amodra at gcc dot gnu.org]

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

--- Comment #17 from Alan Modra  ---
Author: amodra
Date: Fri Apr  8 02:11:52 2016
New Revision: 234821

URL: https://gcc.gnu.org/viewcvs?rev=234821=gcc=rev
Log:
PR70117, ppc long double isinf

gcc/
PR target/70117
* builtins.c (fold_builtin_classify): For IBM extended precision,
look at just the high-order double to test for NaN.
(fold_builtin_interclass_mathfn): Similarly for Inf.  For isnormal
test just the high double for Inf but both doubles for subnormal
limit.
gcc/testsuite/
* gcc.target/powerpc/pr70117.c: New.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr70117.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|6.0 |5.3.0
 Resolution|--- |FIXED

--- Comment #3 from TC  ---
Bah, wrong version field. This should be against 5 (because I was using
Coliru), but I neglected to test 6.

[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Once more, with line breaks:

  when a GNU dialect of a standard is specified, all features supported by the
  compiler are enabled, even when those features change the meaning of the base
  standard.  As a result, some strict-conforming programs may be rejected.

[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It's rejected in -std=gnu++11 and gnu++14 mode, but not -std=c++11 / c++14,
which agrees with the documentation for -std:

> when a GNU dialect of a standard is specified, all features supported by the 
> compiler are enabled, even when those features change the meaning of the base 
> standard.  As a result, some strict-conforming programs may be rejected.

Hex literals have been supported as a GNU extension for many years, that's one
of the reasons they are being standardized for C++17.

[Bug target/70589] New: PowerPC target attribute/pragma cannot set/disable -mfloat128

[meissner at gcc dot gnu.org]

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

Bug ID: 70589
   Summary: PowerPC target attribute/pragma cannot set/disable
-mfloat128
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The new -mfloat128 support in PowerPC GCC 6 cannot be set via a target
attribute or a target pragma.

The reason for this is the __float128 and __ibm128 keywords must be created at
program initialization type complete with the appropriate types. If you change
the float128 setting to on from being off, the keywords are not created.

This was noticed that libgcc's emulation routines did not configure properly
when the default for -mfloat128 was set off for PR 70381.

As a work around, I will submit a patch shortly to disable -mfloat128 or
-mfloat128-hardware from being set via the target attribute or target pragma.
However, a longer term fix should be to make it work.

[Bug c++/70588] [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.9.3
   Keywords||wrong-code
   Last reconfirmed||2016-04-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Depends on||69517
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
I'm marking this bug as dependent on bug 69517 since it makes sense to address
both at the same time and wouldn't do much good if one was fixed but not the
other.  I'm also working on a patch for both bugs so I'm assigning it to
myself.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517
[Bug 69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[Bug c++/70588] New: [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2

[msebor at gcc dot gnu.org]

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

Bug ID: 70588
   Summary: [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX
/ 2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similarly to bug 69517, r218655 (partially) removed from G++ support for
"Runtime-sized arrays with automatic storage duration" specified in WG21 N3639
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html), leaving
only support for ordinary C VLAs.  The support, introduced in r198745 and
available in GCC 4.9, included limited detection of common VLA errors such as
overflow in the VLA bounds.  When compiled with GCC 4.9 in c++1y mode the
program below is instrumented by GCC to detect the overflow and throw an
exception.  However, when compiled with GCC 5 or 6, the same program either
crashes at runtime due to the stack overflow or simply runs to completion.

This is not a new or surprising discovery but because the problem is distinct
from bug 69517 I raise a separate bug for it for the record.

$ cat v.c && /home/msebor/build/gcc-4.9.3/gcc/xg++
-B/home/msebor/build/gcc-4.9.3/gcc -L
/home/msebor/build/gcc-4.9.3/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-O2 -Wall -Wextra -Wpedantic -std=c++1y -xc++ v.c && ./a.out 
void g (void*) { }

void f (__SIZE_TYPE__ n)
{
char a[n];

g (a);
}

int main ()
{
volatile __SIZE_TYPE__ n = __SIZE_MAX__ / 2 + 1;
try {
f (n);
__builtin_printf ("VLA bounds overflow failed to throw\n");
}
catch (...) {
__builtin_printf ("VLA bounds overflow detected\n");
}
}
VLA bounds overflow detected


$ ~/bin/gcc-5.1.0/bin/g++ -O2 -Wall -Wextra -Wpedantic -std=c++14 -xc++ v.c &&
./a.out 
v.c: In function ‘void f(long unsigned int)’:
v.c:5:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 char a[n];
 ^
VLA bounds overflow failed to throw


$ ~/bin/gcc-5.1.0/bin/g++ -Wall -Wextra -Wpedantic -std=c++14 -xc++ v.c &&
./a.out 
v.c: In function ‘void f(long unsigned int)’:
v.c:5:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 char a[n];
 ^
Bus error (core dumped)

[Bug c++/70587] New: 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[rs2740 at gmail dot com]

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

Bug ID: 70587
   Summary: 0e1_p+0 should not be parsed as a single pp-number in
C++14 and earlier
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

p/P followed by +/- is not part of the pp-number production in C++ before
C++17, but GCC includes them anyway. This results in the following code being
erroneously rejected in C++11/14 mode:

long double operator""_p(long double) { return {}; }
auto x = 0e1_p+0; // should be parsed as 0e1_p + 0
  // but parsed as a single pp-number instead and rejected

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

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
On Thu, 7 Apr 2016, manu at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
> 
> --- Comment #8 from Manuel López-Ibáñez  ---
> (In reply to Axel Naumann from comment #2)
> > You asked for it, so here is my wish list:
> > - for C++ < 1z, do not support hexfloats, neither with "unsigned" not
> > negative exponents.
> 
> Since "unsigned" exponents are supported by standard C++11, g++ has to support
> them.

They aren't supported in the sense of being valid floating-literals.  
It's simply the case that if the 'p' or 'P' is followed by a digit, rather 
than by '+' or '-', then it forms part of the pp-number whatever standard 
version is in use (and so none of the lexical complications arise that 
occur in the p+ / p- / P+ / P- cases, so handling p as an extension 
is easy).

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
Slightly reduced test case:

Module foo_pointers_class
  implicit none
  type :: ty_foo_pointers
 class(*),pointer :: foo => NULL()
  end type ty_foo_pointers

  type :: ty_class_basis
  end type ty_class_basis
End Module foo_pointers_class

Module foo_class
  use foo_pointers_class
  implicit none
  type,extends(ty_class_basis) :: ty_foo2
 type(ty_foo_pointers) :: foo
  end type ty_foo2
End Module foo_class

Module foo_scripts_mod
  use foo_class, only: ty_foo2
  implicit none
contains
  subroutine foo_script1
type(ty_foo2) :: foo2
Call foo_init2(foo2)
  end subroutine  foo_script1

  subroutine foo_init2(self)
type(ty_foo2),target :: self
  end subroutine foo_init2
End Module foo_scripts_mod


The ICE goes away when the pointer initialization is removed.
I think there are similar (related?) PRs.

[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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Axel Naumann from comment #2)
> You asked for it, so here is my wish list:
> - for C++ < 1z, do not support hexfloats, neither with "unsigned" not
> negative exponents.

Since "unsigned" exponents are supported by standard C++11, g++ has to support
them.

> Or support both, as a GCC extention that's enabled by
> default - like in the GCC 5 times.

Given Joseph comments, it seems the "signed" extension is incompatible with
standard C++ < 1z. That is, the same valid program may behave differently
whether the extension is enabled or not.

> - if you remove support for C++ < 1z, state that hexfloats are unsupported
> in C++ < 1z.

Only "signed" exponents are unsupported. My patch above tries to catch this
case and give a better error message, but it is not as trivial as I thought.

> NB: Even if I would buy into the argument that diagnostics are limited by
> the tokens, I don't yet see why 'P' ends up being concated to the pp-number
> token in C++ < 1z.

You have to run g++ (actually, cc1plus) under a debugger to see why. See
lex_number. Doing it in a different way would probably break a lot of other
things.

[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  7 21:45:26 2016
New Revision: 234817

URL: https://gcc.gnu.org/viewcvs?rev=234817=gcc=rev
Log:
PR testsuite/70581
* gcc.dg/lto/simd-function_0.c: New test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lto/simd-function_0.c

[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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #6)
> But that wouldn't make any difference between 0x123p-2 and 0x123p -   2
> (or some of them coming from macro, other not etc.).
> So perhaps you want to also check the locus of each of the tokens and find
> out if they are actually consecutive in the source.

Hm, true. That seems more complicated. Possible, but too complicated for me
right now. Perhaps Axel wants to give it a try if he thinks it is important
enough.

Otherwise, perhaps worth mentioning that signed hexadecimal floats are only
available in C++1z in porting_to.html.

[Bug fortran/66643] Missing compilation error for formatted data transfer without format

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Note the extra comma in gfortran.dg/integer_exponentiation_6.F90 (see pr60751).
Any reason to keep it?

[Bug fortran/60751] Extra comma in WRITE statement not diagnosed

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres  ---
Note that the extra comma is used in the following tests:

gfortran.dg/array_constructor_49.f90
gfortran.dg/integer_exponentiation_6.F90
gfortran.dg/graphite/pr38083.f90

Any reason to keep it?

[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[andres.tiraboschi at tallertechnologies dot com]

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

--- Comment #2 from Andrés Agustín Tiraboschi  ---
#include 
int main()
{
__m128i r;

constexpr auto index = 1;
enum {index2 = index};
r = _mm_aeskeygenassist_si128(r, index2);
}

This works also.

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
But that wouldn't make any difference between 0x123p-2 and 0x123p -   2
(or some of them coming from macro, other not etc.).
So perhaps you want to also check the locus of each of the tokens and find out
if they are actually consecutive in the source.

[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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to jos...@codesourcery.com from comment #4)
> On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote:
> 
> > According to the manual, if an extension is not incompatible with the base
> > standard, it should not be disabled:
> 
> In general, this extension *is* incompatible with the base standard - 
> there are cases where a program is valid with both versions of pp-numbers, 
> but with different semantics.  See gcc.dg/c90-hexfloat-2.c, for example.

Oh, well, then current status makes sense.

> It should be possible to lex according to the selected standard, but track 
> that a pp-token could be a hex float together with the following two 
> pp-tokens (+ or - and the exponent with possible suffix) and then handle 
> things specially if that sequence of pp-tokens ends up getting converted 
> to tokens.

Perhaps something simpler like this could be enough to inform naive users like
me?

Index: expr.c
===
--- expr.c  (revision 233781)
+++ expr.c  (working copy)
@@ -568,11 +568,26 @@ cpp_classify_number (cpp_reader *pfile,
{
  if (DIGIT_SEP (*str))
SYNTAX_ERROR_AT (virtual_location,
 "digit separator adjacent to exponent");
  else
-   SYNTAX_ERROR_AT (virtual_location, "exponent has no digits");
+   {
+ if (radix == 16 && !CPP_OPTION (pfile, extended_numbers))
+   {
+ const cpp_token *tok2 = cpp_get_token (parse_in);
+ const cpp_token *tok3 = cpp_get_token (parse_in);
+ if ((tok2 == CPP_MINUS || tok2 == CPP_PLUS) 
+ && tok3  == CPP_NUMBER)
+   {
+ if (CPP_OPTION (pfile, cplusplus))
+   SYNTAX_ERROR_AT (virtual_location, "hexadecimal
floating constant with signed exponent requires C99");
+ else
+   SYNTAX_ERROR_AT (virtual_location, "hexadecimal
floating constant with signed exponent requires C++1z");
+   }
+   }
+   SYNTAX_ERROR_AT (virtual_location, "exponent has no
digits");
+   }
}
  do
{
  seen_digit_sep = DIGIT_SEP (*str);
  str++;



It would be better to say:

prog.cc:1:10: error: hexadecimal floating constant with signed exponent
requires C++1z
 auto d = 0x123p-2;
  ~~^~

but I have no idea how to create ranges dynamically in the new rich_loc world.

[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
int a, e, f;
short b, c, d;

int
foo (int x, int y)
{
  return (y == 0 || (x && y == 1)) ? x : x % y;
}

static short
bar (void)
{
  int i = foo (c, f);
  f = foo (d, 2);
  int g = foo (b, c);
  int h = foo (g > 0, c);
  c = (3 >= h ^ 7) <= foo (i, c);
  if (foo (e, 1))
return a;
  return 0;
}

int
main ()
{
  bar ();
  return 0;
}

I think this goes wrong during ifcombine, will have a look tomorrow.

[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-07
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|wrong code at -O2 and -O3   |[4.9/5/6 Regression] wrong
   |on x86_64-linux-gnu in  |code at -O2 and -O3 on
   |32-bit and 64-bit modes |x86_64-linux-gnu in 32-bit
   ||and 64-bit modes
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r195751, which means that most likely it has been latent before.

[Bug tree-optimization/70586] New: wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[chengniansun at gmail dot com]

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

Bug ID: 70586
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu in
32-bit and 64-bit modes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code is miscompiled by the trunk at -O2 and -O3 on
x86_64-linux-gnu in 32-bit and 64-bit modes.


This also affects gcc-4.8 and later versions.


$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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 20160407 (experimental) [trunk revision 234805] (GCC) 
$: 
$: gcc-trunk -w -m32 small.c -O3 ; ./a.out 
Floating point exception (core dumped)
$: gcc-trunk -w -m32 small.c -O2 ; ./a.out 
Floating point exception (core dumped)
$: gcc-trunk -w -m32 small.c -O1 ; ./a.out 
$: gcc-4.8 -w small.c -O3 ; ./a.out
Floating point exception (core dumped)
$: gcc-4.7 -w small.c -O3 ; ./a.out
$: 
$: cat small.c
int a, e, f;
short b, c, d;
int fn1(p1, p2) { return p2 == 0 || p1 && p2 == 1 ? p1 : p1 % p2; }

static short fn2() {
  int g, h, i = fn1(c, f);
  f = fn1(d, 2);
  g = fn1(b, c);
  h = fn1(g > 0, c);
  c = (3 >= h ^ 7) <= fn1(i, c);
  if (fn1(e, 1))
return a;
}

int main() {
  fn2();
  return 0;
}
$:

[Bug c++/70585] New: Bogus 'ambiguous template instantiation' error with partial specializations involving a pack expansion

[rs2740 at gmail dot com]

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

Bug ID: 70585
   Summary: Bogus 'ambiguous template instantiation' error with
partial specializations involving a pack expansion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

template class meow;
template struct purr;

template
struct purr<T, meow...> {};

template
struct purr<int, meow...> {};

template struct purr<int, meow>;

gcc HEAD 6.0.0 20160407 (experimental) on Wandbox prints:

prog.cc:10:17: error: ambiguous template instantiation for 'struct purr<int,
meow >'
 template struct purr<int, meow>;
 ^~~~
prog.cc:6:8: note: candidates are: template struct
purr<T, meow...> [with T = int; Ts = {int}]
 struct purr<T, meow...> {};
^~~~
prog.cc:8:8: note: template struct purr<int,
meow...> [with Ts = {int}]
 struct purr<int, meow...> {};
^~
prog.cc:10:17: error: explicit instantiation of 'struct purr<int, meow >'
before definition of template
 template struct purr<int, meow>;
 ^~~~

Clang compiles this code.

[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #1 from Daniel Gutson  
---
Additional data: an enumerator works:

int main()
{
__m128i r;

//constexpr auto index = 1;
enum { index = 1 };
r = _mm_aeskeygenassist_si128(r, index);
}

[Bug target/70381] On powerpc, -mfloat128 is on by default for all VSX systems

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-04-07
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from Michael Meissner  ---
Unfortunately the fix checked disables building the software emulation
functions in libgcc.

This is due to #pragma GCC target ("vsx,float128") does not enable the
__float128 keyword, so the test fails.

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

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote:

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

In general, this extension *is* incompatible with the base standard - 
there are cases where a program is valid with both versions of pp-numbers, 
but with different semantics.  See gcc.dg/c90-hexfloat-2.c, for example.

That case involves pp-numbers such as 0x1p+f that aren't valid to convert 
to tokens.  But you could produce other examples involving concatenation 
that are valid without hex floats but not with them, e.g.:

#define a0x123p b
#define concat(x, y) x##y
concat(a, 0x123p-2)

which is valid without hex floats (expanding to b-2), but invalid with 
them because of an invalid concatenation.  So any extended pp-number 
syntax that include valid hex floats also introduces errors on valid code.

It should be possible to lex according to the selected standard, but track 
that a pp-token could be a hex float together with the following two 
pp-tokens (+ or - and the exponent with possible suffix) and then handle 
things specially if that sequence of pp-tokens ends up getting converted 
to tokens.

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

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com  ---
On Tue, 5 Apr 2016, amodra at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
> 
> --- Comment #14 from Alan Modra  ---
> > if (fmt == _extended_double)
> 
> No, there is mips_extended_format too.

I think that's now unused after the removal of IRIX support, and so should 
be removed from GCC.  (The support for that format in fp-bit.[ch] is also 
now unused.)

[Bug c++/70584] New: constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[daniel.gutson at tallertechnologies dot com]

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

Bug ID: 70584
   Summary: constexpr variables cannot be used as intrinsic
arguments where an immediate is expected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at tallertechnologies dot com
  Target Milestone: ---

Created attachment 38216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38216=edit
test case

The following code causes gcc to complain that the last argument should be an
8-bit immediate value:

#include 
int main()
{
__m128i r;

constexpr auto index = 1;
r = _mm_aeskeygenassist_si128(r, index);
}

This fails with -O0 but not with -O3.
The arguments to reproduce the issue are:
g++ -std=c++14 -msse -msse2 -maes -O0 tst.cpp -o tst

I attached the code anyway.

FWIW, this works in clang both for -O0 and for -O3. I think that constexpr
variables should be valid immediate arguments.

This bug affects the development of template metaprograms.

If there is agreement that this should be fixed, feel free to assign this to
andres.tirabos...@tallertechnologies.com .

[Bug c++/70583] New: [6 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 70583
   Summary: [6 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C
-std=gnu++98 execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/vta
ble2.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test
/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/
test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc
/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/tes
t/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98
-fno-s
trict-aliasing
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.li
bs -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/test/g
nu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o ./vtable2.exe
PASS: g++.old-deja/g++.abi/vtable2.C  -std=gnu++98 (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc+
+-v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++
-v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:
/test/gnu/gcc/objdir/gcc
spawn [open ...]
FAIL: g++.old-deja/g++.abi/vtable2.C  -std=gnu++98 execution test

Test returns 5 and fails in this hunk:

  if (! CMP_VPTR (vtbl, _s3))
return 5;

Breakpoint 1, main ()
at /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C:175
175   if (! CMP_VPTR (vtbl, _s3))
(gdb) p vtbl
$1 = (ptrdiff_t *) 0x800101d0 
(gdb) p S3_s3
$2 = {} 0x400034c0 
(gdb) p _s3
$3 = ( *) 0x400034c0 
(gdb) stepi
0x4000366c  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
0x40003670  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
0x40003674  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
0x40003678  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
0x4000367c  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
0x40003680  175   if (! CMP_VPTR (vtbl, _s3))
(gdb)
176 return 5;

This is with revision 234788.  Revision 234427 was okay.

Similar fails:
FAIL: g++.old-deja/g++.abi/vtable2.C  -std=gnu++11 execution test
FAIL: g++.old-deja/g++.abi/vtable2.C  -std=gnu++14 execution test

[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jakub Jelinek  ---
> Created attachment 38215
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38215=edit
> gcc6-pr70581.patch
>
> Your assembler is too old.  Untested fix.

Just tried it: with /bin/as, the test becomes unsupported because the
avx512f test fails, with gas it passes as before.

Thanks.
Rainer

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[costinc at gmail dot com]

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

costinc at gmail dot com changed:

   What|Removed |Added

 CC||costinc at gmail dot com

--- Comment #23 from costinc at gmail dot com ---
I've just been bitten by this.

The problem isn't the attribute, it's the on-by-default warning. Why force
people to move from one convention of ignoring expression results to another?

I've just wasted one hour of my life. On the opposite side of the scale there
are people using prettier ways to ignore expression results. I really hope
someone, somewhere, was deterred from ignoring a result using a much uglier
method than (void) and, because of it, fixed a real bug (this must be the only
scenario that favors disallowing (void), deterrence through repugnance, am I
wrong?).

Note that casting to void seems to be mentioned in the standard precisely for
discarding expression results:
"Any expression can be explicitly converted to type “cv void.” The expression
value is discarded."
At best, this warning should be restricted to gnu99 or similar.

And if the attribute and it's associated warning are supposed to apply only to
important security related code then where is the warning for non-security
related code? The warning name pretty clearly relates to the general problem.
Isn't that confusing?

My 2c: Clang did the right thing.

Please, at least make the warning off-by-default.

[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 #14 from Patrick Palka  ---
trunk is now at

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
  1287 kB ( 1%) ggc
 phase parsing   :   1.28 (100%) usr   0.20 (100%) sys   1.48 (99%)
wall  156462 kB (99%) ggc
 |name lookup:   0.03 ( 2%) usr   0.01 ( 5%) sys   0.04 ( 3%) wall 
81 kB ( 0%) ggc
 |overload resolution:   0.04 ( 3%) usr   0.00 ( 0%) sys   0.05 ( 3%) wall 
   628 kB ( 0%) ggc
 preprocessing   :   0.03 ( 2%) usr   0.04 (20%) sys   0.09 ( 6%) wall 
  2048 kB ( 1%) ggc
 parser (global) :   0.02 ( 2%) usr   0.07 (35%) sys   0.06 ( 4%) wall 
  7735 kB ( 5%) ggc
 parser function body:   1.23 (96%) usr   0.09 (45%) sys   1.33 (89%) wall 
146667 kB (93%) ggc
 TOTAL :   1.28 0.20 1.49
157759 kB


The remaining extra memory and runtime overhead relative to 4.9 is mostly due
to the constexpr_call_table which caches the result of each constexpr call
that's been evaluated.  This table now gets cleared during GC though which in
real programs triggers frequently enough that its size won't be a problem.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #43 from Bernd Schmidt  ---
I suspect the message Roger quoted was from the earlier version with the
printf; that one didn't give a location.

I advocate no action until we have a reproducer so we can know what's going on.

[Bug preprocessor/70518] Conditional compilation of #line directives

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to jos...@codesourcery.com from comment #4)
> On Sun, 3 Apr 2016, elyk03 at gmail dot com wrote:
> 
> > Should #line be processed unconditionally?  I know the preprocessor has to 
> > keep
> 
> It should not be processed in skipped blocks.  See C11 6.10.1#6

I think that settles it.

It might be worth it to open a different PR saying that the caret line should
use the real source location and ignore line directives (and linemarkers). That
seems hard to fix, though.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[manu at gcc dot gnu.org]

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

--- Comment #42 from Manuel López-Ibáñez  ---
(In reply to Roger Orr from comment #41)
> I have seen the message before: for example from a build with revision 
> 
> line-map.c: file "/usr/include/asm/sockios.h" left but not entered

You can also simply filter every '^# [0-9]' line from the preprocessed output
before compiling. There must be some broken linemarker, perhaps as a result of
copy-pasting from another preprocessed file.

I wonder, don't we give a precise location now for the broken linemarker?

Perhaps we should control this with -Wlinemarker, such that people can use
-Wno-linemarker. We may have underestimated how much broken code might be out
there.

[Bug preprocessor/70518] Conditional compilation of #line directives

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Sun, 3 Apr 2016, elyk03 at gmail dot com wrote:

> Should #line be processed unconditionally?  I know the preprocessor has to 
> keep

It should not be processed in skipped blocks.  See C11 6.10.1#6: "Each 
directive’s condition is checked in order. If it evaluates to false 
(zero), the group that it controls is skipped: directives are processed 
only through the name that determines the directive in order to keep track 
of the level of nested conditionals; the rest of the directives’ 
preprocessing tokens are ignored, as are the other preprocessing tokens in 
the group.".

This means, for example, that

#if 0
#line invalid line directive
#endif

is valid, whereas that #line directive would not be valid outside #if 0.

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Of course.  Patch changing both is preapproved.

[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Your assembler is too old.  Untested fix.

[Bug ipa/70582] [6 regression] gcc.dg/attr-weakref-1.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug ipa/70582] [6 regression] gcc.dg/attr-weakref-1.c FAILs

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 38214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38214=edit
assembler output

[Bug ipa/70582] New: [6 regression] gcc.dg/attr-weakref-1.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 70582
   Summary: [6 regression] gcc.dg/attr-weakref-1.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.1[012]
Target: i386-pc-solaris2.1[012]
 Build: i386-pc-solaris2.1[012]

After 20160401, gcc.dg/attr-weakref-1.c started to FAIL on Solaris/x86 with
/bin/as:

FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
WARNING: gcc.dg/attr-weakref-1.c compilation failed to produce executable

Excess errors:
Assembler: attr-weakref-1.c
"/var/tmp//ccUSaysF.s", line 171 : Multiply defined symbol: "Wv3a"

I'm attaching the assembler output.  When using gas, this still works since
.weakref is used there.

Most likely caused by the recent patch for PR ipa/68881.

  Rainer

[Bug target/70581] [6 regression] gcc.dg/lto/simd-function FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/70581] New: [6 regression] gcc.dg/lto/simd-function FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 70581
   Summary: [6 regression] gcc.dg/lto/simd-function FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.1[012]
Target: i386-pc-solaris2.1[012]
 Build: i386-pc-solaris2.1[012]

After 20160401, the gcc.dg/lto/simd-function testcase began to FAIL on
Solaris/x86
with /bin/as:

FAIL: gcc.dg/lto/simd-function c_lto_simd-function_0.o assemble,  -fopenmp-simd
-O3 -ffast-math -mavx2 -flto -flto-partition=max 
UNRESOLVED: gcc.dg/lto/simd-function
c_lto_simd-function_0.o-c_lto_simd-function_0.o execute  -fopenmp-simd -O3
-ffast-math -mavx2 -flto -flto-partition=max 
UNRESOLVED: gcc.dg/lto/simd-function
c_lto_simd-function_0.o-c_lto_simd-function_0.o link  -fopenmp-simd -O3
-ffast-math -mavx2 -flto -flto-partition=max 

Assembler: simd-function_0.c
"/var/tmp//ccw.aGWM.s", line 850 : Invalid instruction argument
Near line: "vmulps  %zmm1, %zmm0, %zmm0"
"/var/tmp//ccw.aGWM.s", line 858 : Illegal mnemonic
Near line: "vpxord  %zmm3, %zmm3, %zmm3"
"/var/tmp//ccw.aGWM.s", line 858 : Syntax error
Near line: "vpxord  %zmm3, %zmm3, %zmm3"
"/var/tmp//ccw.aGWM.s", line 860 : Invalid instruction argument
Near line: "vmulps  %zmm1, %zmm0, %zmm0"
"/var/tmp//ccw.aGWM.s", line 863 : Illegal mnemonic
Near line: "vpcmpd  $4, %zmm3, %zmm2, %k1"
"/var/tmp//ccw.aGWM.s", line 863 : Syntax error
Near line: "vpcmpd  $4, %zmm3, %zmm2, %k1"
"/var/tmp//ccw.aGWM.s", line 866 : Illegal mnemonic
Near line: "kmovw   %k1, %eax"
"/var/tmp//ccw.aGWM.s", line 866 : Syntax error
Near line: "kmovw   %k1, %eax"
"/var/tmp//ccw.aGWM.s", line 870 : Invalid instruction argument
Near line: "vmovaps %zmm0, -120(%ebp){%k1}"
"/var/tmp//ccw.aGWM.s", line 872 : Invalid instruction argument
Near line: "vmovaps -120(%ebp), %zmm0"

for both 32 and 64-bit.  It seems the compiler started to emit avx512f insns
despite the -mavx2.  Either the testcase needs to be amended requiring the 
corresponding effective-target, or the compiler fixed not to emit those unless
told to...

Here's a diff between the assembler outputs from 20160401 and 20160407:

--- /homes/ro/simd-function_0.s 2016-04-07 18:05:16.449629000 +0200
+++ simd-function_0.s   2016-04-07 18:06:05.170292167 +0200
[...]
@@ -846,6 +846,39 @@
leal-4(%ecx), %esp
ret
.size   _ZGVdM8vv_my_mul, .-_ZGVdM8vv_my_mul
+   .p2align 4,,15
+   .globl  _ZGVeN16vv_my_mul
+   .type   _ZGVeN16vv_my_mul, @function
+_ZGVeN16vv_my_mul:
+   vmulps  %zmm1, %zmm0, %zmm0
+   ret
+   .size   _ZGVeN16vv_my_mul, .-_ZGVeN16vv_my_mul
+   .p2align 4,,15
+   .globl  _ZGVeM16vv_my_mul
+   .type   _ZGVeM16vv_my_mul, @function
+_ZGVeM16vv_my_mul:
+   leal4(%esp), %ecx
+   vpxord  %zmm3, %zmm3, %zmm3
+   andl$-64, %esp
+   vmulps  %zmm1, %zmm0, %zmm0
+   pushl   -4(%ecx)
+   pushl   %ebp
+   vpcmpd  $4, %zmm3, %zmm2, %k1
+   movl%esp, %ebp
+   pushl   %ecx
+   kmovw   %k1, %eax
+   subl$308, %esp
+   testw   %ax, %ax
+   je  .L89
+   vmovaps %zmm0, -120(%ebp){%k1}
+.L89:
+   vmovaps -120(%ebp), %zmm0
+   addl$308, %esp
+   popl%ecx
+   popl%ebp
+   leal-4(%ecx), %esp
+   ret
+   .size   _ZGVeM16vv_my_mul, .-_ZGVeM16vv_my_mul
.comm   x,16384,32
.section.rodata
.align 4

  Rainer

[Bug fortran/70575] write syntax check

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---


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

[Bug fortran/60751] Extra comma in WRITE statement not diagnosed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||valeryweber at hotmail dot com

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

[Bug middle-end/70580] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

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

Bug ID: 70580
   Summary: [gomp4] -O0 execution testing FAILs for
libgomp.oacc-c-c++-common/if-1.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

PASSes in trunk.

[Bug middle-end/70579] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

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

Bug ID: 70579
   Summary: [gomp4] -O0 execution testing FAILs for
libgomp.oacc-c-c++-common/host_data-1.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

PASSes in trunk.

[Bug testsuite/70553] pr70496.c should exclude Thumb only targets

[thopre01 at gcc dot gnu.org]

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

--- Comment #1 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Apr  7 16:19:20 2016
New Revision: 234811

URL: https://gcc.gnu.org/viewcvs?rev=234811=gcc=rev
Log:
2016-04-07  Thomas Preud'homme  

gcc/testsuite/

PR testsuite/70553
* gcc.target/arm/pr70496.c: Also require arm_arm_ok effective target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr70496.c

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

--- Comment #9 from Yury Gribov  ---
Better do the same for halt_on_error-2.

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00351.html

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Right. Dominique, can you check if s/memset/__builtin_memset/g fixes the 
> issue?

The test succeeds with the following patch

--- ../_clean/gcc/testsuite/c-c++-common/asan/halt_on_error-1.c 2015-11-23
10:17:05.0 +0100
+++ gcc/testsuite/c-c++-common/asan/halt_on_error-1.c   2016-04-07
18:10:11.0 +0200
@@ -9,7 +9,7 @@ volatile int ten = 10;

 int main() {
   char x[10];
-  memset(x, 0, ten + 1);
+  __builtin_memset(x, 0, ten + 1);
   asm volatile ("" : : : "memory");
   volatile int res = x[ten];
   x[ten] = res + 3;

Thanks.

[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 #13 from Patrick Palka  ---
Author: ppalka
Date: Thu Apr  7 16:12:05 2016
New Revision: 234810

URL: https://gcc.gnu.org/viewcvs?rev=234810=gcc=rev
Log:
Avoid needless unsharing during constexpr evaluation (PR c++/70452)

gcc/cp/ChangeLog:

PR c++/70452
* constexpr.c (find_constructor): New function.
(unshare_constructor): New function.
(cxx_eval_call_expression): Use unshare_constructor instead of
unshare_expr.
(find_array_ctor_elt): Likewise.
(cxx_eval_vec_init_1): Likewise.
(cxx_eval_store_expression): Likewise.
(cxx_eval_constant_expression): Likewise.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #41 from Roger Orr  ---
I have seen the message before: for example from a build with revision 

line-map.c: file "/usr/include/asm/sockios.h" left but not entered

I've only noticed it with builds from gcc-trunk, which I tested with back in
Dec/Jan. I saw this message from some compilation but it seemed benign...

I have not seen this message with builds from gcc 5.3.0 and before, but it is
possible I've simply not noticed as it does gets a bit buried in the build
logs.

[Bug target/59683] ICE: in classify_argument, at config/i386/i386.c:6637 with #pragma GCC target("avx512f")

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
This hunk from Jakub's fix for PR61925 makes test working:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a41efa4..6aebaed 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4962,6 +4962,15 @@ static GTY(()) tree ix86_previous_fndecl;
 void
 ix86_reset_previous_fndecl (void)
 {
+  tree new_tree = target_option_current_node;
+  cl_target_option_restore (_options, TREE_TARGET_OPTION (new_tree));
+  if (TREE_TARGET_GLOBALS (new_tree))
+restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
+  else if (new_tree == target_option_default_node)
+restore_target_globals (_target_globals);
+  else
+TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
+
   ix86_previous_fndecl = NULL_TREE;
 }

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

--- Comment #7 from Yury Gribov  ---
Right. Dominique, can you check if s/memset/__builtin_memset/g fixes the issue?

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #40 from Bernd Schmidt  ---
The message previously was a plain printf, not a warning or error so it would
not have interrupted compilation. Did you get the message with earlier
compilers, or did it start to appear recently?

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Comment on attachment 38213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38213
Proposed patch

Perhaps just use __builtin_memset instead of memset instead?

[Bug target/70574] [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Actually, I believe the bug is already at fwprop1.
We have:
(insn 247 246 18 2 (set (reg:DI 301 [ u128_0 ])
(const_int 0 [0])) pr70574.c:7 85 {*movdi_internal}
 (nil))
(insn 18 247 19 2 (set (reg:QI 115)
(not:QI (subreg:QI (reg:DI 301 [ u128_0 ]) 0))) pr70574.c:8 506
{*one_cmplqi2_1}
 (nil))
...
(insn 31 30 32 2 (set (reg:SI 128)
(subreg:SI (reg:QI 115) 0)) pr70574.c:8 86 {*movsi_internal}
 (nil))
and fwprop1 does:
In insn 31, replacing
 (subreg:SI (reg:QI 115) 0)
 with (const_int -1 [0x])
Changes to insn 31 not profitable
 Setting REG_EQUAL note
and that turns insn 31 into:
(insn 31 29 32 2 (set (reg:SI 128)
(subreg:SI (reg:QI 115) 0)) pr70574.c:8 86 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int -1 [0x])
(expr_list:REG_DEAD (reg:QI 115)
(nil
(and correctly modifies insn 18 first to (set (reg:QI 115) (const_int -1))).
The bug is in the REG_EQUAL note, (subreg:SI (reg:QI 115) 0), a paradoxical
subreg of QImode -1, is not equivalent to SImode -1.  So, either fwprop should
have replaced it the paradoxical subreg with CONST_INT, or it shouldn't add the
REG_EQUAL note.

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

--- Comment #5 from Yury Gribov  ---
Created attachment 38213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38213=edit
Proposed patch

Ah, so the problem is caused by _FORTIFY_SOURCE being enabled on Darwin by
default. This check precedes ASan and causes app to abort too early. Could you
test the attached patch?

[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Attachment #38211|0   |1
is obsolete||

--- Comment #1 from Marek Polacek  ---
Created attachment 38212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38212=edit
preprocessed

Updated preprocessed file.

[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
Offending commit: https://gcc.gnu.org/ml/gcc-cvs/2016-03/msg00744.html :
...
Author: hubicka
Date: Wed Mar 30 14:30:57 2016
New Revision: 234572

URL: https://gcc.gnu.org/viewcvs?rev=234572=gcc=rev
Log:
* tree-ssa-loop-niter.c (idx_infer_loop_bounds): We can't get realistic
estimates here.
* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Use also
max_loop_iterations_int.
(tree_unswitch_outer_loop): Likewise.
* tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise.
* tree-vect-loop.c (vect_analyze_loop_2): Likewise.
...

[Bug debug/70578] New: internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf

[mpolacek at gcc dot gnu.org]

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

Bug ID: 70578
   Summary: internal compiler error: in output_index_string, at
dwarf2out.c with -gsplit-dwarf
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38211=edit
preprocessed

With
Target: x86_64-pc-linux-gnu
Configured with: /home/marek/src/gcc/configure --enable-languages=c,c++,objc
--enable-checking=yes -with-system-zlib --disable-bootstrap --disable-libvtv
--disable-libcilkrts --disable-libitm --disable-libgomp --disable-libcc1
--disable-libstdcxx-pch --disable-libssp --disable-isl --disable-libatomic
Thread model: posix
gcc version 6.0.0 20160407 (experimental) (GCC)

I see:

$ ./cc1plus -fpreprocessed q.ii -quiet -g3 -gsplit-dwarf -O -w
q.ii:763:1: internal compiler error: in output_index_string, at
dwarf2out.c:25505
 }
 ^
0xa09c4e output_index_string(indirect_string_node**, unsigned int*)
/home/marek/src/gcc/gcc/dwarf2out.c:25505
0xa1978e void hash_table<indirect_string_hasher,
xcallocator>::traverse_noresize(unsigned int*)
/home/marek/src/gcc/gcc/hash-table.h:950
0xa09dd7 output_indirect_strings
/home/marek/src/gcc/gcc/dwarf2out.c:25550
0xa0e8d6 dwarf2out_finish
/home/marek/src/gcc/gcc/dwarf2out.c:27680
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/70575] write syntax check

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Add -std=f95 to your command line.

troutmask:sgk[206] gfc6 -c -std=f95 a.f90
a.f90:2:13:

write(*,*) , 1
 1
Error: GNU Extension: Comma before i/o item list at (1)
troutmask:sgk[207]

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||stackoverflow_dl@gmx-topmai
   ||l.de

--- Comment #3 from Jonathan Wakely  ---
*** Bug 70414 has been marked as a duplicate of this bug. ***

[Bug c++/70414] Function declaration in other scope: type safety violation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
This is a dup of a bug I opened recently.

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

[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-regression/2016-03/msg00336.html :

Regressions on trunk at revision 234600 vs revision 234546

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #39 from Roger Orr  ---
The resolution of this issue causes a problem for me as it results in
compilation errors in our build.

We are compiling with distcc which AIUI distributes the pre-processed
intermediate output.

With revision 234480 we get no warnings logged and clean compilation.

With revision 234481 we get a number of warnings logged - but this interacts
unfortunately with -Werror (which we also set) and so quite a number of our
compilations fail.

(I cannot as yet detect a pattern with which compilations are affected, but the
set is consistent on a rebuild.)

I can reproduce the distcc problem by using -E to generate pre-processed source
and compiling this.
Note: the pre-processed intermediate output does not change between 234480 and
234481, it's the compilation of this pre-processed output that fails.

Unfortunately the failing code is proprietary so I am not at liberty to upload
the pre-processed output, I have attempted to produce some smaller examples but
so far with no success.

Could the generation of the warning be made dependent upon a more specific
warning flag?

[Bug tree-optimization/70577] New: prefetch.c scan-tree-dump-times aprefetch failures

[vries at gcc dot gnu.org]

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

Bug ID: 70577
   Summary: prefetch.c scan-tree-dump-times aprefetch failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

PASS: gcc.dg/tree-ssa/prefetch-5.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued
prefetch" 2
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Not
prefetching" 1

[Bug c++/70414] Function declaration in other scope: type safety violation

[jaak at ristioja dot ee]

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

Jaak Ristioja  changed:

   What|Removed |Added

 CC||jaak at ristioja dot ee

--- Comment #3 from Jaak Ristioja  ---
*** Bug 70576 has been marked as a duplicate of this bug. ***

[Bug c++/70576] G++ compiles and links invalid code when shadowing global function in function scope

[jaak at ristioja dot ee]

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

Jaak Ristioja  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jaak Ristioja  ---
OFTC #gcc [16:54:00]  jotik: that the code doesn't get rejected
is a bug in gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414

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

[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from vries at gcc dot gnu.org ---
Confirmed: https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00602.html :
...
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued
prefetch" 2
FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Not
prefetching" 1
...

[Bug c++/70576] New: G++ compiles and links invalid code when shadowing global function in function scope

[jaak at ristioja dot ee]

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

Bug ID: 70576
   Summary: G++ compiles and links invalid code when shadowing
global function in function scope
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaak at ristioja dot ee
  Target Milestone: ---

int foo() { return 2; }
int main() {
  int& foo();
  foo() = 42; // Segfault
}

First detected here:
https://stackoverflow.com/questions/36477542/what-does-int-foo-mean-in-c

Compiles with GCC 4.7.4, 4.8.5, 4.9.3 and 5.3.0 without any warnings with -Wall
-Wextra -Wshadow.

Clang errors with:

test.cpp:3:8: error: functions that differ only in their return type cannot be
overloaded
  int& foo();
   ^
test.cpp:1:5: note: previous definition is here

[Bug target/70574] [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-07
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r210824.

[Bug fortran/70575] New: write syntax check

[valeryweber at hotmail dot com]

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

Bug ID: 70575
   Summary: write syntax check
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Hi All
Should gfortran complain about the syntax of the following code?
v

gcc version 6.0.0 20160330 (experimental) (GCC) 

cat t.f90 
subroutine foo()
write(*,*) , 1
end subroutine foo

[Bug target/64386] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #4 from Kirill Yukhin  ---
Done.

[Bug target/70574] New: [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable

[zsojka at seznam dot cz]

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

Bug ID: 70574
   Summary: [5/6 Regression] wrong code with -mavx2, read of
partially initialised stack variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Created attachment 38210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38210=edit
reduced testcase

Output:
$ gcc -O -fPIC -frerun-cse-after-loop -fno-tree-ccp -mcmodel=medium -mavx2
testcase.c
$ valgrind -q ./a.out
==1282== Conditional jump or move depends on uninitialised value(s)
==1282==at 0x400653: main (in /home/zso/gcc-bug/89/a.out)
==1282== 
Aborted


The problem most likely is (intel sytax):
...
foo:
...
mov DWORD PTR -52[rbp], edi # %sfp, u64_0
mov QWORD PTR -64[rbp], rcx # %sfp, u128_1
1)  mov BYTE PTR -48[rbp], -1   # %sfp,
vpxor   xmm2, xmm2, xmm2# tmp120
2)  vpinsrb xmm2, xmm2, BYTE PTR -48[rbp], 1# tmp120, tmp120, %sfp,
vmovd   xmm4, DWORD PTR -64[rbp]# tmp124, %sfp
mov eax, 0  # tmp126,
vpinsrb xmm4, xmm4, eax, 1  # tmp125, tmp124, tmp126,
3)  vmovd   xmm3, DWORD PTR -48[rbp]# tmp129, %sfp
...

1 stores a "byte" -1, 2 reads "byte" -1, 3 reads "dword" -1 (3 bytes of
garbage)


$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234794-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-234794-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20160406 (experimental) (GCC)

[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|5.3.0   |5.0
 Resolution|--- |FIXED
   Assignee|jnorris at gcc dot gnu.org |tschwinge at gcc dot 
gnu.org
   Target Milestone|--- |5.4

--- Comment #6 from Thomas Schwinge  ---
In r234806 now also fixed on gcc-5-branch.

[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result

[tschwinge at gcc dot gnu.org]

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

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Apr  7 11:43:30 2016
New Revision: 234806

URL: https://gcc.gnu.org/viewcvs?rev=234806=gcc=rev
Log:
[PR libgomp/69414] Fix handling of subarrays with update directive

libgomp/
Backport trunk r234428:

2016-03-23  James Norris  
Daichi Fukuoka 

PR libgomp/69414
* oacc-mem.c (delete_copyout, update_dev_host): Fix device address.
* testsuite/libgomp.oacc-c-c++-common/update-1.c: Additional tests.
* testsuite/libgomp.oacc-c-c++-common/update-1-2.c: Likewise.
* testsuite/libgomp.oacc-fortran/update-1.f90: New file.

Added:
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-fortran/update-1.f90
Modified:
branches/gcc-5-branch/libgomp/ChangeLog
branches/gcc-5-branch/libgomp/oacc-mem.c
   
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1-2.c
   
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1.c

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely  ---
Thanks for the info. The locale_t functionality is the main thing that will
need work, but it's good to know you were able to get everything else working
well.

[Bug libstdc++/70564] Problem with std::experimental::not_fn

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Rodrigo from comment #0)
> which calls _Not_fn(_Not_fn&) since __pred is an lvalue.
> However, between these _Not_fn constructors:
> 
>   template
> explicit
> _Not_fn(_Fn2&& __fn) : _M_fn(std::forward<_Fn2>(__fn)) { }
> 
> _Not_fn(const _Not_fn& __fn) = default;
> _Not_fn(_Not_fn&& __fn) = default;
> 
> the first one wins and triggers an error.

Oops, that constructor needs to be constrained.

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #7)
> (In reply to ktkachov from comment #6)
> > Ah, on second glance the peephole looks correct in itself, but the second
> > branch following the bmi uses an incorrect condition code.
> > So we have:
> > tst r3, #2
> > bne .L3
> > beq .L6
> > 
> > being transformed into:
> > ldrbr3, [r0]@ zero_extendqisi2
> > lslsr3, r3, #30
> > bmi .L3
> > beq .L6
> > 
> > 
> > The beq needs to be updated to be the opposite of bmi. That is, bpl
> 
> Sounds like the peephole is missing a reg-dead check on the condition code
> value.

Yep, that seems to do the trick. I'll test a patch.
Thanks Richard.

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[rearnsha at gcc dot gnu.org]

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

--- Comment #7 from Richard Earnshaw  ---
(In reply to ktkachov from comment #6)
> Ah, on second glance the peephole looks correct in itself, but the second
> branch following the bmi uses an incorrect condition code.
> So we have:
>   tst r3, #2
>   bne .L3
>   beq .L6
> 
> being transformed into:
>   ldrbr3, [r0]@ zero_extendqisi2
>   lslsr3, r3, #30
>   bmi .L3
>   beq .L6
> 
> 
> The beq needs to be updated to be the opposite of bmi. That is, bpl

Sounds like the peephole is missing a reg-dead check on the condition code
value.

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Problem is that we don't have access to Darwin hardware. Perhaps you could
> get a failing stacktrace via gdb?

(lldb) run
Process 79186 launched:
'/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out' (x86_64)
Process 79186 stopped
* thread #1: tid = 0x29c6013, 0x7fff9225df06
libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGABRT
frame #0: 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff9225df06 <+10>: jae0x7fff9225df10; <+20>
0x7fff9225df08 <+12>: movq   %rax, %rdi
0x7fff9225df0b <+15>: jmp0x7fff922587cd; cerror_nocancel
0x7fff9225df10 <+20>: retq   
(lldb) bt
* thread #1: tid = 0x29c6013, 0x7fff9225df06
libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGABRT
  * frame #0: 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff96b934ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff880276e7 libsystem_c.dylib`abort + 129
frame #3: 0x7fff8802785e libsystem_c.dylib`abort_report_np + 181
frame #4: 0x7fff8804da14 libsystem_c.dylib`__chk_fail + 48
frame #5: 0x7fff8804d9e4 libsystem_c.dylib`__chk_fail_overflow + 16
frame #6: 0x7fff8804da7a libsystem_c.dylib`__memset_chk + 37
frame #7: 0x00010f4f a.out`main + 42 at halt_on_error-1.c:12
frame #8: 0x7fff924055ad libdyld.dylib`start + 1

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Ah, on second glance the peephole looks correct in itself, but the second
branch following the bmi uses an incorrect condition code.
So we have:
tst r3, #2
bne .L3
beq .L6

being transformed into:
ldrbr3, [r0]@ zero_extendqisi2
lslsr3, r3, #30
bmi .L3
beq .L6


The beq needs to be updated to be the opposite of bmi. That is, bpl

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

--- Comment #3 from Yury Gribov  ---
Problem is that we don't have access to Darwin hardware. Perhaps you could get
a failing stacktrace via gdb?

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rearnsha at arm dot com

--- Comment #5 from ktkachov at gcc dot gnu.org ---
I think the peephole to transform the 1-bit zero_extract + compare-with-zero
into an lsls (from a tst-immediate) is not valid for positions other than zero
(i.e. when the shift would be by 31). But that case should already be handled
by the peephole below it at line 1567 in thumb2.md.

So I propose we just delete the one at line 1539.
Richard, what do you think?

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
The culprit seems to be the peephole in thumb2.md at line 1539.
Adding -fno-peephole2 gives the correct behaviour.

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5
   Keywords||wrong-code
   Last reconfirmed||2016-04-07
  Component|c   |target
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Bad ARM code generated for  |[4.9/5/6 Regression] Bad
   |evaluating unsigned int |ARM code generated for
   |bitfield value  |evaluating unsigned int
   ||bitfield value
   Target Milestone|--- |4.9.5
  Known to fail||4.9.4, 5.3.1, 6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed on active branches.
I get MYFUNC printed only when running ./prog 0.
At -O0 or with GCC 4.8 I get MYFUNC printed when
running both "./prog 0" and "prog 1".
So this looks like a regression from 4.9 onwards.

[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The thing is that there were no changes in the acats testsuite in the last 1.5
years, and if you say there is no ada process hanging around, it is unlikely
gcc/ada changes affect it either.

[Bug c++/66487] sanitizer/warnings for lifetime DSE

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to Jan Hubicka from comment #19)
> Martin, I suppose the sanitizer bits can be tracked as enhancement and not
> regression. It is a firefox bug so I suppose we can declare this a
> non-regression.

Sure, maybe I would return to support of MSAN in GCC 7.

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> Could you provide details of the fail?

The best I can do from the little I understand is

[Book15] f90/bug% gcc6 -fsanitize-recover=address
/opt/gcc/_clean/gcc/testsuite/c-c++-common/asan/halt_on_error-1.c
[Book15] f90/bug% ./a.out 
Abort
[Book15] f90/bug% printenv ASAN_OPTIONS
[Book15] f90/bug% setenv ASAN_OPTIONS "halt_on_error=false"
[Book15] f90/bug% ./a.out
Abort
[Book15] f90/bug% printenv ASAN_OPTIONS
halt_on_error=false

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
Could you provide details of the fail?

[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Perhaps just tcl bug on your platform then?
> Do you have some revision where you can reliably not reproduce the hang
> (say with 100 invocations)?  Otherwise I kind of don't understand
> the Regression marking.

Regtesting all languages on my machine takes between 4 and 5 hours (at -j8), so
I never test any revision more than once. I typically do a couple regtestings
every day and I have never seen any hanging before March 16 for trunk.

[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Perhaps just tcl bug on your platform then?
Do you have some revision where you can reliably not reproduce the hang (say
with 100 invocations)?  Otherwise I kind of don't understand the Regression
marking.

[Bug sanitizer/70573] New: FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

Bug ID: 70573
   Summary: FAIL: c-c++-common/asan/halt_on_error-1.c   -O*
execution test x86_64-apple-darwin15
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
howarth.at.gcc.testresults at gmail dot com,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
 Build: x86_64-apple-darwin15

The test c-c++-common/asan/halt_on_error-1.c fails on darwin at run time.
AFAICT the test has never succeeded.

[Bug c++/70572] [4.9/5/6 Regression] ICE on code with decltype (auto) on x86_64-linux-gnu in digest_init_r, at cp/typeck2.c:1103 with -std=c++14

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-07
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on code with decltype   |[4.9/5/6 Regression] ICE on
   |(auto) on x86_64-linux-gnu  |code with decltype (auto)
   |in digest_init_r, at|on x86_64-linux-gnu in
   |cp/typeck2.c:1103 with  |digest_init_r, at
   |-std=c++14  |cp/typeck2.c:1103 with
   ||-std=c++14
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
ICE started with r197248, before that it has been rejected with
pr70572.C: In function ‘int foo()’:
pr70572.C:3:4: error: expected primary-expression before ‘decltype’
decltype (auto) a = foo;
^
pr70572.C:3:4: error: expected ‘;’ before ‘decltype’

[Bug c++/70571] [6 Regression] ICE on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2259

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-07
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code on|[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code on x86_64-linux-gnu in
   |verify_ctor_sanity, at  |verify_ctor_sanity, at
   |cp/constexpr.c:2259 |cp/constexpr.c:2259
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r229128, most likely dup of PR70501.

[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Can you bisect it?  There aren't that many changes that could affect
> anything at all.

The problem is non-deterministic: it occurs less than once every two tests. So
r234234 is the first revision for which I saw it, but it does not mean that it
could not have occurred before it. The main change in the reported range was
the update of Tcl to 8.6 from 8.5, but it does not seem to be the culprit.

> Any Ada processes (compiler or some testcase) hang?

AFAICT no, but there is at least one expect process hanging. If I kill it,
regtesting completes after eventually running some gnat tests. Before killing
the expect process I see

[Book15] gcc/build_c% lf gcc/testsuite/ada/acats-parallel/
1/108/  117/  126/  135/  144/  153/  162/  171/  180/  19/   199/  207/ 
216/  225/  25/  34/  43/  52/  61/  70/  8/   89/  98/
10/   109/  118/  127/  136/  145/  154/  163/  172/  181/  190/  2/208/ 
217/  226/  26/  35/  44/  53/  62/  71/  80/  9/   99/
100/  11/   119/  128/  137/  146/  155/  164/  173/  182/  191/  20/   209/ 
218/  227/  27/  36/  45/  54/  63/  72/  81/  90/  finished
101/  110/  12/   129/  138/  147/  156/  165/  174/  183/  192/  200/  21/  
219/  228/  28/  37/  46/  55/  64/  73/  82/  91/
102/  111/  120/  13/   139/  148/  157/  166/  175/  184/  193/  201/  210/ 
22/   229/  29/  38/  47/  56/  65/  74/  83/  92/
103/  112/  121/  130/  14/   149/  158/  167/  176/  185/  194/  202/  211/ 
220/  23/   3/   39/  48/  57/  66/  75/  84/  93/
104/  113/  122/  131/  140/  15/   159/  168/  177/  186/  195/  203/  212/ 
221/  230/  30/  4/   49/  58/  67/  76/  85/  94/
105/  114/  123/  132/  141/  150/  16/   169/  178/  187/  196/  204/  213/ 
222/  231/  31/  40/  5/   59/  68/  77/  86/  95/
106/  115/  124/  133/  142/  151/  160/  17/   179/  188/  197/  205/  214/ 
223/  232/  32/  41/  50/  6/   69/  78/  87/  96/
107/  116/  125/  134/  143/  152/  161/  170/  18/   189/  198/  206/  215/ 
224/  24/   33/  42/  51/  60/  7/   79/  88/  97/

after killing it, the gcc/testsuite/ada/acats-parallel directory is gone.

Killing the last make gives something such as

/opt/gcc/logs/check_a-234697p25.log:/bin/sh: line 30:  3681 Killed: 9  
make check-acats1 check-acats2 check-acats3 check-acats4 check-acats5
check-acats6 check-acats7 check-acats8 check-acats9 check-acats10 check-acats11
check-acats12 check-acats13 check-acats14 check-acats15 check-acats16
check-acats17 check-acats18 check-acats19 check-acats20 check-acats21
check-acats22 check-acats23 check-acats24 check-acats25 check-acats26
check-acats27 check-acats28 check-acats29 check-acats30 check-acats31
check-acats32 check-acats33 check-acats34 check-acats35 check-acats36
check-acats37 check-acats38 check-acats39 check-acats40 check-acats41
check-acats42 check-acats43 check-acats44 check-acats45 check-acats46
check-acats47 check-acats48 check-acats49 check-acats50 check-acats51
check-acats52 check-acats53 check-acats54 check-acats55 check-acats56
check-acats57 check-acats58 check-acats59 check-acats60 check-acats61
check-acats62 check-acats63 check-acats64 check-acats65 check-acats66
check-acats67 check-acats68 check-acats69 check-acats70 check-acats71
check-acats72 check-acats73 check-acats74 check-acats75 check-acats76
check-acats77 check-acats78 check-acats79 check-acats80 check-acats81
check-acats82 check-acats83 check-acats84 check-acats85 check-acats86
check-acats87 check-acats88 check-acats89 check-acats90 check-acats91
check-acats92 check-acats93 check-acats94 check-acats95 check-acats96
check-acats97 check-acats98 check-acats99 check-acats100 check-acats101
check-acats102 check-acats103 check-acats104 check-acats105 check-acats106
check-acats107 check-acats108 check-acats109 check-acats110 check-acats111
check-acats112 check-acats113 check-acats114 check-acats115 check-acats116
check-acats117 check-acats118 check-acats119 check-acats120 check-acats121
check-acats122 check-acats123 check-acats124 check-acats125 check-acats126
check-acats127 check-acats128

[Bug c++/61198] Crash when selecting specializations through aliases.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

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

[Bug c++/70567] internal compiler error: in retrieve_specialization, at cp/pt.c:1020

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This got fixed with r218955, and the ICE started with r181118 when template 
aliases have been introduced.
In r234337 it has been backported to 4.9, so it is fixed on all currently
supported releases.

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