[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 35014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35014&action=edit
gcc5-pr65238.patch

Untested fix.

[Bug other/65384] Intel MPX does not support x32

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
patch posted at
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00627.html

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[boger at us dot ibm.com]

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

--- Comment #46 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #45)
> If we change the PC returned by backtrace_full, and then use that changed PC
> to look up file/line information, we might get different results.  That
> seems clear.  My next question is: when does this matter?
> 
> There are two ways that we use the result of runtime_callers: either we use
> the file/line information, or we use the PC.  If we use the file/line
> information, all is well, and there is nothing to discuss.  If we use the
> PC, as in runtime.Callers, then it's true that if we pass that PC back to
> libbacktrace we may get different file/line information.  But, so what? 
> We've already lost the original file/line information anyhow.
> 
> The idea is that the changed PC will be the same as the PC returned by the
> gc library.  Therefore, we should get approximately the same file/line
> information as the gc library gets.  That is why runtime/pprof/pprof.go in
> the gc library backs up the PC to the call instruction: because it knows
> that it has the PC after the call instruction.

Let me just respond to this last paragraph for now.  If the pc values in gc are
always the instruction following the call (or the excepting instruction), and
runtime_callers expects it to be that way, and we want gc and gccgo to return
the same results, then I don't understand why backtrace_full and
backtrace_simple should ever decrement the pc for any platform.  There is a
brief mention of this in comment 9 -- that we can make use the fact that the pc
had been decremented by inspecting it and making use of the fact that is an
abnormal pc value; however I don't see anywhere in the libgo code where it does
this, and besides, for some platforms after the pc is decremented it is still a
normal looking pc so there is no way to know if it had been decremented. 
Getting the right pc and the right instruction seems more important than
preserving some information that is currently not being used and can't be used
on all platforms.

That means, if the decrement was removed completely from backtrace_full and
backtrace_simple then the pc values would be correct for each platform and the
line numbers would be determined based on the correct pc.  And then we would
still need the BackupPC function for those cases where the call instruction was
needed as is done in pprof.go and some extra stuff for s390 and s390x for their
various call instructions to get the right number of bytes to back up.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 10 21:03:21 2015
New Revision: 221335

URL: https://gcc.gnu.org/viewcvs?rev=221335&root=gcc&view=rev
Log:
PR target/65368
* config/i386/i386.md (bmi2_bzhi_3): Removed define_insn,
new define_expand.
(*bmi2_bzhi_3, *bmi2_bzhi_3_1): New define_insns.

* gcc.target/i386/bmi2-bzhi-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #36 from Martin Sebor  ---
Author: msebor
Date: Tue Mar 10 21:06:41 2015
New Revision: 221336

URL: https://gcc.gnu.org/viewcvs?rev=221336&root=gcc&view=rev
Log:
2015-03-10  Martin Sebor  

PR testsuite/63175
* gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Move
checking of results into main to prevent it from getting optimized
away.
* gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: New test.


Added:
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c

[Bug c++/65382] New: pointer-to-noexcept-function typealias allowed via using

[vgheorgh at gmail dot com]

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

Bug ID: 65382
   Summary: pointer-to-noexcept-function typealias allowed via
using
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgheorgh at gmail dot com

According to 15.4 Exception specifications [except.spec]/2, the following code
should be rejected, 

#include 

using fptr = void(*)() noexcept; // should not be accepted
// typedef void (*FPTR)() noexcept; // rejected by the compiler

void f() noexcept
{
std::cout << "void f() noexcept" << std::endl;
}

int main()
{
fptr fp = f;
fp();
}


Replacing using with a typedef makes the compiler emit an error, however the
code above compiles just fine, and it shouldn't.

[Bug preprocessor/65387] New: cpp -C emits extraneous comment header on every file

[bugs at stellardeath dot org]

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

Bug ID: 65387
   Summary: cpp -C emits extraneous comment header on every file
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at stellardeath dot org

cpp is often (mis)used for non-C files, many Fortran projects for example
prefer to run a separate preprocessor step by invoking cpp by hand instead of
relying on the built-in preprocessing of the fortran compiler (don't ask why -
I don't understand it either).

In order not to mess up anything in the non-C file, cpp is usually invoked as

  cpp -C -P -traditional

The "-C" flag started to make problems in recent versions(?), as this now emits
a large comment header on every file:

#> echo "asd" | cpp -C -P
/* Copyright (C) 1991-2015 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   .  */
/* This header is separate from features.h so that the compiler can
   include it implicitly at the start of every compilation.  It must
   not itself include  or any other header that includes
because the implicit include comes before any feature
   test macros that may be defined in a source file before it first
   explicitly includes a system header.  GCC knows the name of this
   header in order to preinclude it.  */
/* glibc's intent is to support the IEC 559 math functionality, real
   and complex.  If the GCC (4.9 and later) predefined macros
   specifying compiler intent are available, use them to determine
   whether the overall intent is to support these features; otherwise,
   presume an older compiler has intent to support these features and
   define these macros by default.  */
/* wchar_t uses ISO/IEC 10646 (2nd ed., published 2011-03-15) /
   Unicode 6.0.  */
/* We do not support C11 .  */
asd


Would it be too much trouble to not include this extraneous header?

Kind regards,
  Lorenz

[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-03-11
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #8 from vries at gcc dot gnu.org ---
Test fails again (for x86_64, but not with -m32), with similar message:
...
--- FAIL: TestMemoryProfiler (2.17s)
testing.go:278: The entry did not match:
(0|1): (0|2097152) \[1: 2097152\] @ 0x[0-9,a-f x]+
#   0x[0-9,a-f]+   
pprof_test\.allocateTransient2M\+0x[0-9,a-f]+   .*/mprof_test.go:30
#   0x[0-9,a-f]+   
runtime_pprof_test\.TestMemoryProfiler\+0x[0-9,a-f]+.*/mprof_test.go:65
...

[Bug tree-optimization/64705] Bad code generation of sieve on x86-64 because of too aggressive IV optimizations

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to amker from comment #6)
> Since it works on gcc 3.4, so I consider this as a regression and applied
> the patch.  Should be fixed now.
> 
> Hi Vlad, could you please help me verify that the original benchmark is
> fixed too?  Thanks very much!

Yes, it was fixed.  Thanks for working on this.

[Bug tree-optimization/62173] [5 Regression] 64bit Arch can't ivopt while 32bit Arch can

[jiwang at gcc dot gnu.org]

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

--- Comment #36 from Jiong Wang  ---
and for rtl level improvement, need to enable DF_DU_CHAIN build on top of
existing DF_UD_CHAIN (may cause extra compile time resource consumption).

one draft patch is here, no feedback yet.

  https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00736.html

as both tree and rtl fix contain generic code modifications, I think it's
better to defer it to next stage-1 given the issue itself is enhancement not
bug.

[Bug tree-optimization/62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|5.0 |6.0
Summary|[5 Regression] 64bit Arch   |[5/6 Regression] 64bit Arch
   |can't ivopt while 32bit |can't ivopt while 32bit
   |Arch can|Arch can

--- Comment #37 from Jakub Jelinek  ---
Ok.

[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop

[acsawdey at linux dot vnet.ibm.com]

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

--- Comment #3 from Aaron Sawdey  ---
I tried applying the patch that Thomas posted for 64616
(https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00272.html) to trunk 221350 but
that did not change the generated code for this test case on powerpc64le.

[Bug libfortran/65200] Handle EPERM when opening files

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #8 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug fortran/65397] New: [Coarrays][OOP] ICE in resolve_ordinary_assign

[burnus at gcc dot gnu.org]

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

Bug ID: 65397
   Summary: [Coarrays][OOP] ICE in resolve_ordinary_assign
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following valid program ICEs with -fcoarray=lib in resolve_ordinary_assign.

subroutine five
implicit none
type t
  integer, pointer :: a
  integer :: b
end type t
type t2
  class(t), allocatable :: caf2[:]
end type t2
class(t), save, allocatable :: caf[:]
type(t) :: x
type(t2) :: y

x = caf[4] !  ICE
x = y%caf2[5]  !  ICE
end subroutine five

[Bug fortran/65397] [Coarrays][OOP] ICE in resolve_ordinary_assign

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
See also gfortran.dg/coarray_38.f90 of
https://gcc.gnu.org/ml/fortran/2015-03/msg00057.html (assuming it will
eventually appear on the server)

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||thomas.preudhomme at arm dot 
com,
   ||trippels at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
Started with r210843.

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #8 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu Mar 12 06:59:34 2015
New Revision: 221372

URL: https://gcc.gnu.org/viewcvs?rev=221372&root=gcc&view=rev
Log:
Use actual_call_used_reg_set to find conflicting regs

2015-03-12  Tom de Vries  

* lra-lives.c (check_pseudos_live_through_calls): Use
actual_call_used_reg_set instead of call_used_reg_set, if available.

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

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

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

[Bug fortran/65397] [Coarrays][OOP] ICE in resolve_ordinary_assign

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
The problem is in resolve_ordinary_assign (resolve.c):

9428  /* Assign the 'data' of a class object to a derived type.  */
9429  if (lhs->ts.type == BT_DERIVED
9430  && rhs->ts.type == BT_CLASS)
9431gfc_add_data_component (rhs);

But the RHS is:

(gdb) p rhs->expr_type
$2 = EXPR_FUNCTION
(gdb) p rhs->symtree->name
$3 = 0x71f45f90 "_F.caf_get"

And adding "._data" fails in class.c as:

211   gfc_symbol *derived = e->symtree->n.sym->ts.u.derived;
(gdb) p e->symtree->n.sym->ts.u.derived
$4 = (gfc_symbol *) 0x0

[Bug testsuite/65394] r221327 causes gcc.dg/ipa/pr63569.c to fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-12
  Component|ipa |testsuite
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Testsuite issue I think.

[Bug c++/65398] New: [C++11] GCC rejects constexpr variable definitions with valid initialization

[kariya_mitsuru at hotmail dot com]

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

Bug ID: 65398
   Summary: [C++11] GCC rejects constexpr variable definitions
with valid initialization
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com

Created attachment 35017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35017&action=edit
g++ -v

The sample code below should be compiled successfully but gcc 5.0 rejects it.

= sample code =
constexpr char s[] = "abc";
constexpr char c = *(&s[0] + 1);

int main() {}
= sample code =

cf. http://melpon.org/wandbox/permlink/jRbgl6YCTXHSspI9


Note that gcc 4.9.2 accepts it.

cf. http://melpon.org/wandbox/permlink/bwuaSYUvgwAjRTfo


Note also that gcc 5.0 accepts if "&s[0]" is replaced with "s".

= sample code =
constexpr char s[] = "abc";
constexpr char c = *(s + 1);

int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/sy0THyfnSq6XCT0L

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[vries at gcc dot gnu.org]

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

Bug 64895 Summary: RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895

   What|Removed |Added

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

[Bug tree-optimization/65395] [4.9 Regression] compiler crash, -ftree-pre leads to SSA corruption

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-12
  Component|c   |tree-optimization
  Known to work||4.8.3, 5.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.2
   Severity|blocker |normal

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

[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/65396] Function template default template arguments not merged

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Presumably this rule was never implemented for function templates when they
started being allowed default template arguments.

[Bug c++/65399] New: error: invalid use of non-static data member

[dcb314 at hotmail dot com]

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

Bug ID: 65399
   Summary: error: invalid use of non-static data member
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

I've just had a go at compiling gcc trunk with clang.
It says

/usr/bin/../lib/gcc/x86_64-redhat-linux/5.0.0/../../../../include/c++/5.0.0/stdexcept:83:28:
error: invalid use of non-static data member '_M_s'

It seems for the attached code, clang and gcc don't agree.

typedef unsigned long size_t;

  struct __sso_string
  {
struct __str
{
  const char* _M_p;
  size_t _M_string_length;
  char _M_local_buf[16];
};

union {
  __str _M_s;
  char _M_bytes[sizeof(_M_s)];
};
  };

[Bug testsuite/65394] [5 Regression] r221327 causes gcc.dg/ipa/pr63569.c to fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0
Summary|r221327 causes  |[5 Regression] r221327
   |gcc.dg/ipa/pr63569.c to |causes gcc.dg/ipa/pr63569.c
   |fail|to fail

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-10 00:00:00 |2015-03-12

--- Comment #10 from Thomas Preud'homme  ---
(In reply to Martin Sebor from comment #8)
> Created attachment 35016 [details]
> Test case for nettle md4 test failure.
> 
> The attached test case reduced from Nettle 3.0 test 7 in
> testsuite/md4-test.c reproduces the suspected gcc 5.0 incorrect code
> generation on ppc64le.  Compile with -O3 and run and observe a SIGABRT.

I don't have access to such a machine right now so I would appreciate if
somebody can give me the instruction that causes the abort.

Thanks

[Bug tree-optimization/65391] missed store motion for conditionally updated pointer in loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
Summary|unnecessary load of |missed store motion for
   |conditionally updated   |conditionally updated
   |pointer in loop |pointer in loop

--- Comment #4 from Richard Biener  ---
The issue is that invariant/store motion doesn't see the unconditional store
to *o_ptr before the loop and thus thinks that the conditional one may trap.

LIM doesn't consider stores/loads in blocks that are post-dominated by
the loop header to alter that loops "effectively accessed" set of references.
I think considering only the loop preheader is good enough - but we also do not
analyze memory references in non-loop areas (loop preheaders would need to be
added here as well).

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
   0x1a00 <+1024>:  bl  0x15b0 <_init+112>
   0x1a04 <+1028>:  ld  r2,24(r1)
   0x1a08 <+1032>:  lwz r9,224(r1)
   0x1a0c <+1036>:  addir3,r1,200
   0x1a10 <+1040>:  addir4,r1,380
   0x1a14 <+1044>:  stw r9,380(r1)
   0x1a18 <+1048>:  lwz r9,228(r1)
   0x1a1c <+1052>:  stw r9,384(r1)
   0x1a20 <+1056>:  lwz r9,232(r1)
   0x1a24 <+1060>:  stw r9,388(r1)
   0x1a28 <+1064>:  lwz r9,236(r1)
   0x1a2c <+1068>:  stw r9,392(r1)
   0x1a30 <+1072>:  lwz r9,240(r1)
   0x1a34 <+1076>:  stw r9,396(r1)
   0x1a38 <+1080>:  lwz r9,244(r1)
   0x1a3c <+1084>:  stw r9,400(r1)
   0x1a40 <+1088>:  lwz r9,248(r1)
   0x1a44 <+1092>:  stw r9,404(r1)
   0x1a48 <+1096>:  lwz r9,252(r1)
   0x1a4c <+1100>:  stw r9,408(r1)
   0x1a50 <+1104>:  lwz r9,256(r1)
   0x1a54 <+1108>:  stw r9,412(r1)
   0x1a58 <+1112>:  lwz r9,260(r1)
   0x1a5c <+1116>:  stw r9,416(r1)
   0x1a60 <+1120>:  lwz r9,264(r1)
   0x1a64 <+1124>:  stw r9,420(r1)
   0x1a68 <+1128>:  lwz r9,268(r1)
   0x1a6c <+1132>:  stw r9,424(r1)
   0x1a70 <+1136>:  lwz r9,272(r1)
   0x1a74 <+1140>:  stw r9,428(r1)
   0x1a78 <+1144>:  lwz r9,276(r1)
   0x1a7c <+1148>:  stw r9,432(r1)
   0x1a80 <+1152>:  lwz r9,280(r1)
   0x1a84 <+1156>:  stw r9,436(r1)
   0x1a88 <+1160>:  lwz r9,284(r1)
   0x1a8c <+1164>:  stw r9,440(r1)
   0x1a90 <+1168>:  bl  0x1cb0 
   0x1a94 <+1172>:  li  r3,0
   0x1a98 <+1176>:  b   0x1784 
   0x1a9c <+1180>:  bl  0x15e0 <_init+160>
   0x1aa0 <+1184>:  ld  r2,24(r1)
---Type  to continue, or q  to quit---
   0x1aa4 <+1188>:  cmpdi   cr7,r3,0
   0x1aa8 <+1192>:  beq cr7,0x1988 
   0x1aac <+1196>:  li  r3,1
   0x1ab0 <+1200>:  b   0x1998 
   0x1ab4 <+1204>:  bl  0x15f0 <_init+176>
=> 0x1ab8 <+1208>:  ld  r2,24(r1)
   0x1abc <+1212>:  .long 0x0
   0x1ac0 <+1216>:  .long 0x100
   0x1ac4 <+1220>:  .long 0x1280

[Bug sanitizer/65400] New: tsan mis-compiles inlineable C functions

[bernd.edlinger at hotmail dot de]

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

Bug ID: 65400
   Summary: tsan mis-compiles inlineable C functions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 35018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35018&action=edit
stripped down test case

Hi,

I am not sure when this started, probably in february where I was
busy with other tasks, but current trunk miscompiles numerous
simple C functions if optimizations are enabled.  I isolated one example
in the OPC UA ANSI-C stack, and crated a small test case from it.

It mis-compiles with these set of options:

gcc -O2 -fsanitize=thread,undefined -c opcua_string.c

the problem is here:

04b0 :
 4b0:   53  push   %rbx
 4b1:   48 89 fbmov%rdi,%rbx
 4b4:   48 8b 7c 24 08  mov0x8(%rsp),%rdi
 4b9:   e8 00 00 00 00  callq  4be 
4ba: R_X86_64_PC32  __tsan_func_entry-0x4
 4be:   48 85 dbtest   %rbx,%rbx
 4c1:   74 1d   je 4e0 
 4c3:   48 89 dfmov%rbx,%rdi
 4c6:   e8 00 00 00 00  callq  4cb 
4c7: R_X86_64_PC32  __tsan_read1-0x4
 4cb:   80 3b 00cmpb   $0x0,(%rbx)
 4ce:   75 10   jne4e0 
 4d0:   48 89 dfmov%rbx,%rdi
 4d3:   5b  pop%rbx
 4d4:   e9 27 fb ff ff  jmpq   0 
 4d9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
 4e0:   5b  pop%rbx
 4e1:   e9 00 00 00 00  jmpq   4e6 
4e2: R_X86_64_PC32  __tsan_func_exit-0x4


a call to __tsan_func_exit is missing before jmpq 

note that OpcUa_String_Clear.part.0 also call __tsan_func_entry
thus the call stack is completely scrambled:

 :
   0:   55  push   %rbp
   1:   53  push   %rbx
   2:   48 89 fbmov%rdi,%rbx
   5:   48 83 ec 08 sub$0x8,%rsp
   9:   48 8b 7c 24 18  mov0x18(%rsp),%rdi
   e:   e8 00 00 00 00  callq  13 
f: R_X86_64_PC32__tsan_func_entry-0x4


The with other optimization levels or without -fsanitize=undefined,
this example compiles correctly, but some other function start
to have problems.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[thopre01 at gcc dot gnu.org]

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

--- Comment #12 from Thomas Preud'homme  ---
(In reply to Markus Trippelsdorf from comment #11)
>0x1a00 <+1024>:  bl  0x15b0 <_init+112>
>0x1a04 <+1028>:  ld  r2,24(r1)
>0x1a08 <+1032>:  lwz r9,224(r1)
>0x1a0c <+1036>:  addir3,r1,200
>0x1a10 <+1040>:  addir4,r1,380
>0x1a14 <+1044>:  stw r9,380(r1)
>0x1a18 <+1048>:  lwz r9,228(r1)
>0x1a1c <+1052>:  stw r9,384(r1)
>0x1a20 <+1056>:  lwz r9,232(r1)
>0x1a24 <+1060>:  stw r9,388(r1)
>0x1a28 <+1064>:  lwz r9,236(r1)
>0x1a2c <+1068>:  stw r9,392(r1)
>0x1a30 <+1072>:  lwz r9,240(r1)
>0x1a34 <+1076>:  stw r9,396(r1)
>0x1a38 <+1080>:  lwz r9,244(r1)
>0x1a3c <+1084>:  stw r9,400(r1)
>0x1a40 <+1088>:  lwz r9,248(r1)
>0x1a44 <+1092>:  stw r9,404(r1)
>0x1a48 <+1096>:  lwz r9,252(r1)
>0x1a4c <+1100>:  stw r9,408(r1)
>0x1a50 <+1104>:  lwz r9,256(r1)
>0x1a54 <+1108>:  stw r9,412(r1)
>0x1a58 <+1112>:  lwz r9,260(r1)
>0x1a5c <+1116>:  stw r9,416(r1)
>0x1a60 <+1120>:  lwz r9,264(r1)
>0x1a64 <+1124>:  stw r9,420(r1)
>0x1a68 <+1128>:  lwz r9,268(r1)
>0x1a6c <+1132>:  stw r9,424(r1)
>0x1a70 <+1136>:  lwz r9,272(r1)
>0x1a74 <+1140>:  stw r9,428(r1)
>0x1a78 <+1144>:  lwz r9,276(r1)
>0x1a7c <+1148>:  stw r9,432(r1)
>0x1a80 <+1152>:  lwz r9,280(r1)
>0x1a84 <+1156>:  stw r9,436(r1)
>0x1a88 <+1160>:  lwz r9,284(r1)
>0x1a8c <+1164>:  stw r9,440(r1)
>0x1a90 <+1168>:  bl  0x1cb0 
>0x1a94 <+1172>:  li  r3,0
>0x1a98 <+1176>:  b   0x1784 
>0x1a9c <+1180>:  bl  0x15e0 <_init+160>
>0x1aa0 <+1184>:  ld  r2,24(r1)
> ---Type  to continue, or q  to quit---
>0x1aa4 <+1188>:  cmpdi   cr7,r3,0
>0x1aa8 <+1192>:  beq cr7,0x1988 
>0x1aac <+1196>:  li  r3,1
>0x1ab0 <+1200>:  b   0x1998 
>0x1ab4 <+1204>:  bl  0x15f0 <_init+176>
> => 0x1ab8 <+1208>:  ld  r2,24(r1)
>0x1abc <+1212>:  .long 0x0
>0x1ac0 <+1216>:  .long 0x100
>0x1ac4 <+1220>:  .long 0x1280

Alright, so the last 8 bytes of buffer and digest differ. I'll unwind this
tomorrow. Thanks!

[Bug tree-optimization/46038] Vectorizer generates misaligned address for vld1 qn, [rn:alignment]

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #1 from renlin at gcc dot gnu.org ---
I cannot reproduce the fault in 4.9 or trunk.

[Bug target/65044] ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Mar 12 09:23:06 2015
New Revision: 221379

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

PR target/65044
* toplev.c (process_options): Restrict Pointer Bounds Checker
usage with Address Sanitizer.

gcc/testsuite/

PR target/65044
* gcc.target/i386/pr65044.c: New.


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

[Bug other/65384] Intel MPX does not support x32

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Mar 12 08:58:08 2015
New Revision: 221378

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

   PR other/65384
   * configure.ac: Fix x32 test.
   * configure: Regenerate.


Modified:
trunk/libmpx/ChangeLog
trunk/libmpx/configure
trunk/libmpx/configure.ac

[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 12 08:34:00 2015
New Revision: 221376

URL: https://gcc.gnu.org/viewcvs?rev=221376&root=gcc&view=rev
Log:
PR tree-optimization/65388

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/tree-ssa-tail-merge.c

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 12 08:31:36 2015
New Revision: 221375

URL: https://gcc.gnu.org/viewcvs?rev=221375&root=gcc&view=rev
Log:
PR tree-optimization/65388
* tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in comparison.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Thu Mar 12 08:01:24 2015
New Revision: 221374

URL: https://gcc.gnu.org/viewcvs?rev=221374&root=gcc&view=rev
Log:
Revert 'require nonpic target' for fuse-caller-save*.c

2015-03-12  Tom de Vries  

PR rtl-optimization/64895
* gcc.target/i386/fuse-caller-save-rec.c: Revert require nonpic target.
* gcc.target/i386/fuse-caller-save-xmm.c: Ditto.
* gcc.target/i386/fuse-caller-save.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c

[Bug target/65103] [i386] GOTOFF relocation is not propagated into address expression

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Thu Mar 12 09:53:36 2015
New Revision: 221380

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

PR target/65103
* config/i386/i386.c (ix86_address_cost): Fix cost of a PIC
register.

gcc/testsuite/

PR target/65103
* gcc.target/i386/pr65103-1.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65103-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 12 08:34:00 2015
New Revision: 221376

URL: https://gcc.gnu.org/viewcvs?rev=221376&root=gcc&view=rev
Log:
PR tree-optimization/65388

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/tree-ssa-tail-merge.c

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 12 08:31:36 2015
New Revision: 221375

URL: https://gcc.gnu.org/viewcvs?rev=221375&root=gcc&view=rev
Log:
PR tree-optimization/65388
* tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in comparison.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c

[Bug other/65384] Intel MPX does not support x32

[ienkovich at gcc dot gnu.org]

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

ienkovich at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ienkovich at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from ienkovich at gcc dot gnu.org ---
Fixed

[Bug target/39429] compiler create bad asm codes.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.5.0

--- Comment #10 from Ramana Radhakrishnan  ---
Fixed in 4.5.0 but not earlier.

[Bug target/65044] ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds

[ienkovich at gcc dot gnu.org]

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

ienkovich at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ienkovich at gcc dot gnu.org ---
Fixed

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.4.0

--- Comment #15 from Ramana Radhakrishnan  ---
Fixed. ... Wont fix on the 4.3 branch which is now long dead.

[Bug testsuite/65394] [5 Regression] r221327 causes gcc.dg/ipa/pr63569.c to fail

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Should be fixed by r221371.

[Bug rtl-optimization/65401] New: [5 Regression] make_field_assignment broken for big-endian

[jakub at gcc dot gnu.org]

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

Bug ID: 65401
   Summary: [5 Regression] make_field_assignment broken for
big-endian
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

struct S { unsigned short s[64]; };

__attribute__((noinline, noclone)) void
foo (struct S *x)
{
  unsigned int i;
  unsigned char *s;

  s = (unsigned char *) x->s;
  for (i = 0; i < 64; i++)
x->s[i] = s[i * 2] | (s[i * 2 + 1] << 8);
}  

int
main ()
{
  unsigned int i;
  struct S s;
  for (i = 0; i < 64; i++)
s.s[i] = i + ((64 - i) << 8);
  foo (&s);
  for (i = 0; i < 64; i++)
if (s.s[i] != (64 - i) + (i << 8))
  __builtin_abort ();
  return 0;
}

is miscompiled on s390x-linux with -m64 -march=z9-109 -mtune=z10 -O2 -fPIC
since r220249, but most likely has been latent before that.
make_field_assignment during combine misoptimizes:
(set (mem:HI (plus:DI (reg/v/f:DI 126 [ x ])
(reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41,
offset: 0B]+0 S2 A16])
(ior:HI (zero_extend:HI (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
(reg:DI 125 [ ivtmp.11 ])) [0 MEM[base: s_4, index:
ivtmp.11_41, offset: 0B]+0 S1 A8]))
(subreg:HI (reg:SI 128 [ D.1536 ]) 2)))
into:
(set (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
(reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41,
offset: 0B]+0 S1 A16])
(subreg:QI (lshiftrt:SI (reg:SI 128 [ D.1536 ])
(const_int 8 [0x8])) 3))
which is just wrong for big-endian.

[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-12
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug c++/65399] error: invalid use of non-static data member

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Already fixed, update your GCC sources.

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

[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

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

[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Ah, not latent, that make_field_assignment stuff has been added in r220249.
So, either we need to disable it altogether for anything but little endian, or
adjust the addresses when adjusting MEMs mode too.

[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 12 13:02:42 2015
New Revision: 221386

URL: https://gcc.gnu.org/viewcvs?rev=221386&root=gcc&view=rev
Log:
2015-03-12  Richard Biener  

PR middle-end/65270
* fold-const.c (operand_equal_p): Fix ordering of resetting
OEP_ADDRESS_OF and checking for it in the [TARGET_]MEM_REF case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug c++/65399] error: invalid use of non-static data member

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(Also you should have seen the duplicate bug with *exactly* the same error
message when submitting this one)

[Bug c/65402] New: global register variables miscompiled when unit contains sse4.2 functions

[mattiase at acm dot org]

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

Bug ID: 65402
   Summary: global register variables miscompiled when unit
contains sse4.2 functions
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattiase at acm dot org

The mere presence of a function with the attribute target("sse4.2") is enough
for gcc to miscompile other functions with respect to global register
variables:

 code below! -
__attribute__((target("sse4.2"))) void F(void) {}

register long gr1 asm("r12");
register long gr2 asm("r13");

long G(void);

int H(void) {
  gr1 = G();   /* Any code at all, really. */
  return 1;
}
- code above! 

The existence of F causes H to save/restore all global register variables in
its prologue/epilogue, which of course makes these variables impossible to use
inside H. Comment out the definition of F, and the problem disappears.

This occurs in GCC 4.9.2 on x86-64 (Linux), with -O0 or -O2.

Possible workaround: move the register declarations to above F. This is not
always easy (in our case, F is really the stuff in ia32intrin.h that happened
to be included from header files that we need for the types in the register
variable declarations).

Although it's good practice to put the global register declarations at the top
of the unit, not doing so shouldn't cause functions below to be miscompiled.

This appears to be a regression; the bug is not present in GCC 4.8.1.

[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
I was in this code recently, so mine.

[Bug c++/65399] error: invalid use of non-static data member

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Jonathan Wakely from comment #2)
> (Also you should have seen the duplicate bug with *exactly* the same error
> message when submitting this one)

Agreed, I should have done, but I didn't. It looks like
a problem in the search mechanism.

While my gcc trunk sources are less than one day old,
it seems that the error is in fedora alpha 22,
for their gcc dated 20150226.

[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar 12 13:40:50 2015
New Revision: 221387

URL: https://gcc.gnu.org/viewcvs?rev=221387&root=gcc&view=rev
Log:
[simplify-rtx] PR 65235: Calculate element size correctly when simplifying
(vec_select (vec_concat (const_int) (...)) [...])

PR rtl-optimization 65235
* simplify-rtx.c (simplify_binary_operation_1, VEC_SELECT case):
When first element of vec_concat is const_int, calculate its size
using second element.

PR rtl-optimization 65235
* gcc.target/aarch64/pr65235_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr65235_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
In the
9345  else if (GET_CODE (rhs) == AND
9346   && paradoxical_subreg_p (XEXP (rhs, 0))
9347   && GET_CODE (SUBREG_REG (XEXP (rhs, 0))) == MEM
9348   && CONST_INT_P (XEXP (rhs, 1))
9349   && rtx_equal_for_field_assignment_p (gen_rtx_MEM (GET_MODE
(dest),
9350 XEXP (SUBREG_REG (XEXP (rhs, 0)), 0)),
9351dest))
hunks (two similar ones) sometimes GET_MODE (SUBREG_REG (XEXP (rhs, 0))) is
== GET_MODE (dest), then it is certainly safe for big endian and you shouldn't
need to even create a new MEM.
For the other case, I'd say when increasing the mode size you really need to
adjust the address of the mem for endianity, dunno if it is possible to have
also narrower dest than the SUBREG_REG MEM, in that case punt?
Oh, and please use MEM_P instead of GET_CODE () == MEM.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-12 00:00:00 |2015-03-10 0:00
 CC||amodra at gmail dot com

--- Comment #13 from Alan Modra  ---
Markus, are you sure about comment #9?  I completely disabled the bswap pass
and still see a failure of the testcase at -O3.

Incidentally, if I compile with -O2 -fno-inline, the testcase fails on the
first iteration rather than the second (unaligned case) iteration.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[amodra at gmail dot com]

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

--- Comment #14 from Alan Modra  ---
That should be -O3 -fno-inline.

[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||5.0
  Known to fail|5.0 |

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will backport to branches later.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
(In reply to Alan Modra from comment #13)
> Markus, are you sure about comment #9?  I completely disabled the bswap pass
> and still see a failure of the testcase at -O3.
> 
> Incidentally, if I compile with -O2 -fno-inline, the testcase fails on the
> first iteration rather than the second (unaligned case) iteration.

Yes r210842 is fine, r210843 fails with -O3.

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[boger at us dot ibm.com]

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

--- Comment #51 from boger at us dot ibm.com ---
Here is the change I made to go-callers.c.  This patch along with my previous
changes to extern.go and pprof.go allows the test identified in this issue to
report the correct line number on ppc64le.  I wanted to post it here for
comments before I do the bootstrap build and test on ppc64 and ppc64le in case
there is a concern with using an #if defined.  This is in libgo/runtime and I
didn't see any other examples where it used the GOARCH value in C code so that
is why I did it this way.

===
--- libgo/runtime/go-callers.c  (revision 221039)
+++ libgo/runtime/go-callers.c  (working copy)
@@ -83,6 +83,10 @@ callback (void *data, uintptr_t pc, const char *fi
 }

   loc = &arg->locbuf[arg->index];
+#if defined(__powerpc64__) || defined(__s390__) || defined(__s390x__)
+  if ((pc & 1) == 1)
+pc++;
+#endif
   loc->pc = pc;

   /* The libbacktrace library says that these strings might disappear,

[Bug c/65403] New: -Wno-error= is an error

[rguenth at gcc dot gnu.org]

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

Bug ID: 65403
   Summary: -Wno-error= is an error
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

If you want to silence warnings you can use -Wno-XXX without caring about
whether
a compiler implements -WXXX already.  This doesn't seem to work with
-Wno-error=XXX which errors on unknown XXX.

It seems to me that we should treat -W[no-]error=XXX the same as -Wno-XXX
for unknown XXX as it certainly will enable/disable errors for the warning XXX
both if present or not present (no warnings anyway).

> gcc-5 -Wall -Werror -Wno-error=logical-not-parentheses -S t.c
> gcc-4.8 -Wall -Werror -Wno-error=logical-not-parentheses -S t.c
cc1: error: -Werror=logical-not-parentheses: no option
-Wlogical-not-parentheses

> gcc-5 -Wno-error=foo -S t.c
cc1: error: -Werror=foo: no option -Wfoo

[Bug c/65403] -Wno-error= is an error

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Besides that the error also complains about -Werror= instead of -Wno-error=

[Bug go/65404] New: cgo tool on powerpc-linux-gnu maybe incomplete

[doko at gcc dot gnu.org]

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

Bug ID: 65404
   Summary: cgo tool on powerpc-linux-gnu maybe incomplete
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com

cgo tool on powerpc-linux-gnu maybe incomplete

the symptom noted at https://launchpad.net/bugs/1431032
shows an error:
dist/src/github.com/lxc/lxd/shared/container.go:11:2: C source files not
allowed when not using cgo: sqlite3-binding.c

another not yet implemented issue is the support for PPC relocations, reported
as
https://github.com/golang/go/issues/10118

[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Biener  ---
Sth like

@@ -672,8 +650,18 @@ cleanup_tree_cfg_bb (basic_block bb)
   if (single_succ_p (bb)
   && can_merge_blocks_p (bb, single_succ (bb)))
 {
-  merge_blocks (bb, single_succ (bb));
-  return true;
+  /* If there is a merge opportunity with the predecessor
+ do nothing now but wait until we process the predecessor.
+This happens when we visit BBs in a non-optimal order and
+avoids quadratic behavior with adjusting stmts BB pointer.  */
+  if (single_pred_p (bb)
+ && can_merge_blocks_p (single_pred (bb), bb))
+   ;
+  else
+   {
+ merge_blocks (bb, single_succ (bb));
+ return true;
+   }
 }

   return retval;

in addition should do the job.  Iteration on the predecessor should
cover both merges (so we don't actually need to revisit this block itself).

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
Yeah, it is really weird.  With -O0 the testcase also fails on the first
iteration.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
I've tried to add
__builtin_memset(ctx, 0, sizeof (*ctx));
to the beginning of md4_init and it changes the result of the program at -O0,
so I expect the testcase relies on some particular pattern of uninitialized
data in ctx->block.

[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-12
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Kai Tietz  ---
This issue seems to be fixed in 5.0 by Richard's work on libffi.

Could you please check, if issue is fixed for you?

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[ian at airs dot com]

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

--- Comment #52 from Ian Lance Taylor  ---
Why not just
pc++;
on all targets?  Why the #ifdef?  It seems to me that we should aim for
consistent results on all platforms.

[Bug sanitizer/65400] tsan mis-compiles inlineable C functions

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
I think the trouble starts at opcua_string.c.039t.fnsplit :

OpcUa_String_Clear (struct OpcUa_String * a_pString)
{
 ...
  :
  # _25 = PHI <0(2), 1(3), 0(4)>
  if (_25 == 0)
goto ;
  else
goto ;

  :
  OpcUa_String_Clear.part.0 (a_pString_3(D));
  goto ;

  :
  TSAN_FUNC_EXIT ();

  :
  return;

}

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor  ---
The original test doesn't show any valgrind errors so these could be the result
of using delta to reduce the test case.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Yeah.  In md4_digest, for (i = 0; i < 16 - 2; i++) look writes data[0] through
data[13], data[14] is stored after the loop, but data[15] is uninitialized,
but md5_transform reads it and uses it.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Looking at https://git.lysator.liu.se/nettle/nettle/blob/master/md4.c I see
there:
  bit_count = (ctx->count << 9) | (ctx->index << 3);
  data[MD4_DATA_LENGTH-2] = bit_count;
  data[MD4_DATA_LENGTH-1] = bit_count >> 32;
and thus it initializes everything.

[Bug lto/65376] LTO prevents use of fmadd

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #4 from Ramana Radhakrishnan  ---
I think this is not an issue any longer on 5.0. With a cross-compiler to
aarch64-none-linux-gnu built on 09032015, I see the following output

$GCC -flto -Ofast /tmp/fma.c -o t

00400528 :
  400528:   1e600800fmuld0, d0, d0
  40052c:   1f410020fmadd   d0, d1, d1, d0
  400530:   d65f03c0ret
  400534:   d503201fnop


Didn't honza do some work earlier this year in the 5.0 time frame to treat
ffp-contract similar to other options for LTO ? 

regards
Ramana

[Bug lto/65376] LTO prevents use of fmadd

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #22 from Markus Trippelsdorf  ---
Could you please attach the unreduced testcase?

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Created attachment 35019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35019&action=edit
pr65369.c

Adjusted testcase that now works reliably at -O0, and even with -O3
-fno-inline, but fails with -O3 on powerpc64le-linux.  Works on x86_64-linux. 
Contains LP64 dependency right now...

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[msebor at gcc dot gnu.org]

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

--- Comment #24 from Martin Sebor  ---
Created attachment 35020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35020&action=edit
Unreduced translation unit of the test program.

Compil and run like so:

$ gcc -O3 -Wall -Werror  gcc-65369.i && valgrind ./a.out
==86961== Memcheck, a memory error detector
==86961== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==86961== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==86961== Command: ./a.out
==86961== 
buffer[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
buffer[] = { \xdd \x41 \x11 \xdd \x66 \x91 \x3a \xe2 \xf3 \x9a \xdf \xbc \x43
\x82 \x14 \xd6 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
a.out: gcc-65369.c:41: main: Assertion `0 == memcmp (buffer, digest, sizeof
buffer - 1)' failed.
==86961== 
==86961== HEAP SUMMARY:
==86961== in use at exit: 97 bytes in 1 blocks
==86961==   total heap usage: 3 allocs, 2 frees, 295 bytes allocated
==86961== 
==86961== LEAK SUMMARY:
==86961==definitely lost: 0 bytes in 0 blocks
==86961==indirectly lost: 0 bytes in 0 blocks
==86961==  possibly lost: 97 bytes in 1 blocks
==86961==still reachable: 0 bytes in 0 blocks
==86961== suppressed: 0 bytes in 0 blocks
==86961== Rerun with --leak-check=full to see details of leaked memory
==86961== 
==86961== For counts of detected and suppressed errors, rerun with: -v
==86961== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #18 from Markus Trippelsdorf  ---
trippels@gcc2-power8 ~ % valgrind --track-origins=yes ./a.out
==152914== Memcheck, a memory error detector
==152914== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==152914== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==152914== Command: ./a.out
==152914==
==152914== Use of uninitialised value of size 8
==152914==at 0x4135C58: _itoa_word (in /usr/lib64/libc-2.20.so)
==152914==by 0x413A42B: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x1000132B: main (gcc-65369.c:199)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x4135C60: _itoa_word (in /usr/lib64/libc-2.20.so)
==152914==by 0x413A42B: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x1000132B: main (gcc-65369.c:199)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Use of uninitialised value of size 8
==152914==at 0x4135C6C: _itoa_word (in /usr/lib64/libc-2.20.so)
==152914==by 0x413A42B: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x1000132B: main (gcc-65369.c:199)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x413A4AC: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x414107B: printf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x1000132B: main (gcc-65369.c:199)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x413A2CC: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x414107B: printf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so)
==152914==by 0x1000132B: main (gcc-65369.c:199)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
buffer[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x409BE6C: memcmp (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so)
==152914==by 0x100013AB: main (gcc-65369.c:204)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x409BE94: memcmp (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so)
==152914==by 0x100013AB: main (gcc-65369.c:204)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
buffer[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x409BE6C: memcmp (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so)
==152914==by 0x1000138F: main (gcc-65369.c:203)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914== Conditional jump or move depends on uninitialised value(s)
==152914==at 0x409BE94: memcmp (in
/usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so)
==152914==by 0x1000138F: main (gcc-65369.c:203)
==152914==  Uninitialised value was created by a stack allocation
==152914==at 0x100010F0: md4_digest (gcc-65369.c:143)
==152914==
==152914==
==152914== HEAP SUMMARY:
==152914== in use at exit: 0 bytes in 0 blocks
==152914==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==152914==
==152914== All heap blocks were freed -- no leaks are possible
==152914==
==152914== For counts of detected and suppressed errors, rerun with: -v
==152914== ERROR SUMMARY: 206 errors from 9 contexts (suppressed: 0 from 0)

[Bug sanitizer/65400] tsan mis-compiles inlineable C functions

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Jakub,

at that time we do not have the __tsan_func_entry calls, only
the __TSAN_FUNC_EXIT thing.

in opcua_string.c.038t.local-pure-const1
OpcUa_String_Clear looks like it has OpcUa_String_Clear.part.0
at the end.  folding that into a call to OpcUa_String_Clear.part.0
eats away the __TSAN_FUNC_EXIT.

[Bug fortran/65045] [4.8/4.9/5 Regression] ICE when using the same name for a block and a variable.

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to Paul Thomas from comment #2)
> The attached patch bootstraps and regtests on trunk with FC21/x86_64.

Looks good to me - okay with a test case and a ChangeLog.

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
There is nothing in the cgo tool which would cause this error.

When the command runs "go", which go tool is actually running?  The difference
may be that on platforms other than powerpc-linux-gnu it is running the go tool
from the gc compiler, but on powerpc-linux-gnu it is running the go tool from
the gccgo compiler.  This could potentially happen because the gc compiler does
not support 32-bit powerpc.

[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power

[bergner at gcc dot gnu.org]

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

--- Comment #10 from Peter Bergner  ---
Strange, this fails with my builds on our internal POWER8 box, but doesn't with
my build on the external gcc112 POWER8 compile farm system.  I'll try and track
down what the difference is and see if I can recreate it on the external
system.

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
see http://paste.ubuntu.com/10586128/

afaics it is both running the go tool from GCC 5. no other go tool is
installed.

[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9

[mikael at gcc dot gnu.org]

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

--- Comment #24 from Mikael Morin  ---
Author: mikael
Date: Thu Mar 12 16:08:48 2015
New Revision: 221395

URL: https://gcc.gnu.org/viewcvs?rev=221395&root=gcc&view=rev
Log:
PR fortran/60898
fortran/
* resolve.c (resolve_symbol): Check that the symbol found by
name lookup really is the current symbol being resolved.
testsuite/
* gfortran.dg/entry_20.f90: New.



Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/entry_20.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/resolve.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/65403] -Wno-error= is an error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-12
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
For fixing the output, the following should be enough:

Index: opts.c
===
--- opts.c  (revision 221118)
+++ opts.c  (working copy)
@@ -2341,11 +2341,12 @@ enable_warning_as_error (const char *arg
   new_option[0] = 'W';
   strcpy (new_option + 1, arg);
   option_index = find_opt (new_option, lang_mask);
   if (option_index == OPT_SPECIAL_unknown)
 {
-  error_at (loc, "-Werror=%s: no option -%s", arg, new_option);
+  error_at (loc, "-W%s=%s: no option -%s",
+   value ? "error" : "no-error", arg, new_option);
 }
   else
 {
   const diagnostic_t kind = value ? DK_ERROR : DK_WARNING;

[Bug fortran/65045] [4.8/4.9/5 Regression] ICE when using the same name for a block and a variable.

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Hi Tobias,

Thanks. I found one or two similar testcases that still fail. As soon
as I find some time, I will submit a complete fix.

How was the sailing in Scotland?

Paul

On 12 March 2015 at 16:59, burnus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045
>
> Tobias Burnus  changed:
>
>What|Removed |Added
> 
>  CC||burnus at gcc dot gnu.org
>
> --- Comment #3 from Tobias Burnus  ---
> (In reply to Paul Thomas from comment #2)
>> The attached patch bootstraps and regtests on trunk with FC21/x86_64.
>
> Looks good to me - okay with a test case and a ChangeLog.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[stgraber at stgraber dot org]

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

Stéphane Graber  changed:

   What|Removed |Added

 CC||stgraber at stgraber dot org

--- Comment #3 from Stéphane Graber  ---
Hi,

Correct, on both my powerpc and ppc64le systems, I'm running:

(vivid-ppc64el)stgraber@kelsey01:~$ go version
go version go1.4.2 gccgo (Ubuntu 5-20150309-1ubuntu1) 5.0.0 20150310
(experimental) [trunk revision 221296] linux/ppc64le

(vivid-powerpc-sbuild)root@winton-06:~# go version
go version go1.4.2 gccgo (Ubuntu 5-20150309-1ubuntu1) 5.0.0 20150310
(experimental) [trunk revision 221296] linux/ppc


The ppc64le one works fine, the powerpc one fails.

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
OK, found it.  Thanks.  Will send patch shortly.

[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #25 from Markus Trippelsdorf  ---
Jakub's reduced- and the unreduced testcase also started to fail 
with r210843.

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Mar 12 16:41:28 2015
New Revision: 221396

URL: https://gcc.gnu.org/viewcvs?rev=221396&root=gcc&view=rev
Log:
PR go/65404
go/build: cgo works on linux/pcc.

Modified:
trunk/libgo/go/go/build/build.go

[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #6 from Ian Lance Taylor  ---
This one should be fixed.

[Bug target/63679] [5 / 6 Regression][AArch64] Failure to constant fold.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
   Target Milestone|5.0 |6.0
Summary|[5 Regression][AArch64] |[5 / 6 Regression][AArch64]
   |Failure to constant fold.   |Failure to constant fold.

--- Comment #31 from Ramana Radhakrishnan  ---
(In reply to rguent...@suse.de from comment #30)
> On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> > 
> > --- Comment #29 from Tejas Belagod  ---
> > (In reply to rguent...@suse.de from comment #28)
> > > On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> > > > 
> > > > --- Comment #27 from Tejas Belagod  ---
> > > > We'd want to scalarize this early preferably in SRA as it gives a 
> > > > chance to
> > > > passes like vectorization to vectorize more loops. I checked that
> > > > sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a = 
> > > > *.LC0'
> > > 
> > > because SRA can't scalarize 'a = *.LC0'.  But yes, ideally we'd change
> > > gimplification to never decompose initializers but have SRA do it.
> > > But that's of course not a GCC 5 thing.
> > > 
> > > It has the advantage of splitting the initialization only when it is
> > > (likely) profitable and otherwise leave it to the target to decide
> > > how to expand the initialization (and it opens up the possibility
> > > to directly use a constant-pool entry if the data is readonly).
> > 
> > Which cost function(s) control this profitability of early splitting?
> 
> See gimplify_init_constructor and callees.

 Given all the comments above this sounds like a 6.0 fix - I'm just making this
a 6.0 target - we can always change it back if someone can fix it in time for 5 

Ramana

[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|5.0 |---

--- Comment #4 from Ramana Radhakrishnan  ---
Removing the target milestone given that we've agreed it's not a regression.

[Bug target/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
Vlad, 

are you planning a 4.9 backport ? 


Ramana

[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I can reproduce this, but wonder if the bug isn't just earlier in CD-DCE where
the GIMPLE_COND should have been marked necessary.  The immediate
post-dominator is very far from the bb and has tons of incoming edges, some
PHIs are not marked as unnecessary and certainly aren't degenerate:

:
# _17 = PHI <0(15), 0(19), 0(21), 1(34), 0(115), 0(121), 0(129), 0(132),
0(137), 0(140), _112(143), 1(170), 0(31), 1(113), 0(50), 0(42), 0(37), 0(52),
0(46), 0(48)>
# JMPBUF_SAVE_926(ab) = PHI 
# prephitmp_56 = PHI 
# DEBUG addr => (const system__address) JMPBUF_SAVE_926(ab)
_796 = system__soft_links__set_jmpbuf_address;
_796 (prephitmp_56);

is the post_dom_bb, and

:
# DEBUG n => _201
_10 = _264;
_601 = _264 * 32;
_233 = _262 + _601;
_724 = MEM[(struct atree__atree_private_part__node_record[2147483648] *)_233 +
104B];
# DEBUG D#7737 => (types__node_id___XDLU_0__) _724
# DEBUG id => D#7737
# DEBUG e => D#7737
_732 = (sizetype) _724;
_733 = _732 + 1;
_734 = *_262[_733].nkind;
_727 = _734 + 243;
if (_727 > 11)
  goto ;
else
  goto ;

is e->src.  Honza, this is your code, can you please have a look?

[Bug c/65403] -Wno-error= is an error

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
For harmonizing how -Wno-X and -Wno-error=X work, it is a bit more convoluted.
This mostly works:

Index: opts-global.c
===
--- opts-global.c   (revision 221118)
+++ opts-global.c   (working copy)
@@ -139,11 +139,11 @@ complain_wrong_lang (const struct cl_dec
prevented a diagnostic. Otherwise, we just ignore them.  Note that
if we do complain, it is only as a warning, not an error; passing
the compiler an unrecognized -Wno-* option should never change
whether the compilation succeeds or fails.  */

-static void
+void
 postpone_unknown_option_warning (const char *opt)
 {
   ignored_options.safe_push (opt);
 }

@@ -152,15 +152,20 @@ postpone_unknown_option_warning (const c
 void
 print_ignored_options (void)
 {
   while (!ignored_options.is_empty ())
 {
-  const char *opt;
-
-  opt = ignored_options.pop ();
-  warning_at (UNKNOWN_LOCATION, 0,
- "unrecognized command line option %qs", opt);
+  const char * opt = ignored_options.pop ();
+  if (strcmp (opt, "-Wno-error=") == 0)
+   {
+ const char * w_opt = opt + strlen ("-Wno-error=");
+ warning_at (UNKNOWN_LOCATION, 0, "-Wno-error=%s: no option -W%s",
+ w_opt, w_opt);
+   }
+  else
+   warning_at (UNKNOWN_LOCATION, 0,
+   "unrecognized command line option %qs", opt);
 }
 }

 /* Handle an unknown option DECODED, returning true if an error should
be given.  */

Index: opts.h
===
--- opts.h  (revision 221118)
+++ opts.h  (working copy)
@@ -400,6 +400,7 @@ extern void default_options_optimization
 extern void set_struct_debug_option (struct gcc_options *opts,
 location_t loc,
 const char *value);
 extern bool opt_enum_arg_to_value (size_t opt_index, const char *arg,
   int *value, unsigned int lang_mask);
+extern void postpone_unknown_option_warning (const char *opt);
 #endif
Index: opts.c
===
--- opts.c  (revision 221118)
+++ opts.c  (working copy)
@@ -2335,17 +2335,23 @@ enable_warning_as_error (const char *arg
 location_t loc, diagnostic_context *dc)
 {
   char *new_option;
   int option_index;

-  new_option = XNEWVEC (char, strlen (arg) + 2);
+  new_option = XNEWVEC (char, strlen (arg) + strlen ("-Wno-error=") + 1);
   new_option[0] = 'W';
   strcpy (new_option + 1, arg);
   option_index = find_opt (new_option, lang_mask);
   if (option_index == OPT_SPECIAL_unknown)
 {
-  error_at (loc, "-Werror=%s: no option -%s", arg, new_option);
+  if (value)
+   error_at (loc, "-Werror=%s: no option -%s",  arg, new_option);
+  else
+   strcpy (new_option, "-Wno-error=");
+   strcat (new_option, arg);
+   postpone_unknown_option_warning (new_option);
+   return;
 }
   else
 {
   const diagnostic_t kind = value ? DK_ERROR : DK_WARNING;


with some caveats:

* It is a bit too convoluted
* In principle enable_warning_as_error() can be called with a loc !=
UNKNOWN_LOCATION, thus we should record this location for reporting the
warning.

[Bug c/65403] -Wno-error= is an error

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
In fact, this version seems much more straightforward:

Index: opts-global.c
===
--- opts-global.c   (revision 221118)
+++ opts-global.c   (working copy)
@@ -60,13 +60,12 @@ along with GCC; see the file COPYING3.  
 #include "toplev.h"
 #include "tree-pass.h"
 #include "context.h"
 #include "asan.h"

-typedef const char *const_char_p; /* For DEF_VEC_P.  */
-
-static vec ignored_options;
+static vec ignored_options;
+static vec ignored_wnoerror_options;

 /* Input file names.  */
 const char **in_fnames;
 unsigned num_in_fnames;

@@ -145,23 +144,35 @@ static void
 postpone_unknown_option_warning (const char *opt)
 {
   ignored_options.safe_push (opt);
 }

+/* This function is equivalent to the above, but it should be used to
+   buffer options passed to -Wno-error=.  */
+void
+postpone_unknown_wnoerror_warning (const char *opt)
+{
+  ignored_wnoerror_options.safe_push (opt);
+}
+
 /* Produce a warning for each option previously buffered.  */

 void
 print_ignored_options (void)
 {
   while (!ignored_options.is_empty ())
 {
-  const char *opt;
-
-  opt = ignored_options.pop ();
+  const char * opt = ignored_options.pop ();
   warning_at (UNKNOWN_LOCATION, 0,
  "unrecognized command line option %qs", opt);
 }
+  while (!ignored_wnoerror_options.is_empty ())
+{
+  const char * opt = ignored_wnoerror_options.pop ();
+  warning_at (UNKNOWN_LOCATION, 0,
+ "-Wno-error=%s: no option -W%s", opt, opt);
+}
 }

 /* Handle an unknown option DECODED, returning true if an error should
be given.  */

Index: opts.c
===
--- opts.c  (revision 221118)
+++ opts.c  (working copy)
@@ -2341,11 +2341,14 @@ enable_warning_as_error (const char *arg
   new_option[0] = 'W';
   strcpy (new_option + 1, arg);
   option_index = find_opt (new_option, lang_mask);
   if (option_index == OPT_SPECIAL_unknown)
 {
-  error_at (loc, "-Werror=%s: no option -%s", arg, new_option);
+  if (value)
+   error_at (loc, "-Werror=%s: no option -%s",  arg, new_option);
+  else
+   postpone_unknown_wnoerror_warning (arg);
 }
   else
 {
   const diagnostic_t kind = value ? DK_ERROR : DK_WARNING;

Index: opts.h
===
--- opts.h  (revision 221118)
+++ opts.h  (working copy)
@@ -400,6 +400,7 @@ extern void default_options_optimization
 extern void set_struct_debug_option (struct gcc_options *opts,
 location_t loc,
 const char *value);
 extern bool opt_enum_arg_to_value (size_t opt_index, const char *arg,
   int *value, unsigned int lang_mask);
+extern void postpone_unknown_wnoerror_warning (const char *opt);
 #endif

[Bug c/65405] New: improve locations of diagnostics in c-pragma.c

[manu at gcc dot gnu.org]

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

Bug ID: 65405
   Summary: improve locations of diagnostics in c-pragma.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

Created attachment 35021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35021&action=edit
patch

#pragma GCC diagnostic
#pragma GCC diagnostic warn
#pragma GCC diagnostic warning
#pragma GCC diagnostic warning "-Wfoo"

Now:

test.c:1:9: warning: missing [error|warning|ignored] after ‘#pragma GCC
diagnostic’ [-Wpragmas]
 #pragma GCC diagnostic
 ^
test.c:2:9: warning: expected [error|warning|ignored|push|pop] after ‘#pragma
GCC diagnostic’ [-Wpragmas]
 #pragma GCC diagnostic warn
 ^
test.c:3:9: warning: missing option after ‘#pragma GCC diagnostic’ kind
[-Wpragmas]
 #pragma GCC diagnostic warning
 ^
test.c:4:9: warning: unknown option after ‘#pragma GCC diagnostic’ kind
[-Wpragmas]
 #pragma GCC diagnostic warning "-Wfoo"
 ^

After the patch:

test.c:1:23: warning: missing [error|warning|ignored] after ‘#pragma GCC
diagnostic’ [-Wpragmas]
 #pragma GCC diagnostic
   ^
test.c:2:24: warning: expected [error|warning|ignored|push|pop] after ‘#pragma
GCC diagnostic’ [-Wpragmas]
 #pragma GCC diagnostic warn
^
test.c:3:31: warning: missing option after ‘#pragma GCC diagnostic’ kind
[-Wpragmas]
 #pragma GCC diagnostic warning
   ^
test.c:4:32: warning: unknown option after ‘#pragma GCC diagnostic’ kind
[-Wpragmas]
 #pragma GCC diagnostic warning "-Wfoo"
^

And in general, the whole c-pragma.c needs to stop using input_location and
warning() and use explicit locations and warning_at().

[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9

[mikael at gcc dot gnu.org]

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

--- Comment #25 from Mikael Morin  ---
Author: mikael
Date: Thu Mar 12 17:26:17 2015
New Revision: 221400

URL: https://gcc.gnu.org/viewcvs?rev=221400&root=gcc&view=rev
Log:
PR fortran/60898
fortran/
* resolve.c (resolve_symbol): Check that the symbol found by
name lookup really is the current symbol being resolved.
testsuite/
* gfortran.dg/entry_20.f90: New.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/entry_20.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/resolve.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog