[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

Milan Bouchet-Valat  changed:

   What|Removed |Added

  Attachment #37514|0   |1
is obsolete||

--- Comment #14 from Milan Bouchet-Valat  ---
Created attachment 37520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37520=edit
Test C++ program which compiles with GCC 5 but not with GCC 6

Yes, sorry, I was about to explain the actual use case. Looks like I
oversimplified the test program, as I hadn't spotted the difference of behavior
in gcc (as opposed to g++).

I've updated the test case to reflect this.

[Bug other/69554] New: Multi-location diagnostics writes too many lines

[tkoenig at gcc dot gnu.org]

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

Bug ID: 69554
   Summary: Multi-location diagnostics writes too many lines
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

When showing multiple diagnostics in one error message,
intermediate lines are shown (and some empty lines as well).

This can be shown with the attached patch, which has the
line

  gfc_error ("Symbol %qs at %C also declared as a type at %L", name,
 >n.sym->declared_at);

With the test case

type X
end type

integer :: q
real :: a
integer, parameter :: h=3

type(X) :: X

end

the error message is

type.f90:8:12:

 type X
  2  
 end type



 integer :: q

 real :: a

 integer, parameter :: h=3



 type(X) :: X
1
Error: Symbol »x« at (1) also declared as a type at (2)

[Bug other/69554] Multi-location diagnostics writes too many lines

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I thought we already had a PR about this.

[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
Hm, actually the chapter about "private" says nothing about how to actually
*handle* a reference type whereas it states that for "firstprivate" and
"lastprivate" the reference must bind to the same object for all threads.  To
me it still looks as if using references in "private" is undefined.

[Bug other/69554] Multi-location diagnostics writes too many lines

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 37522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37522=edit
patch to expose the problem

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Apparently the case they actually care about in Julia is not what was posted
here, which might be where the disagreement comes from. What they actually have
is:

typedef struct mytype {
struct mytype *fieldptr0[0];
struct mytype *fieldptr[];
} mytype;

The C front-end *does* accept this, which uses the non-standard zero-length
array extension *and* a flexible array member.

[Bug libstdc++/69553] New: Optimizations O1/O2 makes std::array value incorrect when passed to function

[gee at ptilouk dot net]

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

Bug ID: 69553
   Summary: Optimizations O1/O2 makes std::array value incorrect
when passed to function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gee at ptilouk dot net
  Target Milestone: ---

Created attachment 37521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37521=edit
Source code generating the bug

The following example displays incorrect values when compiling with
optimizations -O1 or -O2 (but not without optimization and not with -O3):

--
#include 
#include 

typedef std::array, 2> Matrix;

void foo(const double , const double )
{
  std::cerr << px << " " << py << std::endl;
}

std::ostream& operator<<(std::ostream& os, const std::array& p)
{
  return os << p[0] << " " << p[1];
}

void test (const Matrix& t)
{
  std::cerr << "In test: " << std::endl
<< t[0] << std::endl
<< t[1] << std::endl;

  std::cerr << "In foo: " << std::endl;
  foo(t[0][0], t[0][1]);
  foo(t[1][0], t[1][1]);
}

int main (int, char**)
{
  Matrix t = {{ {{1,2}}, {{3,4}} }};
  test (t);
  return 0;
}
--

(Compiled with 'g++-6 -std=c++11 -O1 test_bug_array.cpp')

Without optimization (or with O3), i have the following output:
In test: 
1 2
3 4
In foo: 
1 2
3 4

Which makes sense. Now if I turn on O1 or O2, I get:
In test: 
1 2
3 4
In foo: 
1 3
3 4

The bug does not appear when using boost::array or when replacing the structure
by a simple C-array (double[2][2]) or by pairs (std::pair).

[Bug c++/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libgomp/69555] New: libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 69555
   Summary: libgomp.c++/target-6.C fails because of undefined
behaviour
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
CC: jakub at gcc dot gnu.org, krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: s390x

The test case libgomp.c++/target-6.C fails on s390x, and I think that's because
it uses a reference type variable in a "private" construct:

-- snip --
...
  int a[y - 2], b[y - 2]; 
  int ()[y - 2] = a, ()[y - 2] = b;
  ^^^
  ...
  #pragma omp target private (x, u, s, c, i) firstprivate (y, v, t, d)
map(from\
:err)
  ^^^
  { 
...
for (i = 0; i < y - 2; i++) 
  c[i] = d[i];
...
  }
  ...
-- snip --

Depending on optimisations and the rest of the code, this leads to either
incorrect values in the array "a" or accessing a pointer to random memory.

As far as I understand it, the "OpenMP Application Program Interface, Version
4.0 - July 2013" explicitly forbids this on page 161:

28 • A variable that appears in a private clause must not have an incomplete
type or a
29   reference type.

[Bug tree-optimization/69556] New: [6 Regression] forwprop4/match.pd undoing work from recip

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 69556
   Summary: [6 Regression] forwprop4/match.pd undoing work from
recip
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---

For this code compiled at -Ofast:

double bar (double, double, double, double, double);

double
foo (double a)
{
  return bar (1.0/a, 2.0/a, 4.0/a, 8.0/a, 16.0/a);
}


GCC 5 generates:

foo:
.LFB0:
.cfi_startproc
movsd   .LC0(%rip), %xmm1
movsd   .LC1(%rip), %xmm4
movsd   .LC2(%rip), %xmm3
divsd   %xmm0, %xmm1
movsd   .LC3(%rip), %xmm2
mulsd   %xmm1, %xmm4
movapd  %xmm1, %xmm0
mulsd   %xmm1, %xmm3
mulsd   %xmm1, %xmm2
addsd   %xmm1, %xmm1
jmp bar

(i.e. one divide, 4 multiplies)

GCC trunk at revision r232907 generates:

foo:
.LFB0:
.cfi_startproc
movapd  %xmm0, %xmm5
movsd   .LC0(%rip), %xmm4
movsd   .LC4(%rip), %xmm0
movsd   .LC1(%rip), %xmm3
movsd   .LC2(%rip), %xmm2
movsd   .LC3(%rip), %xmm1
divsd   %xmm5, %xmm0
divsd   %xmm5, %xmm4
divsd   %xmm5, %xmm3
divsd   %xmm5, %xmm2
divsd   %xmm5, %xmm1
jmp bar

(i.e. 5 divides)

This is bad for performance.

forwprop4 shows:

Applying pattern match.pd:453, gimple-match.c:32116
gimple_simplified to _2 = 1.6e+1 / a_1(D);
Applying pattern match.pd:453, gimple-match.c:32116
gimple_simplified to _3 = 8.0e+0 / a_1(D);
Applying pattern match.pd:453, gimple-match.c:32116
gimple_simplified to _4 = 4.0e+0 / a_1(D);
Applying pattern match.pd:453, gimple-match.c:32116
gimple_simplified to _5 = 2.0e+0 / a_1(D);


This starts with r229107 which moves the (C1/X)*C2 into (C1*C2)/X pattern from
fold-const.c to match.pd.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
Example:

-- snip --
#include  
int main () 
{ 
  int a; 
  int  = a; 
  printf("a %p\n", ); 
  printf("g %p\n", ); 
  #pragma omp target private (c) 
  { 
printf("t %p\n", ); 
  } 
  return 0; 
} 
-- snip --

prints

  a 0x3a0edb4
  g 0x3a0edb4
  t 0x3a0ea24  <--- c in the loop points to different memory

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

--- Comment #11 from Milan Bouchet-Valat  ---
(In reply to Marek Polacek from comment #9)
> Note that this was only accepted by the C++ compiler; the C compiler always
> rejected such a code (going back to at least gcc 3.4).

Indeed you're right. The example only compiles with gcc (both 5 and 6) after
changing the first struct member to *fieldptr0[0].

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

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Any progress on this?

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[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

--- Comment #20 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #19)
> Any progress on this?

Yes, I'm testing patches for both arm and aarch64 to fix this.
I'll try to post them early next week

[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error

[jakub at gcc dot gnu.org]

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

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

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz
  Component|c++ |middle-end

--- Comment #2 from Markus Trippelsdorf  ---
Started with r229265:

commit 2425f3b6ce0532030e1e4274d0fc82a5d7e16c79
Author: hubicka 
Date:   Fri Oct 23 18:05:55 2015 +

* fold-const.c (operand_equal_p): Do not compare TYPE_MODE when
comparing addresses.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
So if the intention is for the C++ front-end to match the C front-end then this
should be accepted (and there's no need to allow the original example even with
-fpermissive).

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
Does it work on other platforms?

[Bug middle-end/32401] [PPC/Altivec] Non optimal code structure with -mabi=altivec

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
New

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
Sure.  Can I provide any debug information or another kind of help?

[Bug c++/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||wrong-code
   Last reconfirmed||2016-01-29
  Component|libstdc++   |c++
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Optimizations O1/O2 makes   |[6 Regression]
   |std::array value incorrect  |Optimizations O1/O2 makes
   |when passed to function |std::array value incorrect
   ||when passed to function
  Known to fail||6.0

--- Comment #1 from Markus Trippelsdorf  ---
This is not a libstdc++ issue.
gcc-5 and clang don't miscompile the example.

[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 29 14:07:40 2016
New Revision: 232981

URL: https://gcc.gnu.org/viewcvs?rev=232981=gcc=rev
Log:
PR target/66137
* gcc.target/i386/pr66137.c: New test.

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

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 29 14:14:56 2016
New Revision: 232982

URL: https://gcc.gnu.org/viewcvs?rev=232982=gcc=rev
Log:
PR target/69551
* config/i386/i386.c (ix86_expand_vector_set) : For
SSE1, copy target into the temporary reg first before recursing
on it.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69551.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.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

--- Comment #21 from ktkachov at gcc dot gnu.org ---
Patches posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02308.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02309.html

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 29 14:37:02 2016
New Revision: 232983

URL: https://gcc.gnu.org/viewcvs?rev=232983=gcc=rev
Log:
PR target/69551
* config/i386/i386.c (ix86_expand_vector_set) : For
SSE1, copy target into the temporary reg first before recursing
on it.

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

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr69551.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
But the test is OpenMP 4.5, and OpenMP 4.5 does allow reference types in the
privatization clauses.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Works on x86_64/i686/ppc64/ppc64le/aarch64 for me, fails on armv7hfp, s390{,x}.
I'm not saying there is not a middle-end bug, will need to analyze it.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
It is well defined.
Anyway, most likely the bug is already during gimplification.
I see in the omplower dump:
  int[0:(sizetype) D.2477] & c;
...
  D.2477 = D.2476 + -1;
...
#pragma omp target num_teams(1) thread_limit(0) map(from:err [len: 4])
firstprivate(d) firstprivate(t) firstprivate(v) firstprivate(y) priv
ate(i) private(c) private(s) private(u) private(x) [child fn:
_Z3fooRiS_R1SS1_RdS2_._omp_fn.0 (.omp_data_arr.7, .omp_data_sizes.8,
.omp_data_kinds.
9)]
  {
try
  {
...
D.2689 = (sizetype) D.2477;
D.2690 = D.2689 + 1;
D.2691 = D.2690 * 4;
D.2692 = __builtin_alloca_with_align (D.2691, 32);
c = D.2692;

Accessing an automatic variable from the caller inside of target region is
wrong, it should have been made firstprivate during gimplification, which would
allow it to work.

[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 29 09:25:14 2016
New Revision: 232969

URL: https://gcc.gnu.org/viewcvs?rev=232969=gcc=rev
Log:
PR c++/69509
PR c++/69516
* constexpr.c (cxx_eval_array_reference): Give the "array subscript
out of bound" error earlier.
* init.c (build_vec_init): Change NE_EXPR into GT_EXPR.  Update the
commentary.

* g++.dg/ext/constexpr-vla2.C: New test.
* g++.dg/ext/constexpr-vla3.C: New test.
* g++.dg/ubsan/vla-1.C: Remove dg-shouldfail.

Added:
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C

[Bug c++/69509] [5/6 regression] infinite loop compiling a VLA in a recursive constexpr function

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 29 09:25:14 2016
New Revision: 232969

URL: https://gcc.gnu.org/viewcvs?rev=232969=gcc=rev
Log:
PR c++/69509
PR c++/69516
* constexpr.c (cxx_eval_array_reference): Give the "array subscript
out of bound" error earlier.
* init.c (build_vec_init): Change NE_EXPR into GT_EXPR.  Update the
commentary.

* g++.dg/ext/constexpr-vla2.C: New test.
* g++.dg/ext/constexpr-vla3.C: New test.
* g++.dg/ubsan/vla-1.C: Remove dg-shouldfail.

Added:
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C
trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C

[Bug debug/66869] [6 regression] -Wunused-function no longer warns for static declarations without definition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69533] [6 Regression] python miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok, makes sense if b and c are signed and thus overflow is undefined.  Where's
that code in python?

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gmail dot com]

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

--- Comment #1 from Alan Modra  ---
Created attachment 37516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37516=edit
possible fix

This fixes the testcase on gcc-5.  I haven't yet bootstrapped it, or
investigated why the problem doesn't seem to occur on master.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
(In reply to Milan Bouchet-Valat from comment #8)
> As I said, I don't deny it's the correct application of the standard, nor
> that it's a sane behavior. But the fact that this was accepted without even
> a warning by default in the last GCC release, and that no way to disable the
> error is offered in GCC 6 creates problems for existing code bases.

Note that this was only accepted by the C++ compiler; the C compiler always
rejected such a code (going back to at least gcc 3.4).

[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|5.3.0   |4.9.2
   Severity|major   |enhancement

--- Comment #8 from Jonathan Wakely  ---
(In reply to Paolo Carlini from comment #7)
> I'm not sure the two bugs are exactly equivalent. Anyway, when working on
> these optimization issues, let' remember c++/63164 too.

They're not the same at all, one involves virtual bases and one involves
devirtualising calls to virtual functions in (non-virtual) bases.

PR 67184 is the same as my PR 69445 though.

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 29 10:52:08 2016
New Revision: 232974

URL: https://gcc.gnu.org/viewcvs?rev=232974=gcc=rev
Log:
Fix Cygwin bootstrap error due to TM symbols

PR libstdc++/69506
* config/os/newlib/os_defines.h (_GLIBCXX_USE_WEAK_REF): Define.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/os/newlib/os_defines.h

[Bug c++/67184] Missed optimization with C++11 final specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

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

[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
dup

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

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The code is nonsense, what's it even supposed to do?

It would be invalid in C (where flexible arrays are actually standard) because
flexible arrays can only be the last member, *and* because apart from the
flexible arrays it's an otherwise empty struct. It's useless, and only compiled
by accident.

Allowing it with -fpermissive might make sense though, as that flag allows all
kinds of terrible rubbish to compile.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

--- Comment #4 from Milan Bouchet-Valat  ---
Yes, -fpermissive is a better solution. The code at stake has been replaced in
the master branch, but breaking API in stable releases isn't great.

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|Wrong code with single  |[4.9/5/6 Regression] Wrong
   |element vector insert   |code with single element
   ||vector insert

--- Comment #4 from Jakub Jelinek  ---
Started with r206420.  Works with gcc 4.8.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

--- Comment #8 from Milan Bouchet-Valat  ---
(In reply to Marek Polacek from comment #6)
> (In reply to Milan Bouchet-Valat from comment #5)
> > Note this actually also happens with the C compiler (the attached example
> > also illustrates this).
> 
> That's the correct behavior.

As I said, I don't deny it's the correct application of the standard, nor that
it's a sane behavior. But the fact that this was accepted without even a
warning by default in the last GCC release, and that no way to disable the
error is offered in GCC 6 creates problems for existing code bases.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Milan Bouchet-Valat from comment #5)
> Note this actually also happens with the C compiler (the attached example
> also illustrates this).

Which is a Good Thing.

It's also a Good Thing that the C++ compiler is now consistent.

GCC has improved. Much rejoicing.

[Bug c++/69550] New: Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

Bug ID: 69550
   Summary: Need a way to disable "flexible array member in an
otherwise empty struct" error on GCC 6
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nalimilan at club dot fr
  Target Milestone: ---

Created attachment 37514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37514=edit
Test C++ program which compiles with GCC 5 but not with GCC 6

GCC 6 has become stricter than GCC 5 as regards having two flexible array
members in a struct with no other fields. In GCC 5, the attached test program
used to compile fine. It only triggered a warning with -Wpedantic. In GCC 6, it
triggers an error with all -std modes.

While this is arguably against the standard, the fact that this code was
accepted before and not in GCC 6 is a problem when the public API of a library
includes such a construct: the library cannot be built with GCC 6 without
breaking the API. This is the case for Julia [1].

Would it be possible to provide a way to turn the error into a warning? For
example, -std=gnu++11 could allow this, while -std=c++11 would still consider
it as an error.



1: https://github.com/JuliaLang/julia/pull/14829

[Bug fortran/67451] [5/6 Regression] ICE with sourced allocation from coarray.

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So
--- gcc/config/i386/i386.c.jj   2016-01-28 15:07:25.0 +0100
+++ gcc/config/i386/i386.c  2016-01-29 13:02:32.100788474 +0100
@@ -46744,6 +46744,7 @@ ix86_expand_vector_set (bool mmx_ok, rtx
{
  /* For SSE1, we have to reuse the V4SF code.  */
  rtx t = gen_reg_rtx (V4SFmode);
+ emit_move_insn (t, gen_lowpart (V4SFmode, target));
  ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt);
  emit_move_insn (target, gen_lowpart (mode, t));
}
?

[Bug target/69533] [6 Regression] python miscompilation

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
I believe it's in replace_substring.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
Also see PR 60336 for impact of empty class.

[Bug target/69533] [6 Regression] python miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ugh, totally insufficient patch.  Probably warrants a CVE, I'm sure some of
them we optimized before, like

 old_size = sz;
 sz += a;
 if (sz < old_size)
   ...

I'll dig further (just look for PyExc_OverflowError) and when I get the
testsuite clean bug our security guys with a patch.

[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 29 11:21:19 2016
New Revision: 232976

URL: https://gcc.gnu.org/viewcvs?rev=232976=gcc=rev
Log:
2016-01-29  Richard Biener  

PR tree-optimization/69547
* tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1):
Do not mark clobbers necessary.
(mark_all_reaching_defs_necessary_1): Likewise.

* g++.dg/tree-ssa/pr69547.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr69547.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dce.c

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
> Im sure there are more...

One more case that I just ran across by coincidence (from resolve.c):


  if (warn_compare_reals)
{
  gfc_intrinsic_op op = e->value.op.op;

  /* Type conversion has made sure that the types of op1 and op2
 agree, so it is only necessary to check the first one.   */
  if ((op1->ts.type == BT_REAL || op1->ts.type == BT_COMPLEX)
  && (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS
  || op == INTRINSIC_NE || op == INTRINSIC_NE_OS))
{
  const char *msg;

  if (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS)
msg = "Equality comparison for %s at %L";
  else
msg = "Inequality comparison for %s at %L";

  gfc_warning (0, msg, gfc_typename (>ts), >where);
}
}

[Bug middle-end/69551] New: Wrong code with single element vector insert

[ubizjak at gmail dot com]

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

Bug ID: 69551
   Summary: Wrong code with single element vector insert
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

Following testcase aborts when compiled with "-O2 -msse -mno-sse2":

--cut here--
typedef unsigned char v16qi __attribute__ ((vector_size (16)));
typedef unsigned int v4si __attribute__ ((vector_size (16)));

char __attribute__((noinline, noclone))
test (v4si vec)
{
  vec[1] = 0x5fb856;

  return ((v16qi) vec)[0];
}

int
main ()
{
  char z = test ( (v4si) {-1, -1, -1, -1} );

  if (z != -1)
__builtin_abort ();
  return 0;
}
--cut here--

$ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc/ -O2 -msse -mno-sse2 -m32 tt.c 
$ ./a.out
Aborted

The test function expands to following RTL:

1: NOTE_INSN_DELETED
4: NOTE_INSN_BASIC_BLOCK 2
2: r91:V4SI=xmm0:V4SI
3: NOTE_INSN_FUNCTION_BEG
6: r92:SI=0x5fb856
7: r94:V4SF=r93:V4SF
8: r93:V4SF=vec_select(vec_concat(r93:V4SF,r93:V4SF),parallel)
9: r93:V4SF=vec_merge(vec_duplicate(r92:SI#0),r93:V4SF,0x1)
   10: r93:V4SF=vec_select(vec_concat(r93:V4SF,r94:V4SF),parallel)
   11: r91:V4SI=r93:V4SF#0
   12: r96:SI#0=vec_select(r91:V4SI#0,parallel)
   13: r90:QI=r96:SI#0
   17: ax:QI=r90:QI
   18: use ax:QI

which is already wrong. r91, used to pass argument is not used anywhere.

[Bug target/69551] Wrong code with single element vector insert

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #2 from Richard Biener  ---
So we go the store_field path in expand_assignment with to_rtx being a V4SI reg
which ends up using the vec_set_optab producing this code:

  /* Use vec_set patterns for inserting parts of vectors whenever
 available.  */
  if (VECTOR_MODE_P (GET_MODE (op0))
  && !MEM_P (op0)
  && optab_handler (vec_set_optab, GET_MODE (op0)) != CODE_FOR_nothing
  && fieldmode == GET_MODE_INNER (GET_MODE (op0))
  && bitsize == GET_MODE_UNIT_BITSIZE (GET_MODE (op0))
  && !(bitnum % GET_MODE_UNIT_BITSIZE (GET_MODE (op0
{
  struct expand_operand ops[3];
  machine_mode outermode = GET_MODE (op0);
  machine_mode innermode = GET_MODE_INNER (outermode);
  enum insn_code icode = optab_handler (vec_set_optab, outermode);
  int pos = bitnum / GET_MODE_BITSIZE (innermode);

  create_fixed_operand ([0], op0);
  create_input_operand ([1], value, innermode);
  create_integer_operand ([2], pos);
  if (maybe_expand_insn (icode, 3, ops))
return true;

[Bug target/67839] Bit addressable instructions generated for invalid memory address

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #5 from Senthil Kumar Selvaraj  ---
The patch did not make it to the 5 branch, my fault really - guess I forgot to
submit it for backporting.

Not sure how you get that code though - I pulled the latest gcc-5_branch
(svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@232962), built it with
main.c from PR 69330, and this is what I got


cbi 0x20,0
ldi r24,0
ldi r25,0
ret
.size   main, .-main
.ident  "GCC: (GNU) 5.3.1 20160129"

The problem shows up only when define_special_predicate is used - 4.9 and below
only used define_predicate. Like I said in the first comment, I don't know wny
that was changed.

The change of constraint from n to i, IIRC, was to defer address computation
for IO instructions to link time, so that that io and io_low attributes work
(https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html)

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Milan Bouchet-Valat from comment #5)
> Note this actually also happens with the C compiler (the attached example
> also illustrates this).

That's the correct behavior.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
CCing Martin.

[Bug c++/67184] Missed optimization with C++11 final specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed|2015-08-11 00:00:00 |2016-1-29
 Resolution|DUPLICATE   |---

--- Comment #4 from Jonathan Wakely  ---
Not a dup, this is a different case.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.  Made me notice we only remove empty loops at -O2.  Sth to think about
for GCC7.

[Bug middle-end/69551] Wrong code with single element vector insert

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-29
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  And note how r93 is used uninitialized.

[Bug driver/69552] flto save-temps overwrites file

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Yes, there's no linker output so we use whatever else.  We could try falling
back to a.out.

Similarly without LTO -save-temps overwrites files if you do

gcc t.c t.C

both assembly and linker files will be t.s/t.o and the link will even fail.

t.c
---
int main() { foo();}

t.C
---
extern "C" int foo () {}

so hardly a new issue with -save-temps - you need to know what you are doing.

[Bug target/69533] [6 Regression] python miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 37519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37519=edit
patch to fix it in two places

Uh, indeed.  Looks like those kind of broken overflow checks are everywhere
(well, the one we optimize only in two places).

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Milan Bouchet-Valat from comment #0)
> Would it be possible to provide a way to turn the error into a warning? For
> example, -std=gnu++11 could allow this, while -std=c++11 would still
> consider it as an error.

There is no reason to sanction this as a supported GNU extension. If it's
allowed it should only be via -fpermissive which means "yes I know my code is
rubbish but I can't fix it".

[Bug debug/66869] [6 regression] -Wunused-function no longer warns for static declarations without definition

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 29 11:14:42 2016
New Revision: 232975

URL: https://gcc.gnu.org/viewcvs?rev=232975=gcc=rev
Log:
PR debug/66869
* decl.c (wrapup_globals_for_namespace): Warn about unused static
function declarations.

* g++.dg/warn/Wunused-function2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-function2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module procedure"

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
(In reply to Paul Thomas from comment #7)
> I could be wrong but I do not agree that this is valid code. I will turn to
> it tomorrow. I believe that a MODULE SUBROUTINE/FUNCTION declaration cannot
> appear in the contained part of a module.

It seems that I was wrong. From the Fortran 2008 standard:

C1247 (R1225) MODULE shall appear only in the function-stmt or subroutine-stmt
of a module subprogram or of a nonabstract interface body that is declared in
the scoping unit of a module or submodule.

Modifying the gcc_assert (trans-decl.c:2065) that causes the ICE to
  bool module_procedure;

  module_procedure = sym->attr.module_procedure
 && sym->ns
 && sym->ns->proc_name
 && sym->ns->proc_name->attr.flavor == FL_MODULE;

  gcc_assert (!sym->attr.external || module_procedure);

Gives what seems to be the correct behaviour and allows:
module A

  interface
 module subroutine A1(i)
   integer i
 end subroutine A1
 module subroutine B1(i)
   integer i
 end subroutine B1
  end interface

contains

  module subroutine A1(i)
integer  i

print *, 'A::A1(): i == ', i
  end subroutine A1
end module A

submodule (A) a_son
contains
  module procedure b1
print *, 'A_SON::B1(): Calling A1'
call a1(i)
  end procedure
end submodule

  use A
  call b1 (42)
end

to do the right thing.

I cannot remember at all where module procedures pick up the external
attribute. It would be better to modify this at source rather than the fix
above :-)

Paul

[Bug target/69551] Wrong code with single element vector insert

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
 if (SSE2)
 
 else
  /* For SSE1, we have to reuse the V4SF code.  */
  rtx t = gen_reg_rtx (V4SFmode);
  ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt);
  emit_move_insn (target, gen_lowpart (mode, t));

somehow ends up recursing in a weird way, using the new reg t but nowhere
using 'target' apart from overwriting it in the end

[Bug driver/69552] New: flto save-temps overwrites file

[vries at gcc dot gnu.org]

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

Bug ID: 69552
   Summary: flto save-temps overwrites file
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Say we use save-temps with flto in it's simplest form:
...
$ gcc -O2 -flto banana.c orange.c lemon.c -O2 -fno-use-linker-plugin
-flto-partition=none -save-temps
...

After compilation we have:
...
$ ls -1 | egrep -v '\.(c|i)$'
a.out
banana.o
banana.s
lemon.o
lemon.s
orange.o
orange.s
...

Both lemon.s and orange.s contain gimple and assembly from the initial cc1
invocation.

But banana.s contains only assembly, and contains at the beginning '.file
""'. It contains the output of lto1.

When adding -c, we see the original contents of banana.s from cc1: gimple and
assembly, starting with '.file "banana.c"'.

So, we appear to be using the file banana.s twice in the compilation process.

Confirmed by grepping:
...
$ gcc -O2 -flto banana.c orange.c lemon.c -O2 -fno-use-linker-plugin
-flto-partition=none -save-temps -v  2>&1 | grep '\-o banana.s'
 libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1 -fpreprocessed banana.i -quiet
-dumpbase banana.c -mtune=generic -march=x86-64 -auxbase banana -O2 -O2
-version -flto -fno-use-linker-plugin -flto-partition=none -o banana.s
 libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto1 -quiet -dumpbase banana.o
-mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
/tmp/ccbAWzhX.lto.o -O2 -O2 -O2 -O2 -version -fmath-errno -fsigned-zeros
-ftrapping-math -fno-trapv -fno-openmp -fno-openacc -fno-use-linker-plugin
-flto-partition=none @/tmp/cctx7jrX -o banana.s
...

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Patch I'm going to bootstrap/regtest momentarily.

[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> So
> --- gcc/config/i386/i386.c.jj 2016-01-28 15:07:25.0 +0100
> +++ gcc/config/i386/i386.c2016-01-29 13:02:32.100788474 +0100
> @@ -46744,6 +46744,7 @@ ix86_expand_vector_set (bool mmx_ok, rtx
>   {
> /* For SSE1, we have to reuse the V4SF code.  */
> rtx t = gen_reg_rtx (V4SFmode);
> +   emit_move_insn (t, gen_lowpart (V4SFmode, target));
> ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt);
> emit_move_insn (target, gen_lowpart (mode, t));
>   }
> ?

Yep. Pre-approved everywhere, if you want to continue with the patch.

[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6

[nalimilan at club dot fr]

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

--- Comment #5 from Milan Bouchet-Valat  ---
Note this actually also happens with the C compiler (the attached example also
illustrates this).

[Bug debug/69518] [6 Regression] Flag -g causes "error: type variant has different TYPE_VFIELD"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  The problem is that when type variants are created, the generic
code copies there also the TYPE_VFIELD aka C_TYPE_INCOMPLETE_VARS.  We clear it
only in the main type variant, but not in other variants, so if not anything
else, it is at least undesirable for GC purposes, plus we leak the C FE use of
that field into the middle-end.

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I suspect the place to start at is looking what arm_function_value does for the
lto case. This is where the code decides what register the function returns its
value based on ABI.

But I'm having a tough time getting gdb to attach properly to debug the final
LTO combination :(

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
So during LTO compilation inside aapcs_allocate_return_reg
the pcs_variant used is ARM_PCS_AAPCS_LOCAL (/* Private call within this
compilation unit.  */)

whereas for non-LTO it is:
ARM_PCS_AAPCS_VFP (/* Use VFP registers for floating point values.  */)

[Bug c++/69462] FLT_EVAL_METHOD and DECIMAL_DIG missing in float.h

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Jan 29 10:03:26 2016
New Revision: 232970

URL: https://gcc.gnu.org/viewcvs?rev=232970=gcc=rev
Log:
PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h.

gcc/ChangeLog

PR c++/69462
* ginclude/float.h: Also provide FLT_EVAL_METHOD and DECIMAL_DIG
for C++-11.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ginclude/float.h

[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/69544] [5/6 Regression] Internal compiler error with -Wall and where

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 6.

[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 29 08:36:04 2016
New Revision: 232968

URL: https://gcc.gnu.org/viewcvs?rev=232968=gcc=rev
Log:
2016-01-29  Richard Biener  

PR middle-end/69537
* match.pd: Allow all integral types when simplifying a
widening or sign-changing conversion.

* gcc.dg/uninit-21.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-21.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Martin is planning some changes, thus confirmed.

[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Jan 29 10:12:11 2016
New Revision: 232972

URL: https://gcc.gnu.org/viewcvs?rev=232972=gcc=rev
Log:
PR other/69006: S/390: Fix extra newlines after diagnostics.

gcc/ChangeLog

PR other/69006
* config/s390/s390-c.c (s390_resolve_overloaded_builtin): Remove
trailing blank line from error message.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390-c.c

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Started with r222135.

[Bug c++/69509] [5/6 regression] infinite loop compiling a VLA in a recursive constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 6.

[Bug target/69459] [5 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
   |with -O2 and vector |with -O2 and vector
   |arithmetics @ x86_64|arithmetics @ x86_64

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

[Bug target/69533] [6 Regression] python miscompilation

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Quick update.  It appears that we've got something like this


t = b * c;
r = b / c;

if (r != b)
   


Which python is using as an overflow check.  We now know how to optimize the
mul/div sequence, which in turn causes the IF statement to have a known value. 
Ultimately we end up removing the overflow check, which appears to make the
python testsuite unhappy.

[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Hmm, so we have

  :
  # _1 = PHI <(2), _9(4)>
  # _2 = PHI <63(2), _10(4)>
  if (_2 == -1)
goto ;
  else
goto ;

  :
  MEM[(struct  &)_1] ={v} {CLOBBER};
  _9 = _1 + 1;
  _10 = _2 + -1;
  goto ;

in CDDCE and do

processing: foo (, 64);

marking necessary through .MEM_15 stmt MEM[(struct  &)_1] ={v} {CLOBBER};
processing: MEM[(struct  &)_1] ={v} {CLOBBER};

I'm trying a patch to fix that.

[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/69557] New: [ARM] revsh instruction not being conditionalised for Thumb2

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69557
   Summary: [ARM] revsh instruction not being conditionalised for
Thumb2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm*

While doing some of the testcase splitting work for PR 65578
I saw that we don't use conditional execution as much as we should for Thumb2.

The testcase:

extern short foos16 (short);
/* revshne */
short swaps16_cond (short x, int y)
{
  short z = x;
  if (y)
z = __builtin_bswap16 (x);
  return foos16 (z);
}

for -march=armv6t2 -mthumb -O2 I get:
swaps16_cond:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cbz r1, .L2
revsh   r0, r0
.L2:
b

whereas for -march=armv6t2 -mthumb -O2 we get conditional execution:
swaps16_cond:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r1, #0
revshne r0, r0
.L2:
b

Note that the -marm version gets conditionalised at the very end in
arm_final_prescan_insn which we don't perform for Thumb2.

The ce3 pass doesn't create the COND_EXEC forms like I'd expect.
For the testcase above it refuses to perform any transformations in
cond_exec_find_if_block (from ifcvt.c) where it fails the check:

  /* The edges of the THEN and ELSE blocks cannot have complex edges.  */
  FOR_EACH_EDGE (cur_edge, ei, then_bb->preds)
{
  if (cur_edge->flags & EDGE_COMPLEX)
return FALSE;
}

Seems the edge is deemed complex so ifconversion bails out.

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-29
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I suspect we should disable "Fold (C1/X)*C2 into (C1*C2)/X" for gimple then and
have it only for generic.

[Bug target/69459] [5 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 29 16:52:15 2016
New Revision: 232988

URL: https://gcc.gnu.org/viewcvs?rev=232988=gcc=rev
Log:
PR target/69459
* config/i386/constraints.md (C): Only accept constant zero operand.
(BC): New constraint.
* config/i386/sse.md (*mov_internal): Use BC constraint
instead of C constraint.
* doc/md.texi (Machine Constraints): Update description
of C constraint.

testsuite/ChangeLog:

PR target/69459
* gcc.target/i386/pr69459.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr69459.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/constraints.md
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[jakub at gcc dot gnu.org]

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

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

Updated non-working patch.  Clearly adjusting the METHOD_TYPEs of some cdtors
is a nightmare, giving up.

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Vladimir Makarov from comment #12)
> (In reply to H.J. Lu from comment #11)
> > (In reply to H.J. Lu from comment #10)
> > > Created attachment 37512 [details]
> > > A new patch
> > > 
> > > I am testing this now.
> > 
> > No regressions on x86-64.  I will leave it to Vladimir.
> 
> Thanks, HJ.  I'll investigate it.  It will take some time.  But what I see
> you removed a code in LRA which was used to fix some bugs.  And it is
> questionable for me.

I reverted r229087 which was supposed to fix PR 67609 which is tracked by
gcc.target/i386/pr67609-2.c and gcc.target/i386/pr67609.c.  Apparently
r229458 made r229087 unnecessary.

[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[sje at gcc dot gnu.org]

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

--- Comment #4 from Steve Ellcey  ---
Author: sje
Date: Fri Jan 29 16:29:58 2016
New Revision: 232985

URL: https://gcc.gnu.org/viewcvs?rev=232985=gcc=rev
Log:
PR target/65604
* config/mips/mips.c (mips_output_division): Check flag_delayed_branch.

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

[Bug target/65010] ppc backend generates unnecessary signed extension

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
Not the same thing.  The ABI requires sign extension for the function
result and the parameters.  In PR23450, the request is we do not follow
the ABI for a function that is only called locally.  In this PR on the
other hand, the sign extension will never do anything, so the PR asks
for the code to be optimised better, removing the unnecessary extsw.

[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Fri Jan 29 16:31:18 2016
New Revision: 232986

URL: https://gcc.gnu.org/viewcvs?rev=232986=gcc=rev
Log:
PR target/65604
* gcc.target/mips/div-delay.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/div-delay.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
  foo (_13, _11);
  _9 = [(const int[2] &)t_2(D) + 8][1];
  foo (_11, _9); [tail call]

Trying to reduce the issue.

(In reply to Markus Trippelsdorf from comment #2)
> Started with r229265:
> 
> commit 2425f3b6ce0532030e1e4274d0fc82a5d7e16c79
> Author: hubicka 
> Date:   Fri Oct 23 18:05:55 2015 +
> 
> * fold-const.c (operand_equal_p): Do not compare TYPE_MODE when
> comparing addresses.

I think this just exposed the issue somewhere else.

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I suspect we should disable "Fold (C1/X)*C2 into (C1*C2)/X" for gimple then
> and have it only for generic.

Or check for single use of the divide.