[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

--- Comment #1 from Abe  ---
The file "incremental-marking.o" is compiled from the source code at "/src/heap/incremental-marking.cc".

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #5)
> BTW, Honza promised to implement a -fnull-this-pointer switch for this issue,
> because Firefox, Kdevelop, QT5, etc. are also affected.

Sounds like so many folks depends on this undefined behavior.  It is sad it was
not until GCC 6 people are finding this undefined behavior.  I rather have
people fix their code rather than changing GCC.

Since -fsantize=undefined will find it. There is no reason to have another flag
to disable the optimization.

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #12)
> They are actually aware of the issue for over a year:
> 
> https://bugs.chromium.org/p/v8/issues/detail?id=3782

That is sad and just means they don't care about their code being correct.

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
.

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

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Abe from comment #9)
> Created attachment 37309 [details]
> preprocessed part of V8
> 
> I will attach a compressed form of the relevant file --
> "incremental-marking.cc" from V8, preprocessed on AMD64 Ubuntu 14.04.3 LTS
> using GCC built from trunk revision 226861; analysis showed that
> preprocessing the same source on the same machine using GCC built from trunk
> revision 226860 produced the same preprocessor output modulo lines starting
> in '#'.

Yes this was the same bug.  I had forgot I had already debugged this and
reported what was wrong with the code.  Can you or someone please report this
back to google about their broken code.

[Bug target/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jan 12 00:30:30 2016
New Revision: 232249

URL: https://gcc.gnu.org/viewcvs?rev=232249=gcc=rev
Log:
Set FLT_EVAL_METHOD to 2 only if 387 FPU is used

When 387 FPU isn't used, there is no excess precision.  We should set
FLT_EVAL_METHOD to 2 only if 387 FPU is used.

gcc/

PR target/69225
* config/i386/i386.h (TARGET_FLT_EVAL_METHOD): Set to 2 only if
TARGET_80387 is true.

gcc/testsuite

PR target/69225
* gcc.target/i386/pr69225-1.c: New test.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69225-1.c
trunk/gcc/testsuite/gcc.target/i386/pr69225-2.c
trunk/gcc/testsuite/gcc.target/i386/pr69225-3.c
trunk/gcc/testsuite/gcc.target/i386/pr69225-4.c
trunk/gcc/testsuite/gcc.target/i386/pr69225-5.c
trunk/gcc/testsuite/gcc.target/i386/pr69225-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug target/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed.

[Bug c/68637] Array of function pointers with attribute leads to wrong code

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
Indeed, the parse appears to be correct (although there are various 
existing cases where an attribute gets automatically moved to apply to a 
type rather than to the original declaration to which it applies according 
to the parse).

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Abe from comment #9)
> > Created attachment 37309 [details]
> > preprocessed part of V8
> > 
> > I will attach a compressed form of the relevant file --
> > "incremental-marking.cc" from V8, preprocessed on AMD64 Ubuntu 14.04.3 LTS
> > using GCC built from trunk revision 226861; analysis showed that
> > preprocessing the same source on the same machine using GCC built from trunk
> > revision 226860 produced the same preprocessor output modulo lines starting
> > in '#'.
> 
> Yes this was the same bug.  I had forgot I had already debugged this and
> reported what was wrong with the code.  Can you or someone please report
> this back to google about their broken code.

They are actually aware of the issue for over a year:

https://bugs.chromium.org/p/v8/issues/detail?id=3782

[Bug middle-end/69234] New: recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

Bug ID: 69234
   Summary: recent GCC trunk compilers miscompile the V8
JavaScript interpreter/JITC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abe_skolnik at yahoo dot com
  Target Milestone: ---

Recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC such
that the compiled V8 [sans Chrome/Chromium] crashes when running the
included-with-V8 benchmarks.  Compiling the exact same V8 source code using GCC
5.2.0 or 5.3.0 results in correct execution.  We have tested execution on both
AMD64 [AKA "x86_64"] and AArch64 [AKA "ARM64"].  For the AMD64-targeting
compilers, the compiler was bootstrapped.  The AArch64-targeting compilers were
cross-compilers.

With lots of help from my teammate Kevin Hu, we have isolated that the first
commit that breaks V8 seems to be trunk Subversion r226861; GCC from trunk
r226860 compiles V8 such that it runs its own benchmarks OK.  [Please note that
the fork known as "Octane" of the V8 benchmarks was not used.]

We have determined that the location of the crash --
"IncrementalMarking::ActivateIncrementalWriteBarrier(NewSpace*)" -- is not
compiled any differently by the two different revisions of the compiler [at
least when targeting AMD64].  However, we _have_ been able to determine that
replacing only the object file containing that method --
"incremental-marking.o" -- and using that file while manually relinking the V8
build that was otherwise compiled with the earlier-revision compiler _does_
produce a crashing V8 "shell" program.  Therefor, logically, at least one
subroutine in this ".o" file was miscompiled.

The same crash has been found on AMD64 in r232207 from today [January 11 2016].

We are still working on reducing the test case further; we will post a smaller
test case later.



Steps to reproduce
--
* build GCC trunk r226860 for either AMD64 or AArch64

* build GCC trunk r226861 for either AMD64 or AArch64

* check out V8 version 4.9.274 from


* build V8 with GCC trunk r226860 using either "make x64.release" or "make
arm64.release",
  "cd" into "benchmarks", execute "../out//shell run.js"

* build V8 with GCC trunk r226861 using either "make x64.release" or "make
arm64.release",
  "cd" into "benchmarks", execute "../out//shell run.js"

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
dup.

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

[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[demoonlit at panathenaia dot halfmoon.jp]

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

--- Comment #2 from yuta tomino  ---
> Yes, remove the convention Intrinsic, it doesn't make any sense here or add 
> pragma Inline_Always on the nested subprogram as indicated.

I agree with your sense. The local subprograms would be optimized well without
the pragmas.
Of course, I did not write the code directly like described above.
Practically, I found this bug from some instantiations of the generic packages.

The real problem is that we can not use the pattern of Inline_Always and
Intrinsic, in writing any generic package, to reduce the code size for
instantiating it in the library-level, because of also allowing use of it in
the nested scope.

[Bug target/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Mon, 11 Jan 2016, kyukhin at gcc dot gnu.org wrote:

> BTW, for -std=gnu99 we have EXCESS_PRECISION_FAST engaged.
> This differs from -std=c99
> 
> If this correct behavior? I see no mentions of this difference w/ c99 in
> documentation. It only states that gnu99 is "C99 with GNU extensions"

Yes, it's intended and documented.  See the documentation for 
-fexcess-precision: "By default, @option{-fexcess-precision=fast} is in 
effect ... @option{-fexcess-precision=standard} ... is enabled by default 
for C if a strict conformance option such as @option{-std=c99} is used".

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This sounds like maybe a bug in the V8 sources.  Can you try
-fno-delete-null-pointer-checks ?

Also can you provide the preprocessed source which is being miscompiled?

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
BTW, Honza promised to implement a -fnull-this-pointer switch for this issue,
because Firefox, Kdevelop, QT5, etc. are also affected.

[Bug tree-optimization/69232] floop-unroll-and-jam, at graphite_transform_loops with isl

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed with 5.3.0. It seems fixed on trunk.

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

--- Comment #9 from Abe  ---
Created attachment 37309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37309=edit
preprocessed part of V8

I will attach a compressed form of the relevant file --
"incremental-marking.cc" from V8, preprocessed on AMD64 Ubuntu 14.04.3 LTS
using GCC built from trunk revision 226861; analysis showed that preprocessing
the same source on the same machine using GCC built from trunk revision 226860
produced the same preprocessor output modulo lines starting in '#'.

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
*** Bug 69234 has been marked as a duplicate of this bug. ***

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[kugan at gcc dot gnu.org]

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

--- Comment #2 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Tue Jan 12 00:40:54 2016
New Revision: 232251

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

2016-01-12  Kugan Vivekanandarajah  
Jim Wilson  

PR target/69194
* config/arm/arm-builtins.c (arm_expand_neon_args): Call
copy_to_mode_reg instead of force_reg.

gcc/testsuite/ChangeLog:

2016-01-12  Kugan Vivekanandarajah  
Jim Wilson  

PR target/69194
* gcc.target/arm/pr69194.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr69194.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org ---
In 4.6, parloops failed to parallelize because in find_data_references_in_stmt
we had:
...
  /* FIXME -- data dependence analysis does not work correctly for objects
 with invariant addresses in loop nests.  Let us fail here until the
 problem is fixed.  */
  if (dr_address_invariant_p (dr) && nest)
{
  free_data_ref (dr);
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "\tFAILED as dr address is invariant\n");
  ret = false;
  break;
}
...

That FIXME was removed in the fix for PR46787, at r175704.

[Bug c/23087] Misleading warning, "... differ in signedness"

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com  ---
Well, an additional

note: 'char' and 'signed char' are different types

(or similar in the unsigned case) could be added in the case where the 
types have the same representation, one is char and the other is signed or 
unsigned char.  Or the wording of the original warning could be refined in 
that case.  But I don't think the less-specific wording about incompatible 
types would be appropriate here, or that the warning should be enabled 
more widely than the general signedness case (if anything, this case is 
less serious than that one).

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
In that case, I guess the questions are:
1) does -fno-delete-null-pointer-checks cure the crash?
2) do any of the functions/methods defined in the problematic file have
nonnull attribute?
3) can you try to compile it with -fsanitize=undefined and see if errors are
reported on it?

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

Abe  changed:

   What|Removed |Added

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

--- Comment #8 from Abe  ---
Attaching the preprocessed source, compressed b/c it`s big...

FYI, I _did_ try searching for "V8" before submitting the bug.  The search
engine found nothing relevant.  It did _not_, for example, find bug #68853  :-(

[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[demoonlit at panathenaia dot halfmoon.jp]

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

yuta tomino  changed:

   What|Removed |Added

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

--- Comment #3 from yuta tomino  ---
In addition, even if it should be an error, I think that the proper error
message should be reported instead of the  error.

[Bug c/23087] Misleading warning, "... differ in signedness"

[Keith.S.Thompson at gmail dot com]

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

--- Comment #17 from Keith Thompson  ---
I just took a quick look at the discussion on the gcc-patches mailing
list.

It's true that the standard doesn't classify plain "char" either as a
signed integer type or as an unsigned integer type.

But I think that 99% of users think of plain "char" as either signed
or unsigned, not some third kind of signedness. If plain "char" has the
same range as "signed char", saying that they "differ in signedness" is
just confusing.  (Even to me, and I read ISO language standards for fun.)

And really, the signedness is not the issue.  The issue is that they're
incompatible types.

I'll also note the documentation of the "-fsigned-char" option:

Let the type 'char' be signed, like 'signed char'.

It's difficult to tell uses that plain char is not signed when gcc's
own documentation says it is.

I understand that you might not want to warn about assigning a "signed
char*" value to a "char* object in the same circumstances where you'd warn
about assigning an "int*" to a "long*".  (Both are constraint violations,
but that's another kettle of fish.)

Perhaps char* vs. signed char* or char* vs. unsigned char* needs to be
treated as a special case. But I still say that the existing warning is
misleading and at least needs to be rephrased.

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||abe_skolnik at yahoo dot com

--- Comment #10 from Markus Trippelsdorf  ---
*** Bug 69234 has been marked as a duplicate of this bug. ***

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
At least the issue should be mentioned either in changes.html or
porting_to.html.

[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
  Known to work||4.8.5
   Target Milestone|--- |4.9.4
Summary|ICE (segfault) at -Os on|[4.9/5/6 Regression] ICE
   |x86_64-linux-gnu in |(segfault) at -Os on
   |"fail_abnormal_edge_coalesc |x86_64-linux-gnu in
   |e"  |"fail_abnormal_edge_coalesc
   ||e"
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.3.0, 6.0

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

[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vries at gcc dot gnu.org ---
patch with test-case committed, marking resolved-fixed.

[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The SSA _1 doesn't have a def stmt ...

int main() ()
{
  bool a_lsm.9;
  int a_lsm.8;
  bool b_lsm.7;
  int b_lsm.6;
  unsigned int _1;
  unsigned int _3;
  int _7;
  int a.0_9;

  :
  a.0_9 = a;
  if (a.0_9 >= 0)
goto ;
  else
goto ;

  :
  b_lsm.6_12 = b;

  :
  # b_lsm.6_6 = PHI 
  _7 = b_lsm.6_6 + 1;
  b_lsm.6_14 = (int) _1;
  if (b_lsm.6_14 >= 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  # a_lsm.8_22 = PHI 
  # b_lsm.6_24 = PHI <_7(4)>
  b = b_lsm.6_24;
  a = a_lsm.8_22;

  :
  return 0;

already broken in IVOPTs.

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> Seems there is a mismatch in between fold_convertible_p and
> verify_gimple_assign_unary (and also the gimplifier).
> E.g. for this special case fold_convertible_p has some weird exception:
> 2188return (TREE_CODE (orig) == VECTOR_TYPE
> 2189&& tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE 
> (orig)));
> But verify_gimple_assign_unary certainly doesn't allow that.  It has also
> various other restrictions, e.g. on pointer conversions etc.
> So, Richard, do we or should we have another predicate that says for outer
> and inner type if it is ok to use GIMPLE_ASSIGN with NOP_EXPR?
> Most of the uses that use fold_convertible_p in the middle-end actually
> perform fold_convert or fold_build1 (... NOP_EXPR, ...), which creates a
> NOP_EXPR from the VECTOR_TYPE to same sized integral type.

But that's invalid.  fold_convert does

case VECTOR_TYPE:
  if (integer_zerop (arg))
return build_zero_vector (type);
  gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
  gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
  || TREE_CODE (orig) == VECTOR_TYPE);
  return fold_build1_loc (loc, VIEW_CONVERT_EXPR, type, arg);

thus always creates a VCE.

Note that fold_build1 (... NOP_EXPR ...) is _not_ equivalent to
fold_convert (...)!

>  Strangely, when
> trying to gimplify that it just creates a NOP_EXPR GIMPLE_ASSIGN, which then
> fails verification.
> So, what is the above mentioned 2188/2189 there for and corresponding
> fold_convert_loc:
> 2246gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
> 2247&& tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE 
> (orig)));
> 2248return fold_build1_loc (loc, NOP_EXPR, type, arg);
> Shall it not create a VCE instead?
> Or shall it at least not gimplify to a VCE instead of a NOP_EXPR?
> For the tree-vect-slp.c case it is of course enough to just replace
> fold_convertible_p with INTEGRAL_TYPE_P && INTEGRAL_TYPE_P check, but I
> really think we should figure out what we want and have proper predicates
> for it.

I think on gimple we can't simply use fold_convertible_p because that has
special handling for a lot of cases where it doesn't end up generating
a NOP_EXPR.  That is, if fold_convertible_p you can call fold_convert
without ICEing, you can't just build a NOP_EXPR gimple assign.

[Bug tree-optimization/69196] code size regression with jump threading at -O2

[sebastian.hu...@embedded-brains.de]

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

--- Comment #4 from Sebastian Huber  ---
I did a very rough check to see which code is faster on the PSIM/GDB simulator
using the following input data:

void printk(const char *fmt, ...)
{
  va_list ap;

  va_start(ap, fmt);
  vprintk(fmt, ap);
  va_end(ap);
}

void test(void)
{
  char *s = "x";
  printk("abc%sx%ix%cx%lu\n", s, 0, 'c', 1UL);
}

GCC 4.9: 311 time units

GCC 6: 316 time units

I guess its quite difficult to determine if this target independent code size
increase is actually a regression in general.  At least in this particular
function with this particular input data on this particular target/simulator
the code size is nearly doubled and the execution is slightly slower.

[Bug c++/69222] [5/6 Regression] C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||5.1.0
   Target Milestone|--- |5.4
Summary|C++14 template code working |[5/6 Regression] C++14
   |in GCC 5.1 stops working in |template code working in
   |5.2 and 5.3 |GCC 5.1 stops working in
   ||5.2 and 5.3
  Known to fail||5.2.0

[Bug tree-optimization/69209] [6 Regression] ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Unless I'm misreading ipa-split.c, it seems it is unprepared to see addressable
retvals with gimple reg type, but where due to the addressability retval is not
is_gimple_val.  Unfortunately, it doesn't seem to be just a single spot, but
tons of them.  I'm afraid with right testcases we could end up e.g. with
addressable int var on the lhs of a call, or as base of a MEM, etc.  Richard,
can you please have a look?

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

[y.gribov at samsung dot com]

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

--- Comment #5 from Yury Gribov  ---
Martin, is this better now? Could you close the bug?

[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jan 11 09:19:33 2016
New Revision: 232211

URL: https://gcc.gnu.org/viewcvs?rev=232211=gcc=rev
Log:
Handle case that outer phi res is not used in a phi in gather_scalar_reductions

2016-01-11  Tom de Vries  

PR tree-optimization/69108
* tree-parloops.c (gather_scalar_reductions): Handle case that outer
phi
res is not used in a phi.

* gcc.dg/autopar/pr69108.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr69108.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug rtl-optimization/69217] [6 Regression] ICE at var-tracking.c:5038 Segmentation fault

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-11
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
> While I should get round to fixing the gimplify stage to conform, I think
> the middle-end should do something other than SEGV when this happens.
> 
> e.g:
> 
>   if (TYPE_FIELDS (type) == NULL_TREE
>   || DECL_CHAIN (TYPE_FIELDS (type)) == NULL_TREE)
> return false;

Yes, that's the correct thing to do, please test it and post the patch on the
gcc-patches@ list once done.

[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk

[jamborm at gcc dot gnu.org]

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

--- Comment #21 from Martin Jambor  ---
Author: jamborm
Date: Mon Jan 11 10:03:44 2016
New Revision: 232214

URL: https://gcc.gnu.org/viewcvs?rev=232214=gcc=rev
Log:
[PR ipa/66616] Copy can_change_signature flag to artificial thunks

2016-01-11  Martin Jambor  

PR ipa/66616
* cgraphclones.c (duplicate_thunk_for_node): Copy can_change_signature
flag.


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

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[aoliva at gcc dot gnu.org]

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

--- Comment #16 from Alexandre Oliva  ---
Author: aoliva
Date: Mon Jan 11 10:40:12 2016
New Revision: 232217

URL: https://gcc.gnu.org/viewcvs?rev=232217=gcc=rev
Log:
[PR69123] make dataflow_set_different details more verbose

for  gcc/ChangeLog

PR bootstrap/69123
* var-tracking.c (dump_onepart_variable_differences): New.
(dataflow_set_different): If a detailed dump is requested,
delay early returns and dump differences between onepart
variables present before and after, and added variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[aoliva at gcc dot gnu.org]

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

--- Comment #17 from Alexandre Oliva  ---
Author: aoliva
Date: Mon Jan 11 10:40:33 2016
New Revision: 232218

URL: https://gcc.gnu.org/viewcvs?rev=232218=gcc=rev
Log:
[PR69123] fix handling of MEMs in VTA to avoid dataflow oscillation

The problem arises because we used to drop overwritten MEMs from loc
lists of VALUEs, but not of other onepart variables, and it just so
happens that, by doing so, block 6 in the testcase has no D#5 in its
output in the first pass, because the MEM holding its (previous) value
was correctly dropped from value 88:88, but gains it in the second
pass because D#5 has the MEM location incoming directly in its loc
list, rather than indirectly in a VALUE.

This incorrect binding enables other blocks to believe they have a
tentative binding for D#5 in some cycles, but others, still operating
on the early conclusion, believe there isn't, and they oscillate from
that.

Since we check for escaping MEMs in clobbers, we won't lose anything
relevant by dropping call-clobbered or overwritten MEMs in all onepart
variables, and this ensures the loc intersection operation in onepart
vars won't let a MEM through that wasn't present in earlier
iterations.

for  gcc/ChangeLog

PR bootstrap/69123
* var-tracking.c (drop_overlapping_mem_locs): Operate on all
onepart vars.  Fix typo in comment.  Fix reversed condition in
unshare test.
(dataflow_set_remove_mem_locs): Operate on all onepart vars.

for gcc/testsuite/ChangeLog

PR bootstrap/69123
* g++.dg/pr69123.C: New.

Added:
trunk/gcc/testsuite/g++.dg/pr69123.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

[ygribov at gcc dot gnu.org]

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

--- Comment #4 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Mon Jan 11 09:11:11 2016
New Revision: 232210

URL: https://gcc.gnu.org/viewcvs?rev=232210=gcc=rev
Log:
Backport fix docs for -frandom-seed.

2016-01-11  Yury Gribov  

Backport from mainline
2016-01-11  Yury Gribov  

PR 67425
* common.opt (frandom-seed): Fix parameter name.
* doc/invoke.texi (frandom-seed): Ditto and describe parameter.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/common.opt
branches/gcc-5-branch/gcc/doc/invoke.texi

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #4 from vries at gcc dot gnu.org ---
Patch committed.

Could be nice to have a go testcase, but haven't figured out how to do that
yet.

Marking resolved-fixed.

[Bug ipa/68981] [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Maybe a warning that becomes an error with -pedantic[-errors] or at least
accept this with -fpermissive.  FWIW I agree it's a bit harsh by default.

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
Isn't it a gccgo front end (spec) bug, that it doesn't bring in GOMP stuff
(builtins, link against libgomp) under the presence of
"-ftree-parallelize-loops=2"?  Cf. gcc/gcc.c:GOMP_SELF_SPECS.

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
It's my change, I will look into it.

[Bug target/69010] Boolean vector constant with a scalar mode is expanded incorrectly

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #2 from Ilya Enkovich  ---
Fixed

[Bug target/69225] New: gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

[vaalfreja at gmail dot com]

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

Bug ID: 69225
   Summary: gcc uses double precision instead of single float with
-m32 -std=c99 -msoft-float
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vaalfreja at gmail dot com
  Target Milestone: ---

Testcase:
int main(){
float x, y, z;
z = x+y;
return 0;
}

Soft float first extends the result to double precision then truncates it.

[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org,
   ||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
Cc Max.

[Bug c++/69216] posix_memalign

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please provide information on the GCC version you are using as well as
preprocessed source.

[Bug tree-optimization/69109] [6 Regression] missing phi argument ICE in transform_to_exit_first_loop_alt with -O2 -funswitch-loops -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from vries at gcc dot gnu.org ---
patch with test-cases committed, marking resolved-fixed.

[Bug libstdc++/69190] FAIL: experimental/type_erased_allocator/uses_allocator.cc

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
It is indeed. Thanks

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jan 11 08:55:16 2016
New Revision: 232208

URL: https://gcc.gnu.org/viewcvs?rev=232208=gcc=rev
Log:
Don't parallelize loops if libgomp not supported

2016-01-11  Tom de Vries  

PR tree-optimization/69058
* tree-parloops.c (pass_parallelize_loops::execute): Return 0 if
libgomp
not supported.

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

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Yes, that should do.

/* PR target/69187 */
/* { dg-do compile } */
/* { dg-require-effective-target arm_neon }  */
/* { dg-options "-O0" }  */
/* { dg-add-options arm_neon }  */

Please send the patch to gcc-patc...@gcc.gnu.org

[Bug tree-optimization/69109] [6 Regression] missing phi argument ICE in transform_to_exit_first_loop_alt with -O2 -funswitch-loops -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jan 11 09:38:28 2016
New Revision: 232212

URL: https://gcc.gnu.org/viewcvs?rev=232212=gcc=rev
Log:
Don't allow latch with phi in try_transform_to_exit_first_loop_alt

2016-01-11  Tom de Vries  

PR tree-optimization/69109
* tree-parloops.c (try_transform_to_exit_first_loop_alt): Don't allow
latch with phi.

* gcc.dg/autopar/pr69109-2.c: New test.
* gcc.dg/autopar/pr69109.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr69109-2.c
trunk/gcc/testsuite/gcc.dg/autopar/pr69109.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug tree-optimization/69209] [6 Regression] ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||hubicka at gcc dot gnu.org
 Blocks||68721
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Hmpf.  I hate IPA split.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68721
[Bug 68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[Bug target/69199] Incorrect prototypes for AVX512 unaligned load/store builtin functions

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
OTOH it doesn't really matter to the middle-end.

[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk

[jamborm at gcc dot gnu.org]

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

--- Comment #20 from Martin Jambor  ---
Author: jamborm
Date: Mon Jan 11 09:59:48 2016
New Revision: 232213

URL: https://gcc.gnu.org/viewcvs?rev=232213=gcc=rev
Log:
[PR 66616] Check for thunks when adding extra constants to clones

2016-01-11  Martin Jambor  

PR ipa/66616
* ipa-cp.c (propagate_constants_accross_call): Move thuk check...
(call_passes_through_thunk_p): ...here.
(find_more_scalar_values_for_callers_subset): Perform thunk checks
like propagate_constants_accross_call does.
* cgraphclones.c (duplicate_thunk_for_node): Copy can_change_signature
flag from the node to the new flag.

testsuite/
* g++.dg/ipa/pr66616.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr66616.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cgraphclones.c
branches/gcc-4_9-branch/gcc/ipa-cp.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/59810] [AArch64] LDn/STn implementations are not ABI-conformant for bigendian.

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-11
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from James Greenhalgh  ---
I believe this is now fixed?

[Bug target/65770] [AArch64] vst2_lane broken on bigendian

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
r222582 for reference.

[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Richard Biener from comment #2)
> > I think we have a dup/related bug where we run into the issue that
> > tree-complex.c
> > wrecks SSA form during its rewrite.
> 
> That is indeed what happens, but what solution do you see other than
> avoiding all the simplifications/optimizations that follow ssa edges?

In the other bug we discussed to do the processing in proper (dominator)
order.  Richard, any progress on that?

> We have:
> :
> # a_22 = PHI 
> # b_23 = PHI 
> # a$real_28 = PHI 
> # a$imag_29 = PHI 
> # b$real_32 = PHI 
> # b$imag_33 = PHI 
> _9 = __complex__ (1.0e+0, 0.0) / a_22;
> b_10 = b_23 - _9;
> a_11 = a_22 + __complex__ (1.0e+0, 0.0);
> _8 = REALPART_EXPR ;
> if (_8 < 1.0e+1)
>   goto ;
> else
>   goto ;
> 
> While we could avoid the crash on lowering the division by handling it last,
> e.g. the addition has a loop of dependencies, so either we create a PHI
> first, but then don't have definitions for its arguments, or we lower the +
> first, but then we don't have definition for the PHI.  We can't create all
> the statements in a transaction together.
> Do you suggest we set some temporary SSA_NAME_DEF_STMTs for the SSA_NAMEs we
> create and we don't have a real definition yet (say GIMPLE_NOP)?

No, that's somewhat gross and I like to avoid that.

> Wouldn't some simplification attempt to optimize it as uninitialized?
> Or stop using gimple_build* and revert to constructing it using builders
> that don't actually fold anything or try to optimize anything, and when we
> have everything fold all newly added statements?

tree-complex.c doesn't use gimple_build but gimplify_build which simply
uses fold_buildN.  The issue is that the new enhanced predicates
unconditionally
walk SSA ... (even if the match-and-simplify machinery is instructed not to
do that which it doesn't for GENERIC anyway)

[Bug middle-end/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #1 from Uroš Bizjak  ---
Not a target issue, this is what middle-end gives us with -std=c99, even for:

float test (float a, float b)
{
  return a + b;
}

~/gcc-build/gcc/cc1 -O2 -m32 -std=c99 -msoft-float -fdump-tree-optimized

float.c.208t.optimized:

;; Function test (test, funcdef_no=0, decl_uid=1275, cgraph_uid=0,
symbol_order=0)

test (float a, float b)
{
  long double _2;
  long double _4;
  long double _5;
  float _6;

  :
  _2 = (long double) a_1(D);
  _4 = (long double) b_3(D);
  _5 = _2 + _4;
  _6 = (float) _5;
  return _6;

}

Without -std=c99, we get:

;; Function test (test, funcdef_no=0, decl_uid=1405, cgraph_uid=0,
symbol_order=0)

test (float a, float b)
{
  float _3;

  :
  _3 = a_1(D) + b_2(D);
  return _3;

}

[Bug c++/69220] Internal error with array of negative size and initializers for it

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
  Known to work||6.0
 Ever confirmed|0   |1
  Known to fail||5.3.0

--- Comment #1 from Richard Biener  ---
On trunk:

> /abuild/rguenther/trunk3-g/gcc/cc1plus -quiet t.C -std=c++11t.C: In function 
> ‘int main()’:
t.C:3:28: error: size of array is negative
  int* p = new int[-1]{1};
^

confirmed for GCC 5 where it loops in

#0  process_init_constructor_array (type=0x769e3bd0, init=0x769ebee8, 
complain=3) at /space/rguenther/src/svn/gcc-5-branch/gcc/cp/typeck2.c:1295

1291for (; i < len; ++i)

(gdb) p len
$2 = 18446744073709551615
(gdb) p i
$3 = 271414772


I suspect that

  int *p = new int[184467440737095LL]{1};

might also take quite some time due to the loop not exiting early.

[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.4

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Seems the identical bug in aarch64 backend has been fixed with r221807.
The patch needs proper ChangeLog entry and the testcase added into the
testsuite too. Perhaps just grab the testcase from PR65624, and stick it into
testsuite/gcc.target/arm/
with
/* PR target/69187 */
/* { dg-require-effective-target arm_neon }  */
/* { dg-options "-O0" }  */
/* { dg-add-options arm_neon }  */
or so?

[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Mon Jan 11 10:09:17 2016
New Revision: 232215

URL: https://gcc.gnu.org/viewcvs?rev=232215=gcc=rev
Log:
[PR ipa/69044] Do not clone for param removal when not possible

2016-01-11  Martin Jambor  

PR ipa/69044
* ipa-cp.c (estimate_local_effects): Do not clone for removal of
useless parameters if we cannot change function signature.

testsuite/
* gcc.target/i386/chkp-pr69044.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/chkp-pr69044.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69211] [6 Regression] g++ ICE on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r230365.  I'll have a look.

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

[ygribov at gcc dot gnu.org]

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

--- Comment #3 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Mon Jan 11 09:06:14 2016
New Revision: 232209

URL: https://gcc.gnu.org/viewcvs?rev=232209=gcc=rev
Log:
Fix docs for -frandom-seed.

2016-01-11  Yury Gribov  

PR 67425
* common.opt (frandom-seed): Fix parameter name.
* doc/invoke.texi (frandom-seed): Ditto and describe parameter.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi

[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
*** Bug 69212 has been marked as a duplicate of this bug. ***

[Bug middle-end/69212] [6 Regresion] g++ ICE (segfault) at -O3 on x86_64-linux-gnu in fsm_find_control_statement_thread_paths

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Essentially a dup - SSA name without def stmt.

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

[Bug c/69224] -Warray-bounds false positive with -O3 and struct pointer parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
If you comment the line x is a trailing array we don't know its size for and
thus
we don't warn.

As with (many?) other cases this happens because complete peeling added one
copy too much (too conservative number of iteration upper bound):

  _72 = s_47->x[4];
  if (_39 >= _72)
goto ;
  else
goto ;

  :
  _74 = s_47->x[5];
  if (_39 <= _74)
goto ;
  else
goto ;

so we have a x[5] in the IL and VRP can't prove it is not reachable either
(obviously).

niter analysis does:

Statement _22 = s_7(D)->x[j_2];
 is executed at most 4 (bounded by 4) + 1 times in loop 2.

Statement _25 = s_7(D)->x[_24];
 is executed at most 3 (bounded by 3) + 1 times in loop 2.

Loop 2 iterates at most 5 times.

t.c:16:33: note: loop with 6 iterations completely unrolled
Latch of last iteration was marked by __builtin_unreachable ().
Forced statement unreachable: _25 = s_7(D)->x[_24];
Forced statement unreachable: _22 = s_7(D)->x[j_2];

it looks like the conditionally read s->x[j] is not properly marked
unreachable.

[Bug c++/69222] [5/6 Regression] C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is PR 69005 which I still have a pending patch for, in addition to Jason's
front-end change.

[Bug target/65770] [AArch64] vst2_lane broken on bigendian

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #1 from James Greenhalgh  ---
Looks to be fixed.

[Bug target/68986] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-11
 Ever confirmed|0   |1

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

[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Fixed with https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00445.html

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #5)
> Isn't it a gccgo front end (spec) bug, that it doesn't bring in GOMP stuff
> (builtins, link against libgomp) under the presence of
> "-ftree-parallelize-loops=2"?  Cf. gcc/gcc.c:GOMP_SELF_SPECS.

Making parloops robust against missing libgomp support is a conservative fix
for the ICE, and appropriate for stage3.

Enabling parloops for go could be a stage1 effort. But (having no go knowledge
whatsoever) I cannot exclude the possibility that the libgomp support is
missing intentionally.

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #18 from Alexandre Oliva  ---
Fixed

[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from Maxim Ostapenko  ---
Dominique, could you please run ASan tests with
ASAN_OPTIONS=debug=1:verbosity=2? This might be helpful for further debugging.

[Bug rtl-optimization/69217] [6 Regression] ICE at var-tracking.c:5038 Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||ebotcazou at gcc dot gnu.org
  Component|middle-end  |rtl-optimization
   Target Milestone|--- |6.0
Summary|ICE at var-tracking.c:5038  |[6 Regression] ICE at
   |Segmentation fault  |var-tracking.c:5038
   ||Segmentation fault

[Bug target/69010] Boolean vector constant with a scalar mode is expanded incorrectly

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Jan 11 10:27:17 2016
New Revision: 232216

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

PR target/69010
* expr.c (expand_expr_real_1): For boolean vector constants
with a scalar mode use const_scalar_mask_from_tree.
(const_scalar_mask_from_tree): New.
* optabs.c (expand_vec_cond_mask_expr): Use mask mode
assigned to a mask type to handle constants.

gcc/testsuite/

PR target/69010
* gcc.target/i386/pr69010.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69010.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|rtl-optimization|target
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #17 from ktkachov at gcc dot gnu.org ---
target issue then.

[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Introduced in vrp1.  I'll have a look.

[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin1*   |x86_64-apple-darwin1*
   |hppa*-*-hpux*   |
   Host|x86_64-apple-darwin1*   |x86_64-apple-darwin1*
   |hppa*-*-hpux*   |
  Build|x86_64-apple-darwin1*   |x86_64-apple-darwin1*
   |hppa*-*-hpux*   |

--- Comment #12 from John David Anglin  ---
Fixed on hppa*-*-hpux*.

[Bug c++/69235] New: [concepts] Spurious ambiguous template instantiation error on oppositely constrained class template specializations

[tom at honermann dot net]

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

Bug ID: 69235
   Summary: [concepts] Spurious ambiguous template instantiation
error on oppositely constrained class template
specializations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
  Target Milestone: ---

I believe the following test case is well-formed, but gcc trunk (r232017) emits
an "ambiguous template instantiation" error for the X specialization.  The
ambiguity arises from the oppositely constrained partial specializations of
template class X.  Since the partial specializations are oppositely
constrained, an ambiguity should not be possible.

The test case exhibits some fragility.  The error only occurs when the requires
expression in the C concept definition specifies a constrained-type-specifer as
the trailing-return-type of the compound-requirement at #3; substituting a
non-placeholder simple-type-specifier as is done at #2 by compiling with the
AVOID_BOOLEAN_CONCEPT macro defined enables successful compilation.

Additionally, compilation is successful (with or without AVOID_BOOLEAN_CONCEPT
defined) if the code is adjusted at #6 to pass a fundamental type (char)
instead of S as the template argument to X, and at #4 and #5 to pass T rather
than the member type T::type in the requires clause.

$ cat t.cpp
template
concept bool
Boolean()
{
  return requires(T t)
  {
{ t } -> bool // #1
  };
}

template
concept bool
C() {
  return requires (T t)
  {
#if AVOID_BOOLEAN_CONCEPT
{ t } -> bool;// #2
#else
{ t } -> Boolean; // #3
#endif
  };
}

template
struct X;
template
requires ! C()  // #4
struct X {
using type = int;
};
template
requires C()// #5
struct X {
using type = int;
};

struct S {
using type = char;
};

void f() {
X::type x; // #6
}

$ svn info   # From my local svn gcc repo.
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 232017
Node Kind: directory
Schedule: normal
Last Changed Author: nathan
Last Changed Rev: 232017
Last Changed Date: 2015-12-31 09:07:52 -0500 (Thu, 31 Dec 2015)

# Using the gcc version above, the error is produced:
$ g++ -c -std=c++1z t.cpp
t.cpp: In function ‘void f()’:
t.cpp:42:9: error: ambiguous template instantiation for ‘struct X’
 X::type x;
 ^~

t.cpp:28:8: note: candidates are: template  requires
predicate(!(C)()) struct X [with T = S]
 struct X {
^~~~

t.cpp:33:8: note: template  requires
predicate((C)()) struct X [with T = S]
 struct X {
^~~~

t.cpp:42:5: error: incomplete type ‘X’ used in nested name specifier
 X::type x;
 ^~~~

# Compiling with AVOID_BOOLEAN_CONCEPT defined avoids the spurious error:
$ g++ -c -std=c++1z t.cpp -DAVOID_BOOLEAN_CONCEPT; echo $?
0

[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
> In addition, even if it should be an error, I think that the proper error
> message should be reported instead of the  error.

"built-in" is because you use Intrinsic!  In any case, the rule of thumb is to
never use pragma Inline_Always with anything except for very small subprograms.

[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin  ---
Author: danglin
Date: Tue Jan 12 02:06:20 2016
New Revision: 232256

URL: https://gcc.gnu.org/viewcvs?rev=232256=gcc=rev
Log:
PR tree-optimization/68356
* gcc.dg/torture/pr68264.c: Disable exp2 ERANGE test on hppa unix.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr68264.c

[Bug testsuite/69007] [6 regression] test cases gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with r231815

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
I just tried the experiment with swapping the two patterns, and it does indeed
solve the problem.

[Bug c++/69158] [6 Regression] ICE in in cxx_eval_indirect_ref, at cp/constexpr.c:2598

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
> It will become to be compiled if I replace pragma Inline_Always to normal
> Inline or remove pragma Convention.

Yes, remove the convention Intrinsic, it doesn't make any sense here or add
pragma Inline_Always on the nested subprogram as indicated.

[Bug middle-end/69230] false -Wmaybe-uninitialized with -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|valid -Wmaybe-uninitialized |false -Wmaybe-uninitialized
   |suppressed by -O2   |with -O1

--- Comment #3 from Andrew Pinski  ---
This new testcase is still broken as i & 3 is 0, 1, 2 or 3.  All of the case
statements are there too.  So if you want to say something the bug is in -O1
which should not warn instead.

But that requires VRP which is what figures out i & 3 to have a range of [0,3]
and that only runs at -O2.

There is still no bug for -O2 here.  GCC is correct those j is initialized on
all paths.

[Bug libgcc/69233] New: fixtfti returns bad value for TI overflow

[munroesj at us dot ibm.com]

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

Bug ID: 69233
   Summary: fixtfti returns bad value for TI overflow
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at us dot ibm.com
  Target Milestone: ---

When converting IBM long double to __int128, large values that overflow are not
returning the expected values.

To be consistent with double to long conversions the conversion to __int128
should return saturated values and set Invalid Integer Convert (VXCVI)
floating-point exception.

For a large positive long double ( > 170141183460469231731687303715884105727.L)
I would expect 0x7fff (largest positive __int128)
but __fixtfti returns 0x

For large negative long double I would expect
0x8000 (largest negative __int128) but __fixtfti
returns 001 or other small positive values.

[Bug target/48344] powerpc ICE with -fstack-limit-register=r2

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #4 from David Edelsohn  ---
The ICE appears to be the missing mode on r2, but I thought that the SET would
be generated by -fstack-limit-register common code.

However, r2 is a fixed register for SVR4 ABI, so the specific choice of r2
seems strange. The user specifically wants a fixed register and knows that it
will not be used for GOT access in this specific use case?

[Bug libgcc/69233] fixtfti returns bad value for TI overflow

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
It is unspecified what the value of an overflow conversion is.  So 1 is correct
so is -1 and/or INT_MAX.

I don't think this is a bug.

The test code which depends on these values is broken and should not be used.

I know some "C validation" suites which have this bug for float/double also (I
put "C validation" is quotes because they are not validating C at that point
but rather an specific implementation of C).

[Bug libgcc/69233] fixtfti returns bad value for TI overflow

[munroesj at us dot ibm.com]

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

--- Comment #2 from Steven Munroe  ---
Well the language spec may not specify. But I can ask the platform to be
consistent with itself. For PowerISA I would expect long double -> __int128 to
be consistent with double -> long, which saturates (INT_MAX).

Also the current fixtfti implementation is very slow.

So while this may not be a general GCC (libgcc) bug. I don't think anyone would
mind if the PowerPC platform optimized this function and made its behavour
consistent with the PowerISA.

[Bug c++/69131] [4.9/5/6 Regression] default constructor of union incorrectly deleted

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jan 11 20:53:07 2016
New Revision: 232243

URL: https://gcc.gnu.org/viewcvs?rev=232243=gcc=rev
Log:
PR c++/69131
* method.c (walk_field_subobs): Add dtor_from_ctor parm.
(process_subob_fn): Likewise.  Don't consider triviality if true.
(synthesize_method_walk): Pass it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/union7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug middle-end/69230] false -Wmaybe-uninitialized with -O1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
My bad.  I confused the decimal 3 for a binary 111.  Gcc does warn both ways
when the controlling expression is (i & 7) so the problem is the other way
around.  Thanks for the correction.  I suppose this really is invalid since the
GCC manual notes the -O1 caveat for a similar case, and glibc should either not
be built with -Wmaybe-uninitialized and -O1 or it should add a default case to
the switch.

[Bug tree-optimization/69069] missing phi argument with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Jan 11 12:08:38 2016
New Revision: 232221

URL: https://gcc.gnu.org/viewcvs?rev=232221=gcc=rev
Log:
Add missing phi args in create_parallel_loop

2016-01-11  Tom de Vries  

PR tree-optimization/69069
* tree-parloops.c (create_parallel_loop): Add missing phi args.

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

[Bug target/69053] [6 Regression] ICE in build_vector_from_val

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #6 from Richard Biener  ---
Certainly bougs though.  The following works for me - can you test that?

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 232213)
+++ gcc/tree-vect-loop.c(working copy)
@@ -4063,10 +4075,10 @@ get_initial_def_for_reduction (gimple *s
   tree *elts;
   int i;
   bool nested_in_vect_loop = false;
-  tree init_value;
   REAL_VALUE_TYPE real_init_val = dconst0;
   int int_init_val = 0;
   gimple *def_stmt = NULL;
+  gimple_seq stmts = NULL;

   gcc_assert (vectype);
   nunits = TYPE_VECTOR_SUBPARTS (vectype);
@@ -4095,16 +4107,6 @@ get_initial_def_for_reduction (gimple *s
   return vect_create_destination_var (init_val, vectype);
 }

-  if (TREE_CONSTANT (init_val))
-{
-  if (SCALAR_FLOAT_TYPE_P (scalar_type))
-init_value = build_real (scalar_type, TREE_REAL_CST (init_val));
-  else
-init_value = build_int_cst (scalar_type, TREE_INT_CST_LOW (init_val));
-}
-  else
-init_value = init_val;
-
   switch (code)
 {
   case WIDEN_SUM_EXPR:
@@ -4181,7 +4183,10 @@ get_initial_def_for_reduction (gimple *s
break;
  }
  }
-   init_def = build_vector_from_val (vectype, init_value);
+   init_val = gimple_convert (, TREE_TYPE (vectype), init_val);
+   if (! gimple_seq_empty_p (stmts))
+ gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts);
+   init_def = build_vector_from_val (vectype, init_val);
break;

   default:

[Bug target/69227] FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors)

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Relevant thread on gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00586.html

[Bug target/64782] -mcpu=native should be supported on aarch64

[ktkachov at gcc dot gnu.org]

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

Bug 64784 Summary: -march=native should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64784

   What|Removed |Added

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