[Bug c++/61721] GCC 4.8-4.10 miscompiles webkit hashing

[cand at gmx dot com]

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

Lauri Kasanen  changed:

   What|Removed |Added

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

--- Comment #8 from Lauri Kasanen  ---
Found this is a duplicate, and yes, it is a webkit bug.

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

[Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns

[cand at gmx dot com]

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

Lauri Kasanen  changed:

   What|Removed |Added

 CC||cand at gmx dot com

--- Comment #23 from Lauri Kasanen  ---
*** Bug 61721 has been marked as a duplicate of this bug. ***

[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
Created attachment 33345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33345&action=edit
C source code

For the attached code, compiled by gcc trunk dated 20140817,
the following crash message is produced

$ ../results/bin/gcc -c -O2 bug160.c
adb.c: In function ‘send_connect’:
adb.c:316:13: internal compiler error: in compute_may_aliases, at
tree-ssa-structalias.c:6986
0xb1ada6 compute_may_aliases()
../../src/trunk/gcc/tree-ssa-structalias.c:6986
0x8d6514 execute_function_todo
../../src/trunk/gcc/passes.c:1721
0x8d6e2b do_per_function
../../src/trunk/gcc/passes.c:1476
0x8d6e2b execute_todo
../../src/trunk/gcc/passes.c:1806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler flag -O2 required.

[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

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

--- Comment #7 from David Binderman  ---
New attachment might be a related bug, or something new.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to Mike Frysinger from comment #18)
> thanks for your help Eric.  new bisection shows r187042 as a possible
> culprit.  feel free to de-cc yourself :).
> 
> Richard: any thoughts here ?  this change is a bit harder to test reverting
> in the latest 4.8 branch to see if it makes a difference.

Well, usual errors regarding to sizetype apply - you have to treat it
as sign-extending if you promote it to larger types (but I doubt that happens
or matters for ia64 as pointers should be DImode, right?).

But you should be able to spot code-gen differences and see where they
originate
from (the revision wasn't supposed to change code-gen though zero differences
wasn't really possible).

I'll wait for Erics investigation.  (ia64 is a dead architecture IMNSHO)

[Bug sanitizer/62089] Sanitizer may fail to instrument struct accesses

[ygribov at gcc dot gnu.org]

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

--- Comment #2 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Mon Aug 18 08:23:47 2014
New Revision: 214086

URL: https://gcc.gnu.org/viewcvs?rev=214086&root=gcc&view=rev
Log:
2014-08-18  Yury Gribov  

PR sanitizer/62089

gcc/
* asan.c (instrument_derefs): Fix bitfield check.

gcc/testsuite/
* c-c++-common/asan/pr62089.c: New test.
* c-c++-common/asan/bitfield-1.c: New test.
* c-c++-common/asan/bitfield-2.c: New test.
* c-c++-common/asan/bitfield-3.c: New test.
* c-c++-common/asan/bitfield-4.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/bitfield-1.c
trunk/gcc/testsuite/c-c++-common/asan/bitfield-2.c
trunk/gcc/testsuite/c-c++-common/asan/bitfield-3.c
trunk/gcc/testsuite/c-c++-common/asan/bitfield-4.c
trunk/gcc/testsuite/c-c++-common/asan/pr62089.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Ok, same for sprintf.  Testing a patch.

[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case

[vries at gcc dot gnu.org]

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

Bug 62030 Summary: wrong code due to ifcvt merging two stores which have 
different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030

   What|Removed |Added

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

[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vries at gcc dot gnu.org ---
Patch and test-cases (general and mips-specific) committed to trunk, 4.9 and
4.8.

Marking resolved fixed

[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Is this something I can add to the compiler build without a patch?

[Bug tree-optimization/62167] New: [tail-merge] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

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

Bug ID: 62167
   Summary: [tail-merge] dead type-unsafe load replaces type-safe
load
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

The example from PR62004 fails with -ftree-tail-merge. The PR62004 report is
reserved for the rtl if-conversion part, this report is reserved for the
tail-merge part.

[Bug rtl-optimization/62004] [if-conversion] dead type-unsafe load replaces type-safe load

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||alias
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|dead type-unsafe load   |[if-conversion] dead
   |replaces type-safe load |type-unsafe load replaces
   ||type-safe load

--- Comment #8 from vries at gcc dot gnu.org ---
if-conversion patch and test-case committed to trunk, 4.8 and 4.9.

tail-merge part filed as PR62167 - [tail-merge] dead type-unsafe load replaces
type-safe load

marking resolved, fixed

[Bug target/62111] ICE when building Linux kernel for sh64

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
(In reply to Kazumoto Kojima from comment #5)
> ...
> 
> even though general_extend_operand doesn't permit (truncate (mem ...)).
> An easy workaround might be to disable truncate in general_extend_operand
> before reload.
> 
> --- gcc/config/sh/predicates.md.orig  2014-08-02 11:55:29.228875715 +0900
> +++ gcc/config/sh/predicates.md   2014-08-17 08:30:20.439326569 +0900
> ...

This does appear to fix the ICE's.  Unfortunately, it seems the kernel code has
bit-rotted too much to get all the way through building.

[Bug target/62111] ICE when building Linux kernel for sh64

[dhowells at redhat dot com]

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

--- Comment #7 from dhowells at redhat dot com  ---
Having said that, if I use make -k, I can get this:

../drivers/scsi/sd.c: In function 'sd_init_command':
../drivers/scsi/sd.c:1139:1: error: unrecognizable insn:
 }
 ^
(insn 1335 1334 9 190 (set (reg/v:DI 336 [ sector ])
(lshiftrt:DI (reg:DI 171 [ D.34693 ])
(const_int -10 [0xfff6]))) ../drivers/scsi/sd.c:707 -1
 (nil))
../drivers/scsi/sd.c:1139:1: internal compiler error: in extract_insn, at
recog.c:2202

Do you want it reducing?

[Bug other/62168] New: error in configure: line 21572: test: =: unary operator expected

[manfred99 at gmx dot ch]

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

Bug ID: 62168
   Summary: error in configure: line 21572: test: =: unary
operator expected
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch

configure: line 21572: test: =: unary operator expected 

This is:
if test -x "$DEFAULT_LINKER"; then
gcc_cv_ld="$DEFAULT_LINKER"
==> elif test $install_gold_as_default = yes \
 && test -f $gcc_cv_ld_gold_srcdir/configure.ac \
 && test -f ../gold/Makefile \

either install_gold_as_default should be set in all cases a few lines
above, or the variable should be surrounded by quotes:

==> elif test "$install_gold_as_default" = yes \

[Bug target/62111] ICE when building Linux kernel for sh64

[kkojima at gcc dot gnu.org]

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

--- Comment #8 from Kazumoto Kojima  ---
A reduced test case is always welcome.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[venkataramanan.kumar at amd dot com]

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

--- Comment #51 from Venkataramanan  ---
(In reply to rguent...@suse.de from comment #35)
> On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> > 
> > --- Comment #34 from Venkataramanan  
> > ---
> > Richard, What I understand is that instead of using tune flags for garbage
> > collection, need to try and fix the object code differences?
> 
> Yes, it points at real bugs.  OTOH fixing that may not be suitable
> for the release branches, neither is passing fixed values for GC
> parameters.  So I'm not quite sure what a suitable workaround is
> (well, make sure !defined ENABLE_GC_CHECKING && !defined 
> ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2
> for bootstrap-lto, that is, init_ggc_heuristics () is executed
> in the same way)

Hi richard, 

In Stage1 we add --enable-checking=yes,types and it sets  ENABLE_GC_CHECKING as
true 

In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the
check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT"
will be true for stage2 only. 

ENABLE_GC_ALWAYS_COLLECT is false in both stages.

Do we need to make sure stage 1 and stage 2 executes the function
init_ggc_heuristics and will it set the parameters to same value?

[Bug target/62111] ICE when building Linux kernel for sh64

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
(In reply to dhowe...@redhat.com from comment #7)
> Having said that, if I use make -k, I can get this:
> 
> ../drivers/scsi/sd.c: In function 'sd_init_command':
> ../drivers/scsi/sd.c:1139:1: error: unrecognizable insn:
>  }
>  ^
> (insn 1335 1334 9 190 (set (reg/v:DI 336 [ sector ])
> (lshiftrt:DI (reg:DI 171 [ D.34693 ])
> (const_int -10 [0xfff6]))) ../drivers/scsi/sd.c:707
> -1
>  (nil))
> ../drivers/scsi/sd.c:1139:1: internal compiler error: in extract_insn, at
> recog.c:2202
> 
> Do you want it reducing?

My first guess is that one of the commits for PR 54089 caused this, where I
forgot to handle SHmedia cases.  A reduced test case would help a lot indeed.

[Bug libstdc++/62169] New: map iterators under _GLIBCXX_DEBUG diverge

[terra at gnome dot org]

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

Bug ID: 62169
   Summary: map iterators under _GLIBCXX_DEBUG diverge
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org

The two types
std::map::iterator
std::map::iterator
are the same when compiled normally, but different under _GLIBCXX_DEBUG.

I actually don't know if the standard allows that, but if it does and the
difference is intentional, then the documentation ought to mention it.




welinder@sherwood:~> cat iterator.C
#include 
#include 

static int foo (const void *) { return 0; }
static int foo (std::map::iterator *) { return 1; }

int
main ()
{
  std::cerr << foo (static_cast::iterator *> (0)) <<
std::endl;
  return 0;
}

welinder@sherwood:~> g++ iterator.C
welinder@sherwood:~> ./a.out 
1

welinder@sherwood:~> g++ -D_GLIBCXX_DEBUG iterator.C
welinder@sherwood:~> ./a.out 
0


welinder@sherwood:~> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) 


(Preprocessed versions coming up, just in case.)

[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge

[terra at gnome dot org]

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

--- Comment #1 from M Welinder  ---
Created attachment 33346
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33346&action=edit
Preprocessed source code for normal case

[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge

[terra at gnome dot org]

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

--- Comment #2 from M Welinder  ---
Created attachment 33347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33347&action=edit
Preprocessed source code for debug case

[Bug target/62111] ICE when building Linux kernel for sh64

[dhowells at redhat dot com]

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

--- Comment #10 from dhowells at redhat dot com  ---
This is the reduced test case for comment 7:

extern void string_get_size(unsigned long long size);
void sd_read_capacity(unsigned long long capacity)
{
string_get_size(capacity << -1);
}

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[manfred99 at gmx dot ch]

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

--- Comment #1 from Manfred Schwarb  ---
The script in question is gcc/configure, not toplevel configure.
The script error location corrsponds to line 2120 in gcc/configure.ac.

The code in question was introduced in revision 205392 by hjl.

[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge

[terra at gnome dot org]

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

--- Comment #3 from M Welinder  ---
A similar divergence of types occurs between the types

std::map::iterator
std::multimap::iterator

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[rguenther at suse dot de]

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

--- Comment #52 from rguenther at suse dot de  ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> 
> --- Comment #51 from Venkataramanan  ---
> (In reply to rguent...@suse.de from comment #35)
> > On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> > > 
> > > --- Comment #34 from Venkataramanan  
> > > ---
> > > Richard, What I understand is that instead of using tune flags for garbage
> > > collection, need to try and fix the object code differences?
> > 
> > Yes, it points at real bugs.  OTOH fixing that may not be suitable
> > for the release branches, neither is passing fixed values for GC
> > parameters.  So I'm not quite sure what a suitable workaround is
> > (well, make sure !defined ENABLE_GC_CHECKING && !defined 
> > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2
> > for bootstrap-lto, that is, init_ggc_heuristics () is executed
> > in the same way)
> 
> Hi richard, 
> 
> In Stage1 we add --enable-checking=yes,types and it sets  ENABLE_GC_CHECKING 
> as
> true 
> 
> In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the
> check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT"
> will be true for stage2 only. 
> 
> ENABLE_GC_ALWAYS_COLLECT is false in both stages.
> 
> Do we need to make sure stage 1 and stage 2 executes the function
> init_ggc_heuristics and will it set the parameters to same value?

Well, it would be a workaround only.  The real fix is to track down
and fix all remaining issues we have with regarding to IL differences
caused by collection changes.

First one is fixed, 2nd one is not yet tracked down completely
(feel free to continue - it takes a lot of time and I have other
stuff to do right now)

[Bug ipa/61800] [5 Regression] ICE: Segmentation fault during Firefox build

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Aug 18 13:26:06 2014
New Revision: 214099

URL: https://gcc.gnu.org/viewcvs?rev=214099&root=gcc&view=rev
Log:
PR ipa/61800

gcc/
* cgraph.h (cgraph_node::create_indirect_edge): Add
compute_indirect_info param.
* cgraph.c (cgraph_node::create_indirect_edge): Compute
indirect_info only when it is required.
* cgraphclones.c (cgraph_clone_edge): Do not recompute
indirect_info fore cloned indirect edge.

gcc/testsuite/
* g++.dg/ipa/pr61800.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr61800.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[venkataramanan.kumar at amd dot com]

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

--- Comment #53 from Venkataramanan  ---
Hi Richard, 

>> Well, it would be a workaround only.  The real fix is to track down and fix 
>> all remaining issues we have with regarding to IL differences caused by 
>> collection changes.

In your earlier comment you mentioned that  

> OTOH fixing that may not be suitable
> for the release branches, neither is passing fixed values for GC
> parameters.

So for  release branch 4.9 shall we go for this workaround patch ?

> First one is fixed, 2nd one is not yet tracked down completely (feel free to 
> continue - it takes a lot of time and I have other stuff to do right now)

I am new to LTO but would love to work learn and contribute :)

Thanks 
Venkat.


-Original Message-
From: rguenther at suse dot de [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Monday, August 18, 2014 6:41 PM
To: Kumar, Venkataramanan
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

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

--- Comment #52 from rguenther at suse dot de  --- On
Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> 
> --- Comment #51 from Venkataramanan  com> --- (In reply to rguent...@suse.de from comment #35)
> > On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> > > 
> > > --- Comment #34 from Venkataramanan  > > dot com> --- Richard, What I understand is that instead of using 
> > > tune flags for garbage collection, need to try and fix the object code 
> > > differences?
> > 
> > Yes, it points at real bugs.  OTOH fixing that may not be suitable 
> > for the release branches, neither is passing fixed values for GC 
> > parameters.  So I'm not quite sure what a suitable workaround is 
> > (well, make sure !defined ENABLE_GC_CHECKING && !defined 
> > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for 
> > bootstrap-lto, that is, init_ggc_heuristics () is executed in the 
> > same way)
> 
> Hi richard,
> 
> In Stage1 we add --enable-checking=yes,types and it sets  
> ENABLE_GC_CHECKING as true
> 
> In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So 
> the check "#if !defined ENABLE_GC_CHECKING && !defined 
> ENABLE_GC_ALWAYS_COLLECT"
> will be true for stage2 only. 
> 
> ENABLE_GC_ALWAYS_COLLECT is false in both stages.
> 
> Do we need to make sure stage 1 and stage 2 executes the function 
> init_ggc_heuristics and will it set the parameters to same value?

Well, it would be a workaround only.  The real fix is to track down and fix all
remaining issues we have with regarding to IL differences caused by collection
changes.

First one is fixed, 2nd one is not yet tracked down completely (feel free to
continue - it takes a lot of time and I have other stuff to do right now)

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[rguenther at suse dot de]

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

--- Comment #54 from rguenther at suse dot de  ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> 
> --- Comment #53 from Venkataramanan  ---
> Hi Richard, 
> 
> >> Well, it would be a workaround only.  The real fix is to track down and 
> >> fix all remaining issues we have with regarding to IL differences caused 
> >> by collection changes.
> 
> In your earlier comment you mentioned that  
> 
> > OTOH fixing that may not be suitable
> > for the release branches, neither is passing fixed values for GC
> > parameters.
> 
> So for  release branch 4.9 shall we go for this workaround patch ?

I don't see why we need to fix this for the 4.9 or 4.8 branch.  It
never worked there and another existing workaround is to configure
with --enable-stage1-checking=release.

[Bug c++/62170] New: wrong quoting (and colors) for typedef diagnostics

[manu at gcc dot gnu.org]

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

Bug ID: 62170
   Summary: wrong quoting (and colors) for typedef diagnostics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

typedef long Py_ssize_t;

int foo(Py_ssize_t *);

int bar() {
  typedef int Py_ssize_t;
  Py_ssize_t pos;
  return foo(&pos);
}

cc1plus:

aka.cc:8:18: error: cannot convert ‘Py_ssize_t* {aka int*}’ to ‘Py_ssize_t*
{aka long int*}’ for argument ‘1’ to ‘int foo(Py_ssize_t*)’
   return foo(&pos);
  ^

clang++:

aka.cc:8:10: error: no matching function for call to 'foo'
  return foo(&pos);
 ^~~
aka.cc:3:5: note: candidate function not viable: no known conversion from
'Py_ssize_t *' (aka 'int *') to 'Py_ssize_t *' (aka 'long *') for 1st argument
int foo(Py_ssize_t *);
^

[Bug c++/62170] wrong quoting (and colors) for typedef diagnostics

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
It is not clear how to fix this. At the point the "aka" part is emitted, we
don't know whether we are within quotes. 

Perhaps the pretty-printer should allow the language-specific formatting
function to modify the formatting string somehow:

"%qT" is passed to the pretty-printer, which starts printing "`", then calls
the c++ formatter which handles the %T part but also modifies the original
format to "%qT (aka %qX)". Then, the formatter will get called again for %qX
but with the original type.

How to pass the info to the pretty-printer doesn't seem trivial. Maybe
modifying the obstacks would be enough...

Ideas welcome!

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[venkataramanan.kumar at amd dot com]

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

--- Comment #55 from Venkataramanan  ---
Hi Richard,

>> I don't see why we need to fix this for the 4.9 or 4.8 branch.  It never 
>> worked there and another existing workaround is to configure with 
>> --enable-stage1-checking=release. 
Linaro releases are based  GCC 4.9 and 4.8 branches and so we wanted to release
GCC 4.9 compiler that would bootstrap LTO.


So once we fix things in gcc 5.0, we will be back porting to 4.9 /4.8 branches
?
Or we need to tell users that GCC 4.9 or GCC 4.8 will always need workarounds

Regards,
Venkat.


-Original Message-
From: rguenther at suse dot de [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Monday, August 18, 2014 7:11 PM
To: Kumar, Venkataramanan
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

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

--- Comment #54 from rguenther at suse dot de  --- On
Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> 
> --- Comment #53 from Venkataramanan  com> --- Hi Richard,
> 
> >> Well, it would be a workaround only.  The real fix is to track down and 
> >> fix all remaining issues we have with regarding to IL differences caused 
> >> by collection changes.
> 
> In your earlier comment you mentioned that
> 
> > OTOH fixing that may not be suitable for the release branches, 
> > neither is passing fixed values for GC parameters.
> 
> So for  release branch 4.9 shall we go for this workaround patch ?

I don't see why we need to fix this for the 4.9 or 4.8 branch.  It never worked
there and another existing workaround is to configure with
--enable-stage1-checking=release.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 33348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33348&action=edit
patch for 4.6 branch

- patches from comment 1 and 3
- c-common.c patch re-applied to lto/lto-lang.c to fix lto buildbreaker
- testcases added.

Patch applies to 4.6 branch, non-bootstrap build succeeds and added test-cases
pass.

In 4.7 branch, this snippet:
...
@@ -5612,6 +5611,12 @@ intra_create_variable_infos (void)
  rhsc.offset = 0;
  process_constraint (new_constraint (lhsc, rhsc));
  vi->is_restrict_var = 1;
+ do
+   {
+ make_constraint_from (vi, nonlocal_id);
+ vi = vi->next;
+   }
+ while (vi);
  continue;
}
... 

conflicts with: 
...
  rhsc.offset = 0;
  process_constraint (new_constraint (lhsc, rhsc));
  for (; vi; vi = vi->next)
if (vi->may_have_pointers)
  {
if (vi->only_restrict_pointers)
  make_constraint_from_global_restrict (vi, "GLOBAL_RESTRICT");
else
  make_copy_constraint (vi, nonlocal_id);
  }
  continue;
}
...

[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Honza?

[Bug c/62158] FAIL: scan-tree-dump-not optimized "gimple_assign"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Well, that's expected - the testcase explicitely requires -Ofast, it's an
optimization testcase.

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-18
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hm, yeah.  Well, not sure if this is worth having a special case for in
tree-ssa-sccvn.c or in gimple_fold_stmt_to_constant_1.  I'd probably
try a simple pattern matching in gimple_fold_stmt_to_constant_1.

What kind of std::string code is this?  That is, can we expect
memcmp and memcpy to be adjacent (without intermediate memory operations?)

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou  ---
Created attachment 33349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33349&action=edit
Reduced testcase

To be compiled at -O1.

[Bug c/62158] FAIL: scan-tree-dump-not optimized "gimple_assign"

[sabrinadfs at gmail dot com]

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

--- Comment #2 from Sabrina Souto  ---
Created attachment 33350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33350&action=edit
Execution log

[Bug c/62158] FAIL: scan-tree-dump-not optimized "gimple_assign"

[sabrinadfs at gmail dot com]

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

--- Comment #3 from Sabrina Souto  ---
You are right, but indeed this test ran with the option -Ofast, I did not
explicitly use this option in the command line because this is already done by
DejaGnu, as you can see in the test code below.


Test case gcc.dg/pr55027.c

/* { dg-do compile } */
/* { dg-options "-Ofast -fdump-tree-optimized-raw" } */

typedef double v2df __attribute__ ((__vector_size__ (2 * sizeof (double;

void f (v2df *x)
{
  *x = 0 + 1 * *x;
}

/* { dg-final { scan-tree-dump-not "gimple_assign" "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */


Moreover, in the execution log there is the complete configuration that GCC
really uses:

Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr55027.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -Ofast
-fdump-tree-optimized-raw -S  -O0  -o pr55027.s(timeout = 300)
spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/pr55027.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast
-fdump-tree-optimized-raw -S -O0 -o pr55027.s

I attached the complete log if you need.

Thanks,
Sabrina Souto.



(In reply to Richard Biener from comment #1)
> Well, that's expected - the testcase explicitely requires -Ofast, it's an
> optimization testcase.

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> What kind of std::string code is this?  That is, can we expect
> memcmp and memcpy to be adjacent (without intermediate memory operations?)

I don't remember the exact code, but it was similar to:
std::string("foo")=="bar"
which, with _GLIBCXX_EXTERN_TEMPLATE=0 (or LTO) gives:

  _29 = _50 + 24;
  __builtin_memcpy (_29, "foo", 3);
  if (_50 != &_S_empty_rep_storage)
goto ;

  :
  MEM[(struct _Rep *)_50].D.20711._M_length = 3;
  MEM[(char_type &)_50 + 27] = 0;
  __r_86 = __builtin_memcmp (_29, "bar", 3);

So it is setting the null character right after the string (could have used
memcpy of size 4?) and the length right before, which requires tight alias
checking to be sure that memcmp is not affected :-(

Probably a bit too specific to be worth it.

[Bug tree-optimization/62171] New: restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[vries at gcc dot gnu.org]

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

Bug ID: 62171
   Summary: restrict pointer to struct with restrict pointers parm
doesn't prevent aliases
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

Created attachment 33351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33351&action=edit
test-case, derived from testcase for PR46032

The test-case (attached) contains a function parameter with type restrict
pointer to struct with restrict pointers:
...
struct omp_data_i
{
  double *__restrict__ results;
  double *__restrict__ pData;
  double *__restrict__ coeff;
};

static double __attribute__((noinline, noclone))
f (struct omp_data_i *__restrict__ p, int argc)
{

  int idx;

  for (idx = 0; idx < nEvents; idx++)
((p->results))[idx] = (*(p->coeff)) * ((p->pData))[idx];

  return ((p->results))[argc];
}
...

Despite using restrict, we don't manage to get rid of the aliases:
...
$ gcc test.c -O2 -ftree-vectorize -fdump-tree-vect-all
$ egrep 'note: vectorized|version' test.c.*.vect
test.c:15:3: note: versioning for alias required: can't determine dependence
between *pretmp_35 and *_8
test.c:15:3: note: versioning for alias required: can't determine dependence
between *_12 and *_8
cost model: Adding cost of checks for loop versioning aliasing.
test.c:15:3: note: created 2 versioning for alias checks.
test.c:15:3: note: loop versioned for vectorization because of possible
aliasing
test.c:11:1: note: vectorized 1 loops in function.
...

Rewriting the example such that it has seperate function parameters with type
restrict pointer fixes the problem. 

Rewriting the example such that it has seperate function parameters with type
restrict pointer to restrict pointer fixes the problem. 

Rewriting the example such that it has as parameter a single struct with
restrict pointers fixes the problem.

[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 18 14:51:04 2014
New Revision: 214105

URL: https://gcc.gnu.org/viewcvs?rev=214105&root=gcc&view=rev
Log:
2014-08-18  Richard Biener  

PR tree-optimization/62090
* builtins.c (fold_builtin_snprintf): Move to gimple-fold.c.
(fold_builtin_3): Do not fold snprintf.
(fold_builtin_4): Likewise.
* gimple-fold.c (gimple_fold_builtin_snprintf): New function
moved from builtins.c.
(gimple_fold_builtin_with_strlen): Fold snprintf and sprintf.
(gimple_fold_builtin): Do not fold sprintf here.

* gcc.dg/pr62090-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr62090-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Fixed again.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[sven.c.dack at virginmedia dot com]

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

--- Comment #56 from Sven C. Dack  ---
> I don't see why we need to fix this for the 4.9 or 4.8 branch.  It never
> worked there and another existing workaround is to configure with
> --enable-stage1-checking=release.

One reason is that it is not working in any of the recent stable compilers. 5.0
is not stable yet and said to be release not before next year.

At least one of the stable compilers should be able to bootstrap itself with
LTO, because it is one of the primary features in its latest development. It
just looks bad when it fails and will discourage people from adopting it. You
do want GCC users to make use of all its features. Why else put them in there
in the first place, or just make them wait, when it is easy to fix?

[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Not much difference using __gnu_cxx::__vstring (no reference counting, small
string optimization):

__builtin_memcpy (&MEM[(struct __sso_string_base
*)&D.28720].D.23707._M_local_data, "foo", 3);
MEM[(size_type *)&D.28720 + 8B] = 3;
MEM[(char_type &)&D.28720 + 19] = 0;
__r_46 = __builtin_memcmp (&MEM[(struct __sso_string_base
*)&D.28720].D.23707._M_local_data, "bar", 3);

[Bug c++/62172] New: Operand to a throw expression is moved when it should be copied

[tsimpson at ubuntu dot com]

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

Bug ID: 62172
   Summary: Operand to a throw expression is moved when it should
be copied
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tsimpson at ubuntu dot com

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

With a throw expression whos operand is an lvalue, which is declared outside
the try block, will move from the expression instead of copy.

The relavent part of the standard is 15.1 [except.throw].
The C++11 standard *could* be interpreded to allow the move when reading the
last sentence of 15.1/3
"...Except for these restrictions and the restrictions on type matching
mentioned in 15.3, the operand of throw is treated exactly as a function
argument in a call (5.2.2) or the operand of a return statement."
Specifically, if the operand of the throw expression was treated exactly the
same as an operand to a return statement then it would become an xvalue and the
move would be allowed.

The wording of that clause changed in C++14, so this is no longer the case. And
I don't think it was the intent to allow that in C++11 either.

Example output with g++ http://rextester.com/USFXJ5678
Exmaple output with clang++ http://rextester.com/EARQ18237

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Aug 18 15:49:16 2014
New Revision: 214108

URL: https://gcc.gnu.org/viewcvs?rev=214108&root=gcc&view=rev
Log:
Set install_gold_as_default to no for --enable-gold=no

PR other/62168
* configure.ac: Set install_gold_as_default to no for
 --enable-gold=no.
 * configure: Regenerated.

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

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

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

[Bug c++/62172] Operand to a throw expression is moved when it should be copied

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-18
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Reduced:

#include 

int move_count = 0;
struct X {
  X() = default;
  X(const X&) = default;
  X(X&&) {++move_count;}
};

int main()
{
  X x;
  try {throw x;}
  catch (X&) {}
  assert(move_count==0);
}

Asserts on gcc, doesn't assert on clang.

[Bug target/62173] New: [AArch64] Performance regression due to r213488

[spop at gcc dot gnu.org]

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

Bug ID: 62173
   Summary: [AArch64] Performance regression due to r213488
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org

void bar(int i) {
  char A[10];
  int d = 0;
  while (i > 0)
A[d++] = i--;

  while (d > 0)
foo(A[d--]);
}

Compile this function at -O3 with the last good revision r213487 and with the
first bad revision r213488 "[AArch64] Improve TARGET_LEGITIMIZE_ADDRESS_P
hook", and diffing:

--- good.s2014-08-18 10:56:42.542867000 -0500
+++ bad.s2014-08-18 10:56:42.50409 -0500
@@ -8,34 +8,33 @@
 stpx29, x30, [sp, -48]!
 cmpw0, wzr
 addx29, sp, 0
-stpx19, x20, [sp, 16]
+strx19, [sp, 16]
 ble.L1
 strbw0, [x29, 32]
 subsw19, w0, #1
-addx20, x29, 32
 beq.L4
 strbw19, [x29, 33]
 subsw1, w0, #2
 beq.L4
-strbw1, [x20, 2]
+strbw1, [x29, 34]
 subsw1, w0, #3
 beq.L4
-strbw1, [x20, 3]
+strbw1, [x29, 35]
 subsw1, w0, #4
 beq.L4
-strbw1, [x20, 4]
+strbw1, [x29, 36]
 subsw1, w0, #5
 beq.L4
-strbw1, [x20, 5]
+strbw1, [x29, 37]
 subsw1, w0, #6
 beq.L4
-strbw1, [x20, 6]
+strbw1, [x29, 38]
 subsw1, w0, #7
 beq.L4
-strbw1, [x20, 7]
+strbw1, [x29, 39]
 subsw1, w0, #8
 beq.L4
-strbw1, [x20, 8]
+strbw1, [x29, 40]
 subsw1, w0, #9
 beq.L4
 strbw1, [x29, 41]
@@ -43,14 +42,16 @@
 .L35:
 subw19, w19, #1
 .L4:
-ldrbw0, [x20, w0, sxtw]
+addx1, x29, 48
+addx0, x1, x0, sxtw
+ldrbw0, [x0, -16]
 blfoo
 movw0, w19
 cbnzw19, .L35
 .L1:
-ldpx19, x20, [sp, 16]
+ldrx19, [sp, 16]
 ldpx29, x30, [sp], 48
 ret
 .sizebar, .-bar


The problem is that gcc now generates an addressing mode that requires two more
add instructions in the second loop:

-ldrbw0, [x20, w0, sxtw]
+addx1, x29, 48
+addx0, x1, x0, sxtw
+ldrbw0, [x0, -16]

[Bug target/62173] [AArch64] Performance regression due to r213488

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-18
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed,  Here is a much shorter testcase and not related to loops either:
void bar(int i)
{
  char A[10];
  g(A);
  f(A[i]);
}
--- CUT ---
Before:
bar:
stpx29, x30, [sp, -64]!
addx29, sp, 0
stpx19, x20, [sp, 16]
addx19, x29, 48
movw20, w0
movx0, x19
blg
ldrbw0, [x19, w20, sxtw]
blf
ldpx19, x20, [sp, 16]
ldpx29, x30, [sp], 64
ret

After:
bar:
stpx29, x30, [sp, -48]!
addx29, sp, 0
strx19, [sp, 16]
movw19, w0
addx0, x29, 32
blg
addx0, x29, 48
addx19, x0, x19, sxtw
ldrbw0, [x19, -16]
blf
ldrx19, [sp, 16]
ldpx29, x30, [sp], 48
ret

[Bug fortran/62174] New: Component declarations overwrite types of Cray Pointee variables

[fritzoreese at gmail dot com]

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

Bug ID: 62174
   Summary: Component declarations overwrite types of Cray Pointee
variables
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fritzoreese at gmail dot com

Created attachment 33353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33353&action=edit
Proposed patch for the described problem

The typespecs for Cray pointees are overwritten by the typespecs of components
with the same name which are declared later.

This problem was introduced with Cray pointer support in 4.1.0 and is present
as far as I can tell up through the current release.

Here is a proposed patch from 4.8.3. The added test case demonstrates the
problem:

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4048ac9..7b3c59a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1904,8 +1904,9 @@ variable_decl (int elem)
 }

   /*  If this symbol has already shown up in a Cray Pointer declaration,
+  and this is not a component declaration,
   then we want to set the type & bail out.  */
-  if (gfc_option.flag_cray_pointer)
+  if (gfc_option.flag_cray_pointer && gfc_current_state () != COMP_DERIVED)
 {
   gfc_find_symbol (name, gfc_current_ns, 1, &sym);
   if (sym != NULL && sym->attr.cray_pointee)
diff --git a/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
b/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
new file mode 100644
index 000..fcc0132
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/cray_pointers_10.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-fcray-pointer" }
+!
+! Since the introduction of Cray pointers in 4.1.0 as late as 4.8.3,
+! component declarations within derived types would overwrite the typespec of 
+! variables with the same name who were Cray pointees.
+implicit none
+
+type t1
+  integer i
+end type t1
+type(t1) x
+
+pointer (x_ptr, x)
+
+type t2
+  real x ! should not overwrite x's type
+end type t2
+
+x%i = 0 ! should see no error here
+
+end
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 53d2691..8d8f9d5 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,8 @@
+2014-08-18  Fritz Reese  
+
+* decl.c (variable_decl): Don't overwrite typesepc of Cray pointees
+when matching a component declaration.
+
 2014-08-17  Tobias Burnus  

 * resolve.c (gfc_resolve_finalizers): Ensure that parents are

[Bug c++/62175] New: Internal compiler error in gimplify_modify_expr gimplify.c:4616

[mbetten at sandia dot gov]

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

Bug ID: 62175
   Summary: Internal compiler error in gimplify_modify_expr
gimplify.c:4616
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mbetten at sandia dot gov

Compile the attached file with openmp and optimized you get a compiler internal
error.  File is preprocessed and all ready to go, no includes needed.

[mbetten@s939194 opt_build_panzer]$ g++ -O3 /tmp/file.cpp  -c   -fopenmp
-O3 -g  -ansi  -ftrapv  -v -save-temps
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.1/configure --prefix=/home/mbetten/gcc
--with-gmp=/home/mbetten/gcc --with-mpfr=/home/mbetten/gcc
--with-mpc=/home/mbetten/gcc
Thread model: posix
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-c' '-fopenmp' '-O3' '-g' '-ansi' '-ftrapv' '-v'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /home/mbetten/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1plus -E -quiet
-v -D_GNU_SOURCE -D_REENTRANT /tmp/file.cpp -mtune=generic -march=x86-64 -ansi
-fopenmp -ftrapv -g -fworking-directory -O3 -O3 -fpch-preprocess -o file.ii
ignoring nonexistent directory
"/home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/opt/intel/composer_xe_2013_sp1.1.106/mkl/include"
ignoring duplicate directory
"/opt/intel/composer_xe_2013_sp1.1.106/tbb/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/intel/composer_xe_2013_sp1.1.106/mkl/include
 /opt/intel/composer_xe_2013_sp1.1.106/tbb/include

/home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1

/home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/x86_64-unknown-linux-gnu

/home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/backward
 /home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include
 /usr/local/include
 /home/mbetten/gcc/include
 /home/mbetten/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-c' '-fopenmp' '-O3' '-g' '-ansi' '-ftrapv' '-v'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /home/mbetten/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1plus
-fpreprocessed file.ii -quiet -dumpbase file.cpp -mtune=generic -march=x86-64
-auxbase file -g -O3 -O3 -ansi -version -fopenmp -ftrapv -o file.s
GNU C++ (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5bd09c8d46de55a1c64a013324c44d10
In file included from
/home/mbetten/Trilinos/Trilinos/packages/teuchos/core/src/Teuchos_Array.hpp:52:0,
 from
/home/mbetten/Trilinos/Trilinos/packages/rtop/src/interfaces/RTOpPack_Types.hpp:49,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_vector/fundamental/Thyra_OperatorVectorTypes.hpp:46,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_solve/fundamental/Thyra_SolveSupportTypes.hpp:45,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_solve/fundamental/Thyra_OperatorSolveTypes.hpp:46,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_solve/fundamental/Thyra_LinearOpWithSolveBase_decl.hpp:45,
 from
/home/mbetten/Trilinos/opt_build_panzer/packages/thyra/core/src/Thyra_LinearOpWithSolveBase.hpp:1,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_solve/fundamental/Thyra_LinearOpWithSolveFactoryBase_decl.hpp:45,
 from
/home/mbetten/Trilinos/opt_build_panzer/packages/thyra/core/src/Thyra_LinearOpWithSolveFactoryBase.hpp:1,
 from
/home/mbetten/Trilinos/Trilinos/packages/thyra/core/src/interfaces/operator_solve/extended/Thyra_LinearSolverBuilderBase.hpp:46,
 from
/home/mbetten/Trilinos/Trilinos/packages/stratimikos/src/Stratimikos_DefaultLinearSolverBuilder.hpp:46,
 from
/home/mbetten/Trilinos/Trilinos/packages/muelu/adapters/stratimikos-tpetra/Stratimikos_MueluTpetraHelpers.hpp:49,
 from
/home/mbetten/Trilinos/Trilinos/packages/muelu/adapters/stratimikos-tpetra/Stratimikos_MueluTpetraHelpers.cpp:47

[Bug target/62011] False Data Dependency in popcnt instruction

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Aug 18 18:00:52 2014
New Revision: 214112

URL: https://gcc.gnu.org/viewcvs?rev=214112&root=gcc&view=rev
Log:
PR target/62011
* config/i386/x86-tune.def (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI):
New tune flag.
* config/i386/i386.h (TARGET_AVOID_FALSE_DEP_FOR_BMI): New define.
* config/i386/i386.md (unspec) : New unspec.
(ffs2): Do not expand with tzcnt for
TARGET_AVOID_FALSE_DEP_FOR_BMI.
(ffssi2_no_cmove): Ditto.
(*tzcnt_1): Disable for TARGET_AVOID_FALSE_DEP_FOR_BMI.
(ctz2): New expander.
(*ctz2_falsedep_1): New insn_and_split pattern.
(*ctz2_falsedep): New insn.
(*ctz2): Rename from ctz2.
(clz2_lzcnt): New expander.
(*clz2_lzcnt_falsedep_1): New insn_and_split pattern.
(*clz2_lzcnt_falsedep): New insn.
(*clz2): Rename from ctz2.
(popcount2): New expander.
(*popcount2_falsedep_1): New insn_and_split pattern.
(*popcount2_falsedep): New insn.
(*popcount2): Rename from ctz2.
(*popcount2_cmp): Remove.
(*popcountsi2_cmp_zext): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/x86-tune.def

[Bug c++/62175] Internal compiler error in gimplify_modify_expr gimplify.c:4616

[mbetten at sandia dot gov]

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

--- Comment #1 from Matt  ---
Created attachment 33354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33354&action=edit
Preprocessed file that causes the internal error

[Bug target/62173] [AArch64] Performance regression due to r213488

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
I have seen a 15% perf regression on a version of bzip2 compress compiled at
-O3.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[a...@cloudius-systems.com]

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

Avi Kivity  changed:

   What|Removed |Added

 CC||a...@cloudius-systems.com

--- Comment #1 from Avi Kivity  ---
This is even more important in conjunction with _Atomic.

Note the code as posted cannot be optimized to use bts, since the BitOffset
operand is signed.

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[manfred99 at gmx dot ch]

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

--- Comment #4 from Manfred Schwarb  ---
This does not catch all cases. There is also
 yes)
   if test x${default_ld} != x; then
 install_gold_as_default=yes
   fi
   ;;

which needs an "else" case, as far as I can see.
"default_ld" is empty for the normal cases, unless you set --enable-ld=no.

Or you fix the if statement some few lines below:

--- configure.ac.orig   2014-07-31 02:30:13.804162521 +0200
+++ configure.ac2014-08-18 21:47:10.722061603 +0200
@@ -2117,7 +2117,7 @@
 AS_VAR_SET_IF(gcc_cv_ld,, [
 if test -x "$DEFAULT_LINKER"; then
gcc_cv_ld="$DEFAULT_LINKER"
-elif test $install_gold_as_default = yes \
+elif test x$install_gold_as_default = xyes \
  && test -f $gcc_cv_ld_gold_srcdir/configure.ac \
  && test -f ../gold/Makefile \
  && test x$build = x$host; then

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #5 from H.J. Lu  ---
(In reply to Manfred Schwarb from comment #4)
> This does not catch all cases. There is also
>  yes)
>if test x${default_ld} != x; then
>  install_gold_as_default=yes
>fi
>;;
> 
> which needs an "else" case, as far as I can see.
> "default_ld" is empty for the normal cases, unless you set --enable-ld=no.

Is there a way to reproduce it?

[Bug fortran/62176] New: [OOP] Inconsistent resolution of GENERIC interface

[fmartinez at gmv dot com]

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

Bug ID: 62176
   Summary: [OOP] Inconsistent resolution of GENERIC interface
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmartinez at gmv dot com

Created attachment 33355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33355&action=edit
Source file generating the compilation errors

Dear all.

The attached module does not compile producing the following message associated
to the generic interface lgt (similar for all other three comparison operators)

...
m_string.f90:141.23:

  generic :: lgt => string_greater_string, &
   1
Error: 'string_greater_char' and 'char_greater_string' for GENERIC 'lgt' at (1)
are ambiguous
...

The inconsistency comes from the us of the char_greater_string and
string_greater_char procedures, which are the implementation of the overloaded
function lgt and also of the operator(>). The compiler complains about the
ambiguity of interfaces for lgt but not for the operator(>).

This overloading is meant to cover the cases c > s and s > c (begin c a
character string and s a t_string type object). Also the cases lgt(c,s) and
lgt(s,c).

The versions that have c on left hand side of the operation have the
pass(right) attibute properly (i belive) assigned to allow that the procedure
is bound to the object according to the second parameter of the function call.

Thanks
Fran

[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-18
 Ever confirmed|0   |1

--- Comment #2 from Oleg Endo  ---
(In reply to dhowe...@redhat.com from comment #1)
> Is this something I can add to the compiler build without a patch?

No, not really.  At least not that I know.  It's hard-coded in the compiler and
should be fixed anyways.

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[manfred99 at gmx dot ch]

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

--- Comment #6 from Manfred Schwarb  ---
I did the following (error present also with your recent patch):

# ../gfortran-source/gcc-5-20140817/configure --enable-languages=c,c++,fortran
--disable-nls --enable-checking=release --disable-libmudflap
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --disable-isl-version-check
--prefix=/usr/local/gfortran-test

# make -j16 bootstrap2-lean 1>/dev/null

[Bug target/62040] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555

[carrot at google dot com]

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

Carrot  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #5 from Carrot  ---
Created attachment 33356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33356&action=edit
simplified test case

Attached is a simplified test case that can still be reproduced on trunk and
4.9 branch

[Bug target/62040] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555

[carrot at google dot com]

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

--- Comment #6 from Carrot  ---
Even more simplified test case for gcc4.9, but it doesn't trigger the error for
trunk.


typedef __builtin_aarch64_simd_udi uint64x1
  __attribute__ ((__vector_size__ (8)));
typedef __builtin_aarch64_simd_udi uint64x2
  __attribute__ ((__vector_size__ (16)));

__extension__ static __inline uint64x2 __attribute__ ((__always_inline__))
vcombine_u64 (uint64x1 __a, uint64x1 __b)
{
  return (uint64x2) __builtin_aarch64_combinedi (__a[0], __b[0]);
}

extern bar(uint64x2 out0);

void foo(short* out) {
  uint64x1 tmp0;
  uint64x2 row = vcombine_u64(tmp0, tmp0);

  bar(row);
}

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #24 from Eric Botcazou  ---
I might have a plausible scenario, but I'd need more info:

  1. the options used to link the runtime linker

  2. the value of registers r25 and r23 right after:

   0x2008a8f0 <+304>:   [MMI]   ld8 r25=[r25]
   0x2008a8f1 <+305>:   ld8 r23=[r23]
   0x2008a8f2 <+306>:   nop.i 0x0;;

for the invocation of _dl_start that leads to the segfault.

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
Created attachment 33357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33357&action=edit
Try this one

[Bug other/62168] error in configure: line 21572: test: =: unary operator expected

[manfred99 at gmx dot ch]

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

--- Comment #8 from Manfred Schwarb  ---
Works for me, the error message is gone.

I inserted a pair of set -x/set +x around the gold configure block,
and the following is the output, everything looks OK:

original:
+ test set = set
+ :
+ enableval=yes
+ case "${enableval}" in
+ test x '!=' x
+ gcc_cv_gld_major_version=
+ gcc_cv_gld_minor_version=
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gld_srcdir=../../gfortran-source/gcc-5-20140817/ld
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gold_srcdir=../../gfortran-source/gcc-5-20140817/gold
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_bfd_srcdir=../../gfortran-source/gcc-5-20140817/bfd
+ test '' = set
+ test -x ''
+ test = yes
/scratch/gfortran-source/gcc-5-20140817/gcc/configure: line 21572: test: =:
unary operator expected
+ test -f ../../gfortran-source/gcc-5-20140817/ld/configure.in
+ test -x collect-ld
+ set dummy
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ test -x
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+
gcc_cv_ld=/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ set +x



with your new patch:
+ install_gold_as_default=no
+ test set = set
+ :
+ enableval=yes
+ case "${enableval}" in
+ test x '!=' x
+ gcc_cv_gld_major_version=
+ gcc_cv_gld_minor_version=
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gld_srcdir=../../gfortran-source/gcc-5-20140817/ld
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gold_srcdir=../../gfortran-source/gcc-5-20140817/gold
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_bfd_srcdir=../../gfortran-source/gcc-5-20140817/bfd
+ test '' = set
+ test -x ''
+ test no = yes
+ test -f ../../gfortran-source/gcc-5-20140817/ld/configure.in
+ test -x collect-ld
+ set dummy
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ test -x
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+
gcc_cv_ld=/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ set +x

[Bug c/62177] New: mips-rtems ICE at lra_assigns.c:1335 compiling strtod.c in newlib

[joel at gcc dot gnu.org]

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

Bug ID: 62177
   Summary: mips-rtems ICE at lra_assigns.c:1335 compiling
strtod.c in newlib
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Host: x86_64-unknown-linux-gnu
Target: mips-rtems4.11

Created attachment 33358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33358&action=edit
Preprocessed newlib strtod.c source to reproduce issue

Fails at -O2. Builds at -O1.

Works: /users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/ -fno-builtin -mips3  -g
-O2 -c mips_bug.c 

Adding -EL results in a failure.


Full command:

/users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-mips-rtems4.11-gcc/mips-rtems4.11/mips3/el/newlib/
-isystem
/users/joel/test-gcc/b-mips-rtems4.11-gcc/mips-rtems4.11/mips3/el/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/mips-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/mips-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/mips-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/mips-rtems4.11/sys-include  -mips3 -EL
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.1.0\" -DPACKAGE_STRING=\"newlib\ 2.1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../../gcc/newlib/libc/stdlib -D_COMPILING_NEWLIB
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -fno-builtin  -g
-O2  -mips3 -EL -c -o lib_a-strtod.o `test -f 'strtod.c' || echo
'../../../../../../../gcc/newlib/libc/stdlib/'`strtod.c
../../../../../../../gcc/newlib/libc/stdlib/strtod.c: In function '_strtod_r':
../../../../../../../gcc/newlib/libc/stdlib/strtod.c:1252:1: internal compiler
error: in assign_by_spills, at lra-assigns.c:1335
 }
 ^
0x7ac8f3 assign_by_spills
../../gcc/gcc/lra-assigns.c:1335
0x7ad296 lra_assign()
../../gcc/gcc/lra-assigns.c:1500
0x7a9022 lra(_IO_FILE*)
../../gcc/gcc/lra.c:2230
0x768946 do_reload
../../gcc/gcc/ira.c:5306
0x768946 execute
../../gcc/gcc/ira.c:5465

[Bug target/62178] New: [AArch64] Performance regression on matrix matrix multiply due to r211211

[spop at gcc dot gnu.org]

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

Bug ID: 62178
   Summary: [AArch64] Performance regression on matrix matrix
multiply due to r211211
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org

int a[30 +1][30 +1], b[30 +1][30 +1], r[30 +1][30 +1];

void Intmm (int run) {
  int i, j, k;

  for ( i = 1; i <= 30; i++ )
for ( j = 1; j <= 30; j++ ) {
  r[i][j] = 0;
  for(k = 1; k <= 30; k++ )
r[i][j] += a[i][k]*b[k][j];
}
}

compile this at -O3 with the last good compiler r211210 and with the first bad
compiler at r211211, then diff the assembly:

--- good.s2014-08-18 17:44:26.179506000 -0500
+++ bad.s2014-08-18 17:44:26.213807000 -0500
@@ -6,45 +6,44 @@
 .typeIntmm, %function
 Intmm:
 moviv3.2s, 0
-adrpx6, a+128
-adrpx8, r+128
-adrpx10, r+3848
-adrpx9, b+128
-adrpx7, b+248
-addx6, x6, :lo12:a+128
-addx8, x8, :lo12:r+128
-addx10, x10, :lo12:r+3848
-addx9, x9, :lo12:b+128
-addx7, x7, :lo12:b+248
+adrpx6, r+128
+adrpx4, a+124
+adrpx8, r+3848
+adrpx7, b
+addx6, x6, :lo12:r+128
+addx4, x4, :lo12:a+124
+addx8, x8, :lo12:r+3848
+addx7, x7, :lo12:b
 .L2:
-movx5, x8
-movx4, x8
-movx3, x9
+movx5, 0
 .L4:
-strd3, [x4]
-addx2, x3, 3720
-moviv0.2s, 0
-movx1, x6
-movx0, x3
+strd3, [x6, x5]
+addx3, x5, 128
+moviv1.2s, 0
+addx3, x3, x7
+movx0, 0
 .L3:
-ldrd1, [x0]
-addx0, x0, 124
-ld1r{v2.2s}, [x1], 4
-cmpx0, x2
-mlav0.2s, v2.2s, v1.2s
+addx1, x4, x0
+lslx2, x0, 5
+subx2, x2, x0
+addx0, x0, 4
+cmpx0, 120
+ldrw1, [x1, 4]
+ldrd2, [x3, x2]
+dupv0.2s, w1
+mlav1.2s, v0.2s, v2.2s
 bne.L3
-strd0, [x5], 8
-addx3, x3, 8
-cmpx3, x7
-addx4, x4, 8
+strd1, [x6, x5]
+addx5, x5, 8
+cmpx5, 120
 bne.L4
-addx8, x8, 124
 addx6, x6, 124
-cmpx8, x10
+addx4, x4, 124
+cmpx6, x8
 bne.L2
 ret
 .sizeIntmm, .-Intmm
 .commr,3844,8
 .commb,3844,8
 .comma,3844,8

Remark that the innermost loop .L3 contains 5 more instructions with the bad
compiler, due to more scalar computations for the addressing modes:

 .L3:
-ldrd1, [x0]
-addx0, x0, 124
-ld1r{v2.2s}, [x1], 4
-cmpx0, x2
-mlav0.2s, v2.2s, v1.2s
+addx1, x4, x0
+lslx2, x0, 5
+subx2, x2, x0
+addx0, x0, 4
+cmpx0, 120
+ldrw1, [x1, 4]
+ldrd2, [x3, x2]
+dupv0.2s, w1
+mlav1.2s, v0.2s, v2.2s
 bne.L3

[Bug target/62178] [AArch64] Performance regression on matrix matrix multiply due to r211211

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Even -fno-ivopts produces better code:
.L3:
addx0, x5, x1, sxtw
addw1, w1, 1
ldrd2, [x3], 124
ldrw0, [x4, x0, lsl 2]
dupv0.2s, w0
mlav1.2s, v0.2s, v2.2s
subsw2, w2, #1
bne.L3

Compared with:
.L3:
lslx2, x0, 5
addx1, x0, x4
subx2, x2, x0
addx1, x1, x5
ldrd2, [x3, x2]
addx0, x0, 4
ldrw1, [x1, 4]
dupv0.2s, w1
mlav1.2s, v0.2s, v2.2s
cmpx0, 120
bne.L3

But I think the main reason for the performance regression is:
ldrw1, [x1, 4]
dupv0.2s, w1

If the compiler had used ldr1 instead the performance would be back to normal.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #25 from Mike Frysinger  ---
here's the series of link commands:
gcc -nostdlib -nostartfiles -r -o elf/librtld.os \
  '-Wl,-(' /home/vapier/glibc/build/elf/dl-allobjs.os elf/rtld-libc.a -lgcc \
  '-Wl,-)' -Wl,-Map,elf/librtld.os.map
gcc -nostdlib -nostartfiles -shared -o elf/ld.so \
  -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
  elf/librtld.os -Wl,--version-script=./ld.map \
  -Wl,-soname=ld-linux-ia64.so.2 \
  -Wl,-defsym=_begin=0

in my disassembly it's using r24 & r22, but i'm guessing that doesn't matter
terribly much:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out 
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.
(gdb) b *_dl_start+304
Breakpoint 1 at 0xabb0: file get-dynamic-info.h, line 61.
(gdb) display /i $pc
(gdb) display $r24
(gdb) display $r22
(gdb) r
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out

Breakpoint 1, elf_get_dynamic_info (temp=0x0, l=0x2008000510c8
<_rtld_local+2456>) at get-dynamic-info.h:61
61   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x2008000505d8
2: $r24 = 0x2008000505d8
1: x/i $pc
=> 0x2008abb0 <_dl_start+304>:  [MMI]   ld8 r24=[r24]
(gdb) stepi
58   + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
3: $r22 = 0x2008000505d8
2: $r24 = 0x380050730
1: x/i $pc
=> 0x2008abb1 <_dl_start+305>:  ld8 r22=[r22]
(gdb) stepi
61   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x380050730
2: $r24 = 0x380050730
1: x/i $pc
=> 0x2008abb2 <_dl_start+306>:  nop.i 0x0;;
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x2008b5f1 in elf_get_dynamic_info (temp=0x0, l=0x2008000510c8
<_rtld_local+2456>) at get-dynamic-info.h:61
61   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x3800502b0
2: $r24 = 0x380050b10
1: x/i $pc
=> 0x2008b5f1 <_dl_start+2929>:   (p07) st8 [r14]=r15
(gdb)

[Bug target/62173] [AArch64] Performance regression due to r213488

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
I have seen potential improvement of bzip/gzip on arm 32.  It relates to
addressing mode which affecting loop invariant hoisting in kernel loop of these
two benchmarks.  I once had a patch but didn't follow up that.  I think it's
worthy of methodical investigation, rather than case by case changes.

Thanks,
bin

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #29 from Manuel López-Ibáñez  ---
Author: manu
Date: Tue Aug 19 02:02:09 2014
New Revision: 214129

URL: https://gcc.gnu.org/viewcvs?rev=214129&root=gcc&view=rev
Log:
gcc/c-family/ChangeLog:

2014-08-19  Manuel López-Ibáñez  
Steven Bosscher  

PR c/52952
* c-format.c: Add extra_arg_loc and format_string_loc to struct
format_check_results.
(check_function_format): Use true and add comment for boolean
argument.
(finish_dollar_format_checking): Use explicit location when warning.
(check_format_info): Likewise.
(check_format_arg): Set extra_arg_loc and format_string_loc.
(check_format_info_main): Use explicit location when warning.
(check_format_types): Pass explicit location.
(format_type_warning): Likewise.

gcc/testsuite/ChangeLog:

2014-08-19  Manuel López-Ibáñez  
Steven Bosscher  

PR c/52952
* gcc.dg/redecl-4.c: Add column markers.
* gcc.dg/format/bitfld-1.c: Likewise.
* gcc.dg/format/attr-2.c: Likewise.
* gcc.dg/format/attr-6.c: Likewise.
* gcc.dg/format/array-1.c: Likewise.
* gcc.dg/format/attr-7.c: Likewise.
* gcc.dg/format/asm_fprintf-1.c: Likewise.
* gcc.dg/format/attr-4.c: Likewise.
* gcc.dg/format/branch-1.c: Likewise.
* gcc.dg/format/c90-printf-1.c: Likewise.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/array-1.c
trunk/gcc/testsuite/gcc.dg/format/asm_fprintf-1.c
trunk/gcc/testsuite/gcc.dg/format/attr-2.c
trunk/gcc/testsuite/gcc.dg/format/attr-4.c
trunk/gcc/testsuite/gcc.dg/format/attr-6.c
trunk/gcc/testsuite/gcc.dg/format/attr-7.c
trunk/gcc/testsuite/gcc.dg/format/bitfld-1.c
trunk/gcc/testsuite/gcc.dg/format/branch-1.c
trunk/gcc/testsuite/gcc.dg/format/c90-printf-1.c
trunk/gcc/testsuite/gcc.dg/redecl-4.c

[Bug target/62178] [AArch64] Performance regression on matrix matrix multiply due to r211211

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Yes, the patch changes addressing modes choosing and further changes ivopts's
decision.  I shall take this one if you are ok.

Thanks,
bin

[Bug lto/62179] New: undefined reference linking failure when combining "extern template"

[miles at gnu dot org]

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

Bug ID: 62179
   Summary: undefined reference linking failure when combining
"extern template"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miles at gnu dot org

[Bug ipa/61800] [5 Regression] ICE: Segmentation fault during Firefox build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

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