[Bug fortran/65086] New: Segfault: Invalid copy-out of temporary as argument is in read-only memory

[burnus at gcc dot gnu.org]

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

Bug ID: 65086
   Summary: Segfault: Invalid copy-out of temporary as argument is
in read-only memory
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

>From James Van Buskirk's example in the comp.lang.fortran thread "Is INTENT
(IN) ever used to control code generation?" /
https://groups.google.com/d/msg/comp.lang.fortran/nzq3Sad_zQE/APiZzlGdNPQJ


The following program segfaults at run time, unless INTENT(IN) is specified for
sub4. The problem is the copy-out part as the original variable is in read-only
memory.


"Both gfortran and ifort throw an error at runtime for the above program with
the INTENT(IN) statements commented out, but ifort runs to completion if either
or both of them are in effect whereas gfortran only works if the INTENT(IN)
statement in subroutine sub4 is in effect."


And:
"But as the standard is written it seems the Fortran processor has to do this
comparison before it can copy out, which seems absolutely horrible to me,
[...]"

Bob replies: "Why does it seem horrible?  Oracle Solaris Studio Fortran uses
this implementation."


module mod1
   implicit none
   character(*), parameter :: x = 'This is a constant string.'
end module mod1

module mod2
   implicit none
   contains
  subroutine sub1(x)
 character(*) x
 call sub2(x,len(x))
  end subroutine sub1
  subroutine sub2(x,size)
 integer size
 character x(size)
 call sub3(x)
  end subroutine sub2
  subroutine sub3(x)
 character x(:)
!INTENT(IN) :: x
 call sub4(x(1::2))
  end subroutine sub3
  subroutine sub4(x)
!INTENT(IN) :: x  ! REQUIRED
 character x(*)
  end subroutine sub4
end module mod2

program main
   use mod1
   use mod2
   implicit none
   write(*,'(a)') x
   call sub1(x)
   write(*,'(a)') x
end program main

[Bug libstdc++/65085] New: Move-assigned empty string corrupt with -D_GLIBCXX_USE_CXX11_ABI=1

[steveire at gmail dot com]

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

Bug ID: 65085
   Summary: Move-assigned empty string corrupt with
-D_GLIBCXX_USE_CXX11_ABI=1
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steveire at gmail dot com

GCC 5.0 generates corrupt CMake binaries currently:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12392/focus=12420

The cause seems to be between the new ABI and moving an empty std::string:

 stephen@hal:~/dev/src/playground/cpp{master}$
/home/stephen/dev/prefix/bin/g++-5.0 -v -std=gnu++11 membug.cpp
-D_GLIBCXX_USE_CXX11_ABI=1 -g  
Using built-in specs.
COLLECT_GCC=/home/stephen/dev/prefix/bin/g++-5.0
COLLECT_LTO_WRAPPER=/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../../src/gcc/configure --prefix=/home/stephen/dev/prefix
--enable-languages=c,c++ --program-suffix=-5.0 --enable-checking=release
--with-system-zlib
Thread model: posix
gcc version 5.0.0 20150130 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=gnu++11' '-D' '_GLIBCXX_USE_CXX11_ABI=1' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE -D
_GLIBCXX_USE_CXX11_ABI=1 membug.cpp -quiet -dumpbase membug.cpp -mtune=generic
-march=x86-64 -auxbase membug -g -std=gnu++11 -version -o /tmp/ccruY1vz.s
GNU C++11 (GCC) version 5.0.0 20150130 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20150130 (experimental), GMP version
6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../include/c++/5.0.0

/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../include/c++/5.0.0/x86_64-unknown-linux-gnu

/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../include/c++/5.0.0/backward
 /home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include
 /usr/local/include
 /home/stephen/dev/prefix/include
 /home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (GCC) version 5.0.0 20150130 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20150130 (experimental), GMP version
6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 017a5c35f0da909f1ce909a8ebb21479
COLLECT_GCC_OPTIONS='-v' '-std=gnu++11' '-D' '_GLIBCXX_USE_CXX11_ABI=1' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccA64A8Z.o /tmp/ccruY1vz.s
GNU assembler version 2.24.51 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.24.90.20141014
COMPILER_PATH=/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/:/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/:/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/:/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/:/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/:/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../x86_64-linux-gnu/:/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=gnu++11' '-D' '_GLIBCXX_USE_CXX11_ABI=1' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/collect2
-plugin
/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/liblto_plugin.so
-plugin-opt=/home/stephen/dev/prefix/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/cckIzEMq.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/stephen/dev/prefix/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/crtbegin.o

[Bug rtl-optimization/61772] RTL if-conversion removes asm volatile goto

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||win32

--- Comment #1 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html.

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[skunk at iskunk dot org]

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

--- Comment #12 from Daniel Richard G.  ---
(In reply to David Edelsohn from comment #8)
> Patches are reviewed on gcc-patches mailinglist, not in Bugzilla

Sorry, I'm not properly set up for mailing lists at the moment...

> > * Escape "{" characters to not annoy older awk programs
> 
> Prerequisites for GCC explicitly states that POSIX or SVR4 awk is required,
> so I don't think that this work-around would be accepted.  For example, you
> can install GNU Awk.

POSIX/SVR4 is significant if the system awk is missing major features that
would make the script awkward/impossible to maintain. But a small syntax tweak
like this, so long as it doesn't hurt other awk implementations, is no big
deal. Especially for a script that is run by users who are only compiling the
code, as opposed to developers.

> This already has been changed.
> 
[...]
> 
> The fixincludes changes are the most plausible ones.

As an aside, is there documentation somewhere on how to generate a GCC dist
tarball from SVN? "make dist" doesn't do it, Web searches turn up nothing, and
I'd rather not have to wait a few days for the next snapshot...

[Bug rtl-optimization/47477] [4.8/4.9 regression] Sub-optimal mov at end of method

[law at redhat dot com]

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

--- Comment #23 from Jeffrey A. Law  ---
Additional tests were extracted into BZ65084.  This BZ is just for tracking the
regression for testcase in c#0.

[Bug tree-optimization/65084] New: Lack of type narrowing/widening inhibits good vectorization

[law at redhat dot com]

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

Bug ID: 65084
   Summary: Lack of type narrowing/widening inhibits good
vectorization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com

These are testcases extracted from 47477.  

short a[1024], b[1024];

void
foo (void)
{
  int i;
  for (i = 0; i < 1024; i++)
{
  short c = (char) a[i] + 5;
  long long d = (long long) b[i] + 12;
  a[i] = c + d;
}
}

Compiled with -O3 -mavx2 we ought to get something similar to:

short a[1024], b[1024];

void
foo (void)
{
  int i;
  for (i = 0; i < 1024; i++)
{
  unsigned short c = ((short)(a[i] << 8) >> 8) + 5U;
  unsigned short d = b[i] + 12U;
  a[i] = c + d;
}
}


though even in this case I still couldn't achieve the sign extension to be
actually performed as 16-bit left + right (signed) shift, while I guess that
would lead to even better code.
Or look at how we vectorize:
short a[1024], b[1024];

void
foo (void)
{
  int i;
  for (i = 0; i < 1024; i++)
{
  unsigned char e = a[i];
  short c = e + 5;
  long long d = (long long) b[i] + 12;
  a[i] = c + d;
}
}
(note, here forwprop pass already performs type promotion, instead of
converting a[i] to unsigned char and back to short, it computes a[i] & 255 in
short mode) and how we could instead with type demotions:
short a[1024], b[1024];

void
foo (void)
{
  int i;
  for (i = 0; i < 1024; i++)
{
  unsigned short c = (a[i] & 0xff) + 5U;
  unsigned short d = b[i] + 12U;
  a[i] = c + d;
}
}

These are all admittedly artificial testcases, but I've seen tons of loops
where multiple types were vectorized and I think in some portion of those loops
we could either use just a single type size, or at least decrease the number of
conversions and different type sizes in the vectorized loops.

[Bug c/65083] New: Can not indirectly call some C11 atomic library functions

[bin.x.fan at oracle dot com]

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

Bug ID: 65083
   Summary: Can not indirectly call some C11 atomic library
functions
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bin.x.fan at oracle dot com

C11 defines these as actual functions, not generic functions or macros:

  atomic_thread_fence
  atomic_signal_fence
  atomic_flag_test_and_set
  atomic_flag_test_and_set_explicit
  atomic_flag_clear
  atomic_flag_clear_explicit

User should be able to take their address and call them indirectly. However,
GCC does not provide definitions of these functions in libatomic.so, so GCC
does not allow the user to take the address of these functions.

Here is an example:

-bash-4.1$ gcc -v
Using built-in specs.
COLLECT_GCC=/net/dv104/export/tools/gcc/4.9.2/sparc-S2/bin/gcc.bin
COLLECT_LTO_WRAPPER=/net/dv104/export/tools/gcc/4.9.2/sparc-S2/libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.9.2/configure
--prefix=/net/dv104/export/tools/gcc/4.9.2/sparc-S2
--enable-languages=c,c++,fortran
--with-gmp=/net/dv104/export/tools/gcc/4.9.2/sparc-S2
--with-mpfr=/net/dv104/export/tools/gcc/4.9.2/sparc-S2
--with-mpc=/net/dv104/export/tools/gcc/4.9.2/sparc-S2
Thread model: posix
gcc version 4.9.2 (GCC) 

-bash-4.1$ cat t.c
#include 
void (*func_ptr) (memory_order order);
int main()
{
 func_ptr = &atomic_thread_fence;
 (*func_ptr)(memory_order_seq_cst);
 return 0;
}
-bash-4.1$ gcc t.c -latomic
t.c: In function 'main':
t.c:5:15: error: 'atomic_thread_fence' undeclared (first use in this function)
  func_ptr = &atomic_thread_fence;
  ^
t.c:5:15: note: each undeclared identifier is reported only once for each
function it appears in

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[howarth at bromo dot med.uc.edu]

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

--- Comment #16 from howarth at bromo dot med.uc.edu ---
(In reply to David Edelsohn from comment #12)
> Author: dje
> Date: Mon Feb 16 15:19:20 2015
> New Revision: 220736
> 
> URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
> Log:
> Daniel Richard G. 
> PR bootstrap/48009
> PR bootstrap/53348
> * inclhack.def (aix_strtof_const): New fix.
> * fixincl.x: Regenerate.
> * tests/base/inttypes.h: New test.
> 
> Modified:
> trunk/fixincludes/ChangeLog
> trunk/fixincludes/fixincl.x
> trunk/fixincludes/inclhack.def

Shouldn't there have been a commit for the changes to tests/base/inttypes.h?

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[howarth at bromo dot med.uc.edu]

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

--- Comment #15 from howarth at bromo dot med.uc.edu ---
What autogen release was used to generate the newly committed fixincl.x? I
recently updated our autogen in fink to 5.18.4 because I discovered that 5.18.2
was producing broken fixincl.x files.

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #14 from howarth at bromo dot med.uc.edu ---
(In reply to David Edelsohn from comment #13)
> Fixed.

At r220743 on x86_64-apple-darwin14 with autogen 5.18.4 installed, make check
now produces...

stdlib.h
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150216/fixincludes/tests/base/stdlib.h
differ: char 240, line 12
*** stdlib.h2015-02-16 22:36:55.0 -0500
---
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150216/fixincludes/tests/base/stdlib.h
   2014-10-29 19:59:47.0 -0400
***
*** 9,19 



- #if defined( AIX_STRTOF_CONST_CHECK )
- extern floatstrtof(const char *, char **);
- #endif  /* AIX_STRTOF_CONST_CHECK */
- 
- 
  #if defined( HPUX11_ABS_CHECK )
  #if !defined(_MATH_INCLUDED) || defined(__GNUG__)
  #endif  /* HPUX11_ABS_CHECK */
--- 9,14 

There were fixinclude test FAILURES

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

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

--- Comment #14 from Alexander Peslyak  ---
For completeness, here are the results for 4.7.x, 4.8.x, and 4.9.0:

4.7.0o - 2142K c/s, 29692 bytes, 1267 movaps, 465 movups
4.7.0h - 2823K c/s, 29692 bytes, 1732 movaps, 0 movups
4.7.4o - 2144K c/s, 29692 bytes, 1267 movaps, 465 movups
4.7.4h - 2827K c/s, 29692 bytes, 1732 movaps, 0 movups
4.8.0o - 1825K c/s, 27813 bytes, 1341 movaps, 721 movups
4.8.0h - 2792K c/s, 27813 bytes, 2062 movaps, 0 movups
4.8.4o - 1827K c/s, 27807 bytes, 1341 movaps, 721 movups
4.8.4h - 2786K c/s, 27807 bytes, 2062 movaps, 0 movups
4.9.0o - 1852K c/s, 28262 bytes, 1319 movaps, 721 movups
4.9.0h - 2685K c/s, 28262 bytes, 2040 movaps, 0 movups

4.8 produces the smallest code so far, but even with the aligned loads hack is
still 6% slower than 4.3.

All of these are with "-O2 -fomit-frame-pointer -Os -funroll-loops
-finline-functions", like similar results I had posted before.  Xeon E5420,
x86_64.

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

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

--- Comment #13 from Alexander Peslyak  ---
(In reply to Richard Biener from comment #11)
> We are putting quite heavy register-pressure on the thing by means of
> partial redundancy elimination, thus disabling PRE using -fno-tree-pre
> might help (we still spill a lot).

It looks like -fno-tree-pre or equivalent was implied in the options I was
using, which were "-O2 -fomit-frame-pointer -Os -funroll-loops
-finline-functions" - yes, with -Os added after -O2 when compiling this
specific source file.  IIRC, this was experimentally derived as producing best
performance with 4.6.x or older.  Adding -fno-tree-pre after all of these
options merely changes the label names in the generated assembly code, while
resulting in identical object files (and obviously no performance change). 
Also, I now realize -Os was probably the reason why GCC preferred SSE
"floating-point" bitwise ops and MOVs here, instead of SSE2's integer ones
(they have longer encodings). Omitting -Os results in usage of the SSE2
instructions (both bitwise and MOVs), with correspondingly larger code. And
yes, when I omit -Os, I do need to add -fno-tree-pre to regain roughly the same
performance, and then to s/movdqu/movdqa/g to regain almost the full speed
(movdqu is just as slow as movups on this CPU). I've just tested all of this
with GCC 4.8.4 to possibly match yours (you mentioned you used 4.8). So I think
you uncovered yet another performance regression I had already worked around
with -Os.

FWIW, here are the generated assembly code sizes ("wc" output) with GCC 4.8.4:

-O2 -fomit-frame-pointer -Os -funroll-loops -finline-functions
  5870  17420 137636 1.s
-O2 -fomit-frame-pointer -Os -funroll-loops -finline-functions -fno-tree-pre
  5870  17420 137636 2.s
-O2 -fomit-frame-pointer -funroll-loops -finline-functions
  6814  20193 156837 a.s
-O2 -fomit-frame-pointer -funroll-loops -finline-functions -fno-tree-pre
  6028  17842 138284 b.s

As you can see, -fno-tree-pre reduces the size almost to the -Os level. (But
the .text size would be significantly larger because of the SSE2 instruction
encodings.  This is why I show the assembly code sizes for this comparison.)

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

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

--- Comment #12 from Alexander Peslyak  ---
(In reply to Richard Biener from comment #11)
> I wonder if you could share the exact CPU type you are using?

This is on (dual) Xeon E5420 (using only one core for these benchmarks), but
there was similar slowdown with GCC 4.6 on other Core 2'ish CPUs as well (such
as desktop Core 2 Duo CPUs). You might not call these "modern".

> Note that we have to use movups because [...]

Thank you for looking into this. I still have a question, though: does this
mean you're treating older GCC's behavior, where it dared to use movaps anyway,
a bug?

I was under impression that with most SSE*/AVX* intrinsics (except for those
explicitly defined to do unaligned loads/stores) natural alignment is assumed
and is supposed to be provided by the programmer. Not only with GCC, but with
compilers for x86(-64) in general. I thought this was part of the contract: I
use intrinsics and I guarantee alignment. (Things would certainly not work for
me at least with older GCC if I assumed the compiler would use unaligned loads
whenever it was unsure of alignment.) Was I wrong, or has this changed (in GCC?
or in some compiler-neutral specification?), or is GCC wrong in not assuming
alignment now?

Is there a command-line option to ask GCC to assume alignment, like it did
before?

[Bug fortran/65079] -Werror= does not work on implicit-procedure warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> I suggest to close these bugs as FIXED, because it is fixed in GCC 5.0.
> The number of changes required is large, and not only in the Fortran FE,
> thus a backport is really not worth the trouble.

Agreed!

[Bug fortran/65079] -Werror= does not work on implicit-procedure warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #1)
> I doubt this will be back ported to 4.9.

I suggest to close these bugs as FIXED, because it is fixed in GCC 5.0. The
number of changes required is large, and not only in the Fortran FE, thus a
backport is really not worth the trouble.

[Bug tree-optimization/47679] [4.8/4.9/5 Regression] Strange uninitialized warning after SRA

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #17 from Jeffrey A. Law  ---
Couldn't this be seen as a failure to thread jumps?  In the rs676361 testcase
we have the following relevant blocks after DOM2:

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  aOldItem = getitem (); [return slot optimization]
  aNewItem_19 = 0;
  _9 = MEM[(bool *)this_4(D)];
  if (_9 != 0)
goto ;
  else
goto ;
;;succ:   3
;;4

;;   basic block 3, loop depth 0
;;pred:   2
  aNewItem$8_22 = MEM[(const long unsigned int &)this_4(D) + 8];
  aNewItem$8_20 = aNewItem$8_22;
  aNewItem_21 = 1;
;;succ:   4

;;   basic block 4, loop depth 0
;;pred:   3
;;2
  # aNewItem_24 = PHI <1(3), 0(2)>
  # aNewItem$8_23 = PHI 
  _5 = MEM[(bool *)&aOldItem];
  _10 = ~_5;
  _11 = VIEW_CONVERT_EXPR(aNewItem_24);
  _12 = ~_11;
  if (_10 == _12)
goto ;
  else
goto ;
;;succ:   5
;;7

;;   basic block 5, loop depth 0
;;pred:   4
  if (_10 != 0)
goto ;
  else
goto ;
;;succ:   7
;;6

;;   basic block 6, loop depth 0
;;pred:   5
  _13 = MEM[(const long unsigned int &)&aOldItem + 8];
  aNewItem$8_14 = aNewItem$8_23;
  iftmp.4_15 = _13 == aNewItem$8_23;
  _16 = ~iftmp.4_15;
  _17 = (int) _16;
;;succ:   7


The key here is that we know the value of _12 depending on how we reach block
#4.  If BB4 then transfers control to block #5 we'll also know the value of _10
which would allow us to thread jumps and I believe simplifies things enough to
avoid the false positive, at least on the reduced case.  I haven't tried case
from Sergey yet.

This appears to be caused by a few deficiencies in jump threading.  None appear
to be major issues though.

[Bug target/28586] thowing exception before main() leads to crash on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||chandrakm at hotmail dot com

--- Comment #3 from David Edelsohn  ---
*** Bug 61637 has been marked as a duplicate of this bug. ***

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #23 from David Edelsohn  ---


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

[Bug target/58643] Running program $SHLIB_DIR/EFSE.RecordsEngine get error 0509-150

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from David Edelsohn  ---
No response

[Bug target/65058] AIX: missing extern decorations "[DS]" for functions and "[UA]" for variables

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 23:03:33 2015
New Revision: 220744

URL: https://gcc.gnu.org/viewcvs?rev=220744&root=gcc&view=rev
Log:
PR target/65058
* gcc.target/powerpc/pr65058.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr65058.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/45402] [4.8/4.9/5 Regression] ICE in extract_insn, at recog.c:2127 for gcc.dg/pr28796-2 on rx-elf

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
This was fixed here:

Author: jsm28 
Date:   Fri Oct 15 12:45:58 2010 +

* config/rx/rx.c (rx_option_optimization): Change to
rx_override_options_after_change.  Don't change
flag_lto_compression_level.  Don't check for changes to whether
FPU instructions can be used.  Check and set only
flag_finite_math_only, not other fast-math flags.
(rx_option_override): Call rx_override_options_after_change.
(TARGET_OPTION_OPTIMIZATION): Remove.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Define.


And thus has been included in several releases..

[Bug middle-end/65082] Wasted cycles when using a register based varible

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Related to bug 44281 and bug 42596.

[Bug c/65082] New: Wasted cycles when using a register based varible

[NickParker at Eaton dot com]

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

Bug ID: 65082
   Summary: Wasted cycles when using a register based varible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: NickParker at Eaton dot com

gcc version 4.8.0 20130306 (experimental) (GCC) 

Was just playing around and found this.  When using a register based variable,
the compiler misses an obvious optimisation.  

Notice in code below the addition does not take place 'in place' and is instead
performed in scratch/temporary registers and then shifted back to "phaseAccPh".
 Why not just add directly to "phaseAccPh" since in this case it IS register
based already.  It seems that GCC "thinks" that the variable is still in SRAM
or something else.
Nick.




c code:
-
register uint16_t phaseAccPh  asm ("r4");
uint16_t phaseAccFr;

phaseAccPh += phaseAccFr;



asm code:
-
  40:pll.c  void pllExec(void)
  41:pll.c  {
  15   .loc 1 41 0
  16   .cfi_startproc
  17   /* prologue: function */
  18   /* frame size = 0 */
  19   /* stack size = 0 */
  20   .L__stack_usage = 0
  42:pll.c    int16_t mix_output_s2;
  43:pll.c    phaseAccPh += phaseAccFr;
  21   .loc 1 43 0
  22  E091  lds r30,phaseAccFr
  23 0004 F091  lds r31,phaseAccFr+1
  24 0008 E40D  add r30,r4
  25 000a F51D  adc r31,r5
  26 000c 2F01  movw r4,r30

[Bug rtl-optimization/44281] [4.8/4.9/5 Regression] Global Register variable pessimisation

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
AFAICT the issue with push_flag_into_global_reg_var is poor register
allocation, perhaps made worse by the x86 backend's constrains on the ashldi3_1
insn.


  Loop 0 (parent -1, header bb2, depth 0)
bbs: 2
all: 0r96 1r94 2r93 3r92
modified regnos: 92 93 94 96
border:
Pressure: GENERAL_REGS=2
Hard reg set forest:
  0:( 0-2 4-6 8-15 21-52)@0
1:( 0-2 4-6 21-52)@0
  2:( 0-2 4-6 37-44)@28000
3:( 0-2 5 6 37-44)@2
  Allocno a0r96 of ALL_REGS(46) has 38 avail. regs  0-2 4-6 21-52, node: 
0-2 4-6 21-52 (confl regs =  3 7 16-20 53-79)
  Allocno a1r94 of GENERAL_REGS(14) has 14 avail. regs  0-2 4-6 37-44,
node:  0-2 4-6 37-44 (confl regs =  3 7-36 45-79)
  Allocno a2r93 of GENERAL_REGS(14) has 14 avail. regs  0-2 4-6 37-44,
node:  0-2 4-6 37-44 (confl regs =  3 7-36 45-79)
  Allocno a3r92 of GENERAL_REGS(14) has 13 avail. regs  0-2 5 6 37-44,
node:  0-2 5 6 37-44 (confl regs =  3 4 7-36 45-79)
  Pushing a3(r92,l0)(cost 0)
  Pushing a2(r93,l0)(cost 0)
  Pushing a1(r94,l0)(cost 0)
  Pushing a0(r96,l0)(cost 0)
  Popping a0(r96,l0)  -- assign reg 0
  Popping a1(r94,l0)  -- assign reg 1
  Popping a2(r93,l0)  -- assign reg 4
  Popping a3(r92,l0)  -- assign reg 5
Disposition:
3:r92  l0 52:r93  l0 41:r94  l0 10:r96  l0 0

In particular note a0(r96) going into reg0.  At that point, we've lost.  We'd
really like to see it go into %ebx, which is a global register variable.  The
key insns are:

(insn 11 10 12 2 (parallel [
(set (reg:DI 96 [ D.1874 ])
(ashift:DI (reg/v:DI 3 bx [ global_flag_stack ])
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) j.c:61 511 {*ashldi3_1}
 (expr_list:REG_DEAD (reg/v:DI 3 bx [ global_flag_stack ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 12 11 0 2 (parallel [
(set (reg/v:DI 3 bx [ global_flag_stack ])
(ior:DI (reg:DI 94 [ D.1873 ])
(reg:DI 96 [ D.1874 ])))
(clobber (reg:CC 17 flags))
]) j.c:61 400 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 96 [ D.1874 ])
(expr_list:REG_DEAD (reg:DI 94 [ D.1873 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

[Bug rtl-optimization/44281] [4.8/4.9/5 Regression] Global Register variable pessimisation

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law  ---
In reference to c#10 and c#14, we get from the trunk:

   0:   ff 65 08jmpq   *0x8(%rbp)
   3:   66 66 66 66 2e 0f 1fdata32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
   a:   84 00 00 00 00 00 

0010 :
  10:   4c 8b 55 08 mov0x8(%rbp),%r10
  14:   48 8d 6d 08 lea0x8(%rbp),%rbp
  18:   41 ff e2jmpq   *%r10
  1b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

0020 :
  20:   48 8b 45 08 mov0x8(%rbp),%rax
  24:   48 83 c5 08 add$0x8,%rbp
  28:   ff e0   jmpq   *%rax
  2a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

0030 :
  30:   48 8b 45 08 mov0x8(%rbp),%rax
  34:   48 83 c5 08 add$0x8,%rbp
  38:   ff e0   jmpq   *%rax

Which is better than the code reference in c#14 and c#10 in each case.  This
was probably Kai's code to improve our indirect jump support in the backend.

We also still get the desired code for push_flag_into_local_var.   The only
issue left is the poor code for push_flag_into_global_reg_var.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hubicka at ucw dot cz]

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

--- Comment #14 from Jan Hubicka  ---
Thanks for looking into that!
> 
> Why do we think rPrimary is 16-byte aligned when it is only 8-byte aligned?

ipa-cp newly does alignment propagation.  You may try to just disable it
by short cirucuiting ipcp_store_alignment_results
(also you ought to be able to find the wrong alignment upgrade in the ipa-cp
dumps)

Honza

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Fixed again after addressing bootstrap failure HJ experienced.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Mon Feb 16 20:56:55 2015
New Revision: 220743

URL: https://gcc.gnu.org/viewcvs?rev=220743&root=gcc&view=rev
Log:
PR tree-optimization/64823
* tree-vrp.c (identify_jump_threads): Handle blocks with no real
statements.
* tree-ssa-threadedge.c (potentially_threadable_block): Allow
threading through blocks with PHIs, but no statements.
(thread_through_normal_block): Distinguish between blocks where
we did not process all the statements and blocks with no statements.

PR tree-optimization/64823
* gcc.dg/uninit-20.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c
trunk/gcc/tree-vrp.c

[Bug c++/64596] Friendship not recognized and template param deduction error

[petschy at gmail dot com]

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

--- Comment #3 from petschy at gmail dot com ---
(In reply to Daniel Krügler from comment #2)

1) if the friend declaration is invalid in line 15, then g++ should tell me so,
shouldn't it? But atm it compiles it, and the surprise comes later, when the
private member can't be accessed, despite the friend decl.

Should I file a separate ticket about this? Any detail about why this
restriction about friend and alias templates is present in the std?

> 
>   template
>   friend class Txn;

This would work, of course, but this form would give friend access to any Txn
on Str, even with different E template params. That might lead to subtle bugs
where invalid usage is not caught at compile time.

Thanks, Peter

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #19)
> (In reply to Jerry DeLisle from comment #17)
> > Created attachment 34765 [details]
> > Handle KIND=1 and KIND=2
> 
> Jerry,
> 
> I applied your patch on top of rev. 220730.
> Unfortunately it ICEs on the following simple code:

Yes, that is an old version.  I have changed it quite a lot since that patch.

This has been evolving quickly since yesterday. I will not be able to continue
until possibly tonight or tomorrow.  I posted the results in Comment#18 so that
you can see the end result.  I will obsolete the patches.

[Bug middle-end/64928] [4.8/4.9/5 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #10 from Jeffrey A. Law  ---
Might want to look at 65076 as well where phase opt and generate is taking 89%
of the compile time.  Might be a better testcase to work with.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #20 from Bernd Edlinger  ---
(In reply to Dominique d'Humieres from comment #12)
> In addition Bernd's patch fixes/hides the ICE for pr61960.

this pr is fixed by this hunk alone:
--- gcc/fortran/trans-expr.c(revision 220662)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface
  expr->symtree = sym->new_sym;
else if (sym->expr)
  gfc_replace_expr (expr, gfc_copy_expr (sym->expr));
-   /* Replace base type for polymorphic arguments.  */
-   if (expr->ref && expr->ref->type == REF_COMPONENT
-   && sym->expr && sym->expr->ts.type == BT_CLASS)
- expr->ref->u.c.sym = sym->expr->ts.u.derived;
   }

   /* ...and to subexpressions in expr->value.  */

I verified the generated code, not only the ICE is gone, but
the code seems work.

So I'd declare pr61960 to be a duplicate of this PR.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #12)
> I agree it is probably differnt issue, but lets see. It would help if you
> can look at the backtract and see if there is a problem between
> local/non-local calling conventions.  I.e. function called with parameters
> passed on stack and consuming them in registers.

X32 passes parameters in registers, just like x86-64.  I got

(gdb) disass
Dump of assembler code for function operator*(ggSpectrum const&, ggSpectrum
const&):
   0x00420780 <+0>:movups (%esi),%xmm0
   0x00420784 <+4>:mov%rdi,%rax
   0x00420787 <+7>:movups 0x10(%esi),%xmm1
=> 0x0042078c <+12>:mulps  (%edx),%xmm0
^ It isn't aligned to 32 bytes.
   0x00420790 <+16>:mulps  0x10(%edx),%xmm1
   0x00420795 <+21>:movups %xmm0,(%edi)
   0x00420799 <+25>:movups %xmm1,0x10(%edi)
   0x0042079e <+30>:retq   
End of assembler dump.
(gdb) p/x $edx
$2 = 0xcc48
(gdb) f 1
#1  0x004452d4 in __base_ctor  (v=..., z=..., y=..., x=..., bPrimary=..., 
gPrimary=..., rPrimary=..., this=0xbf60) at ./ggPhotometer.h:53
53  colorMatrix[0][0] = (cieX * rPrimary).area();
(gdb) p cieX
$3 = {data = {0.146008939, 0.279831082, 0.0505069345, 0.202513069, 
0.729846954, 0.957131386, 0.414069265, 0.0614523999}}
(gdb) p rPrimary
$4 = (const struct ggSpectrum &) @0xcc48: {data = {0, 0, 0, 0, 
0.0899555609, 0.550044477, 0.95979, 1}}
(gdb) ...
   0x004452c4 <+1620>:mov(%esp),%rdx
   0x004452c9 <+1625>:mov%r15,%rsi
   0x004452cc <+1628>:mov%r14,%rdi
   0x004452cf <+1631>:callq  0x420780 
=> 0x004452d4 <+1636>:mov%r14,%rdi
...
Breakpoint 1, 0x004452cf in __base_ctor  (v=..., z=..., y=..., x=..., 
bPrimary=..., gPrimary=..., rPrimary=..., this=0xbf60)
at ./ggPhotometer.h:53
53  colorMatrix[0][0] = (cieX * rPrimary).area();
(gdb) p/x $rdi
$6 = 0xbf40
(gdb) p/x $rsi
$7 = 0xbfa8
(gdb) p/x $rdx
$8 = 0xcc48
(gdb) p this
$9 = (struct ggPhotometer * const) 0xbf60
(gdb) p &cieX
$10 = (struct ggSpectrum *) 0xbfa8
(gdb) p/x &rPrimary
$11 = 0xcc48
(gdb) p/x $pc
$13 = 0x4452cf
(gdb) p rPrimary
$1 = (const struct ggSpectrum &) @0xcc48: {data = {0, 0, 0, 0, 
0.0899555609, 0.550044477, 0.95979, 1}}
(gdb) 

Why do we think rPrimary is 16-byte aligned when it is only 8-byte aligned?

[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 16 19:22:57 2015
New Revision: 220742

URL: https://gcc.gnu.org/viewcvs?rev=220742&root=gcc&view=rev
Log:
PR ipa/64963
* cgraphclones.c (cgraph_node::create_virtual_clone): Copy
section if not linkonce.  Fix up formatting.
(cgraph_node::create_version_clone_with_body): Copy section.
* trans-mem.c (ipa_tm_create_version): Likewise.

* gcc.dg/ipa/ipa-clone-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipa-clone-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/trans-mem.c

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Perf shows:

Overhead  Command   Shared Object   Symbol
   2.45%  cc1plus   libc-2.21.90.so [.] _int_malloc
   1.88%  cc1plus   cc1plus [.] bitmap_find_bit
   1.72%  cc1plus   cc1plus [.] gt_ggc_mx_lang_tree_node
   1.36%  cc1plus   libc-2.21.90.so [.] _int_free
   1.05%  cc1plus   cc1plus [.] ggc_set_mark
   0.97%  cc1plus   cc1plus [.] record_reg_classes
   0.96%  cc1plus   cc1plus [.] df_worklist_dataflow
   0.91%  cc1plus   cc1plus [.] build_qualified_type
   0.88%  cc1plus   cc1plus [.] df_note_compute
   0.84%  cc1plus   libc-2.21.90.so [.] malloc_consolidate

(Using a faster malloc implementation speeds up compile time by ~5%:

markus@x4 ~ % time g++ -w -Ofast tramp3d-v4.cpp
g++ -w -Ofast tramp3d-v4.cpp  26.00s user 0.32s system 99% cpu 26.341 total
markus@x4 ~ % time LD_PRELOAD=/usr/lib/libllalloc.so.1.3 g++ -w -Ofast
tramp3d-v4.cpp
LD_PRELOAD=/usr/lib/libllalloc.so.1.3 g++ -w -Ofast tramp3d-v4.cpp  24.60s user
0.37s system 99% cpu 24.997 total)

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
markus@x4 ~ % g++ -ftime-report -Ofast -w tramp3d-v4.cpp

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1419 kB ( 0%) ggc
 phase parsing   :   1.10 ( 4%) usr   0.41 (20%) sys   1.51 ( 5%) wall 
167809 kB (16%) ggc
 phase lang. deferred:   1.94 ( 7%) usr   0.22 (11%) sys   2.16 ( 7%) wall 
196631 kB (18%) ggc
 phase opt and generate  :  23.73 (89%) usr   1.46 (70%) sys  25.18 (87%) wall 
710026 kB (66%) ggc
 phase finalize  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 |name lookup:   0.20 ( 1%) usr   0.05 ( 2%) sys   0.36 ( 1%) wall 
 25424 kB ( 2%) ggc
 |overload resolution:   0.96 ( 4%) usr   0.10 ( 5%) sys   1.11 ( 4%) wall 
116881 kB (11%) ggc
 garbage collection  :   1.14 ( 4%) usr   0.00 ( 0%) sys   1.14 ( 4%) wall 
 0 kB ( 0%) ggc
 dump files  :   0.13 ( 0%) usr   0.02 ( 1%) sys   0.20 ( 1%) wall 
 0 kB ( 0%) ggc
 callgraph construction  :   0.31 ( 1%) usr   0.02 ( 1%) sys   0.46 ( 2%) wall 
 17921 kB ( 2%) ggc
 callgraph optimization  :   0.37 ( 1%) usr   0.14 ( 7%) sys   0.42 ( 1%) wall 
 14318 kB ( 1%) ggc
 ipa dead code removal   :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa virtual call target :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 1 kB ( 0%) ggc
 ipa cp  :   0.10 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
  4221 kB ( 0%) ggc
 ipa inlining heuristics :   0.35 ( 1%) usr   0.00 ( 0%) sys   0.35 ( 1%) wall 
 10474 kB ( 1%) ggc
 ipa function splitting  :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) wall 
   797 kB ( 0%) ggc
 ipa comdats :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa reference   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa profile :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa pure const  :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall 
   100 kB ( 0%) ggc
 ipa icf :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 1 kB ( 0%) ggc
 ipa SRA :   0.19 ( 1%) usr   0.06 ( 3%) sys   0.20 ( 1%) wall 
 25432 kB ( 2%) ggc
 ipa free inline summary :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 cfg construction:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1645 kB ( 0%) ggc
 cfg cleanup :   0.17 ( 1%) usr   0.00 ( 0%) sys   0.15 ( 1%) wall 
   984 kB ( 0%) ggc
 trivially dead code :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.15 ( 1%) wall 
   107 kB ( 0%) ggc
 df multiple defs:   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall 
 0 kB ( 0%) ggc
 df reaching defs:   0.13 ( 0%) usr   0.00 ( 0%) sys   0.25 ( 1%) wall 
 0 kB ( 0%) ggc
 df live regs:   0.70 ( 3%) usr   0.03 ( 1%) sys   0.80 ( 3%) wall 
 0 kB ( 0%) ggc
 df live&initialized regs:   0.27 ( 1%) usr   0.01 ( 0%) sys   0.18 ( 1%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   0.09 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:   0.35 ( 1%) usr   0.03 ( 1%) sys   0.43 ( 1%) wall 
  4732 kB ( 0%) ggc
 register information:   0.15 ( 1%) usr   0.01 ( 0%) sys   0.09 ( 0%) wall 
 0 kB ( 0%) ggc
 alias analysis  :   0.29 ( 1%) usr   0.00 ( 0%) sys   0.31 ( 1%) wall 
 16094 kB ( 1%) ggc
 alias stmt walking  :   0.63 ( 2%) usr   0.01 ( 0%) sys   0.64 ( 2%) wall 
   795 kB ( 0%) ggc
 register scan   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
   544 kB ( 0%) ggc
 rebuild jump labels :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.07 ( 0%) wall 
 0 kB ( 0%) ggc
 preprocessing   :   0.07 ( 0%) usr   0.13 ( 6%) sys   0.18 ( 1%) wall 
  3198 kB ( 0%) ggc
 parser (global) :   0.13 ( 0%) usr   0.16 ( 8%) sys   0.27 ( 1%) wall 
 50197 kB ( 5%) ggc
 parser struct body  :   0.16 ( 1%) usr   0.02 ( 1%) sys   0.25 ( 1%) wall 
 24480 kB ( 2%) ggc
 parser enumerator list  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
   291 kB ( 0%) ggc
 parser function body:   0.14 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall 
  7849 kB ( 1%) ggc
 parser inl. func. body  :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall 
  4142 kB ( 0%) ggc
 parser inl. meth. body  :   0.15 ( 1%) usr   0.04 ( 2%) sys   0.17 ( 1%) wall 
 17265 kB ( 2%) ggc
 template instantiation  :   2.00 ( 7%) usr   0.27 (13%) sys   2.30 ( 8%) wall 
256355 kB (24%) ggc
 early inlining heuristics:   0.05 ( 0%) usr   0.02 ( 1%) sys   0.08 ( 0%) wall
   8349 kB ( 1%) ggc
 inline parameters   :   0.15 ( 1%) usr   0.01 ( 0%) sys   0.22 ( 1%) wall 
  7914 kB ( 1%) ggc
 integration  

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
Yes, any particular choice has the potential to regress in one way or another. 
These are heuristics after all.  We're just looking for a reasonable refinement
if we can find one.

Dominance doesn't seem to be the right thing to be looking at to me since the
crux of this issue is propagating the "copy" implied by the equality comparison
just changes what SSA_NAME we reference and as a result ultimately hides stuff
from later passes.  It doesn't (in this case) enable further simplifications or
for either SSA_NAME to become unused.  A dominance test between the args of the
equality comparison just doesn't seem helpful here.

In fact, because both names are used in the equality test, these propagations
can never cause an SSA_NAME to become unused.  At best the propagation will
expose some further simplification on one of the paths or it will result in one
SSA_NAME having a single use (the comparison).  We have no good way of guessing
if the former will happen, but we can encourage the latter.

But as I mentioned earlier, I really wonder if we should allow these context
sensitive equivalences to be expressed in the gimple if they didn't prove
useful.  And that was the whole purpose behind uncprop -- to find context
sensitive propagations that ultimately didn't prove useful and which result in
poor coalescing or unwanted constant initializations and un propagate them.

It wouldn't directly help this problem because the use is in a normal
statement, but it's definitely closely related and it wouldn't be hard to
repurpose that code.  In fact, it might be a good thing to do in general.

Essentially what it's doing is building a map of values back to SSA_NAMEs which
hold those values by way of an equality comparison.  At each use of the value,
we can look at the list of SSA_NAMEs that hold that value and select the one
that appears to be least cost based on whatever metrics we see fit.

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
(In reply to homgran from comment #9)
> (In reply to Dominique d'Humieres from comment #8)
> > > > AFAICT the ICE for the original test is as old as the first 
> > > > implementation
> > > > of unlimited polymorphism.
> > >
> > > In that case, should we remove the '[4.9/5 Regression]' tag from the 
> > > summary title?
> > 
> > Please don't do that.
> > 

I agree.

If the type 'T' is declared in the main programme the problem goes away. The
ICE occurs in the course of nullifying the vptr field. It appears that this
latter has no backend_decl; hence the ICE. I think that this implies that
something is going wrong with building the structure for the class component
but I haven't yet found why being use associated makes a difference.

This works fine:
MODULE X
  TYPE T
CLASS(*), pointer :: info
  END TYPE
END MODULE

PROGRAM P
  use x
  class(T), target, allocatable :: tgt
CONTAINS
  SUBROUTINE BUG
USE X
CLASS(T), pointer :: e
   e=>tgt
  END SUBROUTINE

  SUBROUTINE NEXT
USE X
CLASS (T), pointer :: e
  END SUBROUTINE
END

Cheers

Paul

[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Attachment #34770|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #4 from Richard Henderson  ---
Created attachment 34785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34785&action=edit
second patch

I prefer to remove the test against node->definition entirely.
It appears to mean only that we have a definition that we could
emit, not that we're going to actually emit the symbol.

In particular, for functions, we'd have to also check cgraph_node::process.
At which point I suspect that DECL_EXTERNAL is sufficient.  Which means
that we can at least set defined_locally based on DECL_EXTERNAL even if
there is no symtab_node.  I don't know that we'd ever not have one, but
that's certainly not obvious from here.

Starting regression testing on several platforms...

[Bug rtl-optimization/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.

[pthaugen at gcc dot gnu.org]

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

--- Comment #20 from Pat Haugen  ---
(In reply to H.J. Lu from comment #19)
> 
> Can you try fix in PR 65074?

Yes, that fixes the problem.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
I agree it is probably differnt issue, but lets see. It would help if you can
look at the backtract and see if there is a problem between local/non-local
calling conventions.  I.e. function called with parameters passed on stack and
consuming them in registers.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Yep, I looked into this somewhat while preparing the patch. With new metric we
manage to do a lot more inlining before hitting the limits. This is kind of
positive effect - clearly inliner does things that pays back and it is posisble
to drop down INLINE_UNIT_GROWTH.

On the other hand it produces somewhat longer text segment that also leads to
slower compile times.

I finally got working firefox in all setups and plan to do some of inliner
tuning this week, so will look into that. What is the full -Q report you get?

Honza

[Bug rtl-optimization/65067] regression on accessing volatile bit field

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #4 from Bernd Edlinger  ---
this does not happen with 4.9.0,
but I can confirm this behavior with current trunk.

[Bug other/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
 Status|UNCONFIRMED |NEW
  Known to work||4.7.4
   Keywords||ice-on-valid-code, ra
   Last reconfirmed||2015-02-16
  Component|target  |other
 CC||gjl at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in avr-gcc when passing |[4.8/4.9/5.0 Regression]
   |struct member to varargs|ICE in avr-gcc when passing
   |function|struct member to varargs
   ||function
  Known to fail||4.8.3, 4.9.2

[Bug sanitizer/65081] -fsanitize=object-size fails with simple pointer arithm

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #15 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #4)
> we have similar handling for
> 
>   else if (truth_value_p (code))
> /* Truth value results are not pointer (parts).  Or at least
>very very unreasonable obfuscation of a part.  */
> ;

Isn't this unreachable due to 

+  case BIT_FIELD_REF:

in the patch? Or would it be hit if somebody tries to encode pointers with a
packed bitfield struct/union?

No, I won't write a ridiculous testcase to check :-)

Again, great thanks.

[Bug sanitizer/65081] New: -fsanitize=object-size fails with simple pointer arithm

[larsbj at gullik dot net]

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

Bug ID: 65081
   Summary: -fsanitize=object-size fails with simple pointer
arithm
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot net
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

With:

gcc (GCC) 5.0.0 20150216 (experimental) as of 220738

and this test snippet:

---

struct intro {
int a;
char pad_[1];
};

struct intro b;

struct intro * alloc()
{
struct intro * i = &b;
return i + 1;
}

int main(void)
{
struct intro * i = alloc() - 1;
i->a = 1;
}
---

I get this report:

test.c:17:10: runtime error: store to address 0x006010a0 with insufficient
space for an object of type 'int'
0x006010a0: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^

When compiled like this:

 gcc -O1 -fsanitize=object-size test.c

-fno-inline removes the runtime error, as do removing the pad_ from the intro
struct.

This is possibly an duplicate of bug 63303, but the errors are quite different.

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 16 18:15:19 2015
New Revision: 220741

URL: https://gcc.gnu.org/viewcvs?rev=220741&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  

PR tree-optimization/65077
* tree-ssa-structalias.c (get_constraint_for_1): Handle
IMAGPART_EXPR, REALPART_EXPR and BIT_FIELD_REF.
(find_func_aliases): Allow float values to carry pointers again.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr65077.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.9/5 Regression] memcpy   |[4.9 Regression] memcpy
   |generates incorrect code|generates incorrect code
   |with floating point numbers |with floating point numbers
   |and -O1 |and -O1
  Known to fail||4.9.2

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

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

anders.blomdell at control dot lth.se changed:

   What|Removed |Added

  Attachment #34774|0   |1
is obsolete||

--- Comment #12 from anders.blomdell at control dot lth.se ---
Created attachment 34784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34784&action=edit
Somewhat better testcase (less type-cheating)

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #11 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #10)
> Created attachment 34781 [details]
> untested patch
Apllied patch to Fedora SRPM, rebuilt, installed, rerun my testcase:

Works! :-)

> Patch which fixes the testcase and doesn't regress the vectorization
> testcase from PR37021.

Thanks, you are one order of magnitude faster at fixing bugs than my computer
is at compiling them, and at least two orders of magnitude faster than I'm at
isolating bugs. Kudos!

[Bug target/64052] compilation error "local frame unavailable" appears for some optimization levels

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
(In reply to Eugene from comment #4)
> I am not arguing for the sample code to be compilable and functional.
> My expectation is a consistent compilation result regardless of the
> optimisation settings. If it fails with 'O0' should fail with 'Os' too.

IMO this "consistency" is not feasible as the result depends on the
optimization level and probably optimization switches.  For such a
"consistency" the compiler would have to know the results of all other possible
option sets.

Not all diagnostics are emit during lexing or parsing, many diagnostics depend
on further analysis of code and data and might run after early inlining or dead
code / data elimination.

[Bug c++/65080] constexpr-ness lost by using alias in definition

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #3 from Paolo Carlini  ---
Done. Thanks Ville.

[Bug c++/65080] constexpr-ness lost by using alias in definition

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Feb 16 17:48:08 2015
New Revision: 220739

URL: https://gcc.gnu.org/viewcvs?rev=220739&root=gcc&view=rev
Log:
2015-02-16  Paolo Carlini  

PR c++/65080
* g++.dg/cpp0x/constexpr-65080.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-65080.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ada/64548] Lost visibility of package System after raise

[demoonlit at panathenaia dot halfmoon.jp]

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

--- Comment #5 from yuta tomino  ---
Hello, Simon.
I'm glad to look at this report.

I have a similar experience like this.
The trigger of mine was not "private with" but a nested package in the spec of
Ada.Exceptions.

I should think it's useless information, but I would write, just in case.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Martin Jambor from comment #10)
> (In reply to H.J. Lu from comment #9)
> > The same bug affects 252.eon in SPEC CPU 2000 on x32:
> 
> ...
> 
> > 
> > The fix isn't sufficient since adding -fno-ipa-cp fixes eon on x32.
> 
> I really doubt that it is "the same bug."  Just that -fno-ipa-cp
> avoids it certainly does not suffice to make that conclusion.

The symptom is very similar, that is eon died very early.

> Anyway, I will try to find some time to look soon, although setting up
> x32 environment will take me some time.  I suppose this bug also
> manifests itself with -O3 and LTO?

It ONLY shows up with -O3 -funroll-loops -ffast-math -flto

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
(In reply to H.J. Lu from comment #9)
> The same bug affects 252.eon in SPEC CPU 2000 on x32:

...

> 
> The fix isn't sufficient since adding -fno-ipa-cp fixes eon on x32.

I really doubt that it is "the same bug."  Just that -fno-ipa-cp
avoids it certainly does not suffice to make that conclusion.

Anyway, I will try to find some time to look soon, although setting up
x32 environment will take me some time.  I suppose this bug also
manifests itself with -O3 and LTO?

[Bug rtl-optimization/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
(In reply to Pat Haugen from comment #18)
> The following error started with r220674 on powerpc64-linux when trying to
> build 447.dealII from CPU2006 with -m64.
> 
> /usr/bin/ld: exceptions.o: In function `ExceptionBase::what() const':
> exceptions.cc:(.text+0xda0): unresolvable R_PPC64_TOC16_HA against
> `std::__cxx11::basic_string,
> std::allocator >::~basic_string()@@GLIBCXX_3.4.21'
> /usr/bin/ld: exceptions.cc:(.text+0xdac): unresolvable R_PPC64_TOC16_LO
> against `std::__cxx11::basic_string,
> std::allocator >::~basic_string()@@GLIBCXX_3.4.21'
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status

Can you try fix in PR 65074?

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #9 from H.J. Lu  ---
The same bug affects 252.eon in SPEC CPU 2000 on x32:

[hjl@gnu-mic-2 0002]$ ../0002/eon_peak.lto chair.control.cook
chair.camera chair.surfaces chair.cook.ppm ppm pixels_out.cook
Segmentation fault
[hjl@gnu-mic-2 0002]$ gdb ../0002/eon_peak.lto
GNU gdb (GDB) Fedora 7.7.1-21.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../0002/eon_peak.lto...done.
(gdb) r chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/252.eon/run/0002/eon_peak.lto
chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook

Program received signal SIGSEGV, Segmentation fault.
0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.0.fc20.x32
libgcc-4.8.3-7.2.fc20.x86_64 libstdc++-4.8.3-7.2.fc20.x86_64
(gdb) bt
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
#1  0x004452d4 in eonImageCalculator::eonImageCalculator() ()
#2  0x0040378a in main ()
(gdb) f 0
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
(gdb) disass
Dump of assembler code for function _ZmlRK10ggSpectrumS1_:
   0x00420780 <+0>:movups (%esi),%xmm0
   0x00420784 <+4>:mov%rdi,%rax
   0x00420787 <+7>:movups 0x10(%esi),%xmm1
=> 0x0042078c <+12>:mulps  (%edx),%xmm0
   0x00420790 <+16>:mulps  0x10(%edx),%xmm1
   0x00420795 <+21>:movups %xmm0,(%edi)
   0x00420799 <+25>:movups %xmm1,0x10(%edi)
   0x0042079e <+30>:retq   
End of assembler dump.
(gdb) p $edx
$1 = -13304
(gdb) p/x $edx
$2 = 0xcc08

The fix isn't sufficient since adding -fno-ipa-cp fixes eon on x32.

[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #4 from Artem S. Tashkinov  ---
Created attachment 34783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34783&action=edit
Sources and Makefile (run make to reproduce)

This bug affects GCC 4.9.2 too! (I'm on i686):

blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*,
size_t)’:
blake2s.cpp:138:40: error: corrupted value profile: value profile counter
(11286702 out of 11276532) inconsistent with basic-block count (9452310)
   memcpy( S->buf + left, in, fill ); // Fill buffer
^
blake2s.cpp:162:49: error: corrupted value profile: value profile counter
(11504160 out of 11557346) inconsistent with basic-block count (11155414)
   memcpy( S->buf + left, in, (size_t)inlen );
 ^
make: *** [blake2s.o] Error 1

[Bug ipa/65006] [5 Regression] 252.eon in SPEC CPU 2000 miscompiled with LTO

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to H.J. Lu from comment #11)
> r220521 miscompiled 252.eon in SPEC CPU 2000 with LTO for both x86-32:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01063.html
> 
> and x32:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01047.html
> 
> X86-32 was fixed:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01417.html
> 
> But not:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01406.html
> 
> I got
> 
> [hjl@gnu-mic-2 0002]$ ../0002/eon_peak.lto chair.control.cook
> chair.camera chair.surfaces chair.cook.ppm ppm pixels_out.cook
> Segmentation fault
> [hjl@gnu-mic-2 0002]$ gdb ../0002/eon_peak.lto
> GNU gdb (GDB) Fedora 7.7.1-21.fc20
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ../0002/eon_peak.lto...done.
> (gdb) r chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
> pixels_out.cook
> Starting program:
> /export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/252.eon/
> run/0002/eon_peak.lto chair.control.cook chair.camera chair.surfaces
> chair.cook.ppm ppm pixels_out.cook
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
> Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.0.fc20.x32
> libgcc-4.8.3-7.2.fc20.x86_64 libstdc++-4.8.3-7.2.fc20.x86_64
> (gdb) bt
> #0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
> #1  0x004452d4 in eonImageCalculator::eonImageCalculator() ()
> #2  0x0040378a in main ()
> (gdb) f 0
> #0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
> (gdb) disass
> Dump of assembler code for function _ZmlRK10ggSpectrumS1_:
>0x00420780 <+0>:   movups (%esi),%xmm0
>0x00420784 <+4>:   mov%rdi,%rax
>0x00420787 <+7>:   movups 0x10(%esi),%xmm1
> => 0x0042078c <+12>:  mulps  (%edx),%xmm0
>0x00420790 <+16>:  mulps  0x10(%edx),%xmm1
>0x00420795 <+21>:  movups %xmm0,(%edi)
>0x00420799 <+25>:  movups %xmm1,0x10(%edi)
>0x0042079e <+30>:  retq   
> End of assembler dump.
> (gdb) p $edx
> $1 = -13304
> (gdb) p/x $edx
> $2 = 0xcc08

Adding -fno-ipa-cp fixes x32.  Fix for PR 65028 isn't complete.

[Bug c++/65080] constexpr-ness lost by using alias in definition

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
 CC||paolo.carlini at oracle dot 
com,
   ||ville.voutilainen at gmail dot 
com
  Known to work||5.0
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.1

--- Comment #1 from Ville Voutilainen  ---
This does seem like an added test is enough, unless we already have a test for
it,
of course. :) Paolo, could you please handle this?

[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #3 from Artem S. Tashkinov  ---
This bug affects GCC 4.5.4 as well. I guess the bug is no longer relevant since
both these GCC releases are deprecated and unsupported.

[Bug rtl-optimization/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #18 from Pat Haugen  ---
The following error started with r220674 on powerpc64-linux when trying to
build 447.dealII from CPU2006 with -m64.

/usr/bin/ld: exceptions.o: In function `ExceptionBase::what() const':
exceptions.cc:(.text+0xda0): unresolvable R_PPC64_TOC16_HA against
`std::__cxx11::basic_string, std::allocator
>::~basic_string()@@GLIBCXX_3.4.21'
/usr/bin/ld: exceptions.cc:(.text+0xdac): unresolvable R_PPC64_TOC16_LO against
`std::__cxx11::basic_string, std::allocator
>::~basic_string()@@GLIBCXX_3.4.21'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  ---
Note that r220318 does not fix c++1998/all_attributes.cc for
x86_64-apple-darwin10 (see
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01455.html) nor for
powerpc-apple-darwin9 (see
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01454.html).

[Bug c++/65080] New: constexpr-ness lost by using alias in definition

[kaballo86 at hotmail dot com]

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

Bug ID: 65080
   Summary: constexpr-ness lost by using alias in definition
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com

In the following snippet, whether the expression `xxx` designates a
constexpr function or not depends on whether `foo::value` is defined with an
alias or not:

template 
static constexpr T xxx(){ return T(); }

template 
struct foo {
  using type = T(*)();
  static constexpr type value[1] = {&xxx};
};

template 
constexpr typename foo::type foo::value[1]; // fails
//constexpr T (*foo::value[1])(); // works

int main() {
  constexpr int x = foo::value[0](); // error here
}

Both definitions work fine in trunk. I couldn't find a PR for it, so I'm
reporting it anyways to make sure there is a test covering it.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #27 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #26)
> (In reply to howarth from comment #25)
> > (In reply to Iain Sandoe from comment #19)
> > 
> > Are we going with this fix? If so. please post it to gcc-patches with a
> > ChangeLog.
> 
> was posted 3rd Feb
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

Pinged but probably would had better exposure if posted as its a new thread for
your own patch proposal.

[Bug target/65058] AIX: missing extern decorations "[DS]" for functions and "[UA]" for variables

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #4 from David Edelsohn  ---
Fixed.

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Reduced test

program test
  implicit none
  type t
integer :: ii
  end type t
  type, extends(t) :: u
real :: rr
  end type u
  type, extends(t) :: v
real, allocatable :: rr(:)
  end type v
  type, extends(v) :: w
real, allocatable :: rrr(:)
  end type w

  type(v) :: b(3)

  b = func7() ! scalar daughter type to array - alloc comps in parent type

contains

  function func7() result(res)
class(v), allocatable :: res
allocate (res, source = w(3,[10.0,20.0],[100,200]))
  end function func7

end program test

There is no problem with the original test once the following lines are
commented

  b = func7() ! scalar daughter type to array - alloc comps in parent type
  if (any (b(2)%rr .ne. [10.0,20.0])) call abort

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:33:09 2015
New Revision: 220737

URL: https://gcc.gnu.org/viewcvs?rev=220737&root=gcc&view=rev
Log:
2015-02-16  Michael Haubenwallner  
David Edelsohn  

PR target/65058
* config/rs6000/rs6000.c (rs6000_output_symbol_ref): Append storage
mapping class to external variable or function reference.
* config/rs6000/xcoff.h (ASM_OUTPUT_EXTERNAL): Do not append storage
mapping class.

2015-02-16  David Eelsohn  

PR target/53348
* config/rs6000/rs6000.c (rs6000_declare_alias): Only use
ASM_WEAKEN_DECL if defined.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/xcoff.h

[Bug target/65058] AIX: missing extern decorations "[DS]" for functions and "[UA]" for variables

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:33:09 2015
New Revision: 220737

URL: https://gcc.gnu.org/viewcvs?rev=220737&root=gcc&view=rev
Log:
2015-02-16  Michael Haubenwallner  
David Edelsohn  

PR target/65058
* config/rs6000/rs6000.c (rs6000_output_symbol_ref): Append storage
mapping class to external variable or function reference.
* config/rs6000/xcoff.h (ASM_OUTPUT_EXTERNAL): Do not append storage
mapping class.

2015-02-16  David Eelsohn  

PR target/53348
* config/rs6000/rs6000.c (rs6000_declare_alias): Only use
ASM_WEAKEN_DECL if defined.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/xcoff.h

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #13 from David Edelsohn  ---
Fixed.

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed in 5.0.

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:19:20 2015
New Revision: 220736

URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
Log:
Daniel Richard G. 
PR bootstrap/48009
PR bootstrap/53348
* inclhack.def (aix_strtof_const): New fix.
* fixincl.x: Regenerate.
* tests/base/inttypes.h: New test.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:19:20 2015
New Revision: 220736

URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
Log:
Daniel Richard G. 
PR bootstrap/48009
PR bootstrap/53348
* inclhack.def (aix_strtof_const): New fix.
* fixincl.x: Regenerate.
* tests/base/inttypes.h: New test.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[matt at gneilson dot plus.com]

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

--- Comment #9 from homgran  ---
(In reply to Dominique d'Humieres from comment #8)
> > > AFAICT the ICE for the original test is as old as the first implementation
> > > of unlimited polymorphism.
> >
> > In that case, should we remove the '[4.9/5 Regression]' tag from the 
> > summary title?
> 
> Please don't do that.
> 
> (1) The ICE for the reduced test in comment 2 is a regression. Leave some
> time to Janus to look at the problem:
> 
> > > > The ICE for the reduced test in comment 2 [...]
> > > Started at r207986.
> >
> > Huh, that was me committing a patch for PR 60234. Guess I should take a look
> > (but will probably not manage to do so before the weekend ...)
> 
> (2) There are presently more than 800 open PRs, but less than 40 regressions
> that can be fixed during stage 4.

No problem, I was just checking. This is my first time using bugzilla, so I'm
happy to just sit back and observe (perhaps making the occasional comment). I
certainly don't want to get in anybody's way!

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe  ---
(In reply to howarth from comment #25)
> (In reply to Iain Sandoe from comment #19)
> 
> Are we going with this fix? If so. please post it to gcc-patches with a
> ChangeLog.

was posted 3rd Feb
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

[Bug ipa/65006] [5 Regression] 252.eon in SPEC CPU 2000 miscompiled with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5 Regression] 252.eon in   |[5 Regression] 252.eon in
   |SPEC CPU 2000 miscompiled   |SPEC CPU 2000 miscompiled
   ||with LTO

--- Comment #11 from H.J. Lu  ---
r220521 miscompiled 252.eon in SPEC CPU 2000 with LTO for both x86-32:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01063.html

and x32:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01047.html

X86-32 was fixed:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01417.html

But not:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01406.html

I got

[hjl@gnu-mic-2 0002]$ ../0002/eon_peak.lto chair.control.cook
chair.camera chair.surfaces chair.cook.ppm ppm pixels_out.cook
Segmentation fault
[hjl@gnu-mic-2 0002]$ gdb ../0002/eon_peak.lto
GNU gdb (GDB) Fedora 7.7.1-21.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../0002/eon_peak.lto...done.
(gdb) r chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/252.eon/run/0002/eon_peak.lto
chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook

Program received signal SIGSEGV, Segmentation fault.
0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.0.fc20.x32
libgcc-4.8.3-7.2.fc20.x86_64 libstdc++-4.8.3-7.2.fc20.x86_64
(gdb) bt
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
#1  0x004452d4 in eonImageCalculator::eonImageCalculator() ()
#2  0x0040378a in main ()
(gdb) f 0
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
(gdb) disass
Dump of assembler code for function _ZmlRK10ggSpectrumS1_:
   0x00420780 <+0>:movups (%esi),%xmm0
   0x00420784 <+4>:mov%rdi,%rax
   0x00420787 <+7>:movups 0x10(%esi),%xmm1
=> 0x0042078c <+12>:mulps  (%edx),%xmm0
   0x00420790 <+16>:mulps  0x10(%edx),%xmm1
   0x00420795 <+21>:movups %xmm0,(%edi)
   0x00420799 <+25>:movups %xmm1,0x10(%edi)
   0x0042079e <+30>:retq   
End of assembler dump.
(gdb) p $edx
$1 = -13304
(gdb) p/x $edx
$2 = 0xcc08

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #25 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #19)

Are we going with this fix? If so. please post it to gcc-patches with a
ChangeLog.

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
So fixed?

[Bug testsuite/64145] [5 Regression] gcc.dg/graphite/isl-codegen-loop-dumping.c UNRESOLVED after r217315.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
So fixed?

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> > AFAICT the ICE for the original test is as old as the first implementation
> > of unlimited polymorphism.
>
> In that case, should we remove the '[4.9/5 Regression]' tag from the summary 
> title?

Please don't do that.

(1) The ICE for the reduced test in comment 2 is a regression. Leave some time
to Janus to look at the problem:

> > > The ICE for the reduced test in comment 2 [...]
> > Started at r207986.
>
> Huh, that was me committing a patch for PR 60234. Guess I should take a look
> (but will probably not manage to do so before the weekend ...)

(2) There are presently more than 800 open PRs, but less than 40 regressions
that can be fixed during stage 4.

[Bug fortran/65079] -Werror= does not work on implicit-procedure warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.9. It works with trunk (5.0).

pr65079.f90:6:22:

 call bim()
  1
Error: Procedure 'bim' called at (1) is not explicitly declared
[-Werror=implicit-procedure]
pr65079.f90:11:12:

 use bar
1
Fatal Error: Can't open module file 'bar.mod' for reading at (1): No such file
or directory
f951: some warnings being treated as errors
compilation terminated.

I doubt this will be back ported to 4.9.

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 16 14:53:23 2015
New Revision: 220735

URL: https://gcc.gnu.org/viewcvs?rev=220735&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  

PR lto/65015
* varasm.c (default_file_start): For LTO produced units
emit  as file directive.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Finally fixed for 5.0 with reasonably backportable patches.

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 16 14:52:14 2015
New Revision: 220734

URL: https://gcc.gnu.org/viewcvs?rev=220734&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  

PR tree-optimization/63593
* tree-predcom.c (execute_pred_commoning_chain): Delay removing
stmts and releasing SSA names until...
(execute_pred_commoning): ... after processing all chains.

* gcc.dg/pr63593.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr63593.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Ah, if I hack up the preprocessed source, so that some functions like atoi,
gnu_dev_major etc. are __attribute__((__gnu_inline__)), I get 25 %esp
references both with latest trunk and 4.8.  So, I really can't reproduce...

[Bug fortran/65079] New: -Werror= does not work on implicit-procedure warning

[nathanael.huebbe at informatik dot uni-hamburg.de]

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

Bug ID: 65079
   Summary: -Werror= does not work on implicit-procedure warning
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.huebbe at informatik dot uni-hamburg.de

System: Ubuntu
Affected gfortran versions: at least 4.7.2 and 4.8.2

Description:
Compiling this fortran code

module bar
implicit none
contains
subroutine baz()
call bim()
end subroutine
end module

program foo
use bar

call baz()
end program

with the call

$ gfortran -c -Wimplicit-procedure -Werror=implicit-procedure foo.f90

correctly produces the warning, but fails to turn it into an error.

The behavior is the same if `-Wimplicit-procedure` is absent, and if
`implicit-procedure` is replaced by `-Wimplicit-interface`.

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|i?86-*-*|
 Status|WAITING |NEW
 CC||hubicka at gcc dot gnu.org
  Component|regression  |ipa
  Known to fail||5.0

--- Comment #7 from Markus Trippelsdorf  ---
markus@x4 tmp % cat fmgridif.ii
template  class A
{
  T *p;

public:
  A (T *p1) : p (p1) { p->acquire (); }
};

class B
{
public:
  virtual void acquire ();
};
class D : public B
{
};
class F : B
{
  int mrContext;
};
class WindowListenerMultiplexer : F, public D
{
  void
  acquire ()
  {
acquire ();
  }
};
class C
{
  void createPeer () throw ();
  WindowListenerMultiplexer maWindowListeners;
};
class FmXGridPeer
{
public:
  void addWindowListener (A);
} a;
void
C::createPeer () throw ()
{
  a.addWindowListener (&maWindowListeners);
}

markus@x4 tmp % g++ -Os -c fmgridif.ii && nm --demangle fmgridif.o | grep
WindowListenerMultiplexer
 U non-virtual thunk to WindowListenerMultiplexer::acquire()

markus@x4 tmp % g++ -O2 -c fmgridif.ii && nm --demangle fmgridif.o | grep
WindowListenerMultiplexer
 W WindowListenerMultiplexer::acquire()
0010 W non-virtual thunk to WindowListenerMultiplexer::acquire()

Not sure if the devirtualization is valid. Honza?

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Seems this has started with r216247, and indeed, compiling the testcase with
-std=gnu89 even with latest trunk results in those 25 %esp references, while
using -std=gnu11 even with r19 results in 69 %esp references.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> Similar to PR21182 ?
> 
> As suggested in the above PR, does "-fschedule-insns -fsched-pressure" make
> any difference?

No.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 Target||i?86-*-*
 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Seems LRA does a very bad job here for some reason.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Similar to PR21182 ?

As suggested in the above PR, does "-fschedule-insns -fsched-pressure" make any
difference?

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

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

4.8 has

  _62 = MEM[(__m64 * {ref-all})dest_284];
  _63 = VIEW_CONVERT_EXPR(_62);
  _64 = {_63, 0};
  _65 = VIEW_CONVERT_EXPR(_64);
  _66 = __builtin_ia32_punpcklbw128 (_65, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0 });
  _67 = VIEW_CONVERT_EXPR<__m128i>(_66);
  _68 = VIEW_CONVERT_EXPR(_67);
  _70 = __builtin_ia32_paddw128 (pretmp_327, _68);
  _71 = __builtin_ia32_packuswb128 (_70, _70);
  _72 = VIEW_CONVERT_EXPR<__m128i>(_71);
  _73 = __builtin_ia32_vec_ext_v2di (_72, 0);
  MEM[(long long int *)dest_284] = _73;

while 5

  _79 = MEM[(__m64 * {ref-all})dest_268];
  _78 = VIEW_CONVERT_EXPR(_79);
  _77 = {_78, 0};
  _74 = VIEW_CONVERT_EXPR(_77);
  _73 = __builtin_ia32_punpcklbw128 (_74, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0 });
  _69 = VIEW_CONVERT_EXPR(_73);
  _68 = _69 + pretmp_312;
  _67 = VIEW_CONVERT_EXPR(_68);
  _64 = __builtin_ia32_packuswb128 (_67, _67);
  _63 = VIEW_CONVERT_EXPR<__m128i>(_64);
  _62 = BIT_FIELD_REF <_63, 64, 0>;
  MEM[(long long int *)dest_268] = _62;

so some intrinsics are no longer builtins.  But the real difference is
the following weird store sequence

packuswb%xmm1, %xmm2
movaps  %xmm2, (%esp)
movl(%esp), %esi
movl4(%esp), %edi
movl%esi, (%eax)
movl%edi, 4(%eax)

compared to just

packuswb%xmm1, %xmm1
movq%xmm1, (%edx)

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 34782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34782&action=edit
test-case to reproduce

Options -m32 -msse2 -O3 must be used.

[Bug rtl-optimization/65078] New: [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ysrumyan at gmail dot com]

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

Bug ID: 65078
   Summary: [5.0 Regression] 4.9 and 5.0 generate more spill-fill
in comparison with 4.8.2
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

Using attached simple test-case extracted from codec we found out that 4.8.2
compiler generates more compact binaries in comparison with 4.9 & 5.0 compilers
('-O3 -msse2 -m32" options were used), for example 

grep -c "%esp" t1.4.8.2.s   
25
grep -c "%esp" t1.trunk.s   
75

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Created attachment 34781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34781&action=edit
untested patch

Patch which fixes the testcase and doesn't regress the vectorization testcase
from PR37021.

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

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

--- Comment #6 from Michael Stahl  ---
Created attachment 34780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34780&action=edit
manually minimized reproducer

to reproduce, build with:
 g++ -m32 -std=gnu++11 -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o