[Bug c++/70182] New: c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEv

[twoh at fb dot com]

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

Bug ID: 70182
   Summary: c++filt fails to demangle
_ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBe
nchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_type
s14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPK
cSC_OS7_EUljE_E9_M_invokeERKSt9_Any_dataj
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: twoh at fb dot com
  Target Milestone: ---

c++filt cannot demangle
_ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcSC_OS7_EUljE_E9_M_invokeERKSt9_Any_dataj

The demangler fails when it encounters expression "srT_onclE". The reason is
that it applies a wrong rule to demangle expression. Comments in line 3095 of
libiberty/cp-demangle.c (2.26 release) says 

 ::= sr  

is the rule, and this is implemented in line 3110-3124. However, if you see
Itanium C++
ABI(http://mentorembedded.github.io/cxx-abi/abi.html#mangle.expression), the
actual rule is

 ::= sr  

and 'base-unresolved-name' has different rules with 'unqualified-name'.

Below is the source code that generates the name:

typename std::enable_if<
  boost::function_types::function_arity::value
  == 2
>::type
addBenchmark(const char* file, const char* name, Lambda&& lambda) {
  auto execute = [=](unsigned int times) {
unsigned int niter;
niter = lambda(times);
return detail::TimeIterPair(niter, 0);
  };

  detail::addBenchmarkImpl(file, name,
std::function(execute));
}

The symbol is generated from clang-3.7.1 compiler.

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Andy Lutomirski from comment #3)
> I think a similar optimization could be applied to default-visibility
> references as well.  For example, gcc can generate things like this:
> 
>   call__x86.get_pc_thunk.ax
>   addl$_GLOBAL_OFFSET_TABLE_, %eax
>   movlfoo@GOT(%eax), %eax
> 
> The addl is unnecessary.

Yes, GCC does it for MacOS.

[Bug c++/70181] New: missing -Wtautological-compare for constant expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 70181
   Summary: missing -Wtautological-compare for constant
expressions
   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: ---

According to the documentation for -Wtautological-compare:

Warn if a self-comparison always evaluates to true or false. This warning
detects various mistakes such as: ...

all three equality expressions in the program below should be diagnosed, yet
only the first on in function f() is.  Clang diagnoses all three as expected. 
Either the other expressions should be diagnosed or the documentation clarified
that the warning is deliberately not issued for constant expressions.

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
-xc++ v.c
int f (int i) { if (i == i) return 1; return 0; }

enum { i = 0 };
const bool b0 = i == i;

constexpr int j = 0;
constexpr bool b1 = j == j;

v.c: In function ‘int f(int)’:
v.c:1:23: warning: self-comparison always evaluates to true
[-Wtautological-compare]
 int f (int i) { if (i == i) return 1; return 0; }
 ~~^~~~

[Bug c++/70180] New: missing -Wpointer-arith on NULL arithmetic cast to a an object type

[msebor at gcc dot gnu.org]

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

Bug ID: 70180
   Summary: missing -Wpointer-arith on NULL arithmetic cast to a
an object type
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

According to the description of the -Wpointer-arith option in the manual:

Warn about anything that depends on the “size of” a function type or of void.
GNU C assigns these types a size of 1, for convenience in calculations with
void * pointers and pointers to functions. In C++, warn also when an arithmetic
operation involves NULL. 

the following program should be diagnosed because it invokes the addition
expression to perform an arithmetic operation involving the NULL pointer. 
However, no diagnostic is issued.  (The cast to int* suppresses the warning.)

Although the example below is wrong (and should be diagnosed), since C++ allows
some arithmetic on null pointers (e.g., adding zero is allowed, as is
subtracting one from another), the implementation should make sure to avoid
diagnosing such expressions (they aren't today) and the description in the
manual should be clarified that they aren't intended to be diagnosed.

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -Werror
-o/dev/null -xc v.c
#include 

void *p = (int*)NULL + 1;
$

[Bug target/70179] New: PPC64 ICE with -mabi=ieeelongdouble and long double complex

[koorogi+bugs at koorogi dot info]

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

Bug ID: 70179
   Summary: PPC64 ICE with -mabi=ieeelongdouble and long double
complex
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koorogi+bugs at koorogi dot info
  Target Milestone: ---

GCC has an internal compiler error with trivial code using long double complex
values on powerpc64 using -mlong-double-128 and -mabi=ieeelongdouble.

~> cat ldcomplex.c
long double _Complex foo();
long double _Complex bar() { return foo(); }

~> ppc-gcc -mlong-double-128 -mabi=ieeelongdouble -c ldcomplex.c -o ldcomplex.o
ppc-gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
ldcomplex.c: In function 'bar':
ldcomplex.c:2:37: internal compiler error: in read_complex_part, at expr.c:3072
 long double _Complex bar() { return foo(); }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This was with the gcc 6 snapshot from 20160228.  Earlier versons of the
compiler that I've tested (5.2.0 and 4.9.2) have a segmentation fault on the
same test case.

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

[luto at kernel dot org]

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

--- Comment #3 from Andy Lutomirski  ---
I think a similar optimization could be applied to default-visibility
references as well.  For example, gcc can generate things like this:

call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlfoo@GOT(%eax), %eax

The addl is unnecessary.

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
(In reply to Oleg Endo from comment #1)
> 
> I guess there are more cases like (*2) above, where constants are encoded in
> a larger format than necessary.

Looks like that indeed.  For example:

void bleh (volatile unsigned char* p)
{
  *p &= 0x80;
}

compiled on i686:

__Z4blehPVh:
mov.B   [r1], r14
and #0xff80, r14
mov.B   r14, [r1]
rts

003f <__Z4blehPVh>:
  3f:   cc 1e   mov.b   [r1], r14
  41:   74 2e 80 ff ff ff   and #-128, r14
  47:   c3 1e   mov.b   r14, [r1]
  49:   02  rts



compiled on x86_64:

__Z4blehPVh:
mov.B   [r1], r14
and #0xff80, r14
mov.B   r14, [r1]
rts

003f <__Z4blehPVh>:
  3f:   cc 1e   mov.b   [r1], r14
  41:   75 2e 80and #-128, r14
  44:   c3 1e   mov.b   r14, [r1]
  46:   02  rts



Instead of the two patches above, the following patch will avoid printing hex
numbers, which seems to fix most of the issues.

Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c  (revision 234073)
+++ gcc/config/rx/rx.c  (working copy)
@@ -501,18 +501,24 @@
 static void
 rx_print_integer (FILE * file, HOST_WIDE_INT val)
 {
+  if (!TARGET_AS100_SYNTAX)
+{
+  fprintf (file, HOST_WIDE_INT_PRINT_DEC, val);
+  return;
+}
+
   if (IN_RANGE (val, -64, 64))
 fprintf (file, HOST_WIDE_INT_PRINT_DEC, val);
   else
-fprintf (file,
-TARGET_AS100_SYNTAX
-? "0%" HOST_WIDE_INT_PRINT "xH" : HOST_WIDE_INT_PRINT_HEX,
-val);
+fprintf (file,"0%" HOST_WIDE_INT_PRINT "xH", val);
 }

 static bool
 rx_assemble_integer (rtx x, unsigned int size, int is_aligned)
 {
+  if (!TARGET_AS100_SYNTAX)
+return default_assemble_integer (x, size, is_aligned);
+
   const char *  op = integer_asm_op (size, is_aligned);

   if (! CONST_INT_P (x))



With this patch applied I get almost the same result as on x86_64:

  text data bss dec hex
 2534283174   22812  279414   44376

[Bug c++/70171] Poor code generated when return struct using ternary operator

[sethml at ofb dot net]

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

Seth LaForge  changed:

   What|Removed |Added

 CC||sethml at ofb dot net

--- Comment #1 from Seth LaForge  ---
Created attachment 37929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37929=edit
Example C code (does not demonstrate problem!)

And, fascinatingly, the problem does not manifest with the C compiler! The
equivalent C code attached generates the same assembly for all four functions.
So it's something to do with C++ semantics for the ternary operator (presumably
because in C++ the ternary returns an lvalue while in C it returns an rvalue?).

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #3)
> But -fno-pic should turn off even the default -fpie or -fPIE (if you force
> it through configure option) and also make sure neither __PIC__ nor __PIE__
> macros are defined.

There is a separate issue and should be tracked with a new bug report.

[Bug target/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

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

--- Comment #6 from Ulrich Weigand  ---
Fixed.

[Bug target/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

--- Comment #5 from Ulrich Weigand  ---
Author: uweigand
Date: Thu Mar 10 23:59:20 2016
New Revision: 234127

URL: https://gcc.gnu.org/viewcvs?rev=234127=gcc=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c

[Bug target/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

--- Comment #4 from Ulrich Weigand  ---
Author: uweigand
Date: Thu Mar 10 23:58:44 2016
New Revision: 234126

URL: https://gcc.gnu.org/viewcvs?rev=234126=gcc=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[sergio at serjux dot com]

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

Sérgio Basto  changed:

   What|Removed |Added

 CC||sergio at serjux dot com

--- Comment #12 from Sérgio Basto  ---
if EAGAIN and EWOULDBLOCK may be identical, but also that they may be distinct,
this warning doesn't make sense, IMHO, look at this virtualbox solution :

https://www.virtualbox.org/changeset/59960/vbox/trunk 

it is worst than before, just to avoid one warning.

[Bug c/70150] -fno-pic no longer works with --enable-default-pie

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
But -fno-pic should turn off even the default -fpie or -fPIE (if you force it
through configure option) and also make sure neither __PIC__ nor __PIE__ macros
are defined.

[Bug c/70150] -fno-pic no longer works with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> When GCC is configured with --enable-default-pie, -fno-pic doesn't
> turn off PIC:
> 
> [hjl@gnu-6 gcc]$ ./xgcc -B./ -S x.c -fno-pic
> x.c:2:3: error: #error foo
>  # error foo
>^
> [hjl@gnu-6 gcc]$

It isn't a bug since PIC is off by default, but PIE is on by default,
which also defines __PIC__, with --enable-default-pie.

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Perhaps better testcase (-O2 again):

int b[128];

void
foo (int i, int j)
{
  int c, f, g, h;
  for (g = 0; g < 64; g++)
for (h = g, f = 0; f <= i; f++, h++)
  for (c = 0; c < j; c++)
b[h] = 0;
}

This one is well defined if ((j <= 0 && i <= INT_MAX - 63) || i <= 64) and
numbers of loop iterations are 64, min (i >= 0 ? i + 1 : 0, INT_MAX - 62), max
(j, 0).

[Bug c/70150] -fno-pic no longer works with --enable-default-pie

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-10
 CC||hjl.tools at gmail dot com
   Target Milestone|--- |6.0
Summary|--enable-default-pie causes |-fno-pic no longer works
   |hundreds of errors in test  |with --enable-default-pie
   |suite   |
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
When GCC is configured with --enable-default-pie, -fno-pic doesn't
turn off PIC:

[hjl@gnu-6 gcc]$ ./xgcc -B./ -S x.c -fno-pic
x.c:2:3: error: #error foo
 # error foo
   ^
[hjl@gnu-6 gcc]$

[Bug target/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-03/msg00671.ht
   ||ml
  Component|rtl-optimization|target
   Assignee|unassigned at gcc dot gnu.org  |uweigand at gcc dot 
gnu.org

--- Comment #3 from Ulrich Weigand  ---
Patch posted.

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Though, that expression looks weird, on the testcase it is clear that if i is
>= 0 (not -1!), then c must be 0, because otherwise the innermost loop must
invoke undefined behavior, and deriving anything about number of iterations
from the b[h] = 0; assignment in the upper loop is wrong, because the innermost
loop can (and must be) iterated 0 times.

[Bug c++/70121] [5/6 Regression] spurious warning and crash when returning a reference from lambda

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
A candidate patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00669.html

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-10
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
derive_constant_upper_bound is called with
i_11(D) >= -1 ? 126 - (unsigned int) i_11(D) : 127
and as it is a COND_EXPR, obviously calling it for the 2 operand
extract_ops_from_tree doesn't work.
Calling extract_ops_from_tree_1 of course fixes the ICE (why haven't we renamed
it to extract_ops_from_tree BTW and just use overloading?), though the question
is if we can't do better for the COND_EXPR (in that case we'd need to pass it
to the *_ops function and handle COND_EXPR in there).
But we don't even handle INTEGER_CST - variable.
It is a pitty we got COND_EXPR, instead of say MAX_EXPR <126 - (unsigned)
i_11(D), 127>.

--- gcc/tree-ssa-loop-niter.c.jj2016-02-24 14:52:16.0 +0100
+++ gcc/tree-ssa-loop-niter.c   2016-03-10 23:47:45.407770775 +0100
@@ -2742,9 +2742,9 @@ static widest_int
 derive_constant_upper_bound (tree val)
 {
   enum tree_code code;
-  tree op0, op1;
+  tree op0, op1, op2;

-  extract_ops_from_tree (val, , , );
+  extract_ops_from_tree_1 (val, , , , );
   return derive_constant_upper_bound_ops (TREE_TYPE (val), op0, code, op1);
 }

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/70009] test case libgomp.oacc-c-c++-common/vprop.c fails starting with its introduction in r233607

[cesar at gcc dot gnu.org]

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

--- Comment #8 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Thu Mar 10 22:50:40 2016
New Revision: 234124

URL: https://gcc.gnu.org/viewcvs?rev=234124=gcc=rev
Log:
libgomp/
PR testsuite/70009
* testsuite/libgomp.oacc-c-c++-common/vprop.c: Make test data signed.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/vprop.c

[Bug c++/70178] New: Loop-invariant memory loads from std::string innards are not hoisted

[zackw at panix dot com]

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

Bug ID: 70178
   Summary: Loop-invariant memory loads from std::string innards
are not hoisted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

Consider

#include 
#include 
#include 
using std::string;

inline unsigned char hexval(unsigned char c)
{
if (c >= '0' && c <= '9')
return c - '0';
else if (c >= 'A' && c <= 'F')
return c - 'A' + 10;
else if (c >= 'a' && c <= 'f')
return c - 'a' + 10;
else
throw "input character not a hexadecimal digit";
}

void hex2ascii_1(const string& in, string& out)
{
size_t inlen = in.length();
if (inlen % 2 != 0)
throw "input length not a multiple of 2";
out.clear();
out.reserve(inlen / 2);
for (string::const_iterator p = in.begin(); p != in.end(); p++)
{
   unsigned char c = hexval(*p);
   p++;
   c = (c << 4) + hexval(*p);
   out.push_back(c);
}
}

void hex2ascii_2(const string& in, string& out)
{
size_t inlen = in.length();
if (inlen % 2 != 0)
throw "input length not a multiple of 2";
out.clear();
out.reserve(inlen / 2);
std::transform(in.begin(), in.end() - 1, in.begin() + 1,
   std::back_inserter(out),
   [](unsigned char a, unsigned char b)
   { return (hexval(a) << 4) + hexval(b); });
}

It seems to me that both of these should be optimizable to the equivalent thing
you would write in C, with all the pointers in registers ...

void hex2ascii_hypothetical(const string& in, string& out)
{
size_t inlen = in.length();
if (inlen % 2 != 0)
throw "input length not a multiple of 2";
out.clear();
out.reserve(inlen / 2);

const unsigned char *p = in._M_data();
const unsigned char *limit = p + in._M_length();
unsigned char *q = out._M_data();
// (check for pointer wrap-around here?)

while (p < limit)
{
*q++ = (hexval(p[0]) << 4) + hexval(p[1]);
p += 2;
}
}

Maybe it wouldn't be able to deduce that capacity overflow is impossible by
construction, but that's a detail.  The important thing is that g++ 5 and 6
cannot hoist the pointer initializations out of the loop as shown.  They reload
p, limit, and q from memory (that is, from the relevant string objects) on
every iteration.

[Bug tree-optimization/70177] New: [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

Bug ID: 70177
   Summary: [6 Regression] ICE in extract_ops_from_tree starting
with r233660
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int c, e, b[128];

void
foo (int i)
{
  int f, g, h;
  for (g = 0; g < 64; g++)
{
  h = g;
  for (f = 0; f <= i; f++)
{
  for (; c; e++)
b[h] = 0;
  h++;
}
}
}

at -O2 ICEs starting with r233660.

[Bug bootstrap/70173] make distclean: leaves stage_final and libcc1/compiler-name.h

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most people don't use distclean or build in the source directory.  Most people
use a separate build directory and just wipe out that build directory.

[Bug c++/70175] Condition comparing two float numbers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
That is excess precision, use -msse2 -mfpmath=sse or -ffloat-store to avoid
this.  Or even better yet, avoid equality comparisons of floating point
numbers, instead check if the absolute value of the difference of two numbers
is small enough.

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #12 from Manuel López-Ibáñez  ---
At this stage, this will not get fixed before GCC 7 is released in March 2017,
if at all.

If somebody wants to see progress on this, they way forward is:

1) Put a breakpoint at warn_for_sign_compare () at
/home/manuel/test1/src/gcc/c-family/c-common.c
2) Figure out exactly why one case is warned and the other is not.
3) Figure out exactly when the difference is introduced (very likely in
shorten_compare in the same file). The C FE does "folding" (optimizing) while
parsing even at -O0. It is a goal to stop doing this (without breaking anything
else of course, so abundant testing that the generated code does not change is
required).
4) Figure out how to fix the warning or avoid introducing a difference.

Even improving the warning text could help someone to figure out the problem
(printing the types involved, explaining that the comparison is always false,
etc.)

Any of the steps above would make it a bit easier for the next person to come
along and continue the work until a fix is committed.

If you never debugged/modified GCC before, see
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

(In reply to Fredrik Hederstierna from comment #5)
> On Intel i386-GCC (4.2.3) we just get warning only for the line
> 
>   if (c1 == ~c2)
> 
> The other lines does not give warnings, so maybe its just the ARM-backend
> that catch this warning.

I don't see these differences. It works the same in both cases.

[Bug libstdc++/70176] New: Regression with C++03 Issue cstdio

[craie at acm dot org]

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

Bug ID: 70176
   Summary: Regression with C++03 Issue cstdio
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craie at acm dot org
  Target Milestone: ---

Created attachment 37928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37928=edit
Minimal Example to Reproduce Error

When compiling to the C++03 standard, I get the following errors:

$ g++ --std=c++03 minimal.cpp
In file included from
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/fstream:41:0,
 from minimal.cpp:1:
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:175:11: error:
‘::snprintf’ has not been declared
   using ::snprintf;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:176:11: error:
‘::vfscanf’ has not been declared
   using ::vfscanf;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:177:11: error:
‘::vscanf’ has not been declared
   using ::vscanf;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:178:11: error:
‘::vsnprintf’ has not been declared
   using ::vsnprintf;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:179:11: error:
‘::vsscanf’ has not been declared
   using ::vsscanf;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:185:22: error:
‘__gnu_cxx::snprintf’ has not been declared
   using ::__gnu_cxx::snprintf;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:186:22: error:
‘__gnu_cxx::vfscanf’ has not been declared
   using ::__gnu_cxx::vfscanf;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:187:22: error:
‘__gnu_cxx::vscanf’ has not been declared
   using ::__gnu_cxx::vscanf;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:188:22: error:
‘__gnu_cxx::vsnprintf’ has not been declared
   using ::__gnu_cxx::vsnprintf;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdio:189:22: error:
‘__gnu_cxx::vsscanf’ has not been declared
   using ::__gnu_cxx::vsscanf;
  ^

[Bug middle-end/70159] missed CSE optimization

[spop at gcc dot gnu.org]

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

--- Comment #9 from Sebastian Pop  ---
Created attachment 37927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37927=edit
patch for hoisting expressions

Updated the patch from PR23286 to hoist the redundant expressions:

  :
  inv_4 = 1.0e+0 / d_3(D);
  _18 = min_5(D) - a_6(D);
  _19 = _18 / inv_4;
  _20 = max_9(D) - a_6(D);
  _21 = _20 / inv_4;
  if (inv_4 >= 0.0)
goto ;
  else
goto ;

  :

  :
  # tmin_1 = PHI <_19(2), _21(3)>
  # tmax_2 = PHI <_21(2), _19(3)>
  _16 = tmin_1 + tmax_2;
  return _16;

The attached patch does not pass make check and causes some infinite recursion.

[Bug c++/70175] New: Condition comparing two float numbers

[slaver75 at gmail dot com]

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

Bug ID: 70175
   Summary: Condition comparing two float numbers
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slaver75 at gmail dot com
  Target Milestone: ---

When I try compare  two numbers whitch are equal using condition "==" i get
false than true.

Host used to build is gcc 4.9.2 for Qt Creator 5.5 on windows xp 32-bit.

For this example:
int main()
{
double a = 2121;
double b = 15.9075;
double w = (0.0075*a);
cout << a << " " << b << " " << w << endl;
if (b == w) cout << "true";
else cout << "false";
}
program print false altrough in a line 6 function cout print that variable w is
equal 15.9075.

In other cases ewerything is fine and program print true, for example when a =
2000 and b = 15 then w = 15 and condition (b == w) is true.

[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-10
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #7 from Jeffrey A. Law  ---
AFAICT the coalescing code is working as expected here.  Working with
r226900...

So, the only real statement of interest is:

  # iftmp.0_1 = PHI 


Which results in the following partition map:

Partition 0 (iftmp.0_1 - 1 )
Partition 1 (line_7(D) - 7 )
Partition 2 (iftmp.0_18 - 18 )

And the following coalesce list:

Coalesce list: (1)iftmp.0_1 & (18)iftmp.0_18 [map: 0, 2] : Success -> 0

Note that new_line_9 isn't ever processed.  Which is a bit odd to say the
least.  Moving to r226901 we have:

Partition 0 (iftmp.0_1 - 1 )
Partition 1 (line_7(D) - 7 )
Partition 2 (new_line_9 - 9 )
Partition 3 (iftmp.0_18 - 18 )

Coalesce list: (1)iftmp.0_1 & (9)new_line_9 [map: 0, 2] : Success -> 0
Coalesce list: (1)iftmp.0_1 & (18)iftmp.0_18 [map: 0, 3] : Success -> 0

Note that we coalesced new_line_9 into the same partition as iftmp.0_{1,18}.

That seems valid given their use in the PHI and my quick review of the
conflicts.  

So looking at the actual expansion r226900 will emit a copy from new_line_9
into iftmp.0_{1,18}.  That's a result of r226900 not coalescing the objects.

So AFAICT this isn't a coalescing issue, at least not at the gimple->rtl
expansion point.

[Bug rtl-optimization/70174] New: ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[su at cs dot ucdavis.edu]

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

Bug ID: 70174
   Summary: ICE at -O1 and above on x86_64-linux-gnu in
gen_lowpart_general, at rtlhooks.c:63
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following (invalid) code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu at -O1 and above in both 32-bit and 64-bit modes.

This is a regression from 5.3.x. 


$ 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 20160310 (experimental) [trunk revision 234104] (GCC)
$
$ gcc-trunk -O0 -c small.c
small.c: In function ‘fn1’:
small.c:9:8: warning: assignment makes integer from pointer without a cast
[-Wint-conversion]
   a.f0 = fn1;
^
$ gcc-5.3 -O1 -c small.c
small.c: In function ‘fn1’:
small.c:9:8: warning: assignment makes integer from pointer without a cast
[-Wint-conversion]
   a.f0 = fn1;
^
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:9:8: warning: assignment makes integer from pointer without a cast
[-Wint-conversion]
   a.f0 = fn1;
^
small.c:9:8: internal compiler error: in gen_lowpart_general, at rtlhooks.c:63
   a.f0 = fn1;
   ~^
0xb0aea3 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc-source-trunk/gcc/rtlhooks.c:63
0x82c4a3 store_bit_field_using_insv
../../gcc-source-trunk/gcc/expmed.c:678
0x832cf7 store_bit_field_1
../../gcc-source-trunk/gcc/expmed.c:991
0x832daf store_bit_field_1
../../gcc-source-trunk/gcc/expmed.c:1014
0x832f6b store_bit_field(rtx_def*, unsigned long, unsigned long, unsigned long,
unsigned long, machine_mode, rtx_def*, bool)
../../gcc-source-trunk/gcc/expmed.c:1113
0x854758 store_field
../../gcc-source-trunk/gcc/expr.c:6784
0x850203 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-source-trunk/gcc/expr.c:5021
0x73df5c expand_gimple_stmt_1
../../gcc-source-trunk/gcc/cfgexpand.c:3618
0x73df5c expand_gimple_stmt
../../gcc-source-trunk/gcc/cfgexpand.c:3714
0x740f43 expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5720
0x745ff6 execute
../../gcc-source-trunk/gcc/cfgexpand.c:6335
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.
$





struct
{ 
  int f0:4;
} a;

void
fn1 ()
{ 
  a.f0 = fn1;
}

[Bug middle-end/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #10 from PeteVine  ---
At least on ARM (gcc 4.9.3) it does work after a clean generate/use cycle.

[Bug bootstrap/70173] New: make distclean: leaves stage_final and libcc1/compiler-name.h

[dilyan.palauzov at aegee dot org]

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

Bug ID: 70173
   Summary: make distclean: leaves stage_final and
libcc1/compiler-name.h
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

make distclean

leaves these files:

./stage_final
./libcc1
./libcc1/compiler-name.h

and prints:

make[1]: Entering directory '/home/d/gcc'
rm -f stage_current
make[1]: Leaving directory '/home/d/gcc'
rm -rf stage1-* 
rm -rf stage2-* 
rm -rf stage3-* compare 
cat: stage_last: No such file or directory
rm -rf stage4-* compare3 
cat: stage_last: No such file or directory
rm -rf stageprofile-* 
cat: stage_last: No such file or directory
rm -rf stagefeedback-* 
make[1]: Entering directory '/home/d/gcc'
Doing distclean in libcc1
make[2]: Entering directory '/home/d/gcc/libcc1'
test -z "libcc1.la" || rm -f libcc1.la
rm -f "./so_locations"
rm -rf .libs _libs
test -z "libcc1plugin.la" || rm -f libcc1plugin.la
rm -f "./so_locations"
rm -f *.o
rm -f *.lo
rm -f *.tab.c
test -z "" || rm -f 
test . = "/git/gcc/libcc1" || test -z "" || rm -f 
rm -f cc1plugin-config.h stamp-h1
rm -f libtool config.lt
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f config.status config.cache config.log configure.lineno
config.status.lineno
rm -rf ./.deps
rm -f Makefile
make[2]: Leaving directory '/home/d/gcc/libcc1'
make[1]: Leaving directory '/home/d/gcc'
rm -f *.a TEMP errs core *.o *~ \#* TAGS *.E *.log
rm -f Makefile config.status config.cache mh-frag mt-frag
rm -f maybedep.tmp serdep.tmp
if [ "x86_64-pc-linux-gnu" != "." ]; then \
  rm -rf x86_64-pc-linux-gnu; \
else true; fi
rm -rf build-x86_64-pc-linux-gnu
if [ "." != "." ]; then \
  rm -rf .; \
else true; fi
rm -f texinfo/po/Makefile texinfo/po/Makefile.in texinfo/info/Makefile
rm -f texinfo/doc/Makefile texinfo/po/POTFILES
rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
rmdir texinfo/makeinfo texinfo/po texinfo/util 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
rmdir fastjar gcc libiberty texinfo zlib 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
find . -name config.cache -exec rm -f {} \; \; 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)

[Bug c++/60760] arithmetic on null pointers should not be allowed in constant expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I'm up to my ears in constexpr so I might as well try to fix this too.

[Bug middle-end/57955] [4.9/5/6 Regression] Uniquization of constants reduces alignment of initializers

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
> I tried implementing Jakub's suggestion to have CONSTANT_ALIGNMENT return
> 128 for large constructors.  This doesn't fix the r201264 version of the
> test case, which still generates fairly horrid code.  The use of
> CONSTANT_ALIGNMENT in align_variable causes the destination to receive the
> 128-bit alignment, but the constructor itself remains with 32-bit alignment,
> so the aligned-only lvx instruction can't be used.

Isn't that because the SRA pass now undoes what the gimplifier does?

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #25 from Jeffrey A. Law  ---
Essentially the same problem as 64058.  64058 includes a testcase, so I'm going
to make it the canonical bug to track this issue.

If I take my prototype patch for 64058 and apply it to r228667 and r228668
things stabilize considerably.  All the changes in core_list_mergesort and its
constprop variant disappear, leaving us with trivial changes in
core_bench_list.

The core_bench_list changes do not involve any additional copies -- they're
cases where we swap the operands of comparisons due to changes in the
SSA_NAME_VERSIONs and one trivial difference where a copy is sunk one
instruction.

If I compare r228667 to r228668+my patch I do see considerable changes to the
constprop variant of core_list_mergesort.  That's not unexpected because
r228667 essentially randomly orders coalesce pairs with the same cost while
228668 will apply a real tie-breaking heuristic.  When I look at the resulting
code it appears that we get fewer copies and with 228668+my patch when compared
to 228667 -- which is likely a good thing.

Anyway, I'm confident that addressing 64058 will also address 68654.

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

[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||afomin.mailbox at gmail dot com

--- Comment #18 from Jeffrey A. Law  ---
*** Bug 68654 has been marked as a duplicate of this bug. ***

[Bug c++/70172] incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I should add that the bogus "reinterpret_cast" error goes away when the address
of a non-array member is used instead, as in the test case below, even though
this modified test case is also invalid for the same reason (using a null
pointer).  Failing to diagnose the modified test case is the subject of bug
60760.

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
-xc++ z.c
struct S { int a, b; } s;

constexpr S *p = (S*)0;
constexpr const int *q = >b;

[Bug c++/70121] [5/6 Regression] spurious warning and crash when returning a reference from lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
I think I have a patch.

[Bug c++/70172] incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||55004
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
I would normally make the Severity of a bug in the text of a diagnostic minor
but this one seems like it's more than a poorly phrased diagnostic.  The code
that triggers the error is in the potential_constant_expression_1() function in
constexp.c:

case NOP_EXPR:
case CONVERT_EXPR:
case VIEW_CONVERT_EXPR:
  /* -- a reinterpret_cast.  FIXME not implemented, and this rule
 may change to something more specific to type-punning (DR 1312).  */
  {
tree from = TREE_OPERAND (t, 0);
if (POINTER_TYPE_P (TREE_TYPE (t))
&& TREE_CODE (from) == INTEGER_CST
&& !integer_zerop (from))
  {
if (flags & tf_error)
  error_at (EXPR_LOC_OR_LOC (t, input_location),
"reinterpret_cast from integer to pointer");
return false;
  }
return (RECUR (from, TREE_CODE (t) != VIEW_CONVERT_EXPR));
  }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug target/43640] Struct with two floats generates poor code

[sethml at ofb dot net]

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

Seth LaForge  changed:

   What|Removed |Added

 CC||sethml at ofb dot net

--- Comment #3 from Seth LaForge  ---
For what it's worth, this generates similarly terrible code on ARM with gcc
5.2.1. It also occurs if the struct members are ints:

struct u1 { int x, y; };
int foo(struct u1 u) { return u.x + u.y; }

% arm-none-eabi-gcc -O3 -S foo.c

foo:
sub sp, sp, #8
add r3, sp, #8
stmdb   r3, {r0, r1}
ldmia   sp, {r0, r3}
add r0, r0, r3
add sp, sp, #8
bx  lr

% arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202
(release) [ARM/embedded-5-branch revision 231848]

[Bug c++/70172] New: incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization

[msebor at gcc dot gnu.org]

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

Bug ID: 70172
   Summary: incorrect reinterpret_cast from integer to pointer
error on invalid constexpr initialization
   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: ---

The following invalid code is erroneously accepted by 5.x and 4.9.3.  It is
rejected by 6.0 but with an obviously incorrect error.  The code is invalid not
because of a cast (there is none) but because it attempts to use a null pointer
to form the address of a member of an object.

$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B/build/gcc-trunk/gcc -S -Wall
-Wextra -Wpedantic -xc++ ~/tmp/t.c
struct S { int a, b[1]; };

constexpr S *p1 = (S*)0;
constexpr int *q1 = p1->b;


/home/remote/msebor/tmp/t.c:4:25: error: reinterpret_cast from integer to
pointer
 constexpr int *q1 = p1->b;
 ^

[Bug c++/70171] New: Poor code generated when return struct using ternary operator

[sethml at ofb dot net]

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

Bug ID: 70171
   Summary: Poor code generated when return struct using ternary
operator
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sethml at ofb dot net
  Target Milestone: ---

Created attachment 37926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37926=edit
Example C++ code.

Consider the following code:

int int_ternary(int a, int b, bool select) { return select ? a : b; }
int int_if(int a, int b, bool select) { if (select) return a; else return b; }
struct S { int i; };
S struct_ternary(S a, S b, bool select) { return select ? a : b; }
S struct_if(S a, S b, bool select) { if (select) return a; else return b; }

G++ 5.3.0 -O2 generates identical code for int_ternary(), int_if(), and
struct_if() - for x86-64:

testb   %dl, %dl
movl%esi, %eax
cmovne  %edi, %eax
ret

However, for struct_ternary() it generates terrible code which stores a and b
into memory locations and then loads one by address:

struct_ternary(S, S, bool):
leaq-40(%rsp), %rcx
testb   %dl, %dl
movl%edi, -24(%rsp)
leaq-24(%rsp), %rax
movl%esi, -40(%rsp)
cmove   %rcx, %rax
movl(%rax), %eax
ret

Compile command:
% g++-5 -O2 -S ternary_reference_pessimization.cc
% g++-5 --version
g++-5 (Homebrew gcc 5.3.0) 5.3.0

This can have a major performance impact when using wrappers around built-in
types. For example, I discovered it experimenting with John McFarlane's
fixed_point library, which is a candidate for C++ standardization. In
particular, calling std::max() on two fixed_point values results
in the kind of terrible code demonstrated above.
https://github.com/johnmcfarlane/fixed_point/blob/master/doc/p0037r1.md

As wrappers around basic types become more common in C++, the performance
impact of this problem will get worse.

[Bug c++/70170] New: [6 regression] bogus not a constant expression error comparing pointer to array to null

[msebor at gcc dot gnu.org]

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

Bug ID: 70170
   Summary: [6 regression] bogus not a constant expression error
comparing pointer to array to null
   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: ---

The following example compiles successfully with 4.9.3 and 5 but fails with
6.0.  Note that the older compilers issue "warning: the address of ‘s’ will
ever be NULL [-Waddress]" for the "p0 == 0" expression.  GCC 6 does not.  That
seems like another regression.  Without bisecting it I suspect the delayed
folding changes to be responsible for both of these new problems.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B/build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -xc++ t.c
struct S { int a, b[1]; } s;

constexpr S *p0 = 
constexpr int *q0 = p0->b;

constexpr bool b0 = p0 == 0;
constexpr bool b1 = q0 == 0;

t.c:7:24: error: ‘int*)(& s)) + 4u) == 0u)’ is not a constant expression
 constexpr bool b1 = q0 == 0;
 ~~~^~~~

[Bug tree-optimization/70169] [4.9/5/6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-10
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE at -O1 and above on |[4.9/5/6 Regression] ICE at
   |x86_64-linux-gnu in |-O1 and above on
   |gen_lsm_tmp_name, at|x86_64-linux-gnu in
   |tree-ssa-loop.c:791 |gen_lsm_tmp_name, at
   ||tree-ssa-loop.c:791
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug rtl-optimization/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-10
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug tree-optimization/70169] New: ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[su at cs dot ucdavis.edu]

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

Bug ID: 70169
   Summary: ICE at -O1 and above on x86_64-linux-gnu in
gen_lsm_tmp_name, at tree-ssa-loop.c:791
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following (invalid) code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu at -O1 and above in both 32-bit and 64-bit modes.

It also affects at least 4.6.x and after: 
- 4.6.x and 4.7.x hang 
- 4.8.x and later ICE

$ 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 20160310 (experimental) [trunk revision 234104] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$  
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: in gen_lsm_tmp_name, at
tree-ssa-loop.c:791
 fn1 ()
 ^~~
0xcdb56b gen_lsm_tmp_name
../../gcc-source-trunk/gcc/tree-ssa-loop.c:791
0xcdb610 gen_lsm_tmp_name
../../gcc-source-trunk/gcc/tree-ssa-loop.c:731
0xcdc275 get_lsm_tmp_name(tree_node*, unsigned int, char const*)
../../gcc-source-trunk/gcc/tree-ssa-loop.c:805
0xca5d7c execute_sm
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:1957
0xca5d7c hoist_memory_references
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:2021
0xca5d7c store_motion_loop
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:2295
0xca795a store_motion
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:2316
0xca795a tree_ssa_lim
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:2530
0xca795a execute
../../gcc-source-trunk/gcc/tree-ssa-loop-im.c:2580
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.
$ 


---


int printf (const char *, ...); 

void
fn1 ()
{
  int *p = (int *)  
  for (;;)
(*p)++;
}

[Bug rtl-optimization/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

--- Comment #1 from Ulrich Weigand  ---
Created attachment 37925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37925=edit
Patch to add retval vs. newval overlap check

This patch fixes the problem for me with the GCC 5 branch.  Not fully
regression tested yet.

[Bug rtl-optimization/70168] New: [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[uweigand at gcc dot gnu.org]

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

Bug ID: 70168
   Summary: [5 Regression] Wrong code generation in
__sync_val_compare_and_swap on PowerPC
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uweigand at gcc dot gnu.org
CC: amodra at gcc dot gnu.org, dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux

Building the following test case on powerpc64le-linux with -O2 using the
current GCC 5 branch:

unsigned long atomicAND (volatile unsigned long *memRef, unsigned long mask)
{
  unsigned long oldValue, newValue, prevValue;

  for (oldValue = *memRef; ; oldValue = prevValue)
{
  newValue = oldValue & mask;
  if (newValue == oldValue)
break;

  prevValue = __sync_val_compare_and_swap (memRef, oldValue, newValue);
  if (prevValue == oldValue)
break;
}

  return oldValue;
}

results in this assembler output:

atomicAND:
ld 9,0(3)
b .L6
.p2align 4,,15
.L10:
sync
.L3:
ldarx 10,0,3
cmpd 0,10,9
bne- 0,.L4
stdcx. 9,0,3
bne- 0,.L3
.L4:
isync
cmpld 7,9,10
beq 7,.L7
mr 9,10
.L6:
and 10,9,4
cmpld 7,9,10
bne 7,.L10
.L7:
mr 3,10
blr

Note how the stdcx. stores r9, which holds the original value, not the masked
value.  Therefore, this will usually succeed without updating the memory
location.

Debugging this problem, it turns out that rs6000_expand_atomic_compare_and_swap
is called with retval (operands[1]) equal to newval (operands[4]), and the
expander then proceeds to clobber newval before using it.

There is code to detect overlap of retval with oldval (operands[3]), but not
with newval.  Adding the equivalent detection code fixes the problem for me.

For some reason, I can reproduce this problem only with GCC 5; the same problem
should still be latently present in mainline since there's still no overlap
check, but I seem unable to construct a test case that would actually cause
retval == newval with mainline.

[Bug target/69614] [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Reproduced after disabling the extra pass_dce again on current trunk.
Slightly more readable testcase:
typedef unsigned short A;
typedef unsigned short B __attribute__ ((vector_size (16)));
typedef unsigned int C;
typedef unsigned int D __attribute__ ((vector_size (16)));
typedef unsigned long long E;
typedef unsigned long long F __attribute__ ((vector_size (16)));

E __attribute__ ((noinline, noclone))
foo (A a, C b, E c, A d, C e, E f, B g, D h, F i, B j, D k, F l)
{
  i %= (F) { (A) g[5], ~l[1] };
  i[1] = 1;
  k[3] >>= 31;
  l ^= (F) { j[4], f };
  l[0] = (l[0] >> 63) | (l[0] << 1);
  a -= 1;
  k %= (D) -i | 1;
  g /= (B) { -f } | 1;
  h[2] |= (A) ~d;
  return a + c + e + f + g[0] + g[1] + g[2] + g[3] + g[4] + g[5] + g[6] + h[2]
+ h[3] + i[0]
 + j[2] + j[4] + k[0] + k[1] + k[2] + k[3] + l[0] + l[1];
}

int
main ()
{
  E x = foo (0, 0, 1, 0, 0, 1, (B) { -1, 0, 0, 0, 0, 1 }, (D) { 0 }, (F) { 0 },
(B) { 0 }, (D) { 0 }, (F) { 0x67784fdb22ULL, 1 });
  __builtin_printf ("%016llx\n", (unsigned long long) (x >> 0));
  if (x != 0x00cef0a1b646ULL)
__builtin_abort ();
  return 0;
}

There are supposed to be mostly 0 values added, two 0x, and 5 1 values, and
one extra large one - the rotated l[0].
0x20002 corresponds to two 0x values and 4 1 values being added, so most
likely at least one issue is on the rotated l[0].
I've added breakpoints on the two (only) orr *, lsr #31 instructions and it
seems the inputs at that point is already wrong (0s).
Will continue debugging tomorrow.

[Bug middle-end/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #9 from Artem S. Tashkinov  ---
Tow more errors for the same sources:

threadpool.cpp: In member function ‘bool
ThreadPool::GetQueuedTask(ThreadPool::QueueEntry*)’:
threadpool.cpp:213:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
threadpool.cpp:213:1: error: corrupted profile info: number of executions for
edge 7-11 thought to be -23
threadpool.cpp:213:1: error: corrupted profile info: number of executions for
edge 7-8 thought to be 93128
makefile:110: recipe for target 'threadpool.o' failed






unpack.cpp: In member function ‘bool Unpack::ReadTables(BitInput&,
UnpackBlockHeader&, UnpackBlockTables&)’:
unpack.cpp:350:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
7-66 thought to be 12
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
7-5 thought to be -12
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
14-15 thought to be -19
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
14-16 thought to be 10447
unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic
block 15 thought to be -19
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
15-24 thought to be -19
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
41-42 thought to be 184976
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
41-26 thought to be -38846
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
44-46 thought to be 1905937
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
44-45 thought to be -2633
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
55-57 thought to be 2567166
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
55-56 thought to be -2937
unpack.cpp: In member function ‘void Unpack::UnpackDecode(UnpackThreadData&)’:
unpack.cpp:350:1: error: corrupted profile info: profile data is not
flow-consistent
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
15-59 thought to be 22934224
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
15-16 thought to be -22914989
unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic
block 16 thought to be -22888703
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
16-17 thought to be 26397
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
16-18 thought to be -22915100
unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic
block 18 thought to be -22890122
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
18-20 thought to be -22890122
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
36-37 thought to be 28405926
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
36-45 thought to be -867648
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
55-56 thought to be 6025631
unpack.cpp:350:1: error: corrupted profile info: number of executions for edge
55-11 thought to be -6475
makefile:110: recipe for target 'unpack.o' failed

[Bug middle-end/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

Artem S. Tashkinov  changed:

   What|Removed |Added

Summary|error: corrupted value  |Broken profiling for unrar
   |profile: value profile  |sources: error: corrupted
   |counter (X out of Y)|value profile: value
   |inconsistent with   |profile counter (X out of
   |basic-block count   |Y) inconsistent with
   ||basic-block count

--- Comment #8 from Artem S. Tashkinov  ---
Should I reproduce this bug in GCC 6.x as well or at least someone will take a
look at it?

[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

Artem S. Tashkinov  changed:

   What|Removed |Added

   Host||x86_64 i686
Version|5.0 |5.3.1
  Known to fail||4.7.3, 4.8.5, 4.9.4, 5.2.1,
   ||5.3.1
   Severity|normal  |major

[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
The nice thing about looking at the conflict set sizes is it doesn't change the
computational complexity.  After we've built the conflict graph we can walk the
coalesce pairs once and compute the size of the resultant conflict set for each
pair if we're able to coalesce the pair.

We can then trivially use that for tie-breaking.

Note that doesn't capture the effect fully -- doing that would probably result
in an increase in computational complexity as when we successfully coalesce a
pair, we'd have to propagate the conflict set size of the union to any
still-to-be-coalesced pairs that use the representative partition.  It's not
clear if that's really useful or not.

Note that with the primary costing model based on edge frequency we have a
global costing metric.  Using the size of the conflicts as a secondary key
captures at least some of the "how does coalescing this pair potentially affect
other (lower priority) pairs we might want to coalesce later".

Literature in this space isn't particularly helpful except to note that they
use conflicts to reject certain coalescing opportunities because they'll make
the graph uncolorable.  Some have a fairly conservative algorithm which they
iterate (ugh) to achieve better results.

[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #7 from Artem S. Tashkinov  ---
Affects GCC 5.3.1 as well.

[Bug c++/70167] New: Some const array prvalues are incorrectly treated as lvalues

[inadgob at yahoo dot com]

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

Bug ID: 70167
   Summary: Some const array prvalues are incorrectly treated as
lvalues
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: inadgob at yahoo dot com
  Target Milestone: ---

The following code is incorrectly rejected: 
(compiled with -Wall -Wextra -std=c++1z -pedantic)


#include 

template void f(T(&&)[S]) { }

using arr = const int[2];

int main()
{
f(arr{1, 2});
}


Diagnostics:

prog.cc: In function 'int main()':
prog.cc:9:16: error: cannot bind 'arr {aka const int [2]}' lvalue to 'const int
(&&)[2]'
 f(arr{1, 2});
^
prog.cc:3:39: note:   initializing argument 1 of 'void f(T (&&)[S]) [with T =
const int; long unsigned int S = 2ul]'
 template void f(T(&&)[S]) { }
   ^

Also, decltype(arr{1, 2}) yields const int(&)[2], so it looks like the const
array prvalue is incorrectly treated as an lvalue here. Xvalues of such types
work correctly; non-const array rvalues are fine as well.

This also happens if the array element type is an aggregate. Replacing the
alias declaration with

struct A { int i; };
using arr = const A[2];

causes the same error.

However, it doesn't happen for elements of non-aggregate class type. Replacing
the alias declaration with 

struct A { A(int) { } };
using arr = const A[2];

makes the code compile with no diagnostics.

[Bug ipa/69708] ipa inline not working for function reference in static const struct

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I've posted one possible implementation of this feature to the mailing
list along with an explanation why it makes sense to actually do it
better and how :-)

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00649.html

[Bug fortran/70149] Character pointer initialization causes ICE. (F2008)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Removing the gcc_assert allows the code to compile.

Confirmed, but it leads to wrong code: if I use the module with

use myptr_mod

print *, "'", char_data, "'", int_data
print *, "'", number_string, "'", number
end

the output is

 'forty two   '  42
 ''  42

Note that compiling the test in pr68569 gives an ICE at the same gcc_assert. If
I remove the assert, the ICE becomes

 subroutine s(n)

internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #14)
> but if you keep the e = a[0]; assignment, I really don't understand the last
> two statements.  The kept statement already copied them, the extra stores
> don't cover the whole structure, so the old one has to be kept anyway, and
> the stores don't store anything that isn't already there.

True. That however stems from the flow-insensitiveness of SRA.  I've
already started thinking of a flow-sensitive rewrite but it will take
a while.

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
(In reply to alalaw01 from comment #10)
> which is much saner. But I don't really understand why the PARM_DECL case
> that I'm adding to here is that way 

SRA tries to avoid generating unnecessary aggregate loads if it can
figure out that that an area of an aggregate does not have any
(unscalarized) data in it.  In fact, it even removes existing loads of
uninitialized stuff.  The pass is not flow sensitive, so it can only
figure out that a bit of an aggregate does not have anything sensible
in it if there is no store to it anywhere in the function.

However, if the aggregate in question is a parameter, then of course
there is a store it cannot see, which happens in the caller.  The
constants are of course very similar, they contain value even though
there is no store to them anywhere in the function body.  So that is
why they must be considered as containing (unscalarized) data, which
is why you must also set the flag for them.  Does this explain things?

[Bug target/70044] [5 Regression] -flto turns on -fomit-frame-pointer

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5/6 Regression] -flto  |[5 Regression] -flto turns
   |turns on|on -fomit-frame-pointer
   |-fomit-frame-pointer|
  Known to fail|6.0 |

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Thanks, for the record it's:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7044

--- Comment #2 from Nick Clifton  ---
Author: nickc
Date: Thu Mar 10 17:24:16 2016
New Revision: 234118

URL: https://gcc.gnu.org/viewcvs?rev=234118=gcc=rev
Log:
PR target/7044
* config/aarch64/aarch64.c
(aarch64_override_options_after_change_1): When forcing
flag_omit_frame_pointer to be true, use a special value that can
be detected if this function is called again, thus preventing
flag_omit_leaf_frame_pointer from being forced to be false.

* gcc.target/aarch64/pr70044.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr70044.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog


This issue still occurs on GCC 5 though, so I think we want to keep this opened
for the backport

[Bug target/70044] [5/6 Regression] -flto turns on -fomit-frame-pointer

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #6 from Nick Clifton  ---
The patch has now been applied.

[Bug c++/70001] [5 Regression] Infinity compilation time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 regression] Infinity   |[5 Regression] Infinity
   |compilation time|compilation time

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/7044] vax casesi breakage

[nickc at gcc dot gnu.org]

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

--- Comment #2 from Nick Clifton  ---
Author: nickc
Date: Thu Mar 10 17:24:16 2016
New Revision: 234118

URL: https://gcc.gnu.org/viewcvs?rev=234118=gcc=rev
Log:
PR target/7044
* config/aarch64/aarch64.c
(aarch64_override_options_after_change_1): When forcing
flag_omit_frame_pointer to be true, use a special value that can
be detected if this function is called again, thus preventing
flag_omit_leaf_frame_pointer from being forced to be false.

* gcc.target/aarch64/pr70044.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr70044.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70001] [5/6 regression] Infinity compilation time

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 10 17:23:06 2016
New Revision: 234117

URL: https://gcc.gnu.org/viewcvs?rev=234117=gcc=rev
Log:
PR c++/70001
* constexpr.c (cxx_eval_vec_init_1): For pre_init case, reuse
return value from cxx_eval_constant_expression from earlier
elements if it is valid constant initializer requiring no
relocations.

* g++.dg/cpp0x/constexpr-70001-1.C: New test.
* g++.dg/cpp0x/constexpr-70001-2.C: New test.
* g++.dg/cpp0x/constexpr-70001-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70001-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70001-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70001-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70166] New: Wrong optimization of type punning in unions with 2d array

[ch3root at openwall dot com]

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

Bug ID: 70166
   Summary: Wrong optimization of type punning in unions with 2d
array
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Type-punning is underspecified in the C standard and unions with arrays as
members push it to the limit but the following example seems to be broken in
gcc unintentionally. It aborts while it shouldn't.

extern void abort (void);

int main()
{
  union {
double d[1][1];
int a[1][1];
  } u, *volatile p = 

  **u.a = 1;
  **p->d = 0;

  if (**u.a != 0)
abort();
}

Alternatively, if this is intentional, perhaps the following sentence in [1]
could be clarified further:

"Even with -fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type."

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning

Tested with -O2 on gcc 4.7.2, 4.9.2 and 6.0.0 20160310.

[Bug other/70165] build failure in libgcj-6.0.0.jar

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Something like this would be helpful, but that's bash, and the script is sh:
...
index e9cb9f5..1d13056 100644
--- a/libjava/scripts/jar.in
+++ b/libjava/scripts/jar.in
@@ -386,6 +386,7 @@ while test -n "$commands"; do
 done

 set -e
+trap '$progname: $LINENO: command returns $?' ERR

 case "X$jarfile" in
   X)
...

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[jiwang at gcc dot gnu.org]

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

--- Comment #16 from Jiong Wang  ---
(In reply to Richard Henderson from comment #13)
> Created attachment 37911 [details]
> aggressive patch
> 

Cool! Thanks very much for experimenting this thoughtful new aggressive
direction.

But there is a performance issue as described at

  https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00281.html

  "this patch forces register scaling expression out of memory ref, so that
   RTL CSE pass can handle common register scaling expressions"

This is particularly performance critial if a group of instructions are
using the same "scaled register" inside hot loop. CSE can reduce redundant
calculations.

r233136 was fixing this by forcing the scale part into register then turn
somelike:

  ldr dst1, [reg_base1, reg_index, #lsl 1]
  ldr dst2, [reg_base2, reg_index, #lsl 1]
  ldr dst3, [reg_base3, reg_index, #lsl 1]

into

  reg_index = reg_index << 1;
  ldr dst1, [reg_base1, reg_index]
  ldr dst2, [reg_base2, reg_index]
  ldr dst3, [reg_base3, reg_index]

For this aggresive version patch at #c13
===
  In TARGET_LEGITIMATE_ADDRESS_P, the aarch64_classify_index allows
  register scaled offset through those "MUL" checks, this is correct, but
  then address like [reg, reg, #lsl 1] will be judged valid and hiding
  behind MEM unvisiable to RTL passes until quite later stage.

For second patch at #c10
===
  I found op1 is *not* forced to register when op0 is virtual eliminable
  register.  As the perf issue mentioned above, I think we should always
  force op0 into register to expose the scaled calculation to gcc.

I can confirm the following:

  * both the patches at #c13 and #c10 will cause performance regression
and reopen the issue r233136 fixed.

  * for the aggressive patch at #c13, if we explicitly don't allow
(plus reg, (mul reg, imm)) in aarch64_classify_index_allow then
there is no perf regression.

  * for the second patch at #c10, if we always do the following no matter
op0 is virtual & eliminable or not

 "op1 = force_operand (op1, NULL_RTX);"

then there is no performance regression as well. Even more, there is
significant perf improvement beyond current trunk on one benchmark.

If the regression fixed, I fell the second patch at #c10 looks better if the
decision is to fix this by gcc 6.  As I feel expose RTL details to RTL passes
the earlier the better.

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Indeed, the -DFOO=1 case vectorizes with -fno-tree-dominator-opts.

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #20 from Jan Hubicka  ---
Fixed.

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #7 from alalaw01 at gcc dot gnu.org ---
Looking at where the peeling happens. In both -DFOO=0 and -DFOO=1 cases,
107.ch2 peels the inner loop header, so there is an i<=max test in the outer
loop before the inner loop. However, in the -DFOO=1 case, this is dominated by
the extra i>max test (that breaks out of the outer loop), so 110.dom2 removes
the peeled i<=max.

Thus, just before sccp, in the -DFOO=0 case, we have:

  :
  # i_25 = PHI 
  # j_26 = PHI 
  max_7 = 1 << j_26;
  if (max_7 >= i_25)
goto ;
  else
goto ; //skip inner loop

  : //inner loop header
  # i_2 = PHI 
  _8 = (long unsigned int) i_2;
  _9 = _8 * 4;
  _11 = data_10(D) + _9;
  _12 = *_11;
  _13 = _12 + j_26;
  *_11 = _13;
  i_15 = i_2 + 1;
  if (max_7 >= i_15)
goto ; //cleaned, actually via latch
  else
goto ;

note the inner loop exits if !(max_7 >= i_15), and when we hit the inner loop,
we know that (max_7 >= i_25). Whereas in the -DFOO=1 case:
  :
  goto ;

  : //in outer loop
  max_7 = 1 << j_17;
  if (max_7 < i_32)
goto ;
  else
goto ;

  : //outer loop header
  # max_24 = PHI 
  # i_22 = PHI 
  # j_23 = PHI 

  : //inner loop header
  # i_27 = PHI 
  _8 = (long unsigned int) i_27;
  _9 = _8 * 4;
  _11 = data_10(D) + _9;
  _13 = *_11;
  _14 = _13 + j_23;
  *_11 = _14;
  i_16 = i_27 + 1;
  if (i_16 <= max_24)
goto ; //cleaned, actually via latch
  else
goto ;

the inner loop exits if !(max_24 >= i_16), but max_24 is defined as PHI, and we only have that max_7max) break" out of the loop, such that the outer loop now executes
"if (i>max) break" after the inner loop (rather than testing "if (i>max) break"
before the inner loop, as it still did following 107.ch2). So as an
alternative, possibly tweaking the jump-threading/loop-peeling heuristics might
help (?).

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Author: hubicka
Date: Thu Mar 10 16:11:14 2016
New Revision: 234115

URL: https://gcc.gnu.org/viewcvs?rev=234115=gcc=rev
Log:

PR lto/69589
* cgraph.c (cgraph_node::dump): Dump split_part and
indirect_call_target.
* cgraph.h (cgraph_node): Add indirect_call_target flag.
* ipa.c (has_addr_references_p): Cleanup.
(is_indirect_call_target_p): New.
(walk_polymorphic_call_targets): Do not mark virtuals that may be
called indirectly as local.
(symbol_table::remove_unreachable_nodes): Compute indirect_call_target.

* g++.dg/lto/pr69589_0.C: New testcase
* g++.dg/lto/pr69589_1.C: New testcase

Added:
trunk/gcc/testsuite/g++.dg/lto/pr69589_0.C
trunk/gcc/testsuite/g++.dg/lto/pr69589_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/ipa.c
trunk/gcc/testsuite/ChangeLog

[Bug other/70165] New: build failure in libgcj-6.0.0.jar

[vries at gcc dot gnu.org]

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

Bug ID: 70165
   Summary: build failure in libgcj-6.0.0.jar
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Once in a while, I run into this error while building gcc:
...
make[5]: *** [libgcj-6.0.0.jar] Error 1
make[5]: Leaving directory `build/x86_64-pc-linux-gnu/32/libjava'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `build/x86_64-pc-linux-gnu/32/libjava'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `build/x86_64-pc-linux-gnu/libjava'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `build/x86_64-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: *** Waiting for unfinished jobs
...

The command producing the jar file seems to be:
...
here=`pwd`; \
  cd src/libjava/classpath/lib; \
  find gnu java javax org sun -name .svn -prune -o -name '*.class' -print | \
  build/x86_64-pc-linu-gnu/libjava/scripts/jar -cfM@ $here/libgcj-6.0.0.jar
...

I cannot reproduce the failure on the command line.

It's hard to say what the cause of the failure is, given that the error is
silent, AFAICT.

Actually, it seems that the complete jar file is produced correctly (pkgdiff
with jar file from finish build reports 'result: UNCHANGED', and size is the
same).

[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Thu Mar 10 16:05:59 2016
New Revision: 234114

URL: https://gcc.gnu.org/viewcvs?rev=234114=gcc=rev
Log:
PR ipa/69630
* ipa-devirt.c (possible_polymorphic_call_targets): Do not ICE
on cxa_pure_virtual.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
Fixed.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[davejohansen at gmail dot com]

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

--- Comment #19 from Dave Johansen  ---
(In reply to kargl from comment #18)
> (In reply to Dave Johansen from comment #17)
> > (In reply to kargl from comment #16)
> > > See the fortran@ mailinglist archive.  Fritz posted a patch against
> > > 4.8 branch.
> > 
> > Are the patches that were posted against 6.0?
> > 
> 
> What part of "Fritz posted a patch against 4.8 branch"
> is not clear?
> 
> What part of "See the fortran@ mailinglist archive"
> is not clear.
> 
> To be brutally clear:
> https://gcc.gnu.org/ml/fortran/2016-03/msg00013.html

Sorry, that was a complete oversight on my part. The recent patches were inline
text and so I didn't notice the link to the gzipped attachment at the bottom of
that email.

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka  ---
Author: hubicka
Date: Thu Mar 10 16:02:55 2016
New Revision: 234113

URL: https://gcc.gnu.org/viewcvs?rev=234113=gcc=rev
Log:

PR lto/69589
* tree.c (free_lang_data_in_decl): Clear visibility of TYPE_DECL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Author: hubicka
Date: Thu Mar 10 16:02:00 2016
New Revision: 234112

URL: https://gcc.gnu.org/viewcvs?rev=234112=gcc=rev
Log:
PR lto/69589
* tree.c (need_assembler_name_p): Only record main variant type names.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Martin Jambor from comment #11)
> Well, e has size 64 bits and the replacements created for it have 32
> and 2 bits respectively and so in the simple SRA reprezentation of
> things, there are 30 bits that are not covered by the replacements and
> because the copy statement e = a[0] stores 64 bits, it thinks there
> are so called "unscalarized data."  When that happens, SRA does not
> remove original aggregate assignments.

I can understand in that case the e#f_17 and e$g_19 assignments in that case
in:
  e = a[0];
  e$f_17 = MEM[(struct S[1] *)];
  e$g_19 = MEM[(struct S[1] *)].g;
  MEM[(struct S *)] = e$f_17;
  e.g = e$g_19;
but if you keep the e = a[0]; assignment, I really don't understand the last
two statements.  The kept statement already copied them, the extra stores don't
cover the whole structure, so the old one has to be kept anyway, and the stores
don't store anything that isn't already there.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[kargl at gcc dot gnu.org]

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

--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to Dave Johansen from comment #17)
> (In reply to kargl from comment #16)
> > See the fortran@ mailinglist archive.  Fritz posted a patch against
> > 4.8 branch.
> 
> Are the patches that were posted against 6.0?
> 

What part of "Fritz posted a patch against 4.8 branch"
is not clear?

What part of "See the fortran@ mailinglist archive"
is not clear.

To be brutally clear:
https://gcc.gnu.org/ml/fortran/2016-03/msg00013.html

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[davejohansen at gmail dot com]

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

--- Comment #17 from Dave Johansen  ---
(In reply to kargl from comment #16)
> See the fortran@ mailinglist archive.  Fritz posted a patch against
> 4.8 branch.

Are the patches that were posted against 6.0?

> That patch will never be committed to the 4.8 branch because that
> branch is closed.

I understand that 4.8 is EOL and I'm not requesting that they be applied. I'm
just requesting that they be made available so that I can add them to an SCL
build that I do myself using COPR ( https://fedorahosted.org/copr/ ) so they
can be used on RHEL 6/7 (which have not been EOLed).

[Bug c++/70153] [6 Regression] ICE on valid C++ code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[kargl at gcc dot gnu.org]

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

--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Dave Johansen from comment #14)
> Are the patches for 4.8 available or can they be made available? I would
> like to make a Software Collection (SCL) of version of 4.8 with these
> patches so it could be used on RHEL 6/7 without having to jump to a newer
> version of the compiler.

See the fortran@ mailinglist archive.  Fritz posted a patch against
4.8 branch.

That patch will never be committed to the 4.8 branch because that
branch is closed.

[Bug c++/70153] [6 Regression] ICE on valid C++ code

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 10 15:13:01 2016
New Revision: 234111

URL: https://gcc.gnu.org/viewcvs?rev=234111=gcc=rev
Log:
PR c++/70153
* cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR.

* g++.dg/delayedfold/unary-plus1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/delayedfold/unary-plus1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
> Are the patches for 4.8 available or can they be made available? I would like
> to make a Software Collection (SCL) of version of 4.8 with these patches so
> it could be used on RHEL 6/7 without having to jump to a newer version
> of the compiler.

4.8 is no longer supported. AFAICT this PR is not a regression and in principle
should only be applied to the coming gcc-7 branch.

The "port" maintainers (fink or macports for OS X) may want to apply the patch
on their distros.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[davejohansen at gmail dot com]

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

--- Comment #14 from Dave Johansen  ---
Are the patches for 4.8 available or can they be made available? I would like
to make a Software Collection (SCL) of version of 4.8 with these patches so it
could be used on RHEL 6/7 without having to jump to a newer version of the
compiler.

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Going back to variants of the original testcase:
int
foo (int x, int y, int a)
{
  int i = x;
  int j = y;
#ifdef EX1
  if (__builtin_expect (x > y, 1))
#elif defined EX0
  if (__builtin_expect (x > y, 0))
#else
  if (x > y)
#endif
{
  i = a;
  j = i;
}
  return i * j;
}

at least for the -DEX1 case I'd think it is reasonable to assign one of i or j
to the register holding argument a (%r4), because that will for the common case
need one fewer register move.  But, there is one further constraint.  The
multiplication wants the result to live in %r2, because then it can avoid a
move, and the multiplication is commutative two operand one, so one of the
operands needs to match the output.  Thus, from this the reasonable disposition
choices are either i in %r2 and j in %r3 (this is especially desirable if the
if is unlikely, i.e. -DEX0 case), or perhaps i in %r2 and j in %r4 (while this
will need if/then/else rather than if/then only, it would use one fewer move in
the expected likely block).
The problem is that IRA chooses i in %r4 and j in %r3, so there are 2 moves
even in the fast path (the i = a assignment is a nop, but j = i is needed, and
then later on extra reload move is added, because pseudo 67 disposition (result
of mulsi3) is properly in %r2 and if one argument is %r4 and another one %r3,
it needs to copy one to %r2.

Vlad, can you please have a look?

[Bug c++/70029] [6 Regression] ICE with C++11 and -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #5 from Jan Hubicka  ---
Jason, Marek,
it seems that the issue is in build_ref_qualified_type in C++ frontend.  It
builds a type variant which is correctly built with tree.c as having same
canonical type as the main variant and then it does:
1972  else
1973/* T is its own canonical type. */
1974TYPE_CANONICAL (t) = t;

here we end up with TYPE_CANONICAL being a variant type.  This seems odd to me,
but it looks like this code is intentional.

I think the effect of this code is that pointer to TYPE and pointer to T (i.e.
the type and the qualified type we build it from) will be considered
incompatible. So it seemt o me that hunk should be dropped?

Honza

[Bug rtl-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Ilya Enkovich from comment #6)
> Thanks a lot for your analysis!  When chain is built we scan all register
> definitions and their uses.  Thus it includes all register definitions and
> uses.  Uninitialized uses are missed though.  Simply skipping them in
> convert_reg should be OK.  I'm testing this patch:

Ah, ok.

> I'm not sure what's wrong with debug insns.  If register is converted into a
> vector one then why can't it be used in debug insns?  It is still the same
> DI reg with the same value, we just replace its uses with V2DI subreg uses
> to force SSE hard reg allocation.

I don't have a testcase.  If the original pseudo still contains the right value
after the STV pass, then sure, there is no need to adjust debug insns.

[Bug target/70113] [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
Author: clyon
Date: Thu Mar 10 13:29:48 2016
New Revision: 234108

URL: https://gcc.gnu.org/viewcvs?rev=234108=gcc=rev
Log:
2016-03-10  Christophe Lyon  

PR target/70113.
* config/aarch64/aarch64.h (TARGET_FIX_ERR_A53_843419_DEFAULT):
Always define to 0 or 1.
(TARGET_FIX_ERR_A53_843419): New macro.
* config/aarch64/aarch64-elf-raw.h
(TARGET_FIX_ERR_A53_843419_DEFAULT): Update for above changes.
* config/aarch64/aarch64-linux.h: Likewise.
* config/aarch64/aarch64.c
(aarch64_override_options_after_change_1): Do not default
aarch64_nopcrelative_literal_loads to true if Cortex-A53 erratum
843419 is on.
(aarch64_attributes): Handle fix-cortex-a53-843419.
(aarch64_can_inline_p): Likewise.
* config/aarch64/aarch64.opt (aarch64_fix_a53_err843419): Save.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-elf-raw.h
trunk/gcc/config/aarch64/aarch64-linux.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/config/aarch64/aarch64.opt

[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #7 from Jan Hubicka  ---
Oops, seems I missaplied the fix.  I am testing the updated patch.

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Ah, needs -mlittle, not just -mabi=elfv2.

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[wdijkstr at arm dot com]

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

--- Comment #15 from Wilco  ---
(In reply to Richard Biener from comment #14)
> The regression in the original description looks severe enough to warrant
> some fixing even if regressing some other cases.

Agreed, I think the improvement from Richard H's "2nd patch" outweighs the
regression shown in comment 11. Assuming it benchmarks OK, for GCC6 that seems
the best we can do.

It is is unlikely that legitimize_address could ever be used improve addressing
of multiple arrays. The arrays must both be small and allocated close together
for this to be beneficial, and that is something you don't know in advance, let
alone could decide in a callback that only sees one address at a time. So that
requires a different approach.

[Bug rtl-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Thanks a lot for your analysis!  When chain is built we scan all register
definitions and their uses.  Thus it includes all register definitions and
uses.  Uninitialized uses are missed though.  Simply skipping them in
convert_reg should be OK.  I'm testing this patch:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index fa7d3ff..3d8dbc4 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3372,8 +3372,11 @@ scalar_chain::convert_reg (unsigned regno)
bitmap_clear_bit (conv, DF_REF_INSN_UID (ref));
  }
   }
-else if (NONDEBUG_INSN_P (DF_REF_INSN (ref)))
+/* Skip debug insns and uninitialized uses.  */
+else if (DF_REF_CHAIN (ref)
+&& NONDEBUG_INSN_P (DF_REF_INSN (ref)))
   {
+   gcc_assert (scopy);
replace_rtx (DF_REF_INSN (ref), reg, scopy);
df_insn_rescan (DF_REF_INSN (ref));
   }


I'm not sure what's wrong with debug insns.  If register is converted into a
vector one then why can't it be used in debug insns?  It is still the same DI
reg with the same value, we just replace its uses with V2DI subreg uses to
force SSE hard reg allocation.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
..
> simply trigger versioning if that happens.  We still run into
> 
> _14 = *_13;
> tree could trap...
> 
> then of course.  The fix for that is for ref_DR_map to hash/compare
> DR_BASE_ADDRESS, DR_OFFSET, DR_INIT and DR_STEP instead of a somewhat
> stripped DR_REF.

Yes, I encountered another case showing the exact same issue.  Testing a patch
to fix this one.

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[ostash at ostash dot kiev.ua]

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

--- Comment #3 from Viktor Ostashevskyi  ---
Could be the same problem as in PR70145.

[Bug target/70113] [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
(In reply to Christophe Lyon from comment #0)
> This is a follow-up to PR 633304.
I meant bug #63304

[Bug ipa/70161] [4.9/5/6 Regression] fdump-ipa-all-graph causes segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2