[Bug c++/70521] [C++14] nonempty constexpr noexcept constructor rejected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This got fixed on the trunk (for 6.1) with r233514 aka PR65985 and
on the 5 branch with r233812.

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #7)
> -   if (sel & (1 << UINTVAL (j)))
> +   if (sel & (HOST_WIDE_INT_1U << UINTVAL (j)))
> 
> change in simplify-rtx.c is preapproved, but it would be nice to have a
> testcase.

Note I haven't succeeded with creating a testcase for this.
To trigger that one needs a problematic VEC_MERGE inside of VEC_SELECT,
and most of the VEC_SELECTS have VEC_CONCAT as their first operand, the
exception
are e.g. broadcasts, but following doesn't trigger it anyway:
#include 

__v64qi
f1 (__m512i a, __m512i b)
{
  __v64qi c = (__v64qi) _mm512_mask_blend_epi8 (0x1234ULL, a, b);
  __v64qi d = (__v64qi) { 0 };
  return __builtin_shuffle (c, d);
}

So it is likely just a theoretical fix for now.

[Bug c++/70507] integer overflow builtins not constant expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
For GCC's own instrumentation you should obviously not use these builtins, but
the corresponding internal functions, otherwise you take address of something
that doesn't need to be addressable.

Whether we want to mark the builtins as constexpr is for us to decide,
I bet as they are storing to what the last argument points to, it could be only
usable in C++14 and later constexprs, right?

[Bug middle-end/70506] [CilkPlus] error: location references block not in block tree

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Yeah, you should wrap the body into a BIND_EXPR in the FE.

[Bug c++/70505] [4.9/5/6 Regression] Constexpr failure when template type specified

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug c++/70505] [4.9/5/6 Regression] Constexpr failure when template type specified

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-04
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|Constexpr failure when  |[4.9/5/6 Regression]
   |template type specified |Constexpr failure when
   ||template type specified
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is rejected since r196724.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-04
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code on|[6 Regression] ICE on valid
   |x86_64-linux-gnu: canonical |code on x86_64-linux-gnu:
   |types differ for identical  |canonical types differ for
   |types   |identical types
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r222419.
struct __attribute__ ((__may_alias__)) S 
{
  S& operator= (int)
  {
return *this;
  }
};
works properly.

[Bug c/70523] New: Inconsistent casting of floats to unsigned short

[sergey.s at samsung dot com]

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

Bug ID: 70523
   Summary: Inconsistent casting of floats to unsigned short
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergey.s at samsung dot com
  Target Milestone: ---

Created attachment 38171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38171&action=edit
Test program

Casting of float expression to unsigned short gives different result when cast
is performed via intermediate variable. Specifically:

#include 

int main()
{
float f = 1.7857142687f;
printf("%.10f\n", f);
unsigned short b = 28;
unsigned short a = (unsigned short)(b * f);
printf("%u\n", a);
float temp = b * f;
a = (unsigned short)temp;
printf("%u\n", a);
return 0;
}
Output:
1.7857142687
49
50
Reproduced only for 32-bit compilation.
On 64-bit compilers both outputs are 50.
Optimization level shall be default.
If optimization level is -O2 or higher both outputs are 50.
Similar to bug 47297, but here value of float expression is well within range
of unsigned short, so behaviour should be defined.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-04
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on invalid C++ code on  |[4.9/5/6 Regression] ICE on
   |x86_64-linux-gnu:   |invalid C++ code on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
ICEs even in -std=c++98 mode starting with r165935, before that it has been
rejected:
pr70503.C:4:17: error: expected unqualified-id before ‘{’ token
pr70503.C:4:29: error: ‘c’ does not name a type

[Bug middle-end/70307] [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Mon Apr  4 08:11:46 2016
New Revision: 234706

URL: https://gcc.gnu.org/viewcvs?rev=234706&root=gcc&view=rev
Log:
PR c/70307
* c-fold.c (c_fully_fold_internal): Handle VEC_COND_EXPR.

* gcc.dg/torture/pr70307.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70307.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70307] [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/70523] Inconsistent casting of floats to unsigned short

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
That is the effect of excess precision on i387, see PR333.
You can either use -msse2 -mfpmath=sse if your CPU is capable of SSE2,
or -fexcess-precision=standard for slower, but guaranteed excess precision
according to target macros, or -ffloat-store for even slower behavior.

[Bug c/70523] Inconsistent casting of floats to unsigned short

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Sorry for typo, I meant PR323.

[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So, given this is a P1, is anyone working on it?

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'd say the problem is on the side of your generator, you should be putting the
#line 4 after #endif or switch to main.c earlier.

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r217279, both for C and C++.

[Bug hsa/70402] HSA: SBR instruction can be undefined

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Mon Apr  4 08:46:51 2016
New Revision: 234707

URL: https://gcc.gnu.org/viewcvs?rev=234707&root=gcc&view=rev
Log:
Fix PR hsa/70402

PR hsa/70402
* hsa-gen.c (gen_hsa_insns_for_switch_stmt): Guard index
value that is really in range handled by SBR instruction.
* hsa-brig.c (emit_switch_insn): Do not emit unconditional
jump.
* hsa-dump.c (dump_hsa_insn_1): Do not dump default BB.
* hsa.h (hsa_insn_sbr::m_default_bb): Remove field.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-brig.c
trunk/gcc/hsa-dump.c
trunk/gcc/hsa-gen.c
trunk/gcc/hsa.h

[Bug hsa/70402] HSA: SBR instruction can be undefined

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Author: hubicka
Date: Mon Apr  4 09:26:29 2016
New Revision: 234708

URL: https://gcc.gnu.org/viewcvs?rev=234708&root=gcc&view=rev
Log:

PR ipa/68881
* cgraph.h (symtab_node::copy_visibility_from): New function.
* symtab.c (symtab_node::copy_visibility_from): New function.
* ipa-visibility.c (optimize_weakref): New function.
(function_and_variable_visibility): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-visibility.c
trunk/gcc/symtab.c

[Bug rtl-optimization/70484] [4.9/5/6 Regression] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Apr  4 09:30:16 2016
New Revision: 234709

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

PR rtl-optimization/70484
* rtl.h (canon_output_dependence): Declare.
* alias.c (canon_output_dependence): New function.
* dse.c (record_store): Use canon_output_dependence rather
than canon_true_dependence.

* gcc.dg/torture/pr70484.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70484.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/dse.c
trunk/gcc/rtl.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Apr  4 09:32:28 2016
New Revision: 234710

URL: https://gcc.gnu.org/viewcvs?rev=234710&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/65795
* trans-array.c (gfc_array_allocate): When the array is a coarray,
do not nullyfing its allocatable components in array_allocate, because
the nullify missed the array ref and nullifies the wrong component.
Cosmetics.

gcc/testsuite/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/65795
* gfortran.dg/coarray_allocate_6.f08: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Apr  4 09:33:54 2016
New Revision: 234711

URL: https://gcc.gnu.org/viewcvs?rev=234711&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/65795
* trans-array.c (gfc_array_allocate): When the array is a coarray,
do not nullyfing its allocatable components in array_allocate, because
the nullify missed the array ref and nullifies the wrong component.
Cosmetics.

gcc/testsuite/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/65795
* gfortran.dg/coarray_allocate_6.f08: New test.



Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70484] [4.9/5 Regression] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 Regression] Wrong  |[4.9/5 Regression] Wrong
   |optimization with aliasing  |optimization with aliasing
   |and access via char |and access via char

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

[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports before closing.

[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/70524] New: [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[dominiq at lps dot ens.fr]

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

Bug ID: 70524
   Summary: [5/6 Regression] ICE when using  -frepack-arrays
-Warray-temporaries
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: manu at gcc dot gnu.org, vehre at gcc dot gnu.org
  Target Milestone: ---

While investigating pr69659, I noticed that compiling the tests

gfortran.dg/dependency_3[56].f90
gfortran.dg/inline_(sum|transpose)_1.f90

with -frepack-arrays -Warray-temporaries gives an ICE

in gfc_format_decoder, at fortran/error.c:937

While bisecting I have found that the ICE was non-deterministic.

The change occurred between revisions r218255 (2014-12-02, warnings) and
r218414 (2014-12-05, non-deterministic ICE).

[Bug fortran/70524] [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-04
  Known to work||4.9.3
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.0

[Bug fortran/66911] ICE on allocate character with source as a derived type component

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Apr  4 09:47:47 2016
New Revision: 234712

URL: https://gcc.gnu.org/viewcvs?rev=234712&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/66911
* trans-stmt.c (gfc_trans_allocate): Get the deferred length of an
expression by converting the expression when the length is not set
in the symbol's ts.

gcc/testsuite/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/66911
* gfortran.dg/deferred_character_16.f90: New test.



Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_16.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

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

IMNSHO -Wconversion is totally useless warning, and one where if you want to
avoid "false positives", we'd need to implement full VRP in the FEs.

Anyway, given say:
void
f1 (unsigned char * x, int y, int z)
{
  x[z / 8] |= (unsigned char) (0x80 >> y);
}

unsigned char
f2 (unsigned char x, int y)
{
  x = x | (unsigned char) (0x80 >> y);
  return x;
}

unsigned char
f3 (unsigned char x, int y)
{
  x = x | (unsigned char) (y & 255);
  return x;
}

unsigned char
f4 (unsigned char x, int y)
{
  x = x | (unsigned char) (y & 127);
  return x;
}

unsigned char
f5 (unsigned char x, unsigned char y)
{
  x = x | (unsigned char) (y & 255);
  return x;
}

the attached patch disables the warning on f4, and on f5 we don't warn already
before.  Perhaps the match.pd change should be guarded with GIMPLE?  The
match.pd change is responsible for getting rid of the explicit unsigned char
casts early.  Though, if you in the above testcase remove all the explicit
(unsigned char) casts, already gcc 4.9 and earlier warn.
As for the 0x80 >> whatever case, we'd need to handle that in
unsafe_conversion_p as another case (though, the question is if at least on
some targets with negative or other out of bound shift counts we don't
sometimes get (in UB code) values where conversion would alter the values).
And the y & 255 case is also questionable, there it wants to warn that for
negative y the value would change and unsafe_conversion_p for whatever reason
handles unsigned vs. signed mask constant differently for that exact case.

[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to Nathan Sidwell from comment #5)
> the intended current implementation is to treat 'sum' as firstprivate.

Not actively looking into that one at the moment, but:

> however, putting in an explicit firstprivate causes another different ICE
> (in  lower_oacc_reductions) -- regardless of whether 'sum' is a parameter,
> or a local (initialized) variable.  Clearly at least two other bugs lurk.

I highly suspect (will test) that ICE to be fixed by patch that I'm currently
preparing for trunk (already fixed on gomp-4_0-branch).

(In reply to Jakub Jelinek from comment #6)
> So, given this is a P1, is anyone working on it?

So, assigning to me for the moment; will then re-evaluate the status after the
ICE's fixed.

[Bug fortran/66911] ICE on allocate character with source as a derived type component

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Waiting one week for regressions before closing.

[Bug fortran/70524] [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
xg++ from stage1 should already add -lstdc++.  Sth else weird is going on for
you.

[Bug c++/70512] [6 Regression] ICE on valid code on x86_64-linux-gnu: canonical types differ for identical types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Priority|P3  |P2

[Bug c++/70505] [4.9/5/6 Regression] Constexpr failure when template type specified

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 38172 [details]
> gcc6-pr70336.patch
> 
> IMNSHO -Wconversion is totally useless warning, and one where if you want to
> avoid "false positives", we'd need to implement full VRP in the FEs.

What does VRP has to do with this case? This is just that the GCC FEs still
suck by doing early folding after Clang showed almost a decade ago that early
folding is evil and useless.

Also current -Wconversion sucks mostly because of PR40752, which has a patch
that was rejected on purist but IMHO completely non-practical reasons. Also
because, despite doing useless early folding, the current folding is not
powerful enough to analyse relatively simple expressions such as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522#c3.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
   Priority|P3  |P1

[Bug c/70378] wrong warning with -Wconversion with explicit cast

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #2)
> Simpler testcase:
> 
> typedef unsigned int uint32_t;
> void foo(char a, uint32_t b)
> {
>  b = (uint32_t)((b * 10) + (uint32_t)a); 
> }
> 
> Something must be removing the explicit cast or messing up the expression.

Perhaps a duplicate of PR70336. It seems that the move to match.pd just added
more early folding that removes explicit casts.

[Bug fortran/67538] ICE with invalid source allocation

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Apr  4 10:32:32 2016
New Revision: 234714

URL: https://gcc.gnu.org/viewcvs?rev=234714&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/67538
* resolve.c (resolve_allocate_expr): Emit error message when no
array spec and no array valued source= expression is given in an
F2008 allocate() for an array to allocate.

gcc/testsuite/ChangeLog:

2016-04-04  Andre Vehreschild  

PR fortran/67538
* gfortran.dg/allocate_with_source_19.f08: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_19.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

264   gcc_assert (TREE_CODE (var) == VAR_DECL
265   || TREE_CODE (var) == PARM_DECL
266   || TREE_CODE (var) == RESULT_DECL
267   || (TYPE_P (var) && is_gimple_reg_type (var)));
268
(gdb) p var
$1 = 

[Bug fortran/67538] ICE with invalid source allocation

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Waiting one week for regressions before closing.

[Bug fortran/70524] [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  ---
What is the gfc_warning* call that produces the ICE? Backtrace?

It seems gfortran is generating a NULL loc or loc->lb, or it is keeping an
invalid value of loc->nextc or loc->lb->line. This might be due to passing the
wrong thing to the call or not setting up gfc_current_locus correctly. This for
sure pre-dates the move to the new diagnostics:  now we assert when checking
whereas before the wrong loc was simply treated as unknown loc (building with
--disable-checking should do just that and not ICE).

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

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

Patch to revert (for GENERIC only) the match.pd change that causes this
regression.

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

[zsojka at seznam dot cz]

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

Bug ID: 70525
   Summary: generating 'vpandn' without the mode suffix, gnu as
fails to assemble (-mavx512bw)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

Output:
$ gcc -O -mavx512bw testcase.c
/tmp/ccuJjUxJ.s: Assembler messages:
/tmp/ccuJjUxJ.s:8: Error: operand type mismatch for `vpandn'

@@ -5,7 +5,7 @@
foo:   
  .LFB0:
.cfi_startproc
-   vpandn  %zmm0, %zmm1, %zmm0
+   vpandnq %zmm0, %zmm1, %zmm0
ret
.cfi_endproc
 .LFE0:


Fixes the assembly (similar fix applies for the intel syntax). (vpandnd can be
used as well)

Both the "vpandnq" and "vpandnd" instructions should be available in the
"foundation" instruction set with -mavx512f, but -mavx512bw is needed to force
generation of the instruction. I will create a missed-optimization for this,
unless I am wrong.

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 38173 [details]
> gcc6-pr70336.patch
> 
> Patch to revert (for GENERIC only) the match.pd change that causes this
> regression.

Does it fix also PR70378?

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
The above patch (untested so far) should get rid of the regression, thus we'd
warn exactly where 4.9 warned.
But, consider say:
void
f1 (unsigned char * x, int y, int z)
{
  x[z / 8] |= (unsigned char) (0x80 >> y);
}

unsigned char
f2 (unsigned char x, int y)
{
  x = x | (unsigned char) (0x80 >> y);
  return x;
}

unsigned char
f3 (unsigned char x, int y)
{
  x = x | (unsigned char) (y & 255);
  return x;
}

unsigned char
f4 (unsigned char x, int y)
{
  x = x | (unsigned char) (y & 127);
  return x;
}

unsigned char
f5 (unsigned char x, unsigned char y)
{
  x = x | (unsigned char) (y & 255);
  return x;
}

unsigned char
f6 (unsigned char x, int y)
{
  x = (unsigned char) (y & 255);
  return x;
}

void
f7 (unsigned char * x, int y, int z)
{
  x[z / 8] |= (0x80 >> y);
}

unsigned char
f8 (unsigned char x, int y)
{
  x = x | (0x80 >> y);
  return x;
}

unsigned char
f9 (unsigned char x, int y)
{
  x = x | (y & 255);
  return x;
}

unsigned char
f10 (unsigned char x, int y)
{
  x = x | (y & 127);
  return x;
}

unsigned char
f11 (unsigned char x, unsigned char y)
{
  x = x | (y & 255);
  return x;
}

unsigned char
f12 (unsigned char x, int y)
{
  x = (y & 255);
  return x;
}

Here -Wconversion will warn for many casesm even in 4.9, eventhough one could
argue that say in the f4 case nothing is lost during conversion, or that
without the explicit casts we should have known that nothing is altered during
the implicit conversions.  Which is why I've been talking about VRP, when we
start adding further and further cases where the implicit conversions can't
alter the values, we'll reimplement big part of VRP in the FEs.  And this has
nothing to do with not really delayed folding (even when both C and C++ FEs now
actually delay folding to some extents), to avoid the "false positives" from
-Wconversion you then want more folding rather than less folding.

[Bug fortran/70524] [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> What is the gfc_warning* call that produces the ICE? Backtrace?

For gfortran.dg/dependency_35.f90, the backtrace is

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/dependency_35.f90:6:0:

   pure function bar(i,j)

in gfc_format_decoder, at fortran/error.c:937
...
frame #9: 0x000100ca2116 f951`fancy_abort(file=,
line=, function=) + 38 at diagnostic.c:1329
frame #10: 0x0001000313c4 f951`::gfc_format_decoder(pp=,
text=, spec=, precision=,
wide=, plus=, hash=false) + 244 at error.c:937
frame #11: 0x000100ca7012 f951`pp_format(pp=0x0001424015e0,
text=0x7fff5fbfeb40) + 2274 at pretty-print.c:633
frame #12: 0x000100ca2831
f951`diagnostic_report_diagnostic(context=0x0001416248c0,
diagnostic=0x7fff5fbfeb40) + 401 at diagnostic.c:825
frame #13: 0x0001000310b9 f951`::gfc_warning(opt=174, gmsgid="Creating
array temporary at %L", ap=) + 217 at error.c:794
frame #14: 0x000100031dd7 f951`gfc_warning(opt=,
gmsgid=) + 135 at error.c:825
frame #15: 0x0001000e185b
f951`gfc_trans_dummy_array_bias(sym=0x000142704d00,
tmpdesc=0x00014215ba20, block=0x7fff5fbff070) + 2571 at
trans-array.c:6167
frame #16: 0x0001000f7a7e
f951`gfc_trans_deferred_vars(proc_sym=0x000142704d00,
block=0x7fff5fbff070) + 910 at trans-decl.c:4037
frame #17: 0x0001000fa714
f951`gfc_generate_function_code(ns=) + 1332 at trans-decl.c:6258
frame #18: 0x0001000d8322
f951`gfc_generate_module_code(ns=0x000144013400) + 370 at trans.c:2058
frame #19: 0x00010008bbaf f951`gfc_parse_file() + 160 at parse.c:5600
frame #20: 0x00010008bb0f f951`gfc_parse_file() + 1247
frame #21: 0x0001000d1979 f951`::gfc_be_parse_file() + 57 at
f95-lang.c:201
frame #22: 0x00010099fa8c f951`::compile_file() + 60 at toplev.c:465
frame #23: 0x000100d879df f951`toplev::main(int, char**) + 1154 at
toplev.c:1988
frame #24: 0x000100d8755d f951`toplev::main(this=,
argc=, argv=) + 733
frame #25: 0x000100d893b9 f951`main(argc=4, argv=0x7fff5fbff300) +
41 at main.c:39

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I'll have a look.

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Manuel López-Ibáñez from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Created attachment 38173 [details]
> > gcc6-pr70336.patch
> > 
> > Patch to revert (for GENERIC only) the match.pd change that causes this
> > regression.
> 
> Does it fix also PR70378?

Of course it doesn't, how could it?
PR70378 is not a (recent) regression, I can reproduce it all the way back to
r130377.

[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #6 from Kirill Yukhin  ---
Done

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #18 from Christophe Lyon  ---
I think you forgot to re-open this bug.

[Bug fortran/70524] [5/6 Regression] ICE when using -frepack-arrays -Warray-temporaries

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
Oh no, not again gfc_trans_dummy_array_bias...

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

[jandemooij+gccbugs at gmail dot com]

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

Bug ID: 70526
   Summary: GCC 6 miscompiles Firefox JIT compiler
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jandemooij+gccbugs at gmail dot com
  Target Milestone: ---

Created attachment 38175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38175&action=edit
Reduced testcase

See https://bugzilla.mozilla.org/show_bug.cgi?id=1245783

I managed to reduce it to the attached test case.

$ g++ --version
g++-6 (Ubuntu 6-20160319-0ubuntu11) 6.0.0 20160319 (experimental) [trunk
revision 234350]

$ g++-6 -O3 -Wall -o test test.cpp
$ ./test
Fail

It does not print "Fail" with -O0 or with g++ 5.3.1


The problem seems to be on this line:

return TypedOrValueRegister(type, ToAnyRegister(value));

It looks like we read a bogus/uninitialized value from the stack and use that
instead of the result of the ToAnyRegister call.

[Bug tree-optimization/70527] New: Missed fold for "(long int) x * 12 - (long int)(x + 1) * 12"

[amker at gcc dot gnu.org]

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

Bug ID: 70527
   Summary: Missed fold for "(long int) x * 12 - (long int)(x + 1)
* 12"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Given below test:
long unsigned int foo (int x)
{
  return (long unsigned int) x * 12 - (long unsigned int)(x + 1) * 12;
}

long int bar (int x)
{
  return (long int) x * 12 - (long int)(x + 1) * 12;
}
The 004t.gimple dump is like:
foo (int x)
{
  long unsigned int D.1762;

  D.1762 = 18446744073709551604;
  return D.1762;
}


bar (int x)
{
  long int D.1764;
  long int D.1765;
  long int D.1766;
  int D.1767;
  long int D.1768;
  long int D.1769;

  D.1765 = (long int) x;
  D.1766 = D.1765 * 12;
  D.1767 = x + 1;
  D.1768 = (long int) D.1767;
  D.1769 = D.1768 * -12;
  D.1764 = D.1766 + D.1769;
  return D.1764;
}


Seems "(long int) x * 12 - (long int)(x + 1) * 12" is missed in
generic-simplify.

[Bug c++/70528] New: [5/6 Regression] bogus error: constructor required before non-static data member

[trippels at gcc dot gnu.org]

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

Bug ID: 70528
   Summary: [5/6 Regression] bogus error: constructor required
before non-static data member
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Since r225189 LLVM trunk (since commit be4ea76eaa0 ) doesn't build anymore:

In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/move.h:57:0,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/stl_pair.h:59,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/utility:70,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/algorithm:60,
 from /home/markus/llvm/include/llvm/ADT/StringRef.h:14,
 from /home/markus/llvm/include/llvm/ADT/StringMap.h:17,
 from /home/markus/llvm/include/llvm/Support/Host.h:17,
 from /home/markus/llvm/include/llvm/ADT/Hashing.h:49,
 from /home/markus/llvm/include/llvm/ADT/ArrayRef.h:13,
 from /home/markus/llvm/include/llvm/ADT/DenseMapInfo.h:17,
 from /home/markus/llvm/include/llvm/ADT/DenseMap.h:17,
 from
/home/markus/llvm/lib/Bitcode/Writer/ValueEnumerator.h:17,
 from
/home/markus/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:14:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits: In
substitution of ‘template static std::true_type
std::__do_is_default_constructible_impl::__test(int) [with _Tp =
llvm::ValueEnumerator::MDRange;  = ]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:879:35:  
required from ‘struct
std::__is_default_constructible_impl’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:143:12:  
required from ‘struct
std::__and_ >,
std::__is_default_constructible_impl >’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:883:12:  
required from ‘struct
std::__is_default_constructible_atom’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:904:12:  
required from ‘struct
std::__is_default_constructible_safe’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:910:12:  
required from ‘struct
std::is_default_constructible’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:143:12:   [
skipping 6 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable
]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:715:12:  
required from ‘struct
std::is_abstract [1], llvm::SmallDenseMap::LargeRep, char, char, char, char, char,
char, char, char> >’
/home/markus/llvm/include/llvm/Support/AlignOf.h:79:13:   required from
‘constexpr const unsigned int
llvm::AlignOf [1], llvm::SmallDenseMap::LargeRep, char, char, char, char, char,
char, char, char> >::Alignment’
/home/markus/llvm/include/llvm/Support/AlignOf.h:86:52:   required from ‘struct
llvm::AlignOf [1], llvm::SmallDenseMap::LargeRep, char, char, char, char, char,
char, char, char> >’
/home/markus/llvm/include/llvm/Support/AlignOf.h:251:8:   required from ‘struct
llvm::AlignedCharArrayUnion [1], llvm::SmallDenseMap::LargeRep, char, char, char, char, char,
char, char, char>’
/home/markus/llvm/include/llvm/ADT/DenseMap.h:759:59:   required from ‘class
llvm::SmallDenseMap’
/home/markus/llvm/lib/Bitcode/Writer/ValueEnumerator.h:100:39:   required from
here
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:868:48:
error: constructor required before non-static data member for
‘llvm::ValueEnumerator::MDRange::First’ has been parsed
 template
^
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:868:48:
error: constructor required before non-static data member for
‘llvm::ValueEnumerator::MDRange::Last’ has been parsed
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/type_traits:868:48:
error: constructor required before non-static data member for
‘llvm::ValueEnumerator::MDRange::NumStrings’ has been parsed


markus@x4 llvm_build % cat BitcodeWriter.ii
template  struct integral_constant {
  static constexpr _Tp value = 0;
};
template  struct conditional;
template  struct A;
template 
struct A<_B1, _B2> : conditional<_B1::value, _B2>::type {};
struct B : integral_constant {};
struct C {
  template 
  static integral_constant __test(int);
};
template  struct L : C { typedef decltype(__test<_Tp>(0)) type;
};
template  struct M : A> {};
template  struct N : M<_Tp>::type {};
struct D {
  static integral_constant __test();
};
template  struct __is_implicitly_default_constructible_impl : D {
  typedef decltype(__test()) type;
};
template 
struct F : __is_implicitly_default_constructible_impl::type {};
template  struc

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
einline produces the broken SSA name initially (in some way).  Created by

#2  0x00da59f9 in gimple_regimplify_operands (stmt=
, gsi_p=0x7fff8c50)
at /space/rguenther/src/svn/trunk/gcc/gimplify-me.c:303
303 temp = make_ssa_name (temp);
(gdb) l
298 }
299   if (need_temp)
300 {
301   tree temp = create_tmp_reg (TREE_TYPE (lhs));
302   if (gimple_in_ssa_p (cfun))
303 temp = make_ssa_name (temp);
304   gimple_set_lhs (stmt, temp);
305   post_stmt = gimple_build_assign (lhs, temp);
(gdb) p debug_gimple_stmt (stmt)
# .MEM = VDEF <.MEM>
MEM[(struct SIMD *)_1] = SIMD::operator* (&hx, hy);

the code is really weird.

  if (is_gimple_reg_type (TREE_TYPE (lhs)))
need_temp = true;
  else if (TYPE_MODE (TREE_TYPE (lhs)) != BLKmode)
{
  if (is_gimple_call (stmt))
{
  tree fndecl = gimple_call_fndecl (stmt);

  if (!aggregate_value_p (TREE_TYPE (lhs), fndecl)
  && !(fndecl && DECL_RESULT (fndecl)
   && DECL_BY_REFERENCE (DECL_RESULT (fndecl
need_temp = true;
}
  else
need_temp = true;
}

the is_gimple_reg_type case should be the only thing necessary.  But the
whole function is a totally weird beast.  I'm not going to touch that
but try papering over this mess in some way (probably how this shit
evolved...).

So instead of the above we'll get re-gimplified

  D.27340 = SIMD::operator* (&hx, hy);
  MEM[(struct SIMD *)_1] = D.27340;


Index: gcc/gimplify-me.c
===
--- gcc/gimplify-me.c   (revision 234705)
+++ gcc/gimplify-me.c   (working copy)
@@ -299,7 +299,8 @@ gimple_regimplify_operands (gimple *stmt
  if (need_temp)
{
  tree temp = create_tmp_reg (TREE_TYPE (lhs));
- if (gimple_in_ssa_p (cfun))
+ if (gimple_in_ssa_p (cfun)
+ && is_gimple_reg_type (TREE_TYPE (lhs)))
temp = make_ssa_name (temp);
  gimple_set_lhs (stmt, temp);
  post_stmt = gimple_build_assign (lhs, temp);

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

[g...@axel-naumann.de]

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

Bug ID: 70529
   Summary: Unhelpful diagnostic for hex float literals,
inconsistent parsing
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@axel-naumann.de
  Target Milestone: ---

auto d = 0x123p-2;

with g++ prog.cc -Wall -Wextra -std=c++14 -fsyntax-only

produces

prog.cc:1:10: error: exponent has no digits
 auto d = 0x123p-2;
  ^~

That's a gross misrepresentation of the source code ;-) IIUC
https://github.com/gcc-mirror/gcc/commit/14c36b1402b82304739e865a27cb1aed0d87ec73
removed hex float literal support for c++ std <= 14, making this code
ill-formed. 

OTOH this behavior is inconsistent, in that hex float literals with positive
exponents remain valid, even for above invocation.



A more helpful diagnostic (similar to "use of C++1z hexadecimal floating
constant") would be really good to have for people upgrading to GCC 6 without
also upgrading to c++1z. At least for those people with hex floats with
negative exponents :-)

Thanks for considering!

Axel.

[Bug libstdc++/70530] New: You should probably add addressof (a) != addressof (b) check to std::swap

[safinaskar at mail dot ru]

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

Bug ID: 70530
   Summary: You should probably add addressof (a) != addressof (b)
check to std::swap
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: safinaskar at mail dot ru
  Target Milestone: ---

C++ standard says standard library functions may assume rvalue reference
arguments are unique, i. e. are not aliased to any other arguments (final draft
C++14 N3690 17.6.4.9). I think this implies that move assignment for standard
classes assume there will be no move assignment to itself. Also, I think this
is good idea for other classes to assume the same.

As well as I know there is no any mention in the standard that std::swap
argument should not point to the same object. So, code "swap (a, a)" is legit.
Moreover, this code can appear in real programs. For example, this is code from
http://en.cppreference.com/w/cpp/algorithm/iter_swap (as on 2016-04-02):

// libstdc++'s general std::iter_swap just calls std::swap in c++11 mode
template
void selection_sort(ForwardIt begin, ForwardIt end)
{
for (ForwardIt i = begin; i != end; ++i)
std::iter_swap(i, std::min_element(i, end));
}

Current libstdc++ implementation of std::swap calls move constructor (ctor) one
time and move assignment (op=) two times. If we call std::swap (a, a), then
there will be move op= to itself.

So, I think std::move should check whatever its arguments point to the same
object.

It seems all standard classes will work correctly currently if we call
std::swap (a, a) in stdlibc++. I. e. I cannot think about some concrete
libstdc++ class where std::swap (a, a) will cause any damage. But still
assuming rvalue reference is unique is good idea for other libraries, too. And
this is possible that some library author will assume this and std::swap (a, a)
will fail.

So, what to do? My proposed solution is to fix std::swap. But there are other
variants, of course. For example, remove rvalue ref uniqueness assumption from
the standard. Or add requirement for code which calls std::swap. Even if you
decide to fix std::swap, I think it still be good idea to modify the standard.
For example, to stay explicitly that a = std::move (a) is not allowed for
standard classes, that this is recommended for other class to assume there will
be no code "a = std::move (a)", that swap (a, a) is allowed and for this reason
current libstdc++'s swap implementation is not allowed

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
-Wstrict-aliasing=2 warns:

markus@x4 tmp % g++ -O2 -Wstrict-aliasing=2 test_fire.cpp
test_fire.cpp: In instantiation of ‘const T* AlignedStorage2::addr() const
[with T = Register]’:
test_fire.cpp:41:52:   required from here
test_fire.cpp:13:34: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
   const T* addr() const { return reinterpret_cast(u.mBytes); }

-fno-strict-aliasing fixes the issue, thus invalid.

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
A shorter reproducer for the funny part where the error arises:

template 
struct I {
};

struct J {
  struct K {
int First = 0;
  };
  I FunctionMDInfo;
};

[Bug other/70433] backslashes lost in dot file

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00161.html

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |5.4

[Bug c++/70336] [5/6 regression] Incorrect Wconversion warning

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #8)
> Here -Wconversion will warn for many casesm even in 4.9, eventhough one
> could argue that say in the f4 case nothing is lost during conversion, or

There is an explicit cast, so this case is exactly equivalent to:

unsigned char
foo (unsigned char x, unsigned char y)
{
  x = x | y;
  return x;
}

This seems to me the same case as PR40752, and I would be happy not warning
about those and Ian agreed with me, thus I proposed a patch to that effect.

> Which is why I've been talking about VRP,
> when we start adding further and further cases where the implicit
> conversions can't alter the values, we'll reimplement big part of VRP in the
> FEs.  And this has nothing to do with not really delayed folding (even when
> both C and C++ FEs now actually delay folding to some extents), to avoid the
> "false positives" from -Wconversion you then want more folding rather than
> less folding.

Of course, more intelligent static analysis (CCP, VRP, IPA) in the FEs would be
very useful, specially for other warnings such as -Wsign-compare. Clang is
doing some form of CCP and callgraph analysis to improve diagnostics and it is
still faster than GCC FEs.

But from reading the list of -Wconversion bugs in bugzilla, this is not what
people complain about. They complain about explicit casts being ignored, about
not being able to silence warnings for bit-fields and noisy warnings about
implicit integral promotions with operands of the same type, where the result
is converted back to the same type again. None of those need VRP to be fixed,
AFAICT.

In most cases, one wants enough analysis to see through implicit casts. This is
what shorten_compare et al. are doing. However, the fact that they are
optimisations and not analysis make them clumsy to use by -Wconversion and they
do not make distinctions between implicit vs. explicit casts, which is very
important for -Wconversion.

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Seems related to PR 58328

[Bug tree-optimization/70527] Missed fold for "(long int) x * 12 - (long int)(x + 1) * 12"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Note the issue is (non-)canonicalization of (long)(x + 1).  For optimal
re-assoc you'd want to canonicalize this to (long)x + 1L (with x + 1
having undefined behavior on overflow) and then to (long)x * 12 + 12.

But generally you do _not_ want to do this because you lose value-range info
and carry out the op in a larger mode (the former means the reverse transform
is not valid).

Generic folding has very limited capabilities here and GIMPLE reassoc currently
refuses to associate signed ops at all.

[Bug c++/70531] New: Turning optimisation level 2 causes the output program to go into infinite loop

[iliyabo at hotmail dot com]

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

Bug ID: 70531
   Summary: Turning optimisation level 2 causes the output program
to go into infinite loop
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iliyabo at hotmail dot com
  Target Milestone: ---

Created attachment 38176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38176&action=edit
Source file causing the bug

While solving algorithm problems, I stumbled on a problem which I think is a
bug within the g++ compiler. You can see the source code in the attachment. If
I compile with g++ $(srcfile) -o output, the resulting executable works as
expected. But when I turn optimisations (-O2), resulting executable goes into
infinite loop and I must terminate it. This behaviour doesn't happen if I try
to use clang++ (both with optimisation on and off). I am using fedora 23 with
g++ version 5.3.1. If you need anything else, tell me.

[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
The added diagnostic rejects this, which clang and EDG accept:

extern "C" int printf(const char*, ...);
int main() { 
  using A = int[1];
  printf("%p\n", A{1} );
}

ts.c:4:18: error: taking address of temporary array
   printf("%p\n", A{1} );
  ^~~~


This doesn't use compound literals, and seems like valid C++ according to
[conv.array].

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Jonathan Wakely from comment #2)
> Seems related to PR 58328

Hmm, does it makes sense to compute exception specifications even with
-fno-exceptions (LLVM default build flag)?

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
In PR58328 there is no explicit ctor at all, in this case the source actually
has
  K() = default;
With
  K() {}
it works.

[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4

[nickc at gcc dot gnu.org]

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

--- Comment #8 from Nick Clifton  ---

(In reply to Ramana Radhakrishnan from comment #6)
> Fails at O0 in this case, I cannot type. I still think this is a tail from
> PR62254 and that should just be reopened.

I cannot reproduce this failure.  Ie when I compile this test case everything
works, at -O0 all the way up to -O3.

This is with today's mainline sources, which has *both* of the patches from PR
62254 applied.  These sources no longer contain this assertion:

  gcc_assert (REG_P (operands[0]));

although they do contain:

  gcc_assert (REG_P (outval) || SUBREG_P (outval));


If the problem really does exist, could someone tell me what outval looks like
when the assertion is triggered ?

Cheers
  Nick

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

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Markus Trippelsdorf from comment #1)
> -Wstrict-aliasing=2 warns:
> 
> markus@x4 tmp % g++ -O2 -Wstrict-aliasing=2 test_fire.cpp
> test_fire.cpp: In instantiation of ‘const T* AlignedStorage2::addr()
> const [with T = Register]’:
> test_fire.cpp:41:52:   required from here
> test_fire.cpp:13:34: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
>const T* addr() const { return reinterpret_cast(u.mBytes); }
> 
> -fno-strict-aliasing fixes the issue, thus invalid.

Isn't that a bit fast? -Wstrict-aliasing=3 doesn't warn, the read and the write
are both done in type Register. Reducing a bit:

typedef unsigned uint32_t;

template
struct AlignedStorage2
{
  char mBytes[sizeof(T)];

  const T* addr() const { return reinterpret_cast(mBytes); }
  T* addr() { return reinterpret_cast(mBytes); }
};

struct Register {
uint32_t reg_;
};

class TypedOrValueRegister
{
AlignedStorage2 typed;
__attribute__((noinline)) Register& dataTyped() { return *typed.addr(); }
  public:
TypedOrValueRegister(Register reg)
{
  dataTyped() = reg;
}
Register typedReg() const { return *typed.addr(); }
};

int main() {
Register reg = { 10u };
if (TypedOrValueRegister(reg).typedReg().reg_ != 10)
  __builtin_abort();
return 0;
}

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[nickc at gcc dot gnu.org]

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

--- Comment #19 from Nick Clifton  ---
(In reply to Julien Margetts from comment #17)
> The following test case still fails with the patch applied (originally bug
> 70362)
> 
> arm-none-eabi-gcc -march=armv3m -c -o c_compat_x_tst.o
> gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c


I cannot reproduce this failure.  Ie when I compile this test case everything
works, at -O0 all the way up to -O3.

This is with today's mainline sources, which has *both* of the patches from
this PR applied.  These sources no longer contain this assertion:

  gcc_assert (REG_P (operands[0]));

although they do contain:

  gcc_assert (REG_P (outval) || SUBREG_P (outval));


If the problem really does exist, could someone tell me what outval looks like
when the assertion is triggered ?

Cheers
  Nick

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2016-04-04
Summary|You should probably add |[DR2468] You should
   |addressof (a) != addressof  |probably add addressof (a)
   |(b) check to std::swap  |!= addressof (b) check to
   ||std::swap
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Askar Safin from comment #0)
> C++ standard says standard library functions may assume rvalue reference
> arguments are unique, i. e. are not aliased to any other arguments (final
> draft C++14 N3690 17.6.4.9). I think this implies that move assignment for
> standard classes assume there will be no move assignment to itself. Also, I
> think this is good idea for other classes to assume the same.

That rule is actually defective, see:

http://cplusplus.github.io/LWG/lwg-active.html#2468

> As well as I know there is no any mention in the standard that std::swap
> argument should not point to the same object. So, code "swap (a, a)" is
> legit. Moreover, this code can appear in real programs. For example, this is
> code from http://en.cppreference.com/w/cpp/algorithm/iter_swap (as on
> 2016-04-02):
> 
> // libstdc++'s general std::iter_swap just calls std::swap in c++11 mode
> template
> void selection_sort(ForwardIt begin, ForwardIt end)
> {
> for (ForwardIt i = begin; i != end; ++i)
> std::iter_swap(i, std::min_element(i, end));
> }
> 
> Current libstdc++ implementation of std::swap calls move constructor (ctor)
> one time and move assignment (op=) two times. If we call std::swap (a, a),
> then there will be move op= to itself.
> 
> So, I think std::move should check whatever its arguments point to the same
> object.

That would not be conforming.

> It seems all standard classes will work correctly currently if we call
> std::swap (a, a) in stdlibc++. I. e. I cannot think about some concrete
> libstdc++ class where std::swap (a, a) will cause any damage. But still
> assuming rvalue reference is unique is good idea for other libraries, too.
> And this is possible that some library author will assume this and std::swap
> (a, a) will fail.
> 
> So, what to do? My proposed solution is to fix std::swap. But there are
> other variants, of course. For example, remove rvalue ref uniqueness
> assumption from the standard. Or add requirement for code which calls
> std::swap. Even if you decide to fix std::swap, I think it still be good
> idea to modify the standard. For example, to stay explicitly that a =
> std::move (a) is not allowed for standard classes, that this is recommended
> for other class to assume there will be no code "a = std::move (a)", that
> swap (a, a) is allowed and for this reason current libstdc++'s swap
> implementation is not allowed

The more likely direction is to require self-move (and therefore self-swap) to
be valid for all standard classes.

[Bug tree-optimization/70527] Missed fold for "(long int) x * 12 - (long int)(x + 1) * 12"

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to amker from comment #0)
> Seems "(long int) x * 12 - (long int)(x + 1) * 12" is missed in
> generic-simplify.

Interestingly, we manage just fine if 12 is replaced with a variable. The issue
seems to be that we replace a-y*12 by a+y*-12 before we detect the common
factor, so it might be as simple as moving code around. Although recognizing
constant factors that differ only by their sign seems useful as well.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

As the patch shows, I see numerous problems.  E.g. the use of 
in define_insn that really wasn't meant to be masked and doesn't have
 in the name, but the use of  still makes it
masked.
Or the existence of masked V*[QH]I andnot - we really can't support there, as
there are no VPANDNB and VPANDNW instructions.  Plus we have to make sure we
emit vpandnq or vpandnd for all 512-bit modes, there is no such vpandn
instruction.

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

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

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Started with r223126. Richi?

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
A way to look at the problem is to compare against the dump info for the
variant without the extra (redundant) dimension.

So, compare dump-info for -DEXTRADIM={0,1} for this source:
...
#if EXTRADIM
int yu[4][1] = { { 1 }, { 2 }, { 3 }, { 4 } };

int
main (void)
{
  int zh, ro;

  for (zh = 0; zh < 2; ++zh)
for (ro = 0; ro < 3; ++ro)
  yu[ro][0] = yu[zh + 1][0];

  return yu[0][0]; /* Should be 2, but returns 3.  */
}

#else

int yu[4] = { 1, 2, 3, 4 };

int
main (void)
{
  int zh, ro;

  for (zh = 0; zh < 2; ++zh)
for (ro = 0; ro < 3; ++ro)
  yu[ro] = yu[zh + 1];

  return yu[0]; /* Returns 3.  */
}

#endif
...

This shows a bit of the unified diff of the dump info. The fact that the data
references show no reads, is probably already indicative of a problem:
...
 data references (
-  reads: { S_4[i1, i2] -> [1, 1 + i1] : i1 >= 0 and i1 <= 1 and i2 <= 2 and i2
>= 0 }
-  must_writes: { S_4[i1, i2] -> [1, i2] : i2 >= 0 and i2 <= 2 and i1 >= 0 and
i1 <= 1 }
+  reads: {  }
+  must_writes: { S_4[i1, 0] -> [1, 0, 0] : i1 >= 0 and i1 <= 1 }
   may_writes: {  }
 )
 data dependences (
-{ S_4[i1, i2] -> S_4[i1, i2'] : i2' >= 1 + i1 and i2' <= 1 + i1 + i2 and i2'
>= 1 + i2 and i2' <= 2; S_4[0, i2] -> S_4[1, i2'] : i2' >= 2 - i2 and \
i2' <= i2 and i2 <= 2; S_4[0, 0] -> S_4[1, 0] }
+{ S_4[0, 0] -> S_4[1, 0] }
 )
...

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This changed with r223126.
The *.optimized dump is the same between r223124 and r223126, but already there
we can see that SRA used the TypedOrValueRegister type for the read:
  MEM[(struct  &)&D.2403] ={v} {CLOBBER};
  _2 = TypedOrValueRegister::dataTyped (&D.2403);
  MEM[(struct Register *)_2] = 10;
  SR.8_7 = MEM[(struct TypedOrValueRegister *)&D.2403];
  D.2403 ={v} {CLOBBER};
  if (SR.8_7 != 10)
and then the scheduler swaps the store of 10 with the load from the memory.
I'd say this testcase is invalid, but with placement new it would not be
invalid, the question is if it would still misbehave then.

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 38178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38178&action=edit
UDIFF

[Bug c++/70531] Turning optimisation level 2 causes the output program to go into infinite loop

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #1 from James Greenhalgh  ---
Try compiling and running with -fsanitize=undefined. You have a bug in your
logic that results in an out-of-bounds memory access:

   .../ab2.cpp:97:26: runtime error: index -1 out of bounds for type 'long long
int [101]'
   .../ab2.cpp:97:18: runtime error: index -1 out of bounds for type 'long long
int [101][101][101]'
Segmentation fault (core dumped)

(At least) this condition is in the wrong place:

if (xs > xe || ys > ye)
return 0;

When rec is called with arguments (0, -1, 0, -1) (as it will be), this
condition comes after the memory dereference at:

if (dp[xs][xe][ys][ye] != -1)
return dp[xs][xe][ys][ye];

So you will be trying to access dp[0][-1][0][-1] - which is invalid.

I haven't fully audited your code for other logic errors. Please check your
algorithm. For simple inputs I always get a crash, not an infinite loop - but
such is the nature of undefined behaviour. If your bug report relies on
particular input to cause the loop, you'll need to provide that. As it stands,
this looks invalid, but feel free to reopen it after you have audited your code
for other undefined sequences.

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

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

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

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner  ---
In gcc/builtins.c it is probably better to use:

const struct real_format *fmt = FLOAT_MODE_FORMAT (mode);
if (fmt == &ibm_extended_double)
  {
// ...
  }

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #1 from Ville Voutilainen  ---
Mine.

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

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Created attachment 38179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38179&action=edit
First stab at a patch

Initial patch done, testsuite additions to follow, will submit once
compile-farm testing is done.

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
If comment #1 should be accepted, then should this be accepted too?

template 
struct I {
};

struct J {
  struct K {
int First = J::N;
  };
  I FunctionMDInfo;
  static const int N = 0;
};

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Patrick Palka from comment #5)
> If comment #1 should be accepted, then should this be accepted too?
> 
> template 
> struct I {
> };
> 
> struct J {
>   struct K {
> int First = J::N;
>   };
>   I FunctionMDInfo;
>   static const int N = 0;
> };

Clang rejects both.

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The function needs to deal with cases where e.g. DECL_VALUE_EXPR is added to
various VAR_DECLs and the IL needs to be updated accordingtly.  It is mostly
used by OpenMP lowering, and that is done not in SSA form, so that is why most
of its testcase coverage is without SSA.
Anyway, for the testcase, it would be perhaps better to use
typedef double v4df __attribute__((vector_size (32)));
and use v4df instead of __m256d (and immintrin.h include).
Is it inentional that hx and hy are uninitialized and y is unused?  Shouldn't
hx be initialized to Value().data and hy to y.Value().data ?

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Yeah, and it rejects both #c1 and #c5 and the variants with K() = default;
So, unlike PR58328 here both compilers agree, and the disagreement is just
whether it is ok for libstdc++ to use the decltype?

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can you bisect it?  There aren't that many changes that could affect anything
at all.
Any Ada processes (compiler or some testcase) hang?

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

[matthias.hochsteger at tuwien dot ac.at]

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

--- Comment #4 from Matthias Hochsteger  ---
This testcase is just a very striped-down version of the actual code to
reproduce the error, so it may seem useless at some spots, like the missing
initialization.
We already have a workaround by adding additional
__attribute__((__always_inline__)) 
to the methods of SIMD, in this sense it's no critical bug.
This code is part of a cross-platform project. We are including immintrin.h
since it is supplied by all used compilers. I am not sure how
typedef double v4df __attribute__((vector_size (32)));
behaves on others, but we will give it a try.

Thanks,
Matthias

[Bug c++/70507] integer overflow builtins not constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Thank you for the suggestion.

Storing values via pointers is not C++ 14 specific so the answer to your
question is that having the builtins be treated as constexpr would be useful in
both C++ 11 and C++ 14 modes.  The modified example below should help explain
it:

constexpr int mul (int x, int y, int z = 0)
{
  return __builtin_mul_overflow *(x, y, &z) ? 0 : z;
}

constexpr int z = mul (1234, 5678);

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I don't know how to implement is_default_constructible without using that
decltype, or something similar that will cause the same problem.

If we had a __is_constructible(_Tp, _Args...) builtin we could use that (for
is_constructible, and then define is_default_constructible in terms of that).

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I haven't been talking on what you should be using in your project, but rather
what testcase we want to include in GCC sources.  And there the immintrin.h
dependency IMHO is unnecessary etc.

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

[matthias.hochsteger at tuwien dot ac.at]

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

--- Comment #6 from Matthias Hochsteger  ---
Oh, now I get it, sorry for the misunderstanding.

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[ppalka at gcc dot gnu.org]

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

--- Comment #9 from Patrick Palka  ---
Here's something strange.

gcc rejects and clang accepts the following test case, but if decltype (A()) is
replaced by decltype (T()) then gcc accepts and clang rejects it.

template 
struct H
{
  template 
  H ();
};

template 
struct I {
  H u;
};

struct J {
  struct K {
int First = 0;
  };
  I FunctionMDInfo;
};

The error is still

error: constructor required before non-static data member for ‘J::K::First’ has
been parsed

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Apr  4 15:42:19 2016
New Revision: 234716

URL: https://gcc.gnu.org/viewcvs?rev=234716&root=gcc&view=rev
Log:
[gcc]

2016-04-04  Bill Schmidt  
Jakub Jelinek 

PR middle-end/70457
* tree-inline.c (estimate_num_insn): Use gimple_call_builtin_p
to ensure a call statement is compatible with a built-in's
prototype.
* tree-ssa-math-opts.c (pass_optimize_windening_mul::execute):
Likewise.

[gcc/testsuite]

2016-04-04  Bill Schmidt  
Jakub Jelinek 

PR middle-end/70457
* gcc.dg/torture/pr70457.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70457.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-ssa-math-opts.c