[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013

--- Comment #15 from Jakub Jelinek  ---
Untested patch to turn things into true predicate when running out of space is:
--- gcc/ipa-inline-analysis.c.jj2014-02-03 08:53:12.0 +0100
+++ gcc/ipa-inline-analysis.c2014-02-05 08:01:57.093878954 +0100
@@ -310,7 +310,7 @@ add_clause (conditions conditions, struc
   if (false_predicate_p (p))
 return;

-  /* No one should be sily enough to add false into nontrivial clauses.  */
+  /* No one should be silly enough to add false into nontrivial clauses.  */
   gcc_checking_assert (!(clause & (1 << predicate_false_condition)));

   /* Look where to insert the clause.  At the same time prune out
@@ -372,9 +372,13 @@ add_clause (conditions conditions, struc
 }


-  /* We run out of variants.  Be conservative in positive direction.  */
+  /* We run out of variants.  Conservatively turn clause into true
+ predicate.  */
   if (i2 == MAX_CLAUSES)
-return;
+{
+  p->clause[0] = 0;
+  return;
+}
   /* Keep clauses in decreasing order. This makes equivalence testing easy. 
*/
   p->clause[i2 + 1] = 0;
   if (insert_here >= 0)
@@ -412,6 +416,8 @@ and_predicates (conditions conditions,
 {
   gcc_checking_assert (i < MAX_CLAUSES);
   add_clause (conditions, &out, p2->clause[i]);
+  if (true_predicate_p (&out))
+break;
 }
   return out;
 }
@@ -459,6 +465,8 @@ or_predicates (conditions conditions,
   {
 gcc_checking_assert (i < MAX_CLAUSES && j < MAX_CLAUSES);
 add_clause (conditions, &out, p->clause[i] | p2->clause[j]);
+if (true_predicate_p (&out))
+  return out;
   }
   return out;
 }
@@ -1035,7 +1043,7 @@ inline_node_removal_hook (struct cgraph_
   memset (info, 0, sizeof (inline_summary_t));
 }

-/* Remap predicate P of former function to be predicate of duplicated
functoin.
+/* Remap predicate P of former function to be predicate of duplicated
function.
POSSIBLE_TRUTHS is clause of possible truths in the duplicated node,
INFO is inline summary of the duplicated node.  */

and fixes the testcase.  Yet another possibility would be to keep
add_clause/{and,or}_predicates as is and just add comment that the oscillation
is possible due to using only a subset of the predicates, and during
compute_bb_predicates just wait until all basic blocks have bb->aux set, then
do a couple of iterations of the main loop after that and finally either just
terminate, or change the oscillating bb's into true predicate.

[Bug sanitizer/60055] Invalid binding of __tsan_default_options

[chefmax at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055

Maxim Ostapenko  changed:

   What|Removed |Added

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

--- Comment #6 from Maxim Ostapenko  ---
Fixed by Jakub.

[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600

--- Comment #11 from eggert at gnu dot org ---
It's not easy for me to test the fix, sorry, I don't normally build GCC.  If it
works on the test case my guess is that it'll work for Emacs, though.

[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600

--- Comment #10 from Yury Gribov  ---
Paul, does this work for you?

[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined

[ygribov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600

--- Comment #9 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Wed Feb  5 05:22:29 2014
New Revision: 207497

URL: http://gcc.gnu.org/viewcvs?rev=207497&root=gcc&view=rev
Log:
PR sanitizer/59600

gcc/
* cif-code.def (ATTRIBUTE_MISMATCH): New CIF code.
* ipa-inline.c (report_inline_failed_reason): Handle mismatched
sanitization attributes.
(can_inline_edge_p): Likewise.
(sanitize_attrs_match_for_inline_p): New function.

gcc/testsuite/
* gcc.dg/asan/nosanitize-and-inline.c: : New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cif-code.def
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60071] New: [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60071

Bug ID: 60071
   Summary: [4.9 Regression] [SH] internal compiler error: in
final_scan_insn, at final.c:2963
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
CC: olegendo at gcc dot gnu.org
Target: sh*-*-*

SH fails to build on trunk with

../../../ORIG/trunk/libgcc/fp-bit.c:1437:1: error: could not split insn
 }
 ^
(insn 119 38 83 (parallel [
(set (reg:SI 0 r0 [orig:160 D.2909 ] [160])
(minus:SI (const_int -2147483648 [0x8000])
(reg:SI 147 t)))
(clobber (reg:SI 147 t))
]) ../../../ORIG/trunk/libgcc/fp-bit.c:1429 404 {*mov_t_msb_neg}
 (expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_UNUSED (reg:SI 147 t)
(nil
../../../ORIG/trunk/libgcc/fp-bit.c:1437:1: internal compiler error: in
final_scan_insn, at final.c:2963
0x859edbf _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../ORIG/trunk/gcc/rtl-error.c:109

during building libgcc after the revision

r207460 | jakub | 2014-02-04 21:14:52 +0900 (Tue, 04 Feb 2014) | 6 lines

PR rtl-optimization/57915
* recog.c (simplify_while_replacing): If all unary/binary/relational
operation arguments are constant, attempt to simplify those.

Here is a reduced test case for -O1:

int
foo (int class, int sign)
{
  if (__builtin_expect (class == 4, 0))
return (sign
? (-((int) ((~(unsigned)0) >> 1)))-1
: ((int) ((~(unsigned)0) >> 1)));
}

It looks that now *mov_t_msb_neg define_insn_and_split is produced
in ira pass and has no chance to split.

[Bug libstdc++/57350] std::align missing

[potswa at mac dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350

--- Comment #11 from David Krauss  ---
No, that code wasn't right either. I'll just leave it at this and a caveat to
the reader:

inline void *align( std::size_t alignment, std::size_t size,
void *&ptr, std::size_t &space ) {
std::uintptr_t pn = reinterpret_cast< std::uintptr_t >( ptr );
std::uintptr_t aligned = ( pn + alignment - 1 ) & - alignment;
std::size_t padding = aligned - pn;
if ( space < size + padding ) return nullptr;
space -= padding;
return ptr = reinterpret_cast< void * >( aligned );
}

[Bug middle-end/60070] An option to disable all floating-pont

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60070

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
Some targets have this option.  

Like AARCH64:
mgeneral-regs-only
Target Report RejectNegative Mask(GENERAL_REGS_ONLY)
Generate code which uses only the general registers


I rather see this as a target specific option and not a single option as it is
a target specific problem and some targets don't have floating point/vector
registers.  


Also some targets having some support for having vector/floating point in the
kernel.

[Bug c/60070] New: An option to disable all floating-pont

[hpa at zytor dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60070

Bug ID: 60070
   Summary: An option to disable all floating-pont
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com

In the Linux kernel, and quite possibly in other standalone/embedded
environments, the use of any floating-point state or instructions is an error.

It would be nice to have a single option to have gcc error out on any floating
point use, rather than having to chase options.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #23 from Yury Gribov  ---
Can we close this one?

[Bug target/59777] Incorrect expansion of TLS arguments in a call

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59777

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #4 from John David Anglin  ---
Fixed on trunk and 4.8 branch.

[Bug target/59777] Incorrect expansion of TLS arguments in a call

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59777

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Wed Feb  5 00:47:25 2014
New Revision: 207494

URL: http://gcc.gnu.org/viewcvs?rev=207494&root=gcc&view=rev
Log:
PR target/59777
* config/pa/pa.c (legitimize_tls_address): Return original address
if not passed a SYMBOL_REF rtx.
(hppa_legitimize_address): Call legitimize_tls_address for all TLS
addresses.
(pa_emit_move_sequence): Simplify TLS source operands.
(pa_legitimate_constant_p): Reject all TLS constants.
* config/pa/pa.h (PA_SYMBOL_REF_TLS_P): Correct comment.
(CONSTANT_ADDRESS_P): Reject TLS CONST addresses.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/pa/pa.c
branches/gcc-4_8-branch/gcc/config/pa/pa.h

[Bug target/59777] Incorrect expansion of TLS arguments in a call

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59777

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Wed Feb  5 00:43:56 2014
New Revision: 207493

URL: http://gcc.gnu.org/viewcvs?rev=207493&root=gcc&view=rev
Log:
PR target/59777
* config/pa/pa.c (legitimize_tls_address): Return original address
if not passed a SYMBOL_REF rtx.
(hppa_legitimize_address): Call legitimize_tls_address for all TLS
addresses.
(pa_emit_move_sequence): Simplify TLS source operands.
(pa_legitimate_constant_p): Reject all TLS constants.
* config/pa/pa.h (PA_SYMBOL_REF_TLS_P): Correct comment.
(CONSTANT_ADDRESS_P): Reject TLS CONST addresses.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c
trunk/gcc/config/pa/pa.h

[Bug c/60069] New: Different warning messages for -Wconversion with different optimization levels

[chengniansun at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60069

Bug ID: 60069
   Summary: Different warning messages for -Wconversion with
different optimization levels
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

For the following code, gcc with -O0 emits a conversion warning, and gcc with
-O1 emits an overflow warning. 

Does gcc have a similar policy to Clang that warnings should be not affected by
optimization levels? 


$: cat s.c
void fn1() {
  unsigned short *l_432;
  const long l_448 = 70758;
  *l_432 = +l_448;
}
$: gcc-trunk -O0 -c -Wconversion s.c
s.c: In function ‘fn1’:
s.c:4:12: warning: conversion to ‘short unsigned int’ from ‘long int’ may alter
its value [-Wconversion]
   *l_432 = +l_448;
^
$: gcc-trunk -O1 -c -Wconversion s.c
s.c: In function ‘fn1’:
s.c:4:12: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
   *l_432 = +l_448;
^
$: gcc-trunk --version
gcc-trunk (GCC) 4.9.0 20140204 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/60063] -Wunused-local-typedefs warning despite attribute used in a template

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60063

--- Comment #1 from Martin Sebor  ---
I confused attribute used with unused in the test case. With the latter, the
warning is not emitted as one would expect. Attribute used isn't documented for
types, so it's not completely clear whether the test is valid.

Searching through the test suite, I came across Wunused-local-typedefs.c
(apparently added for bug 33255) which exercises attribute used with a typedef,
albeit in C code, so the test case might be valid after all and the
documentation might need updating.

[Bug c/59976] Spurious warning on converting const int variable to unsigned long (Also inconsistency between O0 and O1)

[chengniansun at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59976

Chengnian Sun  changed:

   What|Removed |Added

Summary|Spurious warning on |Spurious warning on
   |converting const int|converting const int
   |variable to unsigned long   |variable to unsigned long
   ||(Also inconsistency between
   ||O0 and O1)

--- Comment #1 from Chengnian Sun  ---
The warning is gone if I compile the program with -O1. 

I also have a similar example below:

$: cat s.c
unsigned g;
void fn1() {
  int a;
  const unsigned char b = 0;
  a = b & g;
}
$: gcc-trunk -c -Wconversion -O0 s.c
s.c: In function ‘fn1’:
s.c:5:7: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign
of the result [-Wsign-conversion]
   a = b & g;
   ^
$: gcc-trunk -c -Wconversion -O1 s.c
$:

[Bug c++/60068] New: missing diagnostic on array with negative bounds in template

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60068

Bug ID: 60068
   Summary: missing diagnostic on array with negative bounds in
template
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gmail dot com

GCC 4.8.2 and all versions prior to it fail to diagnose the following
ill-formed C++ '98 program:

$ cat u.cpp && g++ -Wall -Wextra -Werror -pedantic -c -o/dev/null u.cpp && echo
success
template 
void f (int [N]) { }

void g (void) {
f<-1>(0);
}

success

[Bug bootstrap/59913] [4.9 Regresion] bootstrap failure on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Hopefully fixed.

[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013

--- Comment #14 from Jakub Jelinek  ---
Important thing I forgot to mention is the order or predecessors, bb10 has
first bb9 and then bb11, bb11 has first bb4, then bb12, then bb5, bb6, bb8.

The oscillation is there really just because of the first and second processing
of bb11, where first time we've ored
{0x100,4,0}, , {0x80,0x40,4,0}, {0x20,0x10,4,0},
{0x200,8,0} and the second time:
{0x100,4,0}, {0x200,8,0}, {0x80,0x40,4,0}, {0x20,0x10,4,0}, {0x200,8,0}
{0x100,4,0}
So the result was first time
{0x3a0,0x390,0x360,0x350,0x1a8,0x198,0x168,0x158,0},
second time {0x3a0,0x390,0x360,0x350,0x204,0x1a8,0x198,0x168,0}.

{0x200,8,0} | {0x3a0,0x390,0x360,0x350,0x1a8,0x198,0x168,0x158,0}
gives the second operand.
{0x100,4,0} | {0x3a0,0x390,0x360,0x350,0x204,0x1a8,0x198,0x168,0}
gives also the second operand and oring into it {0x80,0x40,4,0},
{0x20,0x10,4,0}
and {0x200,8,0} doesn't change anything.
{0x200,8,0} | {0x3a0,0x390,0x360,0x350,0x204,0x1a8,0x198,0x168,0}
gives the second operand.
{0x100,4,0} | {0x3a0,0x390,0x360,0x350,0x1a8,0x198,0x168,0x158,0}
gives the second operand and oring into it {0x80,0x40,4,0}, {0x20,0x10,4,0}
and {0x200,8,0} doesn't change anything.

The oscillation is there because we always get the one before previous
iteration's predicate of bb10 through bb12.

[Bug c++/60067] New: bogus error default template arguments may not be used in function templates

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067

Bug ID: 60067
   Summary: bogus error default template arguments may not be used
in function templates
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gmail dot com

GCC 4.8.2 issues the bogus error below on the following valid C++ '98 program.
Instantiating C (or the whole definition of foo) isn't necessary to trigger the
error.

$ cat u.cpp && g++ -c -o/dev/null u.cpp
template  struct A;
template  struct B { enum { v = 1 };  };

template )>
struct C {
  void f () {
void g (int [B::v]);
  }
};

void foo (void) {
C().f ();
}

u.cpp: In member function ‘void C::f()’:
u.cpp:7:26: error: default template arguments may not be used in function
templates without -std=c++11 or -std=gnu++11
 void g (int [B::v]);
  ^

[Bug fortran/60066] Bad elemental invocation of non-scalar base object

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-04
 CC||mikael at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
This seems to have been fixed between r207387 and r207408 (r207389 or r207386).
These revisions are supposed to be back ported.

[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013

--- Comment #13 from Jakub Jelinek  ---
Ok, here is what happens on the reduced testcase.  We have 9 dynamic conditions
and 14 basic blocks.  Let's use letters for the dynamic conditions:
A (op1[ref offset: 0] == 0)
B (op1[ref offset: 0] != 0)
C (op0 >= 2)
D (op0 <= 3)
E (op0 >= 4)
F (op0 <= 6)
G (op0 == 8)
H (op1[ref offset: 0] == 1)
I (op1[ref offset: 0] != 1)

Most of the basic blocks have only a single predecessor and aren't part of any
kind of loop, so they have fixed set of predicates after first iteration, and
bb13 has one pred edge (the default: edge of switch) with true predicate, so it
is always true in the end, so the only really interesting basic blocks are
bb10, bb11 (ABNORMAL_DISPATCHER) and bb12.  The preds of bb10 are bb11 and bb9,
preds of bb11 are bb4, bb5, bb6 and bb12 and pred of bb12 is bb10.  The
predicates for
the bbs that really don't change after first iterations are:
bb4 G&A
bb5 F&E&A
bb6 D&C&A
bb9 H&B
and the problematic basic blocks are always processed in increasing bb->index,
i.e. bb10, bb11, bb12.  So bb10 get's H&B.  Then bb11 is processed, bb12 still
has no predicates computed, and the DNF (G&A)|(F&E&A)|(D&C&A)|(H&B) is being
converted into CNF, but there is a cap on the number of &s (8), thus we don't
compute the whole CNF (which would need to have 12 M|N|O|P style operands, 4
M|N|O style operands and 1 M|N style operand, i.e. in total 17?), but we pick
just 8 operands from this (the ones with largest values of the bitmask), so
(H|G|F|D)&(H|G|F|C)&(H|G|E|D)&(H|G|E|C)&(G|F|D|B)&(G|F|C|B)&(G|E|D|B)&(G|E|C|B).
Next time bb12 is processed and it's predicate is set to H&B.
On the next big round, nothing but these 3 bbs change, bb10 is set to
the same predicate as bb11 previously, the oring of H&B predicate into this
doesn't change anything, either H or B condition is already in all the
predicates.  Then bb11 is processed, and unlike previous case there is now one
additional executable edge with H&B predicate (the same as from bb8), but this
time the computed (incomplete) set of predicate is almost like the previous
one, but does contain additionally &(H|A) term and &(G|E|C|B) term fell out, as
there was no space for it.  Then bb12 again copies bb10 predicate, the one
without &(H|A) and with &(G|E|C|B).  Then next time bb10 is processed again,
and (H&B) is being ored with the current bb11 predicate, including (H|A),
excluding (G|E|C|B), the result is the same as that bb11 predicate.  Then bb11
is processed and as a result get's the old big predicate, the one with
(G|E|C|B) term and without (H|A) and that is the start of the oscillation.

The interesting thing is e.g. that the
(H|G|F|D)&(H|G|F|C)&(H|G|E|D)&(H|G|E|C)&(G|F|D|B)&(G|F|C|B)&(G|E|D|B)&(G|E|C|B)
ored with (H&B) gives the
(H|G|F|D)&(H|G|F|C)&(H|G|E|D)&(H|G|E|C)&(H|A)&(G|F|D|B)&(G|F|C|B)&(G|E|D|B)
result, while (H&B) ored with
(H|G|F|D)&(H|G|F|C)&(H|G|E|D)&(H|G|E|C)&(G|F|D|B)&(G|F|C|B)&(G|E|D|B)&(G|E|C|B)
gives the second operand.

So, IMHO easiest fix would be just to punt whenever we need during or_predicate
more than 8 terms - turn it into a true_predicate, then we will get guaranteed
termination, the drawback would be that in some cases we could have more true
predicates than previously.

Or we could e.g. always compute the or in infinite precision (or say with say
256 terms and punt into true predicate if we reach that) and only at the end of
processing some particular bb pick some subset of at most 8 bitmasks some way
(either prefer the highest values of the bitmask ever appearing there, or say
prefer terms that were already present among the predicates on the bb
previously (if any) and only pick the highest values otherwise, etc.

[Bug target/35767] x86 backend uses aligned load on unaligned memory

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35767

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #5 from Paul Pluzhnikov  ---
gcc.target/i386/pr35767-5.c is failing for me in both -m32 and -m64 mode on
trunk: xgcc (GCC) 4.9.0 20140204 (experimental)

The assembly produced:

test:
subq$24, %rsp
movaps  .LC0(%rip), %xmm0
movups  %xmm0, (%rsp)
movaps  %xmm0, %xmm7
movaps  %xmm0, %xmm6
movaps  %xmm0, %xmm5
movaps  %xmm0, %xmm4
movaps  %xmm0, %xmm3
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
callfoo
movl$0, %eax
addq$24, %rsp
ret

The movups appears to be especially bogus since it's moving to 0(%rsp) that is
guaranteed to be 16-byte aligned by the ABI.

[Bug fortran/60066] Bad elemental invocation of non-scalar base object

[fmartinez at gmv dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066

--- Comment #2 from Fran Martinez Fadrique  ---
Created attachment 32042
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32042&action=edit
Main program

[Bug fortran/60066] Bad elemental invocation of non-scalar base object

[fmartinez at gmv dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066

--- Comment #1 from Fran Martinez Fadrique  ---
Created attachment 32041
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32041&action=edit
Core type containing the elemental subroutine

[Bug fortran/60066] New: Bad elemental invocation of non-scalar base object

[fmartinez at gmv dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066

Bug ID: 60066
   Summary: Bad elemental invocation of non-scalar base object
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmartinez at gmv dot com

Created attachment 32040
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32040&action=edit
Array triggering the call to the elemental subroutine

Dear gfortran team.

The attached code compiles properly but the execution does not properly invoke
the elemental subroutine assertion_character that is a procedure bound to type
t_assertion_character. This happens in line 33 of
m_assertion_array_character.f90.
The attribute 'name' in t_assertion_character is not properly initialised to
the inpur value given in line 13 of main.f90.
When browsing the execution with the debugger, the subroutie
assertion_character is correctly invoked for each of the elements in the
ast%rast array. However, the value passed to the attribute 'name' is not
correctly passed to the subroutine assertion_character.
The implementation compiles and executes correctly with Intel fortran 14.
The same behaviour is observed with gfortran 4.7 and 4.8
Compiling with gfortran 4.6 the following message is issued (in case it may be
a hint):

m_assertion_array_character.f90:33.10:

  call ast%rast%assertion_character( name )
  1
Error: Non-scalar base object at (1) currently not implemented

Best regards,
Fran

[Bug c++/60065] New: [c++1y] ICE with auto parameter pack

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60065

Bug ID: 60065
   Summary: [c++1y] ICE with auto parameter pack
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following line of code (compiled with "-std=c++1y") triggers an ICE on
trunk:


template void foo(auto... x);


bug.cc:1:32: internal compiler error: tree check: expected template_type_parm
or template_template_parm or bound_template_template_parm, have integer_type in
convert_generic_types_to_packs, at cp/pt.c:21726
 template void foo(auto... x);
^
0xdc4824 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9192
0x64ad63 tree_check3
../../gcc/gcc/tree.h:2749
0x64ad63 convert_generic_types_to_packs(tree_node*, int, int)
../../gcc/gcc/cp/pt.c:21726
0x6c8f47 cp_parser_parameter_declaration_list
../../gcc/gcc/cp/parser.c:18279
0x6c9532 cp_parser_parameter_declaration_clause
../../gcc/gcc/cp/parser.c:18179
0x6bfd05 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:17072
0x6bfd05 cp_parser_declarator
../../gcc/gcc/cp/parser.c:16943
0x6ca599 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16496
0x6cb41a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23113
0x6cb704 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22915
0x6d6af9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10947
0x6d55e8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d6eca cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d6eca c_parse_file()
../../gcc/gcc/cp/parser.c:31528
0x7f6973 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]

The code compiles if I remove the 'x' or replace 'int' by 'typename'.
I'm not sure whether the code is valid or not, though.

[Bug c++/60064] New: [c++1y] ICE with auto as parameter of friend function

[reichelt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60064

Bug ID: 60064
   Summary: [c++1y] ICE with auto as parameter of friend function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with "-std=c++1y") triggers an ICE
on trunk:

===
struct A
{
  friend void foo(auto) {}
};
===

bug.cc:4:1: internal compiler error: in poplevel_class, at
cp/name-lookup.c:2951
 };
 ^
0x77ff17 poplevel_class()
../../gcc/gcc/cp/name-lookup.c:2951
0x665008 popclass()
../../gcc/gcc/cp/class.c:7127
0x679edd finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:6808
0x6ac14a cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19218
0x6ac14a cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19437
0x6ac14a cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14302
0x6c5540 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cc139 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6af5f3 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d68f2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d55e8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d6eca cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d6eca c_parse_file()
../../gcc/gcc/cp/parser.c:31528
0x7f6973 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]

[Bug ipa/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062

--- Comment #2 from Marek Polacek  ---
What I'm seeing is that this was fine in r202186, then started ICEing in
r202187 [*], then r202661 turned it into wrong-code issue.

[*]
/home/polacek/p.c:17:1: error: inlined_to pointer is set but no predecessors
found
 }
 ^
foo/1 (foo) @0x76811d10
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  References: 
  Referring: 
  Function foo/1 is inline copy in main/2
  Availability: local
  Function flags: body local
  Called by: 
  Calls: puts/3 (1.00 per call) 
/home/polacek/p.c:17:1: internal compiler error: verify_cgraph_node failed
0x61358e verify_symtab_node(symtab_node_def*)
/home/polacek/src/gcc/gcc/symtab.c:772
0x6135c7 verify_symtab()
/home/polacek/src/gcc/gcc/symtab.c:789
0x620251 compile()
/home/polacek/src/gcc/gcc/cgraphunit.c:2146
0x621779 finalize_compilation_unit()
/home/polacek/src/gcc/gcc/cgraphunit.c:2209
0x4e8732 c_write_global_declarations()
/home/polacek/src/gcc/gcc/c/c-decl.c:10125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/60063] New: -Wunused-local-typedefs warning despite attribute used in a template

[msebor at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60063

Bug ID: 60063
   Summary: -Wunused-local-typedefs warning despite attribute used
in a template
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gmail dot com

GCC 4.8.2 issues the following bogus warning on the defintion of Y in bar
despite attribute used. The same definition in an ordinary function emits no
warning.

$ cat t.cpp && g++ -Wunused-local-typedefs -c -o/dev/null t.cpp
template  struct S;

void foo (int i) {
typedef __attribute__ ((used)) S X;
}

template 
void bar (T i) {
typedef __attribute__ ((used)) S Y;
}

t.cpp: In function ‘void bar(T)’:
t.cpp:9:41: warning: typedef ‘Y’ locally defined but not used
[-Wunused-local-typedefs]
 typedef __attribute__ ((used)) S Y;
 ^

[Bug ipa/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-04
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.8.3
   Target Milestone|--- |4.9.0
Summary|wrong code (for code with   |[4.7/4.9 Regression] wrong
   |the optimize attribute) at  |code (for code with the
   |-O1 and above on|optimize attribute) at -O1
   |x86_64-linux-gnu in 32-bit  |and above on
   |mode|x86_64-linux-gnu in 32-bit
   ||mode
 Ever confirmed|0   |1

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

[Bug ipa/60062] New: wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062

Bug ID: 60062
   Summary: wrong code (for code with the optimize attribute) at
-O1 and above on x86_64-linux-gnu in 32-bit mode
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code that uses the optimize
attribute on x86_64-linux at -O1 and above in 32-bit mode (but not 64-bit). 

This is a regression from 4.8.x.

It also affects 4.7.x and 4.6.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140204 (experimental) [trunk revision 207452] (GCC) 
$ 
$ gcc-trunk -m32 -O0 small.c; a.out
hello
$ gcc-trunk -m64 -O1 small.c; a.out
hello
$ gcc-4.8 -m32 -O1 small.c; a.out
hello
$
$ gcc-trunk -m32 -O1 small.c; a.out
Segmentation fault (core dumped) 
$ gcc-4.7 -m32 -O1 small.c; a.out
Segmentation fault (core dumped)
$ gcc-4.6 -m32 -O1 small.c; a.out
Segmentation fault (core dumped)
$ 


--


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

int a;

static void 
foo(const char *p1, int p2) 
{ 
  printf("%s\n", p1); 
}

__attribute__((optimize(0))) 
int 
main() 
{
  foo("hello", a);
  return 0;
}

[Bug bootstrap/59913] [4.9 Regresion] bootstrap failure on arm-linux-gnueabihf

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913

--- Comment #7 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Feb  4 18:56:59 2014
New Revision: 207485

URL: http://gcc.gnu.org/viewcvs?rev=207485&root=gcc&view=rev
Log:
2014-02-04  Vladimir Makarov  

PR bootstrap/59913
* lra-constraints.c (need_for_split_p): Use more 3 reloads as
threshold for pseudo splitting.
(update_ebb_live_info): Process call argument hard registers and
hard registers from insn definition too.
(max_small_class_regs_num): New constant.
(inherit_in_ebb): Update live hard regs through EBBs.  Update
reloads_num only for small register classes.  Don't split for
outputs of jumps.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug lto/60061] New: Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60061

Bug ID: 60061
   Summary: Different dump-ipa-cp-details without/with -flto for
gfortran.dg/pr53787.f90
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org

The outputs pr53787_lto.f90.046i.cp of 

gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/pr53787.f90 -S -O3
-fdump-ipa-cp-details -fno-inline -fwhole-program

and

gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/pr53787.f90 -S -O3
-fdump-ipa-cp-details -fno-inline -fwhole-program -flto

differ. In particular the regexps in the test are no longer present with -flto:

...
-Evaluating opportunities for init/0.
- - Creating a specialized node of init/0 for all known contexts.
-  cannot change function signature
- the new node is init_.constprop.0/8.
- Aggregate replacements: 1[0]=10
-
-Evaluating opportunities for init/0.
-  Marking node as dead: init/0.
+Evaluating opportunities for init_/0.
...
-Modification phase of node init_.constprop.0/8
- Aggregate replacements: 1[0]=10
-Modifying stmt:
-  _2 = *n_1(D);
-into:
-  _2 = 10;
+  :
...

Is this expected? If yes, are there better regexps to scan?

[Bug c/60036] [4.9 Regression] Spurious signedness conversion warning with relational operator

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/60036] [4.9 Regression] Spurious signedness conversion warning with relational operator

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Tue Feb  4 18:05:29 2014
New Revision: 207481

URL: http://gcc.gnu.org/viewcvs?rev=207481&root=gcc&view=rev
Log:
PR c/60036
c-family/
* c-common.c (conversion_warning): Unwrap C_MAYBE_CONST_EXPR and/or
SAVE_EXPR.
testsuite/
* gcc.dg/pr60036.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr60036.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/60060] New: [4.9 Rgression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060

Bug ID: 60060
   Summary: [4.9 Rgression] lto1: internal compiler error: in
add_AT_specification, at dwarf2out.c:4096
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: aldyh at gcc dot gnu.org, burnus at gcc dot gnu.org,
rguenth at gcc dot gnu.org

At r207473 compiling gfortran.dg/namelist_51.f90 with '-g -flto' gives the
following ICE

lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

Compiling the tests with '-g' or '-g -flto -O3' gives on x86_64-apple-darwin13
the warning

warning: invalid DWARF generated by the compiler: DIE 0x01f0 has multiple 
AT_calling_convention attributes in
'/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccLHCwpM.ltrans0.ltrans.o'.

Note that before r207471 (and after r205679) the ICE was

/opt/gcc/work/gcc/testsuite/gfortran.dg/namelist_51.f90: In function
'readnamelist.1900':
/opt/gcc/work/gcc/testsuite/gfortran.dg/namelist_51.f90:8:0: internal compiler
error: in lto_output_tree, at lto-streamer-out.c:1390
 call readNamelist()

[Bug ipa/60058] [4.9 Regression] internal compiler error: Segmentation fault

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Tue Feb  4 17:25:38 2014
New Revision: 207478

URL: http://gcc.gnu.org/viewcvs?rev=207478&root=gcc&view=rev
Log:

PR ipa/60058
* ipa-cp.c (ipa_get_indirect_edge_target_1): Check that target
is non-null.
* g++.dg/torture/pr60058.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr60058.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013

--- Comment #12 from Jakub Jelinek  ---
Slightly more reduced testcase for -O2:
typedef long int jmp_buf[64];
extern int _setjmp (jmp_buf) __attribute__ ((__nothrow__));
struct S { int a, b, c; };
extern struct S *baz (struct S *);
static jmp_buf j;

static inline int
bar (int b, int d)
{
  return (b & d) < 0;
}

struct S *
foo (int a, struct S *b, struct S *c, struct S *d)
{
  if (b->a == 0)
{
  switch (a)
{
case 8:
  return baz (b);
case 7:
  bar (b->c, c->b);
  return 0;
case 6:
case 5:
case 4:
  return baz (c);
case 3:
case 2:
  return baz (d);
}
  return 0;
}
  if (b->a == 1)
{
  if (baz (c))
return c;
  else if (_setjmp (j))
baz (b);
}
  return 0;
}

[Bug ipa/60058] [4.9 Regression] internal compiler error: Segmentation fault

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jan Hubicka  ---
Fixed, thanks!

[Bug target/60017] [4.7/4.8 Regression] Struct not returned correctly

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb  4 16:46:06 2014
New Revision: 207476

URL: http://gcc.gnu.org/viewcvs?rev=207476&root=gcc&view=rev
Log:
Backport from mainline
2014-02-02  Uros Bizjak  

PR target/60017
* config/i386/i386.c (classify_argument): Fix handling of bit_offset
when calculating size of integer atomic types.

testsuite/ChangeLog

Backport from mainline
2014-02-02  Uros Bizjak  

PR target/60017
* gcc.c-torture/execute/pr60017.c: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr60017.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260

--- Comment #13 from Martin Jambor  ---
Fix to this second issue (which is indeed very similar to the initial
one) has been sent to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00201.html

[Bug ipa/60058] [4.9 Regression] internal compiler error: Segmentation fault

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

--- Comment #2 from Jan Hubicka  ---
Ah yes, if the method can not be referred, we need to check that target is
non-NULL.
I reorganized the code one too man times.  I will double check it is what
happens in your testcase.

Honza

[Bug target/60017] [4.7/4.8 Regression] Struct not returned correctly

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2014-02/msg00027.htm
   ||l
 Resolution|--- |FIXED

--- Comment #7 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/60017] [4.7/4.8 Regression] Struct not returned correctly

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60017

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb  4 16:43:00 2014
New Revision: 207475

URL: http://gcc.gnu.org/viewcvs?rev=207475&root=gcc&view=rev
Log:
Backport from mainline
2014-02-02  Uros Bizjak  

PR target/60017
* config/i386/i386.c (classify_argument): Fix handling of bit_offset
when calculating size of integer atomic types.

testsuite/ChangeLog:

Backport from mainline
2014-02-02  Uros Bizjak  

PR target/60017
* gcc.c-torture/execute/pr60017.c: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr60017.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
As discussed on IRC the #c1 patch would need to be moved after the
if (STMT_VINFO_GATHER_P (stmtinfo_a)...) {}
Getting the version checks below the default limit would be really nice, the
benchmark numbers look much nicer when it is vectorized, even with
--param vect-max-version-for-alias-checks=32.

[Bug c/60059] New: Error when building gcc-4.8.2 together with binutils 2.24

[tangyilei10 at itp dot ac.cn]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60059

Bug ID: 60059
   Summary: Error when building gcc-4.8.2 together with binutils
2.24
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyilei10 at itp dot ac.cn

I'm building gcc-4.8.2 with binutils extracted in the source directory. After I
made dir gcc-build as a build dir, configured it and typed make, error came
out. The error indicates that the system was unable to acquire ar in directory
binutils. So I went into the binutils directory inside the gcc-build and typed

ln -sv binutils/ar ar
cd ..
make

The make goes on while it reported it could not find ranlib, so I again go into
the binutils directory and typed

ln -sv binutils/ranlib ranlib
cd ..
make

The make goes on while it was bothered again reporting that the nm in the
directory gcc returned the wrong message, so I just

cd gcc
mv nm nm_backup
ln -sv ../binutils/binutils/nm-new nm
cd ..
make

and the make goes on.

As it worked in every stage, the previously compiled binutils and gcc are wiped
off so these tricks should be repeated 2 times. I think it is the bug because
you misunderstood the structure of the tarball of the binutils. Any way, my
trick seems to work well.

[Bug fortran/55960] [OOP] ICE in replace_comp, at fortran/expr.c:4356

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Sergio Losilla from comment #6)
> Well, a very similar case, with a non-abstract type throws an ICE with
> gfortran 4.8.1:

Right. This comes from mio_expr and seems to be similar or identical to the ICE
that 4.8 throws on comment 2. But both of them are gone with current trunk.

[Bug fortran/55960] [OOP] ICE in replace_comp, at fortran/expr.c:4356

[loximann at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960

--- Comment #6 from Sergio Losilla  ---
Well, a very similar case, with a non-abstract type throws an ICE with gfortran
4.8.1:

module Foo_class
type :: Foo
integer :: n
contains
procedure :: n2  => Foo_n2
procedure :: vec => Foo_vec
end type

contains

pure function Foo_n2(self)
class(Foo), intent(in) :: self
integer:: Foo_n2

Foo_n2 = self%n**2
end function

function Foo_vec(self)
class(Foo) :: self
real   :: Foo_vec(self%n2())

Foo_vec=1.0
end function

end module

[Bug fortran/55960] [OOP] ICE in replace_comp, at fortran/expr.c:4356

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from janus at gcc dot gnu.org ---
Note that 'replace_comp' has been removed in r195562 (cf. PR 54107), with the
consequence that the original ICE on comment 0 is fixed in 4.8.0 and above.

Also the double error message is reduced to a single one in 4.8.

For comment 2, 4.8 actually gives an ICE in mio_expr, but it compiles cleanly
with trunk, so I'm closing this whole PR as fixed.

[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042

Richard Biener  changed:

   What|Removed |Added

  Attachment #32038|0   |1
is obsolete||

--- Comment #6 from Richard Biener  ---
Created attachment 32039
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32039&action=edit
updated patch

[Bug rtl-optimization/56885] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Known to work||4.9.0
Summary|[4.8/4.9 Regression] ICE:   |[4.8 Regression] ICE: in
   |in assign_by_spills, at |assign_by_spills, at
   |lra-assigns.c:1268 with -O  |lra-assigns.c:1268 with -O
   |-fschedule-insns|-fschedule-insns
   |-fselective-scheduling  |-fselective-scheduling
  Known to fail|4.9.0   |

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk then, perhaps it might be worthwhile to add the testcase
though.

[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Tue Feb  4 14:53:24 2014
New Revision: 207471

URL: http://gcc.gnu.org/viewcvs?rev=207471&root=gcc&view=rev
Log:
2014-02-04  Richard Biener  

PR lto/59723
* lto-streamer-out.c (tree_is_indexable): Force NAMELIST_DECLs
in function context local.
(lto_output_tree_ref): Do not write trees from lto_output_tree_ref.
* lto-streamer-in.c (lto_input_tree_ref): Handle LTO_namelist_decl_ref
similar to LTO_imported_decl_ref.

lto/
* lto.c (mentions_vars_p): Handle NAMELIST_DECL.
(lto_fixup_prevailing_decls): Handle fixing up CONSTRUCTOR values.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c

[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-04
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Created attachment 32038
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32038&action=edit
patch for the PRE issue

The attached patch delays inhibit_phi_insertion to a point where it can give
a more definitive answer (eliminate () time).

[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885

--- Comment #10 from H.J. Lu  ---
On trunk, it was fixed by r206938.

[Bug ipa/60058] [4.9 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.9.0

[Bug fortran/57033] [4.7/4.8/4.9 Regression] ICE on extended derived type and default initialization

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57033

Mikael Morin  changed:

   What|Removed |Added

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

[Bug tree-optimization/60002] ICE: SIGSEGV in skip_artificial_parms_for() with -O2 -fcompare-debug -fdeclone-ctor-dtor -fipa-cp-clone

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60002

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 13:38:13 2014
New Revision: 207465

URL: http://gcc.gnu.org/viewcvs?rev=207465&root=gcc&view=rev
Log:
PR tree-optimization/60002
* cgraphclones.c (build_function_decl_skip_args): Clear
DECL_LANG_SPECIFIC.

* g++.dg/opt/pr60002.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr60002.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/60002] ICE: SIGSEGV in skip_artificial_parms_for() with -O2 -fcompare-debug -fdeclone-ctor-dtor -fipa-cp-clone

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60002

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> Bah, and with -fipa-pta -Ofast -fwhole-program we now _do_ see that there
> isn't any aliasing but PRE messes up the loop and creates loop carried
> dependencies ... :/

Ok, that's because PRE would be the one to make the array loads base
addresses simple induction variables (it performs invariant motion of the
address load from the global matrix struct).  Thus inhibit_phi_insertion
returns false.  Looks like ordering of PRE / LIM isn't too great when
considering such cases.

[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042

--- Comment #3 from Richard Biener  ---
Bah, and with -fipa-pta -Ofast -fwhole-program we now _do_ see that there
isn't any aliasing but PRE messes up the loop and creates loop carried
dependencies ... :/

[Bug ipa/60058] [4.9 Regression] internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

--- Comment #1 from Markus Trippelsdorf  ---
Looks like an "if (target)" wrapper like in the other hunk of r207447 is
necessary.

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 68afeb0d89e4..dab9e8a0f80d 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1573,20 +1573,23 @@ ipa_get_indirect_edge_target_1 (struct cgraph_edge *ie,
{
  target = gimple_get_virt_method_for_vtable
(ie->indirect_info->otr_token,
  vtable, offset);
- if ((TREE_CODE (TREE_TYPE (target)) == FUNCTION_TYPE
-  && DECL_FUNCTION_CODE (target) == BUILT_IN_UNREACHABLE)
- || !possible_polymorphic_call_target_p
-  (ie, cgraph_get_node (target)))
+ if (target)
{
- if (dump_file)
-   fprintf (dump_file,
-"Type inconsident devirtualization: %s/%i->%s\n",
-ie->caller->name (), ie->caller->order,
-IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (target)));
- target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
- cgraph_get_create_node (target);
+ if ((TREE_CODE (TREE_TYPE (target)) == FUNCTION_TYPE
+  && DECL_FUNCTION_CODE (target) == BUILT_IN_UNREACHABLE)
+ || !possible_polymorphic_call_target_p
+  (ie, cgraph_get_node (target)))
+   {
+ if (dump_file)
+   fprintf (dump_file,
+"Type inconsident devirtualization: %s/%i->%s\n",
+ie->caller->name (), ie->caller->order,
+IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
(target)));
+ target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
+ cgraph_get_create_node (target);
+   }
+ return target;
}
- return target;
}
 }

[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-04
 Ever confirmed|0   |1

[Bug tree-optimization/60023] [4.9 Regression] ICE: verify_gimple failed: dead STMT in EH table with -O3 -fnon-call-exceptions -mavx2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60023

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/60023] [4.9 Regression] ICE: verify_gimple failed: dead STMT in EH table with -O3 -fnon-call-exceptions -mavx2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60023

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 13:08:00 2014
New Revision: 207464

URL: http://gcc.gnu.org/viewcvs?rev=207464&root=gcc&view=rev
Log:
PR tree-optimization/60023
* tree-if-conv.c (predicate_mem_writes): Pass true instead of
false to gsi_replace.
* tree-vect-stmts.c (vect_finish_stmt_generation): If stmt
has been in some EH region and vec_stmt could throw, add
vec_stmt into the same EH region.
* tree-data-ref.c (get_references_in_stmt): If IFN_MASK_LOAD
has no lhs, ignore it.
* internal-fn.c (expand_MASK_LOAD): Likewise.

* g++.dg/vect/pr60023.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr60023.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-if-conv.c
trunk/gcc/tree-vect-stmts.c

[Bug ipa/60026] [4.8 Regression] ICE at -O3 on valid code (with the optimize pragma) on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60026

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|4.9.0   |4.8.3
Summary|[4.8/4.9 Regression] ICE at |[4.8 Regression] ICE at -O3
   |-O3 on valid code (with the |on valid code (with the
   |optimize pragma) on |optimize pragma) on
   |x86_64-linux-gnu|x86_64-linux-gnu

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

[Bug ipa/60026] [4.8/4.9 Regression] ICE at -O3 on valid code (with the optimize pragma) on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60026

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 13:04:37 2014
New Revision: 207463

URL: http://gcc.gnu.org/viewcvs?rev=207463&root=gcc&view=rev
Log:
PR ipa/60026
* tree-inline.c (copy_forbidden): Fail for
__attribute__((optimize (0))) functions.

* c-c++-common/torture/pr60026.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/torture/pr60026.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug ipa/60058] New: [4.9 Regression] internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60058

Bug ID: 60058
   Summary: [4.9 Regression] internal compiler error: Segmentation
fault
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

markus@x4 common % cat test.ii
typedef enum {} UErrorCode;
class A {
public:
  virtual A &m_fn1(A &, const A &, UErrorCode &) const;
  void m_fn2();
  A();
  A(int);
};
class __attribute__((visibility("default"))) B : public A {
public:
  B(A &p1) : norm2(p1), set(0) {}
  A &m_fn1(A &, const A &, UErrorCode &) const;
  A &norm2;
  const int &set;
};

UErrorCode a;
A c;
void fn1(A *p1) {
  A b;
  p1->m_fn1(b, 0, a).m_fn2();
}

void fn2() {
  B d(c);
  fn1(&d);
}

markus@x4 common % g++ -c -O2 test.ii
test.ii:27:1: internal compiler error: Segmentation fault
 }
 ^
0xb4d18f crash_signal
../../gcc/gcc/toplev.c:337
0x103ef73 contains_struct_check
../../gcc/gcc/tree.h:2822
0x103ef73 ipa_get_indirect_edge_target_1
../../gcc/gcc/ipa-cp.c:1576
0x9d1360 estimate_edge_devirt_benefit
../../gcc/gcc/ipa-inline-analysis.c:2945
0x9d1360 estimate_edge_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2977
0x9d1360 estimate_calls_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3030
0x9d1872 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3117
0x9d4cb7 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3660
0x9d4e62 estimate_edge_size
../../gcc/gcc/ipa-inline.h:277
0x9d4e62 estimate_edge_growth
../../gcc/gcc/ipa-inline.h:289
0x9d4e62 do_estimate_growth_1
../../gcc/gcc/ipa-inline-analysis.c:3771
0x82a4de cgraph_for_node_and_aliases(cgraph_node*, bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/gcc/cgraph.c:2209
0x9d537a do_estimate_growth(cgraph_node*)
../../gcc/gcc/ipa-inline-analysis.c:3785
0x105073b estimate_growth
../../gcc/gcc/ipa-inline.h:264
0x105073b inline_small_functions
../../gcc/gcc/ipa-inline.c:1565
0x105073b ipa_inline
../../gcc/gcc/ipa-inline.c:2025
0x105073b execute
../../gcc/gcc/ipa-inline.c:2381
Please submit a full bug report,
with preprocessed source if appropriate.

Started with r207447.

[Bug rtl-optimization/57915] [4.8 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||4.9.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[4.8/4.9 Regression] ICE in |[4.8 Regression] ICE in
   |set_address_disp, at|set_address_disp, at
   |rtlanal.c:5537  |rtlanal.c:5537
  Known to fail|4.9.0   |

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

[Bug middle-end/57499] [4.7/4.8/4.9 Regression] ICE when noreturn destructor returns after throw with -O

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57499

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 32037
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32037&action=edit
gcc47-pr57499.patch

Untested fix.

[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 12:31:30 2014
New Revision: 207462

URL: http://gcc.gnu.org/viewcvs?rev=207462&root=gcc&view=rev
Log:
PR other/58712
* omp-low.c (simd_clone_struct_copy): If from->inbranch
is set, copy one less argument.
(expand_simd_clones): Don't subtract clone_info->inbranch
from simd_clone_struct_alloc argument.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032

--- Comment #3 from Alan Modra  ---
No, not quite.  SECONDARY_MEMORY_NEEDED_MODE looks to be required by lra, so
make rs6000_secondary_memory_needed_mode depend on lra_in_progress.

[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 12:19:32 2014
New Revision: 207461

URL: http://gcc.gnu.org/viewcvs?rev=207461&root=gcc&view=rev
Log:
PR other/58712
* omp-low.c (simd_clone_struct_copy): If from->inbranch
is set, copy one less argument.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug c/60036] [4.9 Regression] Spurious signedness conversion warning with relational operator

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-04
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|Spurious signedness |[4.9 Regression] Spurious
   |conversion warning with |signedness conversion
   |relational operator |warning with relational
   ||operator
 Ever confirmed|0   |1

[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 12:14:52 2014
New Revision: 207460

URL: http://gcc.gnu.org/viewcvs?rev=207460&root=gcc&view=rev
Log:
PR rtl-optimization/57915
* recog.c (simplify_while_replacing): If all unary/binary/relational
operation arguments are constant, attempt to simplify those.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr57915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|amodra at gcc dot gnu.org  |
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

--- Comment #2 from Alan Modra  ---
Looks to be as simple as deleting SECONDARY_MEMORY_NEEDED_MODE.  Testing..

[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #9 from Andrey Belevantsev  ---
Trunk does not ICE for me anymore, though the two insns Yuri mentioned are
still reordered.  I will explain what happens in more detail.

The selective scheduler supports register renaming.  So on seeing an
anti-dependence in this case for di=r69 it assumes that the RHS of this insn
can be moved up with the new register, e.g. r?? = r69 and later di = r??.  When
the new register is being chosen, there is nothing in the function that
prevents using the original register, di -- no liveness or hardware imposed
restrictions are reported by the backend so we allow to move the insn with the
original register.  The reason for this is that the dependence comes from the
implicit_set on the another insn (insn 30 in Yuri's dump), and implicit sets do
not get reflected in the dataflow information (which we get from DF_LIVE_IN
sets and df_simulate_one_insn_backwards interfaces).

Now, if the extra dependencies really come from the evaluation_hook interface
of the x86 backend, I'd note that the hook, originally implemented for ia64
only, was not intended for adding any new dependencies, but rather for
reflecting the dependencies added in the backend for its own purposes.  E.g.
for ia64 the interface allows to get the complete dependence picture before
making decisions on bundling.  So I'd claim that any dependencies created for
the scheduler should also be calculated via the general deps_analyze_insn
mechanism of sched-deps.c, with the correctly prepared deps context.  E.g. any
changes done with implicit_sets/clobbers/uses and IRA/LRA interfaces are also
visible within the selective scheduling.  The selective scheduling analyzes
dependencies between separate insns, not blocks, so the evaluation_hook
interface does not make sense for it.

To summarize, if the backend wants to stop reordering insns in question and
also forbid renaming, then this should be exposed from within a hook called
from sched-deps.c when calculating dependencies through deps_analyze_insn, not
later, and then we can judge whether the new dependence comes from
LHS/RHS/whole insn and make appropriate changes for renaming.  The current
interface does not tell us that renaming is prohibited and we cannot derive it
from the IR.  The best way would be to properly reflect all restrictions in the
IR and not end up lying to the dataflow machinery and the scheduler.

[Bug fortran/54852] Bogus(?) warnings when compiling gfortran.dg/bind_c_vars.f90 gfortran.dg/bind_c_vars_driver.c with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, lto
 Status|WAITING |NEW

--- Comment #3 from Richard Biener  ---
LTO warns that

/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars_driver.c:12:5:
warning: type of 'myF90Array2D' does not match original declaration [enabled by
default]
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars.f90:16:0:
note: previously declared here
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars_driver.c:11:5:
warning: type of 'myF90Array3D' does not match original declaration [enabled by
default]
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars.f90:15:0:
note: previously declared here

which effectively means that assignments in GIMPLE between those arrays
would be invalid (not array members but whole arrays).  Not sure if we
can create a testcase that will eventually ICE though.  Usually the above
also means that the arrays use different alias sets but that's safe here
because the alias set of an array is that of its element (and those are
compatible here).

The issue is that in C a[2][3] is ARRAY_TYPE  > but
GFortran represents a(2)(3) as 1D ARRAY_TYPE <...> and thus both types
are not structurally equivalent (which is why LTO warns).

Not sure if this case is motivation enough to treat arrays structurally
the same if their overall size is the same.

[Bug fortran/54852] Bogus(?) warnings when compiling gfortran.dg/bind_c_vars.f90 gfortran.dg/bind_c_vars_driver.c with -flto

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

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

[Bug fortran/60057] bind(C): multi-dimensional arrays have incompatible types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60057

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr54852.

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

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r174820.  Reduced testcase -std=c++11:

constexpr bool foo () { return noexcept (true); }
template 
struct V
{
  void bar (V &) noexcept (foo ()) {}
};
template 
struct W : public V 
{
  void bar (W &x) { V ::bar (x); }
};

int
main ()
{
  W  a, b;
  a.bar (b);
}

[Bug fortran/60057] New: bind(C): multi-dimensional arrays have incompatible types

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60057

Bug ID: 60057
   Summary: bind(C): multi-dimensional arrays have incompatible
types
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic, lto
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

As can be seen with

make check-gfortran RUNTESTFLAGS="--target_board=unix/-flto
dg.exp=bind_c_vars.f90"

FAIL: gfortran.dg/bind_c_vars.f90  -O0  (test for excess errors)
...

which is because LTO warns that

/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars_driver.c:12:5:
warning: type of 'myF90Array2D' does not match original declaration [enabled by
default]
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars.f90:16:0:
note: previously declared here
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars_driver.c:11:5:
warning: type of 'myF90Array3D' does not match original declaration [enabled by
default]
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/bind_c_vars.f90:15:0:
note: previously declared here

which effectively means that assignments in GIMPLE between those arrays
would be invalid (not array members but whole arrays).  Not sure if we
can create a testcase that will eventually ICE though.  Usually the above
also means that the arrays use different alias sets but that's safe here
because the alias set of an array is that of its element (and those are
compatible here).

The issue is that in C a[2][3] is ARRAY_TYPE  > but
GFortran represents a(2)(3) as 1D ARRAY_TYPE <...> and thus both types
are not structurally equivalent (which is why LTO warns).

Not sure if this case is motivation enough to treat arrays structurally
the same if their overall size is the same.

[Bug c/60036] Spurious signedness conversion warning with relational operator

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60036

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This is so since r206620.

[Bug tree-optimization/60006] [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60006

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Following Jakub answer on IRC, closing as duplicate of pr60003.

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

[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

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

[Bug sanitizer/60055] Invalid binding of __tsan_default_options

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  4 10:46:22 2014
New Revision: 207459

URL: http://gcc.gnu.org/viewcvs?rev=207459&root=gcc&view=rev
Log:
PR sanitizer/60055
* tsan/tsan_flags.cc (__tsan_default_options): Add
SANITIZER_INTERFACE_ATTRIBUTE.  Backport from upstream r200747.
* tsan/tsan_rtl.cc (__tsan::OnFinalize): Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/tsan/tsan_flags.cc
trunk/libsanitizer/tsan/tsan_rtl.cc

[Bug c++/60056] New: [C++11] ICE in var_defined_without_dynamic_init, at cp/decl2.c:2876 with TLS static

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60056

Bug ID: 60056
   Summary: [C++11] ICE in var_defined_without_dynamic_init, at
cp/decl2.c:2876 with TLS static
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 59994

template
class Foo {
public:
Foo() {
++c;
}
private:
thread_local static int c;
};

template thread_local int Foo::c(0);

int main(){
Foo o;
}

Maybe related to PR58671.

[Bug sanitizer/60055] Invalid binding of __tsan_default_options

[chefmax at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055

--- Comment #4 from Maxim Ostapenko  ---
(In reply to Dmitry Vyukov from comment #3)
> Hi,
> 
> Does this work for you
> http://llvm.org/viewvc/llvm-project?view=revision&revision=200747
> ?
> 
> These callbacks are intended for very specific usages. I am curious how do
> you want to use them?

We use these callbacks in tsan test g++.dg/tsan/default_options.C.

I guess we'll wait for next merge with LLVM libsanitizer to get this fix.

[Bug middle-end/57499] [4.7/4.8/4.9 Regression] ICE when noreturn destructor returns after throw with -O

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57499

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Likely started with r151696.

[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-04
  Known to work||4.6.4
   Target Milestone|--- |4.7.4
Summary|internal compiler error: in |[4.7/4.8/4.9 Regression]
   |nothrow_spec_p, at  |internal compiler error: in
   |cp/except.c:1280|nothrow_spec_p, at
   ||cp/except.c:1280
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Compiles ok with 4.6.4.

[Bug c++/60051] [4.9 Regression] [c++11] ICE with auto and array initialization

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60051

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/60026] [4.8/4.9 Regression] ICE at -O3 on valid code (with the optimize pragma) on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60026

--- Comment #10 from Richard Biener  ---
You could also check gimple_vop (fn) == NULL_TREE (not in virtual SSA form,
we probably should have a better way to query that).  But indeed guarding
this for -O0 is better.

[Bug c++/60051] [4.9 Regression] [c++11] ICE with auto and array initialization

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60051

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-04
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
namespace std
{
  typedef __SIZE_TYPE__ size_t;
  template
  struct initializer_list
  {
const T *c;
size_t d;
constexpr initializer_list(const T *x, size_t y) : c(x), d(y) { }
constexpr initializer_list() noexcept : c(0), d(0) { }
  };
}
auto x[2] = {};

(though of course, the original testcase is likely better for the testsuite).

Started with r203725.

[Bug tree-optimization/60006] [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60006

--- Comment #2 from Dominique d'Humieres  ---
Created attachment 32035
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32035&action=edit
Assembly file for fib_no_return.c at r207381

[Bug tree-optimization/60006] [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60006

--- Comment #3 from Dominique d'Humieres  ---
Created attachment 32036
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32036&action=edit
Assembly file for fib_no_return.c at r207382

[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

--- Comment #12 from Richard Biener  ---
That's good news!

[Bug middle-end/59261] [4.9 regression] FAIL: gcc.dg/vect/bb-slp-26.c -flto -ffat-lto-objects (internal compiler error)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59261

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed then.

[Bug rtl-optimization/60043] -fschedule-insns2 breaks anti-dependency

[abel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60043

--- Comment #5 from Andrey Belevantsev  ---
(In reply to Richard Biener from comment #4)
> Hmm, oops.  The testcase has a true dependence ... ;)  Still, isn't the
> code in sched_analyze_2 wrong?  Or are pending_mems all before 't'?

Yes (to second question :).  The analysis code roughly works like this
(sched_analyze is the entry point):

- process insns one by one in a bb/ebb doing two things in parallel:

  o mark reads/writes to registers, writes/reads to mems of this insn in
various fields of the deps context; and
  o find dependencies between this insn reads/writes of registers/memory and
previously noted reads/writes of the same register or memory from the deps
context.

So the pending_mem read/write will always happen before the currently
processing insn mem read/write.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 60012, which changed state.

Bug 60012 Summary: Vectorizer generates unnecessary loop versioning for alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60012

   What|Removed |Added

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