[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #12 from Mikael Morin  ---
Patch for comment #0 submitted at:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00085.html

reviewed at:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00186.html

[Bug middle-end/69643] Address space discarded

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Fri Feb  5 22:05:17 2016
New Revision: 233189

URL: https://gcc.gnu.org/viewcvs?rev=233189=gcc=rev
Log:
PR c/69643

  * tree.c (tree_nop_conversion_p): Do not strip casts into or
  out of non-standard address spaces.
testsuite/
  * gcc.target/i386/addr-space-4.c: New.
  * gcc.target/i386/addr-space-5.c: New.

Added:
trunk/gcc/testsuite/gcc.target/i386/addr-space-4.c
trunk/gcc/testsuite/gcc.target/i386/addr-space-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/69698] New: [meta-bug] flexible array members

[msebor at gcc dot gnu.org]

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

Bug ID: 69698
   Summary: [meta-bug] flexible array members
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This bug collects issues with the g++ implementation of flexible array members.

[Bug tree-optimization/69675] [6 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
The patch of comment #4 appears to be easily extendible to reject
arrays as loop variables (I hope I got this right):

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 232904)
+++ gcc/fortran/match.c (working copy)
@@ -877,6 +877,18 @@
   if (m != MATCH_YES)
 return MATCH_NO;

+  if (var->ts.type == BT_CHARACTER)
+{
+  gfc_error ("Loop variable at %C cannot be of type CHARACTER");
+  goto cleanup;
+}
+
+  if (var->symtree->n.sym->attr.dimension)
+{
+  gfc_error ("Loop variable at %C cannot be an array");
+  goto cleanup;
+}
+
   /* F2008, C617 & C565.  */
   if (var->symtree->n.sym->attr.codimension)
 {

[Bug c++/69700] New: [C++14] constexpr incorrectly implies const

[michael.price at synopsys dot com]

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

Bug ID: 69700
   Summary: [C++14] constexpr incorrectly implies const
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.price at synopsys dot com
  Target Milestone: ---

Created attachment 37602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37602=edit
preprocessed source

The following code (derived from the subject of CWG DR 1683) should be
ill-formed in C++14:

  struct A {
  constexpr A() {}
  constexpr operator int() { return 1; }
  };

  template  struct X {};

  constexpr A a;
  X x;


GCC compiles it as if it were C++11, under which it is well-formed. The output
below is from 5.2.0, but the behavior 4.9.0 through 5.3.0 seemed consistent.

  $ g++ -v -save-temps -c -std=c++14 constexpr-vs-const.cpp
  Using built-in specs.
  COLLECT_GCC=/opt/pkg/gcc-5.2.0/bin/g++
  Target: x86_64-unknown-linux-gnu
  Configured with: ../gcc-5.2.0/configure --prefix=/opt/pkg/gcc-5.2.0
--program-suffix=-5.2.0 --enable-languages=c,c++
  Thread model: posix
  gcc version 5.2.0 (GCC)
  COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
   /opt/pkg/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E
-quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE constexpr-vs-const.cpp
-mtune=generic -march=x86-64 -std=c++14 -fpch-preprocess -o
constexpr-vs-const.ii
  ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
  ignoring nonexistent directory
"/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include"
  #include "..." search starts here:
  #include <...> search starts here:
  
/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0
  
/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu
  
/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
   /opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
   /usr/local/include
   /opt/pkg/gcc-5.2.0/include
   /opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
   /usr/include/x86_64-linux-gnu
   /usr/include
  End of search list.
  COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
   /opt/pkg/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus
-fpreprocessed constexpr-vs-const.ii -quiet -dumpbase constexpr-vs-const.cpp
-mtune=generic -march=x86-64 -auxbase constexpr-vs-const -std=c++14 -version -o
constexpr-vs-const.s
  GNU C++14 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
  compiled by GNU C version 5.2.0, GMP version 4.3.2, MPFR version
2.4.2, MPC version 0.8.1
  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  GNU C++14 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
  compiled by GNU C version 5.2.0, GMP version 4.3.2, MPFR version
2.4.2, MPC version 0.8.1
  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  Compiler executable checksum: d48b14d3a677b3306bfa594605d7fb25
  COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
   as -v --64 -o constexpr-vs-const.o constexpr-vs-const.s
  GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.22
 
COMPILER_PATH=/opt/pkg/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/:/opt/pkg/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/:/opt/pkg/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/:/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/:/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/
 
LIBRARY_PATH=/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/:/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/opt/pkg/gcc-5.2.0/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../:/lib/:/usr/lib/
  COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
  $

[Bug c++/69701] New: "v.operator T()" incorrectly parsed if "v.T()" present.

[eric at efcs dot ca]

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

Bug ID: 69701
   Summary: "v.operator T()" incorrectly parsed if "v.T()"
present.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37603=edit
reprodu

If a class "B" provides a conversion operator to class "A" and a method named
"A", then trying to explicitly call B's conversion operator will fail to
compile.

I'm not exactly sure what the standard requires, but IMHO B::A shouldn't affect
calls to "b.operator A()" outside of the class body.

[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this should be diagnose differently in that A changes meanings inside
the class.
That is if we used:
 operator A () const noexcept { return {}; }

We get the following error message:
t9.cc:8:12: error: declaration of ‘void B::A()’ [-fpermissive]
  void A() {}
^
t9.cc:2:7: error: changes meaning of ‘A’ from ‘class A’ [-fpermissive]
 class A {};
   ^

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
On it.

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 37606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37606=edit
Patch I'm testing to fix the bug

REG_N_CALLS_CROSSED's computation didn't always disregard debug insns, which
led to the sched differences.  Fixing the function that computes it without
skipping debug insns removes the -fcompare-debug sched differences.

[Bug c++/69686] Useless -Wparentheses for A && B || !A && C

[wipedout at yandex dot ru]

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

--- Comment #5 from wipedout at yandex dot ru ---
Here the compiler just enforces people to add parentheses so that they
accidentally put them wrong and then the compiler is happy and the code is
buggy.

[Bug c++/69277] [6 Regression] ICE mangling a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
Fixed (for the third time).

[Bug c++/69251] [6 Regression] ICE in unify_array_domain on a flexible array member

[msebor at gcc dot gnu.org]

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

Bug 69277 Summary: [6 Regression] ICE mangling a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277

   What|Removed |Added

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

[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> Created attachment 37594 [details]
> Updated tentative patch
> 
> This patch builds, and runs target-libgomp with -flto -flto-partition=1to1
> -fno-toplevel-reorder, giving the same failures as normal (-fno-lto).

Hmm, fails with -fno-use-linker-plugin though.

[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects

[ppalka at gcc dot gnu.org]

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

--- Comment #12 from Patrick Palka  ---
Created attachment 37596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37596=edit
better fix for gcc 7

[Bug c++/69687] Buffer Overflow in libiberty

[boehme.marcel at gmail dot com]

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

--- Comment #4 from Marcel Böhme  ---
Here is my preliminary analysis:
The function demangle_args (cplus-dem.c:4424) parses the (crafted) mangled
function args from the binary. In line 4452, r is read from mangled. In line
4491, we enter a loop with r iterations. In line 4498, arg is parsed from
mangled (always from the same region). In each loop iteration arg is appended
to decl, such that the length of decl grows in each iteration.

The function string_appends (cplus-dem.c:4820) appends string arg to string
decl. In line 4827, it uses string_need to check whether sufficient memory is
allocated in decl to append arg. Then, it memcopies whatever is in arg to the
end of decl.

The function string_need (cplus-dem.c:4751) checks whether sufficient memory is
available to append size-of-arg more characters. If not, xrealloc decl with
n=2*(length of decl + length of arg) characters. Since n is a signed int, n
wraps over at some iteration. Since, realloc expects n to be unsigned, we end
up allocating less memory then actually needed. In the beginning though n is
too large and xrealloc simply complains. However, if you play a bit with the
length of arg, you'll quickly turn that integer overflow in a buffer overflow.
Later, string_appends will memcopy whatever arg contains.

In our simple test case the relevant bits in the binary are specified the
binary (arbitrarily): r = 8000, arg = "A__\235\235\235_N" of
length 020.

A particularly malicious attacker could craft an executable that executes when
*analysed* by objdump, nm or gdb, or any other libbfd / libiberty - based
forensics tool (if the demangling option is switched on).

--
Marcel Böhme
Postdoctoral Researcher
TSUNAMi Security Research Lab
National University of Singapore

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[hjl at gcc dot gnu.org]

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

--- Comment #18 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Feb  5 16:24:06 2016
New Revision: 233180

URL: https://gcc.gnu.org/viewcvs?rev=233180=gcc=rev
Log:
Add a testcase for PR target/69677

PR target/69677
* gcc.target/i386/pr69677.c: New test.

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

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law  ---
Richi,

The patch fixes both the original testcase as well as the reduced testcase. 
The difficultly I see is building a reliable test for the regression suite.  

Parsing RTL dumps looking for the right assignments to the argument registers
is, umm, painful.

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
I've got enough state on this BZ and remember just enough MIPS that I can
verify behaviour with a cross.

[Bug c++/66999] Missing comma in lambda capture causes internal compiler error

[sshannin at gmail dot com]

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

sshannin at gmail dot com changed:

   What|Removed |Added

 CC||sshannin at gmail dot com

--- Comment #1 from sshannin at gmail dot com ---
Confirmed still present in gcc 5.3.0.

I got a smaller example with a slightly different flavor if it helps:

---
#include 

struct foo {
void bar() {
std::function f = std::function(
[]() {
int x;
});
}
};

[Bug c++/69686] Useless -Wparentheses for A && B || !A && C

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to wipedout from comment #5)
> Here the compiler just enforces people to add parentheses so that they
> accidentally put them wrong and then the compiler is happy and the code is
> buggy.

Yes, the compiler forces people to put them in the wrong place. That's right.
That's not a ridiculous assertion at all. Thanks for your bug report.

[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #11 from Patrick Palka  ---
Conservative fix applied for GCC 6, a better fix (attached) is going to replace
it for GCC 7.  A diagnostic is now issued for this invalid constructor call.

(Hopefully for GCC 7 we will no longer silently discard erroneous code like
that, see https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02234.html)

[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I think the bug is in move_plus_up, as that function transforms:
(subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
into:
(plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(const_int 16 [0x10]))
(const_int 16 [0x10]))
which looks just wrong, it should have been
(plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(const_int 16 [0x10])))

[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/69696] New: incorrect initialization of block-scope flexible array members

[msebor at gcc dot gnu.org]

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

Bug ID: 69696
   Summary: incorrect initialization of block-scope flexible array
members
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As pointed in the following discussion
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00420.html, g++ allows local
structs with flexible array members to be initialized on definition but then
allocates the arrays in a way that overlaps other local variables, leading to
data corruption.  In C mode, GCC rejects initialization of such structs (this
was done to fix bug 28865).

G++ should either also reject initialiation of such structs, or it should do it
without this overlapping problem.  Note that bug 68489 is also related to this
problem, as is bug 69338.

The following test case shows that while structures containing flexible array
members and having static or thread storage duration are initialized correctly,
those having automatic storage duration are not. 

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
-Wpedantic -xc++ t.c && ./a.out
enum { X = 12345678, Y = 87654321 };

struct A { int n, a []; };
struct A a0 = { 1, { 2, 3, 4 } };

void print (const int *i, struct A *a, const int *j)
{
__builtin_printf ("\ni = %i\n"
  "a = { %i, { %i, %i, %i }\n"
  "j = %i\n",
  *i, a->n, a->a[0], a->a[1], a->a[2],
  *j);

if (*i != X || *j != Y || a->a[0] != 2 || a->a[1] != 3 || a->a[2] != 4)
   __builtin_abort ();
 }

int main ()
{
{
static int i = X;
static struct A a = { 1, { 2, 3, 4 } };
static int j = Y;

print (, , );
}
{
__thread int i = X;
__thread struct A a = { 1, { 2, 3, 4 } };
__thread int j = Y;

print (, , );
}
{
int i = X;
struct A a = { 1, { 2, 3, 4 } };
int j = Y;

print (, , );
}
}
t.c:4:32: warning: initialization of a flexible array member [-Wpedantic]
 struct A a0 = { 1, { 2, 3, 4 } };
^
t.c: In function ‘int main()’:
t.c:22:46: warning: initialization of a flexible array member [-Wpedantic]
 static struct A a = { 1, { 2, 3, 4 } };
  ^
t.c:28:22: warning: function-scope ‘i’ implicitly auto and declared ‘__thread’
 __thread int i = X;
  ^
t.c:29:27: warning: function-scope ‘a’ implicitly auto and declared ‘__thread’
 __thread struct A a = { 1, { 2, 3, 4 } };
   ^
t.c:29:48: warning: initialization of a flexible array member [-Wpedantic]
 __thread struct A a = { 1, { 2, 3, 4 } };
^
t.c:30:22: warning: function-scope ‘j’ implicitly auto and declared ‘__thread’
 __thread int j = Y;
  ^
t.c:36:39: warning: initialization of a flexible array member [-Wpedantic]
 struct A a = { 1, { 2, 3, 4 } };
   ^

i = 12345678
a = { 1, { 2, 3, 4 }
j = 87654321

i = 12345678
a = { 1, { 2, 3, 4 }
j = 87654321

i = 4
a = { 1, { 2, 3, 4 }
j = 87654321
Aborted (core dumped)

[Bug c++/69696] incorrect initialization of block-scope flexible array members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
   Last reconfirmed||2016-2-5
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
This problem seems to have always existed in C++.

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
Created attachment 37599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37599=edit
Testcase for the testsuite

My best attempt at pulling together the right dg-markers for this test. 
mips.exp does some "interesting" stuff.  I think I managed to narrow it down to
the case we want to test and reasonable strings to search for in the RTL
expansion dump.

Essentially it verifies that we've got a single assignment to $6 (for the
3-argument call to sprintf) and two assignments to $5 (one for the sprintf call
one for the enter call).

When we generate the wrong code we have two assignments to $6 and one to $5.

Use as you see fit.

[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working

[szo at szo dot hu]

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

Szókovács Róbert  changed:

   What|Removed |Added

 CC||szo at szo dot hu

--- Comment #4 from Szókovács Róbert  ---
Confirming for 4.9.1, I found no combination of options to make it work, but in
some cases it actually corrupted the value of the variable.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #32 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
>
> Thus a "fix" for the case where treating a[i] as a[0] is the issue
> would be
> 
> Index: gcc/tree-dfa.c
> ===
> --- gcc/tree-dfa.c  (revision 233172)
> +++ gcc/tree-dfa.c  (working copy)
> @@ -617,7 +617,11 @@ get_ref_base_and_extent (tree exp, HOST_
>if (maxsize == -1
>   && DECL_SIZE (exp)
>   && TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
> -   maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
> +   {
> + maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
> + if (maxsize == size)
> +   maxsize = -1;
> +   }
>  }
>else if (CONSTANT_CLASS_P (exp))
>  {

Maybe if we only did that for DECL_COMMONs if -std=legacy was in force?

Tho as you say:

> but that wouldn't fix the aggressive-loop optimization issue as that is
> _not_ looking at DECL_SIZE but at the array types domain.

I wonder if we can't get both places looking at the same thing (DECL_SIZE or
array type domain), but I haven't looked into that at all.

[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3

[wilson at gcc dot gnu.org]

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

--- Comment #14 from Jim Wilson  ---
Andrew Pinksi wrote the patch to fix the ICE.  I was expecting him to submit
it.

He also pointed out that the code with the patch is inefficient, and can be
optimized by adding some patterns to the aarch64 and arm backends.  I thought
he was going to do the aarch64 work.  I volunteered to look at the arm backend.
 Adding a vcond_mask* pattern gives a sequence one instruction shorter.  To get
a sequence two instructions shorter it looks like I need to rewrite some
patterns to use vector rtl instead of unspecs, which seemed inappropriate at
this time. I was going to look at this again when we move to stage 1.  This
stuff should perhaps be a separate bug report.

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Looking at the LTO data creation, by putting a breakpoint in cc1plus on
lto_output_location to see the values that are written, I see that the
bogus-looking location is coming from this ordinary map.  It has an
insane-looking value for "to_line":
  (gdb) p *map
  $13 = { = {start_location = 8224, reason = LC_LEAVE}, to_file =
0x2154630 "Unified_cpp_js_src35.ii", to_line = 1048576, included_from = -1,
sysp = 0 '\000', m_column_and_range_bits = 12, m_range_bits = 5}

This ordinary map was created within cc1plus in response to the "#" line
directive:
(gdb) bt
#0  linemap_add (set=0x77ffb000, reason=LC_RENAME, sysp=0,
to_file=0x2154630 "Unified_cpp_js_src35.ii", to_line=1048576)
at ../../src/libcpp/line-map.c:560
#1  0x01541f13 in _cpp_do_file_change (pfile=0x213d5d0,
reason=, to_file=, 
file_line=, sysp=) at
../../src/libcpp/directives.c:1071
#2  0x015420bc in do_linemarker (pfile=0x213d5d0) at
../../src/libcpp/directives.c:1056
#3  0x01541cb0 in _cpp_handle_directive (pfile=pfile@entry=0x213d5d0,
indented=)
at ../../src/libcpp/directives.c:510

Within linemap_add, it transitions from this map:
(gdb) p map[-1]
$47 = { = {start_location = 32, reason = LC_ENTER}, to_file =
0x2161630 "Unified_cpp_js_src35.ii", to_line = 1, 
  included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
m_range_bits = 5}

to this map:
(gdb) p *map
$46 = { = {start_location = 0, reason = LC_LEAVE}, to_file = 0x0,
to_line = 0, included_from = 0, sysp = 0 '\000', 
  m_column_and_range_bits = 0, m_range_bits = 0}

and this conditional fires:
  if (MAIN_FILE_P (map - 1))

and we hit this error-handling:
  /* A TO_FILE of NULL is special - we use the natural values.  */
  if (error || to_file == NULL)
{
  to_file = ORDINARY_MAP_FILE_NAME (from);
  to_line = SOURCE_LINE (from, from[1].start_location);
  sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
}
and so we have:
  (gdb) p to_file
  $48 = 0x2161630 "Unified_cpp_js_src35.ii"
  (gdb) p to_line
  $49 = 1048576
  (gdb) p /x to_line
  $50 = 0x10

giving us the bogus to_line value.

Where is this "to_line" value coming from?
  551 to_line = SOURCE_LINE (from, from[1].start_location);

Breakpoint 9, SOURCE_LINE (ord_map=0x77fed000, loc=0) at
../../src/libcpp/include/line-map.h:1092
  (gdb) p *ord_map
  $54 = { = {start_location = 32, reason = LC_ENTER}, to_file =
0x2161630 "Unified_cpp_js_src35.ii", to_line = 1, 
  included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
m_range_bits = 5}

1088/* Converts a map and a source_location to source line.  */
1089inline linenum_type
1090SOURCE_LINE (const line_map_ordinary *ord_map, source_location loc)
1091{
1092  return ((loc - ord_map->start_location)
1093  >> ord_map->m_column_and_range_bits) + ord_map->to_line;
1094}
1095

so we have this calculation: ((0 - 32) >> 12) + 1

(gdb) p /x ((unsigned int)(0 - 32)) >> 12
$59 = 0xf
(gdb) p /x (((unsigned int)(0 - 32)) >> 12) + 1
$60 = 0x10

which explains where the bogus value is coming from.

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
A more minimal reproducer for these insane line numbers:

$ cat test.C
# 9 "" 2
not_a_type a;

# With recent trunk:
$ gcc -c test.C
line-map.c: file "" left but not entered
test.C:1048537:1: error: ‘not_a_type’ does not name a type

# With gcc 4.8.3:
$ /usr/bin/gcc -c test.C
line-map.c: file "" left but not entered
test.C:33554393:1: error: ‘not_a_type’ does not name a type

[Bug fastjar/69695] New: slice of an array retains pointer attribute

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 69695
   Summary: slice of an array retains pointer attribute
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fastjar
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following testcase:

> cat test.f90
module point
  implicit none
  type point_type
integer, dimension(:,:), pointer :: array
  end type point_type
contains
  subroutine ptest(a)
integer, dimension(:), intent(in), pointer :: a
write(*,*) a**2
  end subroutine ptest
end module point
program test
  use point
  implicit none
  integer :: i, j
  type(point_type), pointer:: p1
  integer, dimension(:,:), pointer :: a
  allocate(p1)
  allocate(p1%array(5,2))
  p1%array=42
  a => p1%array
  call ptest(a(:,2))
end program test

returns a valgrind error and seemingly wrong output:

> gfortran -g test.f90 
> valgrind ./a.out
==81284== Memcheck, a memory error detector
==81284== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==81284== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==81284== Command: ./a.out
==81284== 
==81284== Invalid read of size 4
==81284==at 0x400920: __point_MOD_ptest (test.f90:9)
==81284==by 0x400B64: MAIN__ (test.f90:22)
==81284==by 0x400BA3: main (test.f90:13)
==81284==  Address 0x4dbf458 is 0 bytes after a block of size 40 alloc'd
==81284==at 0x4A06B3F: malloc (vg_replace_malloc.c:299)
==81284==by 0x4009B9: MAIN__ (test.f90:19)
==81284==by 0x400BA3: main (test.f90:13)
==81284== 
1764176417641764   0
==81284== 
==81284== HEAP SUMMARY:
==81284== in use at exit: 112 bytes in 2 blocks
==81284==   total heap usage: 21 allocs, 19 frees, 11,952 bytes allocated
==81284== 
==81284== LEAK SUMMARY:
==81284==definitely lost: 72 bytes in 1 blocks
==81284==indirectly lost: 40 bytes in 1 blocks
==81284==  possibly lost: 0 bytes in 0 blocks
==81284==still reachable: 0 bytes in 0 blocks
==81284== suppressed: 0 bytes in 0 blocks
==81284== Rerun with --leak-check=full to see details of leaked memory
==81284== 
==81284== For counts of detected and suppressed errors, rerun with: -v
==81284== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 5)

However, the underlying problem is that gfortran doesn't generate a compile
time error, as the array slice is passed to a subroutine that expects a pointer
argument. Ifort diagnoses this clearly:

> ifort test.f90
test.f90(22): error #7121: A ptr dummy may only be argument associated with a
ptr, and this array element or section does not inherit the POINTER attr from
its parent array.   [A]
  call ptest(a(:,2))
-^
compilation aborted for test.f90 (code 1)

I think this should be diagnosed by gfortran as well.

[Bug fortran/69695] slice of an array retains pointer attribute

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
It's failing this assertion:
803   linemap_assert (SOURCE_LINE (map, r) == to_line);

here:

(gdb) bt
#2  0x01257bba in linemap_line_start (set=0x77ffb000,
to_line=to_line@entry=1048577, max_column_hint=128)
at ../../src/libcpp/line-map.c:803
#3  0x0092e0da in lto_location_cache::apply_location_cache
(this=this@entry=0x1dc6e08)
at ../../src/gcc/lto-streamer-in.c:193

with a bogus-looking line number:
  (gdb) p to_line
  $1 = 1048577

The bogus line number is in the LTO data itself.

[Bug target/69693] Wrong mode is used to load spilled register

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 37598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37598=edit
A patch

It is a backend bug. We need to add

; Used by STV to load a DI into an xmm register.
(define_insn "*movdi_to_v2di"
  [(set (match_operand:V2DI 0 "register_operand" "=x") 
(subreg:V2DI (match_operand:DI 1 "nonimmediate_operand" "xm") 0))]
  "!TARGET_64BIT && TARGET_SSE2"
  "%vmovq\t{%1, %0|%0, %1}"
  [(set_attr "type" "ssemov")
   (set_attr "prefix" "maybe_vex")
   (set_attr "mode" "DI")])

I am testing this patch.

[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Jim Wilson from comment #14)
> Andrew Pinski wrote the patch to fix the ICE.  I was expecting him to submit
> it.

I will be doing it later today.  Got distracted by some Linux performance
patches.

[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Fri Feb  5 17:52:07 2016
New Revision: 233183

URL: https://gcc.gnu.org/viewcvs?rev=233183=gcc=rev
Log:
Make issues similar to PR c++/68948 fail loudly.

* semantics.c (finish_expr_stmt): If expr is error_mark_node,
make sure we've seen_error().

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug rtl-optimization/69609] [6 Regression] block reordering consumes an inordinate amount of time, REE consumes much memory

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Something like this maybe? Tries to determine if too large a fraction of blocks
are only reachable by computed jumps in a large function (which I'm guessing is
what triggers the compile time issues).

diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index 8cbde89..10d106a 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -2435,13 +2435,39 @@ reorder_basic_blocks (void)
 {
   gcc_assert (current_ir_type () == IR_RTL_CFGLAYOUT);

-  if (n_basic_blocks_for_fn (cfun) <= NUM_FIXED_BLOCKS + 1)
+  int n_bbs = n_basic_blocks_for_fn (cfun);
+  if (n_bbs <= NUM_FIXED_BLOCKS + 1)
 return;

   set_edge_can_fallthru_flag ();
   mark_dfs_back_edges ();

-  switch (flag_reorder_blocks_algorithm)
+  enum reorder_blocks_algorithm alg = flag_reorder_blocks_algorithm;
+  /* Try to detect cases where the STC algorithm is too expensive
+ and likely to be ineffective.  */
+  if (alg == REORDER_BLOCKS_ALGORITHM_STC && n_bbs > 2000)
+{
+  basic_block bb;
+  int abnormals = 0;
+  FOR_EACH_BB_FN (bb, cfun)
+   {
+ edge e;
+ edge_iterator ei;
+ bool all_abnormal = true;
+ FOR_EACH_EDGE (e, ei, bb->preds)
+   if (!(e->flags & EDGE_ABNORMAL))
+ {
+   all_abnormal = false;
+   break;
+ }
+ if (all_abnormal)
+   abnormals++;
+   }
+  if ((double)abnormals * 16 / n_bbs > 3)
+   alg = REORDER_BLOCKS_ALGORITHM_SIMPLE;
+}
+
+  switch (alg)
 {
 case REORDER_BLOCKS_ALGORITHM_SIMPLE:
   reorder_basic_blocks_simple ();

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(FWIW, the test case seems to run to completion if I remove the assert in
comment #1)

[Bug c++/69684] New: Useless -Wparentheses for A || !A && B

[wipedout at yandex dot ru]

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

Bug ID: 69684
   Summary: Useless -Wparentheses for A || !A && B
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wipedout at yandex dot ru
  Target Milestone: ---

I'm compiling this with gcc 5.3.0 with  -O3 -Wall -std=c++11

void test()
{
  int a, b;
  if(a || !a && b);
}

Please ignore the uninitialized variables for now.

I get this warning emitted:
warning: suggest parentheses around '&&' within '||' [-Wparentheses]

There're two options of how to put parentheses here.

Option one is to repeat the default behavior:

if(a || (!a && b));

Option two is this:

if((a || !a) && b);

and then I have "always true" on the left hand of && which is likely not what
anyone would want. So option two makes no sense and there's only one reasonable
way to put parentheses in this code and so the suggestion is completely useless
in this code.

[Bug c++/69686] New: Useless -Wparentheses for A && B || !A && C

[wipedout at yandex dot ru]

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

Bug ID: 69686
   Summary: Useless -Wparentheses for A && B || !A && C
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wipedout at yandex dot ru
  Target Milestone: ---

I'm compiling this with gcc 5.3.0 with  -O3 -Wall -std=c++11

void test()
{
  int a, b, c;
  if(a && b || !a && c);
}

Please ignore the uninitialized variables. I get this warning:
warning: suggest parentheses around '&&' within '||' [-Wparentheses]

Okay, there're four ways to put them here:

Option one is repeating the default behavior
if((a && b) || (!a && c));

Option two is
if(a && (b || !a) && c);
Note "a && (b || !a)" part which is equivalent to "a && b || a && !a" which
contains "a && !a" which is always "false" and so makes no sense.

Option three is
if((a && b || !a) && c);
which now contains "a && b || !a" which makes no sense.

Option four is
if(a && (b || !a && c)); which contains the same nonsense as option two.

So here there's only once reasonable way to put parentheses and the warning is
useless.

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[kyukhin at gcc dot gnu.org]

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

--- Comment #5 from Kirill Yukhin  ---
(In reply to ktkachov from comment #3)
> CC'ing Kirill for AVX512 opinion

I suppose that there's something wrong w/ MD patterns.
E.g. for example provided pattern is:
;; /export/users/kyukhin/gcc/git/gcc/gcc/config/i386/sse.md: 9199
(define_insn ("avx512vl_truncatev4siv4qi2_mask")
 [
(set (match_operand:V16QI 0 ("register_operand") ("=v"))
(vec_concat:V16QI (vec_merge:V4QI (truncate:V4QI
(match_operand:V4SI 1 ("register_operand") ("v")))
(vec_select:V4QI (match_operand:V16QI 2
("vector_move_operand") ("0C"))
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(match_operand:QI 3 ("register_operand") ("Yk")))
(const_vector:V12QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
Right now I think that 2nd operand predicate is not correct.
It should be const0_rtx (of corresponding mode) or duplicate of operand 0
(result actually)
This is whats contstraint tells.

However predicate says simply that operand is either const0_rtx or
nonimmediate: no connection with operand 0.

[Bug target/69619] [6 Regression] compilation doesn't terminate during CCMP expansion

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed then.
Wilco, can you please file a separate PR for fixing up the ccmp interface more
properly for GCC 7?

[Bug target/69685] New: GCC cross compiler build failed

[pieter.cardoen at hotmail dot com]

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

Bug ID: 69685
   Summary: GCC cross compiler build failed
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pieter.cardoen at hotmail dot com
  Target Milestone: ---

Created attachment 37591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37591=edit
Console output

Dear

I am trying to build gcc 4.9.3 for target avr-unknown-elf. If I build it, it
seems that the build hangs on this item:

/home/test02/build-gcc/./gcc/xgcc -B/home/test02/build-gcc/./gcc/
-B/usr/local/g
cc-4.9.3-avr-unknown-elf/avr-unknown-elf/bin/
-B/usr/local/gcc-4.9.3-avr-unknown
-elf/avr-unknown-elf/lib/ -isystem
/usr/local/gcc-4.9.3-avr-unknown-elf/avr-unkn
own-elf/include -isystem
/usr/local/gcc-4.9.3-avr-unknown-elf/avr-unknown-elf/sy
s-include-g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototy
pes -Wold-style-definition  -isystem ./include   -DDF=SF -Dinhibit_libc
-mcall-p
rologues -Os -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_li
bc  -DDF=SF -Dinhibit_libc -mcall-prologues -Os -I. -I. -I../.././gcc
-I../../..
/gcc-4.9.3/libgcc -I../../../gcc-4.9.3/libgcc/.
-I../../../gcc-4.9.3/libgcc/../g
cc -I../../../gcc-4.9.3/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_satfra
ctHQUSQ.o -MT _satfractHQUSQ.o -MD -MP -MF _satfractHQUSQ.dep -DL_satfract
-DFRO
M_HQ -DTO_USQ -c ../../../gcc-4.9.3/libgcc/fixed-bit.c -fvisibility=hidden
-DHID
E_EXPORTS

A console screenshot has been added to this thread. What's the reason that this
problem occurs and how can I debug this kind of issues?

I use these packages:
gcc-4.9.3
mpfr-3.1.3
gmp-6.1.0
mpc-1.0.3
isl-0.14
binutils-2.22.90
newlib-2.2.0


Thanks
Pieter

[Bug target/69693] Wrong mode is used to load spilled register

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #2)

> It is a backend bug. We need to add

It is not.

Please see in reload dump, where:
3: r109:DI=[argp:SI+0x8]
Inserting insn reload after:
   43: r95:DI=r109:DI
...
   15: r111:V2DI=r111:V2DI:DI#0
  REG_DEAD r108:DI
  REG_DEAD r95:DI
Inserting insn reload before:
   45: r111:V2DI=r95:DI#0
Inserting insn reload after:
   46: r99:DI#0=r111:V2DI

which results in:

(insn 3 2 43 2 (set (reg/v:DI 2 cx [orig:95 p2 ] [95])
(mem/c:DI (plus:SI (reg/f:SI 7 sp)
(const_int 36 [0x24])) [2 p2+0 S8 A32])) pr69693.c:6 85
{*movdi_internal}
 (nil))
(insn 43 3 4 2 (set (mem/c:DI (reg/f:SI 7 sp) [3 %sfp+-16 S8 A128])
(reg/v:DI 2 cx [orig:95 p2 ] [95])) pr69693.c:6 85 {*movdi_internal}
 (nil))
...
(insn 45 40 15 3 (set (reg:V2DI 23 xmm2 [111])
(mem/c:V2DI (reg/f:SI 7 sp) [3 %sfp+-16 S16 A128])) pr69693.c:13 1223
{*movv2di_internal}
 (nil))
(insn 15 45 46 3 (set (reg:V2DI 23 xmm2 [111])
(and:V2DI (reg:V2DI 23 xmm2 [111])
(reg:V2DI 21 xmm0 [108]))) pr69693.c:13 3471 {*andv2di3}
 (nil))

Please note how (insn 45) is accessing uninitialized memory.

Your patch will just paper over the real issue in this particular testcase.

[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[mtliang at synopsys dot com]

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

--- Comment #4 from Mike Liang  ---
I see.  With -fsignalling-nans the 004t.gimple at -O1 is generated as I
expected and all is well.  Thanks for you help!

[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #6 from Harald Anlauf  ---
(In reply to Mikael Morin from comment #5)
> The initial test doesn't lead to a segfault any more.
> 
> It is now rejected with:
> comment_0.f90:7.8:
> 
> call sub(1)
> 1
> Error: Explicit interface required for 'sub' at (1): volatile argument
> 
> 
> However, the following variant is also rejected with the same error:
> 
>  call sub(1)
> contains
>   subroutine sub(j)
>integer, volatile :: j
>   end subroutine sub
> end

With current trunk I get for this testcase:

f951: internal compiler error: Segmentation fault
0x884c5d0 crash_signal
../../trunk/gcc/toplev.c:335
0x8247bb7 compare_actual_formal
../../trunk/gcc/fortran/interface.c:2972
0x8248f02 gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*)
../../trunk/gcc/fortran/interface.c:3441
0x82a0753 resolve_specific_s0
../../trunk/gcc/fortran/resolve.c:3282
0x82a0753 resolve_specific_s
../../trunk/gcc/fortran/resolve.c:3302
0x82a0753 resolve_call
../../trunk/gcc/fortran/resolve.c:3456
0x82a8b14 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:10613
0x82ab342 resolve_codes
../../trunk/gcc/fortran/resolve.c:15529
0x829a1aa gfc_resolve
../../trunk/gcc/fortran/resolve.c:15563
0x829a1aa gfc_resolve
../../trunk/gcc/fortran/resolve.c:15543
0x828ec38 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:5551
0x828ec38 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:5803
0x82d2a55 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:201

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
ICE on invalid code.  Adding 

 real, dimension(:) :: f

in the interface makes the code compile.

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #2)
> Within linemap_add, it transitions from this map:
> (gdb) p map[-1]
> $47 = { = {start_location = 32, reason = LC_ENTER}, to_file =
> 0x2161630 "Unified_cpp_js_src35.ii", to_line = 1, 
>   included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
> m_range_bits = 5}
> 
> to this map:
> (gdb) p *map
> $46 = { = {start_location = 0, reason = LC_LEAVE}, to_file = 0x0,
> to_line = 0, included_from = 0, sysp = 0 '\000', 
>   m_column_and_range_bits = 0, m_range_bits = 0}

start_location cannot decrease. What creates this map? Something seems to be
handling wrong the "left but not entered" problem. It should not create a
LC_LEAVE map.

[Bug middle-end/69643] Address space discarded

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Henderson  ---
Fixed.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Finally got back to this for a bit.  I've tracked the problem down to the
register renaming pass.  I suspect it's having trouble with the
fusion_gpr_load_di pattern:

(insn 452 236 243 19 (set (reg:DI 9 9)
(unspec:DI [
(zero_extend:DI (mem:SI (plus:DI (plus:DI (reg:DI 9 9 [335])
(const_int 65536 [0x1]))
(const_int -21428 [0xac4c])) [160
MEM[(\
struct target_reload *)_130 + 44108B]+0 S4 A32]))
] UNSPEC_FUSION_GPR))
/home/wschmidt/gcc/gcc-mainline-test/gcc/call\
er-save.c:141 757 {fusion_gpr_load_di}
 (nil))

At a guess, the (mem (plus (plus (reg ... pattern might have caught it by
surprise, making the reference to (reg:DI 9 9) get missed in the analysis. 
Prior to the renaming pass, the feeding insn 217 defines (reg:DI 9 9) as
expected:

(insn 217 214 218 17 (set (reg:DI 9 9 [335])
(plus:DI (reg/f:DI 9 9 [orig:338 _29 ] [338])
(reg:DI 26 26 [orig:185 _59 ] [185])))
/home/wschmidt/gcc/gcc-mainl\
ine-test/gcc/caller-save.c:140 81 {*adddi3}
 (nil))

Following renaming, it now defines (reg:DI 3 3) instead, causing the
fusion_gpr_load_di pattern to be fed by a different definition of (reg:DI 9 9),
causing the problem:

(insn 217 214 218 17 (set (reg:DI 3 3 [335])
(plus:DI (reg/f:DI 28 28 [orig:338 _29 ] [338])
(reg:DI 26 26 [orig:185 _59 ] [185])))
/home/wschmidt/gcc/gcc-mainl\
ine-test/gcc/caller-save.c:140 81 {*adddi3}
 (nil))

Recording this here as I may not get back to it before I leave on vacation for
a week.

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
Must be mine, taking.

[Bug libstdc++/69699] New: libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

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

Bug ID: 69699
   Summary: libstdc++ ABI documentation is out of date
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bastian.beisc...@rwth-aachen.de
  Target Milestone: ---

The page

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

is out of date, specifically section 7 of the history. This section is often
very useful when checks on the '__GLIBCXX__' macro need to be implemented.

All the releases since GCC 4.8 are missing. For example, GCC 5.3.0 has
__GLIBCXX__ 20151204 but it's not mentioned on the page.

It is possible that other changes are also missing, but I'm not sure.

[Bug c++/69662] -Wplacement-new on allocated one element array members

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Feb  5 22:27:37 2016
New Revision: 233190

URL: https://gcc.gnu.org/viewcvs?rev=233190=gcc=rev
Log:
PR c++/69662 - -Wplacement-new on allocated one element array members

gcc/testsuite/ChangeLog:
PR c++/69662
* g++.dg/warn/Wplacement-new-size-1.C: New test.
* g++.dg/warn/Wplacement-new-size-2.C: New test.

gcc/cp/ChangeLog:
PR c++/69662
* init.c (find_field_init): New function.
(warn_placement_new_too_small): Call it.  Handle one-element arrays
at ends of structures special.

gcc/c-family/ChangeLog:
PR c++/69662
* c.opt (Warning options): Update -Wplacement-new to take
an optional argument.

gcc/ChangeLog:
PR c++/69662
* doc/invoke.texi: Update -Wplacement-new to take an optional
argument.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size-1.C
trunk/gcc/testsuite/g++.dg/warn/Wplacement-new-size-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/69662] -Wplacement-new on allocated one element array members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Implemented in r233190.

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[bastian.beisc...@rwth-aachen.de]

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

--- Comment #1 from bastian.beisc...@rwth-aachen.de ---
This is a list of all the missing values of the __GLIBCXX__ macro

4.7.3 20130411
4.7.4 20140612
4.8.0 20130322
4.8.1 20130531
4.8.2 20131016
4.8.3 20140522
4.8.4 20141219
4.8.5 20150623
4.9.0 20140422
4.9.1 20140716
4.9.2 20141030
4.9.3 20150626
5.1.0 20150422
5.2.0 20150716
5.3.0 20151204

obtained with the following zsh script:

#!/usr/bin/env zsh

VERSIONS=( 4.7.3
   4.7.4
   4.8.0
   4.8.1
   4.8.2
   4.8.3
   4.8.4
   4.8.5
   4.9.0
   4.9.1
   4.9.2
   4.9.3
   5.1.0
   5.2.0
   5.3.0 )

rm -f allversions.txt
for v in ${VERSIONS}; do
  wget
ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-${v}/gcc-${v}.tar.bz2
  tar xjvf gcc-${v}.tar.bz2 --wildcards "gcc-${v}/gcc/DATESTAMP"
  version=$(cat gcc-${v}/gcc/DATESTAMP)
  echo ${v} ${version} >> allversions.txt
  rm -fr gcc-${v}*
done

[Bug c/69702] New: excessive stack usage with -fprofile-arcs

[arnd at linaro dot org]

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

Bug ID: 69702
   Summary: excessive stack usage with -fprofile-arcs
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 37604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37604=edit
standalone test case extracted from Linux kernel

With gcc versions 4.9 or higher, the stack usage of some functions in the Linux
kernel has grown to the point where we risk a stack overflow, with 8kb or 16kb
of stack being available per thread.

When building an ARM kernel, I get at least these warnings in some
configurations when using "gcc -fprofile-arcs -Wframe-larger-than=1024", and
don't get them without -fprofile-arcs:

drivers/isdn/isdnhdlc.c:629:1: error: the frame size of 1152 bytes is larger
than 1024 bytes 
drivers/media/common/saa7146/saa7146_hlp.c:464:1: error: the frame size of 1040
bytes is larger than 1024 bytes 
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: error: the frame size of 1040 bytes
is larger than 1024 bytes 
drivers/net/wireless/ath/ath6kl/main.c:495:1: error: the frame size of 1200
bytes is larger than 1024 bytes 
drivers/net/wireless/ath/ath9k/ar9003_aic.c:434:1: error: the frame size of
1208 bytes is larger than 1024 bytes 
drivers/video/fbdev/riva/riva_hw.c:426:1: error: the frame size of 1248 bytes
is larger than 1024 bytes 
lib/lz4/lz4hc_compress.c:514:1: error: the frame size of 2464 bytes is larger
than 1024 bytes 

The lz4hc_compress.c file is a good example, as it has the worst stack usage
and is usable as a working test case outside of the kernel. I have reduced this
file to a standalone .c file that can optionally compile into an executable
program (lz4 compression from stdin to stdout). The code is orginally from
www.lz4.org, but has been adapted for use in Linux.

Compile with:
gcc -O2 -Wall -Wno-pointer-sign -Wframe-larger-than=200 -fprofile-arcs  -c
lz4hc_compress.c 

The same problem happens on all architectures, e.g. gcc-4.9.3:

Target  -fprofile-arcs  normal
aarch64-linux-gcc 1136  112 
alpha-linux-gcc   1008  304 
am33_2.0-linux-gcc1280   84 
arm-linux-gnueabi-gcc 1080  112 
cris-linux-gcc828   100 
frv-linux-gcc 904   104 
hppa64-linux-gcc  944   248 
hppa-linux-gcc82492 
i386-linux-gcc824   108 
m32r-linux-gcc908   136 
microblaze-linux-gcc  83288 
mips64-linux-gcc  864   192 
mips-linux-gcc792   120 
powerpc64-linux-gcc   80096 
powerpc-linux-gcc 80856 
s390-linux-gcc832   112 
sh3-linux-gcc 824   128 
sparc64-linux-gcc 896   192 
sparc-linux-gcc   824   104 
x86_64-linux-gcc  912   192 
xtensa-linux-gcc  816   128 

With gcc-4.8.1, the numbers are much lower:

arm-linux-gnueabi-gcc 184   104
x86_64-linux-gcc  224   192

The size of the binary object has also grown noticeably, from around 3000 bytes
 without -fprofile-arcs (on any version) to 10300 bytes with gcc-5.3.1 but only
6941 bytes with gcc-4.8. Runtime speed does not appear to be affected much
(less than 20% overhead for -fprofile-arcs, which seems reasonable).

I have tested ARM cross-compilers version 4.9.3 through 5.3.1, which all show
similar problematic behavior, while version 4.6 through 4.8.3 are ok.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

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

--- Comment #13 from Mikael Morin  ---
Author: mikael
Date: Fri Feb  5 21:41:15 2016
New Revision: 233188

URL: https://gcc.gnu.org/viewcvs?rev=233188=gcc=rev
Log:
Fix fortran scalar elemental dependency mishandling

PR fortran/66089
gcc/fortran/
* trans-expr.c (expr_is_variable, gfc_expr_is_variable): Rename
the former to the latter and make it non-static.  Update callers.
* gfortran.h (gfc_expr_is_variable): New declaration.
(struct gfc_ss_info): Add field needs_temporary.
* trans-array.c (gfc_scalar_elemental_arg_saved_as_argument):
Tighten the condition on aggregate expressions with a check
that the expression is a variable and doesn't need a temporary.
(gfc_conv_resolve_dependency): Add intermediary reference variable.
Set the needs_temporary field.
gcc/testsuite/
* gfortran.dg/elemental_dependency_6.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/elemental_dependency_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug target/69693] Wrong mode is used to load spilled register

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
LRA generates reload:

(insn 45 0 0 (set (reg:V2DI 111)
(subreg:V2DI (reg/v:DI 95 [ p2 ]) 0)) -1
 (nil))

With movdi_to_v2di, we get

(insn 45 40 15 3 (set (reg:V2DI 23 xmm2 [111])
(subreg:V2DI (mem/c:DI (reg/f:SI 7 sp) [3 %sfp+-16 S8 A64]) 0)) x.i:13
1288 {*movdi_to_v2di}
 (nil))

Without movdi_to_v2di, simplify_operand_subreg in lra-constraints.c:

 /* If we change address for paradoxical subreg of memory, the
 address might violate the necessary alignment or the access might
 be slow.  So take this into consideration.  We should not worry
 about access beyond allocated memory for paradoxical memory
 subregs as we don't substitute such equiv memory (see processing
 equivalences in function lra_constraints) and because for spilled
 pseudos we allocate stack memory enough for the biggest
 corresponding paradoxical subreg.  */
  if (MEM_P (reg)
  && (! SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg))
  || MEM_ALIGN (reg) >= GET_MODE_ALIGNMENT (mode)))
{
  rtx subst, old = *curr_id->operand_loc[nop];

  alter_subreg (curr_id->operand_loc[nop], false);
  subst = *curr_id->operand_loc[nop];
  lra_assert (MEM_P (subst));
  if (! valid_address_p (innermode, XEXP (reg, 0),
 MEM_ADDR_SPACE (reg))
  || valid_address_p (GET_MODE (subst), XEXP (subst, 0),
  MEM_ADDR_SPACE (subst)))
return true;

turns

(subreg:V2DI (reg/v:DI 95 [ p2 ]) 0)

into

(mem/c:V2DI (reg/f:SI 7 sp) [3 %sfp+-16 S16 A128]

It looks that it is done on purpose.

[Bug c++/69697] New: incorrect initialization of static flexible array members

[msebor at gcc dot gnu.org]

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

Bug ID: 69697
   Summary: incorrect initialization of static flexible array
members
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 69696, G++ accepts the questionable program below but emits
incorrect code overlaying the flexible array member over the variable j.  This
can be seen in the generated assembly file (below).  The underlying problem is
that G++ emits a .size directive that corresponds to the size of the type as
opposed to the ultimate size of the object (or its largest initializer).  This
was fixed in the C front end via bug 28865.

.globl  i
.bss
.align 4
.type   i, @object
.size   i, 4
i:
.zero   4
.globl  a
.align 4
.type   a, @object
.size   a, 4
a:
.zero   4
.globl  j
.align 4
.type   j, @object
.size   j, 4
j:
.zero   4

G++ should either reject such code with an error or it should lay down the
global variables consecutively.

$ cat x.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -std=c++14
-xc++ x.c && ./a.out
int i;
struct A { int n, a[]; } a = i ? A({ 1, { 2 } }) : A({ 2, { 3, 4 } });
int j;

int main ()
{
__builtin_printf ("i = %i, j = %i, a = { %i, { ", i, j, a.n);
for (int i = 0; i != a.n; ++i)
__builtin_printf ("%i, ", a.a[i]);
__builtin_printf ("} }\n");
}
x.c:2:48: warning: initialization of a flexible array member [-Wpedantic]
 struct A { int n, a[]; } a = i ? A({ 1, { 2 } }) : A({ 2, { 3, 4 } });
^
x.c:2:69: warning: initialization of a flexible array member [-Wpedantic]
 struct A { int n, a[]; } a = i ? A({ 1, { 2 } }) : A({ 2, { 3, 4 } });
 ^
i = 0, j = 3, a = { 2, { 3, 4, } }

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Tobias Schlüter from comment #3)
> Just for the fun of it, another confusing way this error message appears:
> $ cat t3.f90
> character c(5)
> 
> do c=2,3
> end do
> 
> END 
> $ gfortran t3.f90
> t3.f90:3.4:
> 
> do c=2,3
> 1
> Error: Loop variable at (1) cannot be a sub-component
> t3.f90:4.3:
> 
> end do
>1
> Error: Expecting END PROGRAM statement at (1)
> $ 
> 
> Of course this behavior is expected once you look at the code.

The above error message is somewhat improved with the following patch:

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 232904)
+++ gcc/fortran/match.c (working copy)
@@ -877,6 +877,12 @@
   if (m != MATCH_YES)
 return MATCH_NO;

+  if (var->ts.type == BT_CHARACTER)
+{
+  gfc_error ("Loop variable at %C cannot be of type CHARACTER");
+  goto cleanup;
+}
+
   /* F2008, C617 & C565.  */
   if (var->symtree->n.sym->attr.codimension)
 {

I now get:

t3.f90:3:4:

 do c=2,3
1
Error: Loop variable at (1) cannot be of type CHARACTER
t3.f90:4:3:

 end do
   1
Error: Expecting END PROGRAM statement at (1)

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
I'd be real surprised if that commit was the real cause.  It's more likely
exposing a latent issue.  Note that the two list implementation changes the
order in which SSA_NAMEs are reused, which in turn can change coalescing
decisions.

Normally I'd push this to P4, but leaving it as a P3 until at least enough
analysis is done to know if it's really a problem with tpcs-leaf-frame or
exposing a deeper problem elsewhere that might be critical to fix.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
(In reply to David Malcolm from comment #14)
> Is there any way to do multiline comments in gfortran?
> 
> Am attempting to write expected output like this:
> 
> ! { dg-begin-multiline-output "" }
> EXPECTED OUTPUT TO GO HERE
> ! { dg-end-multiline-output "" }
> 
> If not, I may need to require every line within the begin/end to start with a
>   "! "
> and to strip that.

It is not possible to continue comments in Fortran.

You could place a block of code inside an #if 0 and invoke the
C preprocessor (preferably by using a file suffix like .F90)
to do something like

ig25@linux-fd1f:/tmp> cat comment.F90 
program main
#if 0
{ dg-begin-multiline-output "" }
EXPECTED OUTPUT TO GO HERE
{ dg-end-multiline-output "" }
#endif
end program main

which would a bit of a hack.

[Bug libstdc++/69703] New: char16_t conversions broken in filesystem::path

[eric at efcs dot ca]

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

Bug ID: 69703
   Summary: char16_t conversions broken in filesystem::path
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37605=edit
reproducer.cpp

Hi Jonathan,

While running the libc++ filesystem tests against libstdc++ I found that my
character conversion tests worked for wchar_t and char32_t but not char16_t.

IDK a lot about character encoding, so I apologize if the bug is on my end.

[Bug c++/69628] [6 Regression] Conditional jump or move depends on uninitialised value(s) in lex_charconst(cpp_token const*) (c-lex.c:1252)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  5 19:39:48 2016
New Revision: 233186

URL: https://gcc.gnu.org/viewcvs?rev=233186=gcc=rev
Log:
PR c++/69628
* charset.c (cpp_interpret_charconst): Clear *PCHARS_SEEN
and *UNSIGNEDP if bailing out early due to errors.

* g++.dg/parse/pr69628.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr69628.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c

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

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Reduced test case:

$ g++ -O2 -rdynamic -flto tc1.ii tc2.ii

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

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 37600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37600=edit
tc1.ii

[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  5 21:13:43 2016
New Revision: 233187

URL: https://gcc.gnu.org/viewcvs?rev=233187=gcc=rev
Log:
PR rtl-optimization/69691
* lra-eliminations.c (move_plus_up): Don't add the addend twice.

* gcc.c-torture/execute/pr69691.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr69691.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-eliminations.c
trunk/gcc/testsuite/ChangeLog

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Is there any way to do multiline comments in gfortran?

Am attempting to write expected output like this:

! { dg-begin-multiline-output "" }
EXPECTED OUTPUT TO GO HERE
! { dg-end-multiline-output "" }

If not, I may need to require every line within the begin/end to start with a
  "! "
and to strip that.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[kelvin at gcc dot gnu.org]

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

--- Comment #15 from kelvin at gcc dot gnu.org ---
On my macbook, g++ (Apple LLVM version 7.0.2 (clang-700.1.81), Target:
x86_64-apple-darwin15.3.0), the test program does compile successfully.

For Martin's simplified example, it produces the following code:

__Z3barv:   ## @_Z3barv
.cfi_startproc
## BB#0:
pushq   %rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
subq$80, %rsp
movl$16, %eax
movl%eax, %edi
xorl%ecx, %ecx
leaq-16(%rbp), %rdx
movq%rdx, %rsi
callq   ___atomic_load
leaq-40(%rbp), %rdx
xorl%esi, %esi
movl$24, %eax
movl%eax, %edi
movq%rdx, %r8
movq%rdi, -48(%rbp) ## 8-byte Spill
movq%r8, %rdi
movq-48(%rbp), %r8  ## 8-byte Reload
movq%rdx, -56(%rbp) ## 8-byte Spill
movq%r8, %rdx
callq   _memset
movq-56(%rbp), %rdx ## 8-byte Reload
movq(%rdx), %rdi
movq%rdi, (%rsp)
movq8(%rdx), %rdi
movq%rdi, 8(%rsp)
movq16(%rdx), %rdi
movq%rdi, 16(%rsp)
callq   __Z3foo1B
addq$80, %rsp
popq%rbp
retq
.cfi_endproc

I tried Alan's small-value test case on the Apple Mac compiler as well.  I made
minor changes to the source code to make the "stricter" type checking of that
environment happy.  The program compiles and runs ok on Apple Macintosh:

#include 

/* intel compiler claims to ignore packed __attribute__ */
struct foo { 
char pad;
char x[4];
} __attribute__((packed)) a;

int
bar (int val)
{
int ret;
char array1[4];
char array2[4];

*((int *) array1) = val;
/* copies a.x to array2 and copies array1 to a.x, atomically. */
__atomic_exchange (, , , 5);

ret = *((int *) array2);
return  ret;
}

int main ()
{
std::cout << "Result from first __atomic_exchange is " << bar (42) << "\n";
std::cout << "Result from second __atomic_exchange is " << bar (13) <<
"\n";
std::cout << "Result from third __atomic_exchange is " << bar (25) << "\n";
}

Though I'm no longer fluent in reading Intel assembler, I'm pretty confident
that the struct is packed and the atomic exchange deals with an unaligned
address to a 4-byte quantity:

.globl  __Z3bari
.align  4, 0x90
__Z3bari:   ## @_Z3bari
.cfi_startproc
## BB#0:
pushq   %rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
subq$16, %rsp
leaq_a(%rip), %rax
addq$1, %rax
movl$5, %edx
movl%edi, -4(%rbp)
movl-4(%rbp), %edi
movl%edi, -12(%rbp)
movl-12(%rbp), %esi
movq%rax, %rdi
callq   ___atomic_exchange_4
movl%eax, -16(%rbp)
movl-16(%rbp), %eax
movl%eax, -8(%rbp)
movl-8(%rbp), %eax
addq$16, %rsp
popq%rbp
retq
.cfi_endproc

with _a declared as follows:

.globl  _a  ## @a
.zerofill __DATA,__common,_a,5,0

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

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 37601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37601=edit
tc2.ii

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

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug c++/69628] [6 Regression] Conditional jump or move depends on uninitialised value(s) in lex_charconst(cpp_token const*) (c-lex.c:1252)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #11 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #10)
> > The code compiles with 4.8.5, 4.9.3, 5.2.0, and to trunk (6.0), but not
> > with 4.8.2 or 4.9.0. The change occurred between revisions r215860
> > (2014-10-03, error) and r216098 (2014-10-10, compiles).
> 
> Does someone care to add a test case? Otherwise this PR can be closed as
> FIXED.

Why not simply add the code from comment #0 to testsuite/gfortran.dg/gomp/
and the close this PR?

! PR fortran/52531
! { dg-do compile }

module test_mod
  type, public :: test_type
  end type
contains
  subroutine foo(bar)
type(test_type) :: bar
!$omp parallel default(none) shared(bar) ! Compiles if one removes
default(none)
call question(bar)
!$omp end parallel
  end subroutine
  subroutine question(var)
class(test_type), intent(in) :: var ! Compiles if one replaces class by
type
  end subroutine
end module

[Bug libgcc/68126] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2239 while compiling under platform mips64el

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #1 from Steve Ellcey  ---
It looks like this is actually a bug in the GCC 4.4.7 compiler on the system
where you are building GCC.  gensupport.c is compiled with the system compiler
in order to build gensupport which is run as part of the build.  Your best bet
would be to do the build with a newer system compiler if you have one.

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.9 up to trunk, it "works" with 4.8.5. The change occurred
> between revisions r208241 (2014-03-01, works) and r208311 (2014-03-04,
> fails), likely r208302 (pr60148).

Indeed, reverting the change to list_read.c fixes the issue.

[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Ok, it's also really enabled attributes that previously triggered
non-commutative ops.

The following patch (in testing now) fixes the SPEC regression.

Index: gcc/ira.c
===
--- gcc/ira.c   (revision 231814)
+++ gcc/ira.c   (working copy)
@@ -1888,10 +1888,11 @@ ira_setup_alts (rtx_insn *insn, HARD_REG
}
   if (commutative < 0)
break;
-  if (curr_swapped)
-   break;
+  /* Swap forth and back to avoid changing recog_data.  */
   std::swap (recog_data.operand[commutative],
 recog_data.operand[commutative + 1]);
+  if (curr_swapped)
+   break;
 }
 }

[Bug c++/69686] Useless -Wparentheses for A && B || !A && C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
This is a coding-style warning so the association will be obvious.  The
compiler doesn't do any analysis about possible associations and their "sense".

[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Note the documentation says the following:

---

@item -fsignaling-nans
@opindex fsignaling-nans
Compile code assuming that IEEE signaling NaNs may generate user-visible
traps during floating-point operations.  Setting this option disables
optimizations that may change the number of exceptions visible with
signaling NaNs.  This option implies @option{-ftrapping-math}.

This option causes the preprocessor macro @code{__SUPPORT_SNAN__} to
be defined.

The default is @option{-fno-signaling-nans}.

This option is experimental and does not currently guarantee to
disable all GCC optimizations that affect signaling NaN behavior.

---

but even with -fsignalling-nans the bug reproduces with GCC 5.3.0.
This is due to PR69308 which I believe is a dup of this bug (this means
trunk is not affected).  This will be fixed in GCC 5.4.0.

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

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/69675] [6 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  5 09:23:03 2016
New Revision: 233167

URL: https://gcc.gnu.org/viewcvs?rev=233167=gcc=rev
Log:
PR bootstrap/69677
* config/i386/i386.c (convert_scalars_to_vector): Readd stack
alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV even for
-m{incoming,preferred}-stack-boundary=3.

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

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
But something like that might remove the flexibility from the register
allocator.

Wonder why the RA in this case doesn't see that the value loaded into that
pseudo register is CONST0_RTX which satisfies the C constraint and doesn't undo
CSE (rematerialize) in that case if it doesn't have that value already loaded
in the matching register to the output one.

[Bug c++/69687] Buffer Overflow in libiberty

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Component|c   |c++

--- Comment #2 from Markus Trippelsdorf  ---
I don't think it makes much sense to fuzz the demangler with arbitrary binary
files.
This isn't some daemon that runs 24/7 and is vulnerable to buffer overflow
attacks.

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
void bar (void);

void
foo (int p2, int p3)
{
  unsigned long a = p2;
  unsigned long b = (~(unsigned long) ((unsigned int) p3 + -1U)) + a;
  unsigned long c = (a - (unsigned long) ((unsigned int) p3 + -1U)) + (-1UL);
  if (b != c)
bar ();
}

shows this folding inconsistency in the *.original dump:
  long unsigned int a = (long unsigned int) p2;
  long unsigned int b = (a - (long unsigned int) ((unsigned int) p3 +
4294967295)) - 1;
  long unsigned int c = (a - (long unsigned int) ((unsigned int) p3 +
4294967295)) + 18446744073709551615;
but *.gimple already canonicalizes it, so that it does + 18446744073709551615
at the end in both cases.

[Bug c++/69684] Useless -Wparentheses for A || !A && B

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
See other PR, this is about coding-style.  One could say even a || !a && b
doesn't make sense as the !a in the !a && b conditon will always be true
and thus this is a || b.

So a diagnostic is warranted - maybe it's wording is not exactly helpful and
"warning: your condition is obfuscated" would be better? ;)

[Bug target/69685] GCC cross compiler build failed

[pieter.cardoen at hotmail dot com]

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

--- Comment #2 from Pieter Cardoen  ---
How do you mean: appending -v? The only command I execute is: 

../gcc-4.9.3/configure  --prefix=/usr/local/gcc-4.9.3-avr-unknown-elf \
--target=avr-unknown-elf --build=i686-pc-$(ENV) \
--enable-languages=c,c++ --with-newlib \
--disable-__cxa_atexit --disable-nls \
--disable-threads --disable-shared \
--enable-static --disable-win32-registry \
--disable-sjlj-exceptions --with-dwarf2 \
--with-gmp=$(PKG_DIR) --with-mpfr=$(PKG_DIR) \
--with-mpc=$(PKG_DIR) --with-isl-prefix=$(PKG_DIR)

make -j2
make install

[Bug tree-optimization/69675] [6 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-05
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Feb  5 10:08:17 2016
New Revision: 233168

URL: https://gcc.gnu.org/viewcvs?rev=233168=gcc=rev
Log:
S/390: Fix r6 vararg handling.

This patch fixes a problem introduced with the GPR into FPR slot save
feature for leaf functions.

r6 is argument register as well as call-saved.  Currently we might
decide that it will be a candidate for being saved into an FPR.  If it
turns out later that r6 also needs to be saved due to being required
for vararg we undo the FPR save decision and put it on the stack
again.  Unfortunately the code did not adjust the GPR restore range
accordingly so that the register does not get restored in the load
multiple.

This fixes the following testcases on s390x:

< FAIL: libgomp.c/doacross-1.c execution test
< FAIL: libgomp.c/doacross-2.c execution test
< FAIL: libgomp.c/doacross-3.c execution test
< FAIL: libgomp.c++/doacross-1.C execution test

gcc/ChangeLog:

2016-02-05  Andreas Krebbel  

PR target/69625
* config/s390/s390.c (SAVE_SLOT_NONE, SAVE_SLOT_STACK): New
defines.
(s390_register_info_gprtofpr): Use new macros above.
(s390_register_info_stdarg_fpr): Adjust max_fpr to better match
its name.
(s390_register_info_stdarg_gpr): Adjust max_gpr to better match
its name.  Adjust restore and save gpr ranges.
(s390_register_info_set_ranges): New function.
(s390_register_info): Use new macros above.  Call
s390_register_info_set_ranges.
(s390_optimize_register_info): Likewise.
(s390_hard_regno_rename_ok): Use new macros.
(s390_hard_regno_scratch_ok): Likewise.
(s390_emit_epilogue): Likewise.
(s390_can_use_return_insn): Likewise.
(s390_optimize_prologue): Likewise.
* config/s390/s390.md (GPR2_REGNUM, GPR6_REGNUM): New constants.


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

[Bug c/69687] Buffer Overflow in libiberty

[boehme.marcel at gmail dot com]

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

--- Comment #1 from Marcel Böhme  ---
Created attachment 37593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37593=edit
Test Case #2

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[ienkovich at gcc dot gnu.org]

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

--- Comment #14 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #6)
> STV turns:
> 
> insn 21 19 23 4 (parallel [
> (set (reg:DI 102 [ val ])
> (and:DI (reg/v:DI 97 [ val ])
> (mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
> (const_int 8 [0x8]))
> (symbol_ref:SI ("mode_mask_array") [flags 0x40] 
> )) [13 mode_mask_array S8 A64])))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134
> 332 {*anddi3_doubleword}
>  (expr_list:REG_DEAD (reg/v:DI 97 [ val ])
> (expr_list:REG_DEAD (reg/v:SI 96 [ mode ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)
> (insn 23 21 24 4 (parallel [
> (set (reg:DI 103)
> (ashift:DI (const_int 1 [0x1])
> (subreg:QI (reg:SI 91 [ _8 ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:135
> 449 {*ashldi3_doubleword}
>  (expr_list:REG_DEAD (reg:SI 91 [ _8 ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> 
> into
> (insn 47 19 21 4 (set (reg:DI 111)
> (mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
> (const_int 8 [0x8]))
> (symbol_ref:SI ("mode_mask_array") [flags 0x40]   0xf517e160 mode_mask_array>)) [13 mode_mask_array S8 A64]))
> /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134 -1
>  (nil))
> (insn 21 47 23 4 (set (subreg:V2DI (reg:DI 102 [ val ]) 0)
> (and:V2DI (subreg:V2DI (reg/v:DI 97 [ val ]) 0)
> (subreg:V2DI (reg:DI 111) 0)))
> /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134 3253
> {*andv2di3}
>  (expr_list:REG_DEAD (reg/v:DI 97 [ val ])
> (expr_list:REG_DEAD (reg/v:SI 96 [ mode ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)
> (insn 23 21 45 4 (parallel [
> (set (reg:DI 103)
> (ashift:DI (const_int 1 [0x1])
> (subreg:QI (reg:SI 91 [ _8 ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:135
> 449 {*ashldi3_doubleword}
>  (expr_list:REG_DEAD (reg:SI 91 [ _8 ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> 
> So STV requires 16 byte stack alignment and uses 16 byte stack alignment.

I don't see how STV requires 16 byte stack alignment here.  All registers are
DI here.  Emitted movdqa is not produced by STV, it seems like LRA bug which
writes 8 bytes to stack but reads 16.

[Bug c/69687] New: Buffer Overflow in libiberty

[boehme.marcel at gmail dot com]

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

Bug ID: 69687
   Summary: Buffer Overflow in libiberty
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

Created attachment 37592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37592=edit
Test Case #1

The attached program binary causes a buffer overflow in cplus-dem.c when it
tries to demangle specially crafted function arguments in the binary. Both the
buffer size as well as the buffer content are controlled from the binary.

objdump -x -C 
nm -C 

Tested on the following configurations
* 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 22:00:00 UTC 2015 x86_64 x86_64
x86_64 GNU/Linux
* 4.1.12-boot2docker #1 SMP Tue Nov 3 06:03:36 UTC 2015 x86_64 x86_64 x86_64
GNU/Linux
* Binutils versions: 2.20 and 2.26

Best regards,
- Marcel

Backlink: https://sourceware.org/bugzilla/show_bug.cgi?id=19571

[Bug target/69685] GCC cross compiler build failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||avr

--- Comment #1 from Richard Biener  ---
You can look where gcc "hangs" by appending -v to the command-line, looking for
the command that hangs (likely a ../gcc/cc1 invocation) and attaching to that
process with gdb.

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[ienkovich at gcc dot gnu.org]

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

--- Comment #15 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #13)
> Fixed.

I think you just hide LRA issue disabling STV and LRA still may generate
incorrect register fill

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
So do you want to use reg_or_0_operand?  I don't think we usually tie output
with input already in the predicates, except when match_dup is used.