[Bug middle-end/66251] New: [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1484

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 66251
   Summary: [6 Regression] ICE in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1484
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

recent regression (last day): 

gcc version 6.0.0 20150522 (experimental) [trunk revision 223512] (GCC)

> cat bug.f90
SUBROUTINE dbcsr_data_convert (n)
  COMPLEX(KIND=4), DIMENSION(:), POINTER :: s_data_c
  COMPLEX(KIND=8), DIMENSION(:), POINTER :: t_data_z
  t_data_z(1:n) = CMPLX(s_data_c(1:n), KIND=8)
  CALL foo()
END SUBROUTINE dbcsr_data_convert

> gfortran -c -O3 bug.f90
bug.f90:1:0:

 SUBROUTINE dbcsr_data_convert (n)
^
internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1484
0xd97159 vect_get_vec_def_for_operand(tree_node*, gimple_statement_base*,
tree_node**)
../../gcc/gcc/tree-vect-stmts.c:1484
0xda51e3 vectorizable_store
../../gcc/gcc/tree-vect-stmts.c:5315
0xda7fbd vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*,
bool*, _slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:7466
0xdc6279 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3502
0xdc6a90 vect_schedule_slp(_loop_vec_info*, _bb_vec_info*)
../../gcc/gcc/tree-vect-slp.c:3572
0xdafdf7 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6165
0xdcea3e vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:502
Please submit a full bug report,

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[anders at sjogren dot info]

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

--- Comment #6 from Anders Sjögren  ---
An alternative test case, which also tests that the correct version is
selected, could be:

#include 

using expected_lvalue_res_t = int;
using expected_rvalue_res_t = double;

struct A {
  auto f() & {return expected_lvalue_res_t{};}
  auto f() && {return expected_rvalue_res_t{};}
};

void lvalue_assert()
{
  A a;
  a.f();
  static_assert(std::is_same::value,"");
}

void rvalue_assert()
{
  A{}.f();
  static_assert(std::is_same::value,"");
}

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[anders at sjogren dot info]

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

--- Comment #5 from Anders Sjögren  ---
A typo snuck in...
"However, as an l-value at the site of the call[...]"
should be
"However, a is an l-value at the site of the call[...]"

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[anders at sjogren dot info]

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

--- Comment #4 from Anders Sjögren  ---
Thanks for fixing the bug!

It seems that the test file
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/g%2B%2B.dg/cpp1y/pr60943.C?view=markup&pathrev=223502
contains an error.

It contains:
void Bar (A &&a)
{
  a.f ();
}

My guess is that it was meant to call the member function from an R-value
object a. However, as an l-value at the site of the call, and both Foo and Bar
will select the l-value version. Something like std::move(a).f() or just
A{}.f(); should do the trick.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gcc at robbertkrebbers dot nl]

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

--- Comment #31 from Robbert  ---
[oops, that was meant to be private, please remove my last comment]

[Bug c++/66067] [5/6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574

[jamrial at gmail dot com]

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

--- Comment #2 from James Almer  ---
Created attachment 35594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35594&action=edit
Preprocessed source as generated by -freport-bug, from the second test case

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[mail at robbertkrebbers dot nl]

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

--- Comment #30 from mail at robbertkrebbers dot nl ---
Hi Gil,

Nice example! I am a bit occupied lately, and thus have not read all 
comments at the bug report in detail. I will be away for the weekend, 
but will read those quickly after.

Robbert

On 05/22/2015 04:12 AM, gil.hur at sf dot snu.ac.kr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
>
> --- Comment #29 from Chung-Kil Hur  ---
> Dear Richard,
>
> This time, I think I constructed a real bug.
> Please have a look and correct me if I am wrong.
>
> =
> #include 
>
> int main() {
>int x = 0;
>uintptr_t xp = (uintptr_t) &x;
>uintptr_t i;
>
>for (i = 0; i < xp; i++) { }
>
>*(int*)xp = 15;
>
>printf("%d\n", x);
> }
> =
>
> This program prints "15" and I do not think this raises UB.
>
> Now I add an if-statement to the program.
>
> =
> #include 
>
> int main() {
>int x = 0;
>uintptr_t xp = (uintptr_t) &x;
>uintptr_t i;
>
>for (i = 0; i < xp; i++) { }
>
>/*** begin ***/
>if (xp != i) {
>  printf("hello\n");
>  xp = i;
>}
>/*** end ***/
>
>*(int*)xp = 15;
>
>printf("%d\n", x);
> }
> =
>
> This program just prints "0".
>
> Since "hello" is not printed, the if-statement is not executed.
> However, it prints a different result than before, which I think is a bug.
>

[Bug c++/66067] [5/6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574

[jamrial at gmail dot com]

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

James Almer  changed:

   What|Removed |Added

  Known to work|5.1.0   |
Summary|[6 Regression] tree check   |[5/6 Regression] tree check
   |ICE: accessed elt 1 of  |ICE: accessed elt 1 of
   |tree_vec with 0 elts in |tree_vec with 0 elts in
   |write_template_args, at |write_template_args, at
   |cp/mangle.c:2574|cp/mangle.c:2574
  Known to fail||5.1.1

--- Comment #1 from James Almer  ---
While the above file compiles with 4.9.2 and 5.1, the following file fails with
5.1 with a segmentation fault error in the same line (6.0 however also fails
with the tree check ICE).

In file included from
/home/jamrial/range-v3/include/range/v3/range_fwd.hpp:19:0,
 from /home/jamrial/range-v3/include/range/v3/begin_end.hpp:21,
 from /home/jamrial/range-v3/include/range/v3/core.hpp:17,
 from /home/jamrial/range-v3/test/algorithm/rotate.cpp:26:
/home/jamrial/range-v3/include/meta/meta.hpp: In instantiation of ‘constexpr
const size_t
meta::v1::detail::reverse_find_index_, 0>, meta::v1::defer >, std::integral_constant > > >, const
long int&>::i’:
/home/jamrial/range-v3/test/algorithm/rotate.cpp:278:1:   required from here
/home/jamrial/range-v3/include/meta/meta.hpp:1645:46: internal compiler error:
Segmentation fault
  static constexpr std::size_t i = List::size() -
reverse_find::size();

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

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

--- Comment #12 from asmwarrior  ---
Hi, I just did a test on the cygwin 32bit tool chain.
1, download the cygwin installer.
2, install  gcc-g++ 4.9.2 and boost 1.57 package
3, run the steps in comment 6, except that you don't need to add the
"-ID:\mingw-builds\boost_1_55_0" in the build command, because we can use the
boost library installed from the previous step. 
4, when building the pch files, I get a 318M pch.h.gch file
5, when building the object file, I get a 365K test.o file

So, this bug doesn't happen in the cygwin tool chain, and it looks like the bug
only happens in the MinGW and MinGW-W64 tool chain.

Any ideas what is the reason of this bug? Maybe, someone can supply a debug
version of g++, and let help to run under GDB.

[Bug target/66226] Incorrect code generation ppc, later assignment causes calling argument corruption

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
Both AIX and POSIX require that:

  In this hints structure, all members other than ai_flags, ai_eflags
ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer.

The program fails to set to zero the ai_addrlen member which causes the
function to fail (with both gcc and xlc).  Once ai_addrlen is set to zero, the
program behaves as you expect.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

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

--- Comment #29 from Chung-Kil Hur  ---
Dear Richard,

This time, I think I constructed a real bug.
Please have a look and correct me if I am wrong.

=
#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i;

  for (i = 0; i < xp; i++) { }

  *(int*)xp = 15;

  printf("%d\n", x);
}
=

This program prints "15" and I do not think this raises UB.

Now I add an if-statement to the program.

=
#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i;

  for (i = 0; i < xp; i++) { }

  /*** begin ***/
  if (xp != i) {
printf("hello\n");
xp = i;
  }
  /*** end ***/

  *(int*)xp = 15;

  printf("%d\n", x);
}
=

This program just prints "0".

Since "hello" is not printed, the if-statement is not executed.
However, it prints a different result than before, which I think is a bug.

[Bug c++/43486] Preserve variable-use locations

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Matthew Woehlke from comment #8)
> Can this *please* get fixed? This really hurts the ability to use
> -Wzero-as-null-ptr in particular. See
> https://bugreports.qt.io/browse/QTBUG-45291 for an example of the pain this
> causes.

Fixing this is hard. There are several ideas floating around but all of them
have their disadvantages
(https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01373.html and
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00164.html). Unless some new
brilliant contributor appears and starts passionately working on this, this is
not going to be fixed in the near (or medium) term. If you know such a person,
please let us know.

[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed

[jose.marchesi at oracle dot com]

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jose.marchesi at oracle dot com

--- Comment #10 from Jose E. Marchesi  ---
This problem is also seen in the the sparcv9-*-linux-gnu and
sparc64-*-linux-gnu builds.  Both builds pass that point after applying the
patch in #6, but then they break for what is apparently another problem.

[Bug c++/66210] Variable template specialization does not work with alias-declarations

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug c++/66210] Variable template specialization does not work with alias-declarations

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 21 22:39:32 2015
New Revision: 223506

URL: https://gcc.gnu.org/viewcvs?rev=223506&root=gcc&view=rev
Log:
2015-05-21  Paolo Carlini  

PR c++/66210
* g++.dg/cpp1y/var-templ28.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ28.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/66210] Variable template specialization does not work with alias-declarations

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Thanks Daniel, I'm adding a testcase and closing the bug.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #26 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #25)
> So, if I understand correctly ...
> - 4.9.something doesn't bootstrap because of something unknown
> - 5.something doesn't bootstrap because of c#19
> 
> ... right?

You are right.  I've missed the reason of debian 4.9.2-16 bootstrap
failure described in #c6.  It's a stage2/3 comparison failure of
gcc/d/ctfeexpr.dmd.o which means debian adds D lang to FSF GCC tree.
BTW, warnings for cc1*-checksum.o would mean that Adrian's board
enables randomize_va_space feature which I always make it disable
with 'sudo echo 0 >/proc/sys/kernel/randomize_va_space' on my GCC
work.  I don't know why/how debian packages D lang together with
the vanilla GCC.  It seems 4.9.2-16 could bootstrap without D lang.

[Bug c++/43486] Preserve variable-use locations

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||darlingm at gmail dot com

--- Comment #9 from Paolo Carlini  ---
*** Bug 66231 has been marked as a duplicate of this bug. ***

[Bug c++/66231] -Werror=zero-as-null-pointer-constant - errors on -isystem function default values of NULL

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Dup.

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

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 21 21:58:57 2015
New Revision: 223505

URL: https://gcc.gnu.org/viewcvs?rev=223505&root=gcc&view=rev
Log:
Allow indirect branch via GOT slot for x32

X32 doesn't support indirect branch via 32-bit memory slot since
indirect branch will load 64-bit address from 64-bit memory slot.
Since x32 GOT slot is 64-bit, we should allow indirect branch via GOT
slot for x32.

gcc/

PR target/66232
* config/i386/constraints.md (Bg): New constraint for GOT memory
operand.
* config/i386/i386.md (*call_got_x32): New pattern.
(*call_value_got_x32): Likewise.
* config/i386/predicates.md (GOT_memory_operand): New predicate.

gcc/testsuite/

PR target/66232
* gcc.target/i386/pr66232-1.c: New test.
* gcc.target/i386/pr66232-2.c: Likewise.
* gcc.target/i386/pr66232-3.c: Likewise.
* gcc.target/i386/pr66232-4.c: Likewise.
* gcc.target/i386/pr66232-5.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66232-1.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-2.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-3.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-4.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug other/66250] New: Can't adjust complex nor decimal floating point modes

[hjl.tools at gmail dot com]

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

Bug ID: 66250
   Summary: Can't adjust complex nor decimal floating point modes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

machmode.def has

/* Allow the target to specify additional modes of various kinds.  */
#if HAVE_EXTRA_MODES
# include EXTRA_MODES_FILE
#endif

/* Complex modes.  */
COMPLEX_MODES (INT);
COMPLEX_MODES (FLOAT);

/* Decimal floating point modes.  */
DECIMAL_FLOAT_MODE (SD, 4, decimal_single_format);
DECIMAL_FLOAT_MODE (DD, 8, decimal_double_format);
DECIMAL_FLOAT_MODE (TD, 16, decimal_quad_format);

We can't adjust any complex nor DFP modes in i386-modes.def since they
aren't available yet.  But we need to include i386-modes.def before

COMPLEX_MODES (INT);
COMPLEX_MODES (FLOAT);

to get extra modes. Should we add an EXTRA_ADJUSTMENTS_FILE and include it
after all modes are created?

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[sch...@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab  ---
This fixes the ICE both on aarch64 and m68k.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #25 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #24)
> 
> I am partially to be blamed for that. I initially reported the gcc-5 issue
> here, then saw gcc-4.9 failed to build as well and then assumed both were
> the same problem.

So, if I understand correctly ...
- 4.9.something doesn't bootstrap because of something unknown
- 5.something doesn't bootstrap because of c#19

... right?

Adrian, which compiler do you use to build the SH native compiler(s)?
Last time I've tried to do a native GCC 5 build on the SH4 debian box, vanilla
GCC would not build and I gave up.  Sorry for my impatience.

> But in any case, I am super happy you guys are fixing this. I will be back
> in Japan in October, so if I have a chance to meet either of you, I owe you
> some beer/sake/wine etc :).

Will trade beer for Mohnkuchen.
Will trade many other things for an SH4A-X4 8-core board with 2+ GB RAM.

[Bug c/66247] make check-gmp fails for gcc-5.1.0

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Matthew L. Martin from comment #3)
> The source code in question is downloaded as a prerequisite for building
> gcc-5.1.0 (gmp).
> 
> Where should I file a bug against the test?

Assuming you are using the antique GMP-4.3.2, simply don't. Scientists are
debating whether that release predates the extinction of dinosaurs.

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Propagate ref qualifier to new function type.

[Bug c++/60943] [C++14] Return type deduction interferes with ref-qualifiers

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Thu May 21 20:50:45 2015
New Revision: 223502

URL: https://gcc.gnu.org/viewcvs?rev=223502&root=gcc&view=rev
Log:
cp/
PR c++/60943
* decl2.c (change_return_type): Propagate FUNCTION_REF_QUALIFIED.

testsuite/
* g++.dg/cpp1y/pr60943.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60943.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66223] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[d.frey at gmx dot de]

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

--- Comment #2 from Daniel Frey  ---
I'm using Ubuntu 14.04 in a VM, packages are installed from
http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu trusty main. Package
version is 5.1.0-0ubuntu11~14.04.1

Output from g++-5 -v:

Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1) 

I'm compiling the example code with:

g++-5 -std=c++14 -O3 -Wall -Wextra t.cpp

I tried it without -O3 and it then prints the old output:

pure virtual method called
terminate called without an active exception
Aborted (core dumped)

So that probably means it has something to do with the optimizer?

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[miyuki at gcc dot gnu.org]

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

--- Comment #4 from Mikhail Maltsev  ---
Created attachment 35593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35593&action=edit
Proposed patch

Please try this patch. I tested it on the attached profile and it seems to fix
the ICE.

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The problem also occurs in gcc HEAD 6.0.0 20150521 (experimental).

[Bug c++/66210] Variable template specialization does not work with alias-declarations

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The problem seems to be fixed in gcc HEAD 6.0.0 20150521 (experimental).

[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 21 19:17:28 2015
New Revision: 223500

URL: https://gcc.gnu.org/viewcvs?rev=223500&root=gcc&view=rev
Log:
PR tree-optimization/66233
* match.pd (ocvt (icvt@1 @0)): Don't handle vector types.
Simplify.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr66233.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/65954] gcc segfaults on the following input with a syntax error

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Added expected diagnostic

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

Bug 66176 Summary: Handle conjg() in inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66176

   What|Removed |Added

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

[Bug fortran/66176] Handle conjg() in inline matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Actually closing.

[Bug fortran/66176] Handle conjg() in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Done, closing.

[Bug fortran/66176] Handle conjg() in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Thu May 21 19:00:45 2015
New Revision: 223499

URL: https://gcc.gnu.org/viewcvs?rev=223499&root=gcc&view=rev
Log:
2015-05-21  Thomas Koenig  

PR fortran/66176
* frontend-passes.c (check_conjg_variable):  New function.
(inline_matmul_assign):  Use it to keep track of conjugated
variables.

2015-05-21  Thomas Koenig  

PR fortran/66176
* gfortran.dg/inline_matmul_11.f90:  New test

Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/66241] [6 regression] [ARM] ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[vp at gcc dot gnu.org]

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

--- Comment #3 from Vidya Praveen  ---
And this change seems to be the cause:

Author: hubicka
Date: Sat May 16 20:51:50 2015
New Revision: 223252

URL: https://gcc.gnu.org/viewcvs?rev=223252&root=gcc&view=rev
Log:
* tree.c (verify_type_variant): Verify tree_base and type_common flags.
(verify_type): Verify STRING_FLAG.

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

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-21
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
(In reply to ktkachov from comment #3)
> Considering that the -O0 version is the only one that ends up calling the
> library functions, perhaps there's something wrong with your math library?
> I'm using newlib for arm-none-eabi

Or maybe the libm that is not using the correct ABI.  Since you did not place
how you built gcc, it is hard to tell right away.

[Bug c/66247] make check-gmp fails for gcc-5.1.0

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I think send a report to gmp-b...@gmplib.org.

[Bug c/65446] Improve -Wformat-signedness

[eblake at redhat dot com]

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

--- Comment #4 from Eric Blake  ---
Arguably, "%u" with short should warn, while "%hu" with short should not.  On
the other hand, if I use "%hu" with int, it is unclear to me whether I should
get a warning (the fact that I'm using %h to intentionally truncate the value
before it is printed, even though %hu and %hd print different values, makes it
hard to discern whether I have a mismatch).  But this does mean that whatever
changes are made to -Wformat-signedness, it should take into account the use of
%h range-limiting vs. pre-integer-promotion types.

[Bug c/66247] make check-gmp fails for gcc-5.1.0

[mlmar...@clearsky-data.com]

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

--- Comment #3 from Matthew L. Martin  ---
The source code in question is downloaded as a prerequisite for building
gcc-5.1.0 (gmp).

Where should I file a bug against the test?

[Bug target/66224] PowerPC _GLIBCXX_READ_MEM_BARRIER too weak

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
Author: dje
Date: Thu May 21 17:18:25 2015
New Revision: 223496

URL: https://gcc.gnu.org/viewcvs?rev=223496&root=gcc&view=rev
Log:
PR target/66224
* config/cpu/powerpc/atomic_word.h (_GLIBCXX_READ_MEM_BARRIER):
Don't use isync. Use lwsync if available.
* configure.host (atomic_word_dir) [aix[56789]*]: Delete to use
powerpc cpu definition.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/cpu/powerpc/atomic_word.h
trunk/libstdc++-v3/configure.host

[Bug c/66249] -Wformat-signedness should not warn on enums

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
-Wformat-signedness has many issues (which was the reason it's been pulled out
of -Wformat=2).

[Bug c/65446] Improve -Wformat-signedness

[eblake at redhat dot com]

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

--- Comment #3 from Eric Blake  ---
see also bug 66249 where the implementation-defined signedness of enums comes
into play, and where I argue that neither %d nor %u should warn when an enum
type is passed through varargs where the range of the enum is identical through
either format representation.

[Bug c/66249] New: -Wformat-signedness should not warn on enums

[eblake at redhat dot com]

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

Bug ID: 66249
   Summary: -Wformat-signedness should not warn on enums
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

The standard is clear that enums have implementation-defined signedness (C99
6.7.2.2P4 "Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the values of all
the members of the enumeration.").  However, while there is a way to force gcc
to use a smaller or larger type (-fshort-enums), I don't know how to force gcc
to use a signed or unsigned type for enums whose members could fit in either. 
As such, since I cannot guarantee that compiling on some other platform will
want to use a different signedness, I'm forced to add casts any time I want to
print an enum, when using the new -Wformat-signedness (implied by -Wformat=2).

Here's a demonstration of what I mean (testing on Fedora rawhide):

$ gcc --version | head -n1
gcc (GCC) 5.1.1 20150422 (Red Hat 5.1.1-1)
$ cat foo.c
#include 
int main(void) {
  int i = 0;
  unsigned u = 0;
  enum e_signed { as, bs = -1 } es = as;
  enum e_unsigned { au, bu = 0x } eu = au;
  enum e_implementation { ai } ei = ai;
  printf ("%u %d %u %d %u %d %u %d\n", i, u, es, es, eu, eu, ei, ei);
  return 0;
}
$ gcc -Wformat -Wformat-signedness foo.c -o foo
foo.c: In function ‘main’:
foo.c:8:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘int’ [-Wformat=]
   printf ("%u %d %u %d %u %d %u %d\n", i, u, es, es, eu, eu, ei, ei);
   ^
foo.c:8:11: warning: format ‘%d’ expects argument of type ‘int’, but argument 3
has type ‘unsigned int’ [-Wformat=]
foo.c:8:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 4 has type ‘int’ [-Wformat=]
foo.c:8:11: warning: format ‘%d’ expects argument of type ‘int’, but argument 7
has type ‘unsigned int’ [-Wformat=]
foo.c:8:11: warning: format ‘%d’ expects argument of type ‘int’, but argument 9
has type ‘unsigned int’ [-Wformat=]
[dummy@rawhide64 ~]$ 

The warning for arguments 2, 3, 4, and 7 are expected (2 and 3 to show the
normal usage of the warning, 4/5 to show that I can force an enum to be signed
by including negative members, 6/7 to show that I can force an enum to be
unsigned by including members larger than INT_MAX); and the lack of warning for
arguments 5 and 6 is good.  I can squelch the warning for the first four
problematic arguments by either using the correct %d vs. %u counterpart, or by
changing the signedness of the variable that I'm printing.

However, argument 8/9 is problematic.  From the compiler warning on argument 9,
it looks like gcc defaults to unsigned, at least on my platform.  But I
_cannot_ know whether the compiler will pick a signed or unsigned
representation for the enum on other platforms (since all members would fit in
either type, and since the platform ABI may demand a particular signedness), so
I cannot know whether %u or %d would trigger a warning because I picked the
wrong type.  My only recourse is to add a cast (such as "%d",(int)ei); but that
is ugly.

And look what happens when I add -fshort-enums to the mix:

$ gcc -fshort-enums -Wformat -Wformat-signedness foo.c -o foo
foo.c: In function ‘main’:
foo.c:8:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘int’ [-Wformat=]
   printf ("%u %d %u %d %u %d %u %d\n", i, u, es, es, eu, eu, ei, ei);
   ^
foo.c:8:11: warning: format ‘%d’ expects argument of type ‘int’, but argument 3
has type ‘unsigned int’ [-Wformat=]
foo.c:8:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but
argument 4 has type ‘int’ [-Wformat=]
foo.c:8:11: warning: format ‘%d’ expects argument of type ‘int’, but argument 7
has type ‘unsigned int’ [-Wformat=]
[dummy@rawhide64 ~]$ 

Here, arguments 4/5 are still signed, arguments 6/7 are still unsigned; but
arguments 8/9 are now a type compatible with 'char', and promotes to 'int'
(whether the enum's underlying type is signed or unsigned).  Oddly enough, the
compiler did not warn for EITHER 8 or 9, but by the technical argument, "%u"
should have warned for argument 8.  And consider what happens from a promotion
standpoint: if gcc picked 'char' (rather than 'signed char' or unsigned char')
as the underlying type when -fshort-enums is in effect, and my enum contained a
value in the range [128-255], then I am now dependent on whether 'char' is
signed or unsigned for whether %d will print 128 or -128 (and %u would print
128 or 4294967168).

Conversely, we should be able to reason that if the compiler was able to pick a
smaller type when -fshort-enums is in effect, a

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
FWIW I can't reproduce on a bare-metal arm-none-eabi trunk (i.e. future GCC 6)
With: -mcpu=cortex-a8 -march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mthumb-interwork -mfpu=neon -Wall -Wextra -mfloat-abi=soft prsqrt.c
-specs=rdimon.specs -lm

I get:
3.016621
3.016621
3.016621
3.016621

Note that I also had to add -lm to link the sqrt and sqrtf functions in.
Considering that the -O0 version is the only one that ends up calling the
library functions, perhaps there's something wrong with your math library?
I'm using newlib for arm-none-eabi

[Bug rtl-optimization/66248] New: subreg truncation not hoisted from loop

[jon at beniston dot com]

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

Bug ID: 66248
   Summary: subreg truncation not hoisted from loop
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jon at beniston dot com
  Target Milestone: ---

In the following code, where 'short' is 16-bits, on 32-bit processors
(ARM/MIPS/SPARC targets), the code that is generated to truncate the value of
the variable 'ret' to 16-bits (typically a shift left then right), appears in
each iteration of the loop.

short func(short *a, int y)
{
 short ret;
 int i;
 for(i = 0; i < y; i++) 
   ret += a[i];

 return ret;
}

E.g. on ARM at -O2/3:

.L3:
ldrhr2, [r0], #2
add r3, r2, r3
mov r3, r3, asl #16
cmp r0, r1
mov r3, r3, lsr #16
bne .L3


Should these not be hoisted out of the loop and only executed once before the
return?

[Bug c/66247] make check-gmp fails for gcc-5.1.0

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
The code has undefined behavior:

../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c:84:27: runtime error: index 6 out
of bounds for type 'const int [6]'

I believe here
for (oindex = 0; oindex <= (int) (sizeof (offset) / sizeof ((offset)[0]));
oindex++)
you need to change <= to <.

[Bug c/66247] make check-gmp fails for gcc-5.1.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
static const int offset[] = {
-2, -1, 0, 1, 2, 3
};
...
  for (oindex = 0; oindex <= (int) (sizeof (offset) / sizeof
((offset)[0])); oindex++)
{
  o = offset[oindex];
  if ((int) isize*(64 - 0) < -o)
continue;
(unless the test is exiting the loop through exit (1);) seems to be undefined
behavior, for offset[6] you can only validly takes its address, but not
dereference it.

[Bug c/60194] -Wformat should also warn when using %d (instead of %u) for unsigned arguments

[eblake at redhat dot com]

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

Eric Blake  changed:

   What|Removed |Added

 CC||eblake at redhat dot com

--- Comment #5 from Eric Blake  ---
See also bug 65446 for a possible hole in the -Wformat-signedness
implementation, when dealing with integer promotion.

[Bug c/66247] New: make check-gmp fails for gcc-5.1.0

[mlmar...@clearsky-data.com]

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

Bug ID: 66247
   Summary: make check-gmp fails for gcc-5.1.0
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mlmar...@clearsky-data.com
  Target Milestone: ---

Created attachment 35592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35592&action=edit
Preprocessor output

It appears that a pre-fetch at the bottom of a loop walks off the end of
addressable memory. Setting -fno-aggressive-loop-optimizations does change the
behavior by moving the loop comparison to the bottom of the loop and forcing
the next page to be allocated.

$ uname -a
Linux vm-mlmartin-5-1.clearsky-data.net 3.13.9-5.clearsky.el7.centos.x86_64 #1
SMP Wed Aug 6 21:22:34 BST 2014 x86_64 x86_64 x86_64 GNU/Linux

$ /home/mlmartin/gcc-5.1.0-build/./prev-gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/mlmartin/gcc-5.1.0-build/./prev-gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/opt/clearsky
--enable-languages=c,c++ --disable-multilib --with-system-zlib
Thread model: posix
gcc version 5.1.0 (GCC) 

$ pwd
/home/mlmartin/gcc-5.1.0-build/gmp/tests/mpz

$[mlmartin@vm-mlmartin-5-1 mpz]$ /home/mlmartin/gcc-5.1.0-build/./prev-gcc/xgcc
-B/home/mlmartin/gcc-5.1.0-build/./prev-gcc/
-B/opt/clearsky/x86_64-unknown-linux-gnu/bin/
-B/opt/clearsky/x86_64-unknown-linux-gnu/bin/
-B/opt/clearsky/x86_64-unknown-linux-gnu/lib/ -isystem
/opt/clearsky/x86_64-unknown-linux-gnu/include -isystem
/opt/clearsky/x86_64-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I../../../../gcc-5.1.0/gmp/tests/mpz -I../.. -I../../../../gcc-5.1.0/gmp
-I../../../../gcc-5.1.0/gmp/tests  -DNO_ASM  -Wall -Wextra  -fwrapv  -g -O2
-gtoggle -c ../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c -save-temps
In file included from ../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c:23:0:
../../../../gcc-5.1.0/gmp/gmp-impl.h: In function ‘mpn_toom33_mul_itch’:
../../../../gcc-5.1.0/gmp/gmp-impl.h:980:46: warning: unused parameter ‘bn’
[-Wunused-parameter]
 mpn_toom33_mul_itch (mp_size_t an, mp_size_t bn)
  ^
../../../../gcc-5.1.0/gmp/gmp-impl.h: In function ‘mpn_toom44_mul_itch’:
../../../../gcc-5.1.0/gmp/gmp-impl.h:989:46: warning: unused parameter ‘bn’
[-Wunused-parameter]
 mpn_toom44_mul_itch (mp_size_t an, mp_size_t bn)
  ^
../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c: In function ‘main’:
../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c:124:11: warning: unused parameter
‘argc’ [-Wunused-parameter]
 main (int argc, char *argv[])
   ^
../../../../gcc-5.1.0/gmp/tests/mpz/t-scan.c:124:23: warning: unused parameter
‘argv’ [-Wunused-parameter]
 main (int argc, char *argv[])
   ^
$ ./t-scan
Segmentation fault (core dumped)

[mlmartin@vm-mlmartin-5-1 mpz]$ gdb ./t-scan
core.t-scan.13359.vm-mlmartin-5-1.clearsky-data.net.1432223828 
GNU gdb (GDB) 7.8
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-unknown-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 ./t-scan...done.
[New LWP 13359]
Core was generated by `./t-scan'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00400f80 in check_ref ()
(gdb) disassemble
Dump of assembler code for function check_ref:
   0x00400e70 <+0>: push   %r15
   0x00400e72 <+2>: push   %r14
   0x00400e74 <+4>: push   %r13
   0x00400e76 <+6>: push   %r12
   0x00400e78 <+8>: push   %rbp
   0x00400e79 <+9>: push   %rbx
   0x00400e7a <+10>:mov$0x4153c4,%ebp
   0x00400e7f <+15>:sub$0x18,%rsp
   0x00400e83 <+19>:mov%rsp,%rdi
   0x00400e86 <+22>:callq  0x404b20 <__gmpz_init>
   0x00400e8b <+27>:xor%esi,%esi
   0x00400e8d <+29>:mov%rsp,%rdi
   0x00400e90 <+32>:callq  0x4053c0 <__gmpz_random2>
   0x00400e95 <+37>:mov$0xfffe,%esi
   0x00400e9a <+42>:nopw   0x0(%rax,%rax,1)
   0x00400ea0 <+48>:mov%esi,%eax
   0x00400ea2 <+50>:neg%eax
   0x00400ea4 <+52>:test   %eax,%eax
   0x00400ea6 <+54>:jg 0

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[matthew.thompson at nasa dot gov]

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

Matt Thompson  changed:

   What|Removed |Added

Version|4.9.1   |5.1.0

--- Comment #9 from Matt Thompson  ---
This bug is still present in 5.1.0 stable. Using the code in Comment #3, I see:

(350) $ gfortran --version
GNU Fortran (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

(351) $ gfortran test.F90
test.F90:23:0:

 GRIDIM => LocStream%Ptr%Tiling(:)%IM
 1
internal compiler error: Segmentation fault
0xa7efff crash_signal
../../gcc-5.1.0/gcc/toplev.c:383
0x6ff34a gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../gcc-5.1.0/gcc/fortran/trans-expr.c:7612
0x6cb196 trans_code
../../gcc-5.1.0/gcc/fortran/trans.c:1682
0x6eab63 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.1.0/gcc/fortran/trans-decl.c:5841
0x6ea9c7 gfc_generate_contained_functions
../../gcc-5.1.0/gcc/fortran/trans-decl.c:4979
0x6ea9c7 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.1.0/gcc/fortran/trans-decl.c:5765
0x688e60 translate_all_program_units
../../gcc-5.1.0/gcc/fortran/parse.c:5341
0x688e60 gfc_parse_file()
../../gcc-5.1.0/gcc/fortran/parse.c:5538
0x6c8315 gfc_be_parse_file
../../gcc-5.1.0/gcc/fortran/f95-lang.c:228
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/65446] Improve -Wformat-signedness

[eblake at redhat dot com]

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

Eric Blake  changed:

   What|Removed |Added

 CC||eblake at redhat dot com

--- Comment #2 from Eric Blake  ---
'unsigned short' promotes to 'int', not 'unsigned int', when passed through
var-args.  The warning is technically correct, but annoying, since all values
of 'unsigned short' are representable in both 'int' and in 'unsigned int',
therefore %d vs. %u won't ever have to deal with a negative value.

"%u" with signed 'short' should indeed warn, because that is a case where
promotion to 'int' differs from printing unsigned values.

"%x" with 1 should indeed warn, because that is passing 'int'.  Use "%x" with
1U if you want to avoid the warning.

[Bug c/66230] Using optimizations causes program to segfault

[gpnuma at centaurean dot com]

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

--- Comment #11 from gpnuma at centaurean dot com ---
(In reply to Markus Trippelsdorf from comment #10)
> (In reply to gpnuma from comment #8)
> > Thanks Markus I didn't think these alignment issues were actually the
> > problem, it goes a long way.
> > 
> > By doing memmoves instead of pointer cast allocations I got rid of the
> > segfault, but of course things are much slower... this "undefined behaviour"
> > is really treacherous !!
> > 
> > Is there any way to ensure proper alignment so I don't fall into this trap
> > and still benefit from maximum speed ?
> 
> I'm afraid there is no general recipe that would ensure proper alignment.
> But using memcpy hasn't necessary to be "much slower".
> And trading undefined behavior for a little more speed isn't a good idea in
> general.

Thanks, actually the code with __builtin_memmove is 30% slower compiled with
gcc 4.9.2 or 4.8 than it is with pointer cast allocations in 4.8 (4.9 can't say
because of the segfault).

However after testing with gcc 5.1 I had the pleasant surprise to see that it's
performing at the same speed as before, which means 30% faster than gcc 4.9.

30% faster is huge, you've obviously done a great job in the optimization
stages for 5.1 !

[Bug c++/61683] decltype-specifier not accepted as mem-initializer-id

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Patch here: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01948.html

[Bug middle-end/66241] [6 regression] [ARM] ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-none-linux-gnueabi,
   ||arm-none-eabi,arm-none-linu
   ||x-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 CC||ramana at gcc dot gnu.org
Summary|ICE: verify_type failed |[6 regression] [ARM] ICE:
   |while building libstdc++|verify_type failed while
   |(dwarfout.c:|building libstdc++
   |gen_type_die_with_usage())  |(dwarfout.c:
   ||gen_type_die_with_usage())
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed.

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

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  ---
(In reply to vehre from comment #7)
> Ah, ok, which opens the question why that isn't done?

Performance, for (very) big arrays.

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to H.J. Lu from comment #2)
> Created attachment 35585 [details]
> A patch
> 
> I am testing this.

It failed this:

[hjl@gnu-6 pr66232]$ cat x.c
extern void (*bar) (void);
void
foo (int n)
{
  int i;
  for (i = 0; i < n; i++)
{
  if (!bar)
continue;
  (*bar) ();
}
}
[hjl@gnu-6 pr66232]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc -fPIC -O -mx32 -S -o x.s x.c
x.c: In function ‘foo’:
x.c:12:1: error: unable to generate reloads for:
 }
 ^
(call_insn 17 15 18 5 (call (mem:QI (zero_extend:DI (reg/f:SI 87 [ D.1845 ]))
[0 *_6 S1 A8])
(const_int 0 [0])) x.c:10 651 {*call_x32}
 (expr_list:REG_DEAD (reg/f:SI 87 [ D.1845 ])
(nil))
(nil))
x.c:12:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3488
0xcf0c1e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/gnu/import/git/sources/gcc/gcc/rtl-error.c:110
0xbc6dec curr_insn_transform
/export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:3488
0xbc9c6c lra_constraints(bool)
/export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4436
0xbb6074 lra(_IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/lra.c:2317
0xb64a10 do_reload
/export/gnu/import/git/sources/gcc/gcc/ira.c:5412
0xb64dbe execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5583
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 pr66232]$

[Bug preprocessor/66246] PCH breaks preprocessor

[kai-bugs at cats dot ms]

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

--- Comment #1 from kai-bugs at cats dot ms ---
Created attachment 35591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35591&action=edit
Source

[Bug preprocessor/66246] New: PCH breaks preprocessor

[kai-bugs at cats dot ms]

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

Bug ID: 66246
   Summary: PCH breaks preprocessor
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kai-bugs at cats dot ms
  Target Milestone: ---

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

Test consists of:
- make sure we have no PCH
- compile the source w/o PCH
- compile the PCH
- compile the source w/PCH

As far as I can tell, the reason for the problems is that macros no longer get
expanded

If it matters, this is from the MinGW packaged with Qt 5.4.

$ cat t.sh
#! /bin/bash -x

gcc --version
rm th.hh.gch
g++ -Winvalid-pch -c -save-temps test.cc
g++ -x c++-header -c -save-temps th.hh
g++ -Winvalid-pch -c -save-temps test.cc

$ ./t.sh
+ gcc --version
gcc.exe (i686-posix-dwarf-rev2, Built by MinGW-W64 project) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ rm th.hh.gch
+ g++ -Winvalid-pch -c -save-temps test.cc
+ g++ -x c++-header -c -save-temps th.hh
+ g++ -Winvalid-pch -c -save-temps test.cc
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:13:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw_secapi.h:51:10: error:
redefinition of 'struct __if_array'
   struct __if_array  {
  ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:13:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw_secapi.h:51:10: error:
previous definition of 'struct __if_array'
   struct __if_array  {
  ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h: In function 'void
__debugbreak()':
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:657:101: error:
redefinition of 'void __debugbreak()'
 __MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
   
 ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:10:0,
 from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/_mingw.h:657:101: note: 'void
__debugbreak()' previously defined here
 __MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
   
 ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h: At global scope:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:159:16: error:
redefinition of 'struct localeinfo_struct'
 typedef struct localeinfo_struct {
^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:159:16: error:
previous definition of 'struct localeinfo_struct'
 typedef struct localeinfo_struct {
^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:18: error:
invalid type in declaration before ',' token
 } _locale_tstruct,*_locale_t;
  ^
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:18: error:
conflicting declaration 'typedef int _locale_tstruct'
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from th.hh:1:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:3: note:
previous declaration as 'typedef struct localeinfo_struct _locale_tstruct'
 } _locale_tstruct,*_locale_t;
   ^
In file included from
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/assert.h:15:0,
 from test.cc:4:
C:/Qt/Tools/mingw491_32/i686-w64-mingw32/include/crtdefs.h:162:20: error:
conflicting declaration 'typedef int* _locale_t'
 } _locale_tstruct,*_locale_t;
^
In 

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
(In reply to Maciej Andrzejewski from comment #1)
> It is getting even more interesting.
> 
> I have disassabled 4 binaries compiled with options:
> 1) -mfloat-abi=softfp
> 2) -mfloat-abi=softfp -O
> 3) -mfloat-abi=hard
> 4) -mfloat-abi=hard -O
> 
> and from what I understand if we turn ON the optimization the FPU is turned
> OFF!
> I dont see in assembler that FPU s** registers are used in those two cases
> where optimization is turned on:

Yeah it's called constant folding in the compiler. Why make the cpu do more
work at run time when the compiler can statically tell you the value for sqrt
of a floating point value. The cycles spent in compiling with -O have to give
you some value surely ... :)

I have no idea why your -O0 case fails though, offhand.

Ramana


> 
> -- DISASSAMBLE OPTION 1 --
> 00010570 :
>10570: e92d4800push{fp, lr}
>10574: e28db004add fp, sp, #4
>10578: e24dd040sub sp, sp, #64 ; 0x40
>1057c: e3032333movwr2, #13107  ; 0x
>10580: e3432333movtr2, #13107  ; 0x
>10584: e303movwr3, #13107  ; 0x
>10588: e3443022movtr3, #16418  ; 0x4022
>1058c: e14b20fcstrdr2, [fp, #-12]
>10590: ed5b0b03vldrd16, [fp, #-12]
>10594: eef77be0vcvt.f32.f64s15, d16
>10598: ee170a90vmovr0, s15
>1059c: eba1bl  10428 
>105a0: ee070a90vmovs15, r0
>105a4: eef70ae7vcvt.f64.f32d16, s15
>105a8: ed4b0b05vstrd16, [fp, #-20] ; 0xffec
>105ac: e30006ccmovwr0, #1740   ; 0x6cc
>105b0: e341movtr0, #1
>105b4: e14b21d4ldrdr2, [fp, #-20]  ; 0xffec
>105b8: eba0bl  10440 
>105bc: e309399amovwr3, #39322  ; 0x999a
>105c0: e3443111movtr3, #16657  ; 0x4111
>105c4: e50b3018str r3, [fp, #-24]  ; 0xffe8
>105c8: e51b0018ldr r0, [fp, #-24]  ; 0xffe8
>105cc: eb95bl  10428 
>105d0: ee070a90vmovs15, r0
>105d4: eef70ae7vcvt.f64.f32d16, s15
>105d8: ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
>105dc: e30006ccmovwr0, #1740   ; 0x6cc
>105e0: e341movtr0, #1
>105e4: e14b22d4ldrdr2, [fp, #-36]  ; 0xffdc
>105e8: eb94bl  10440 
>105ec: e3032333movwr2, #13107  ; 0x
>105f0: e3432333movtr2, #13107  ; 0x
>105f4: e303movwr3, #13107  ; 0x
>105f8: e3443022movtr3, #16418  ; 0x4022
>105fc: e14b22fcstrdr2, [fp, #-44]  ; 0xffd4
>10600: e14b02dcldrdr0, [fp, #-44]  ; 0xffd4
>10604: eb8abl  10434 
>10608: e14b03f4strdr0, [fp, #-52]  ; 0xffcc
>1060c: e30006ccmovwr0, #1740   ; 0x6cc
>10610: e341movtr0, #1
>10614: e14b23d4ldrdr2, [fp, #-52]  ; 0xffcc
>10618: eb88bl  10440 
>1061c: e309399amovwr3, #39322  ; 0x999a
>10620: e3443111movtr3, #16657  ; 0x4111
>10624: e50b3038str r3, [fp, #-56]  ; 0xffc8
>10628: ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
>1062c: eef70ae7vcvt.f64.f32d16, s15
>10630: ec510b30vmovr0, r1, d16
>10634: eb7ebl  10434 
>10638: e14b04f4strdr0, [fp, #-68]  ; 0xffbc
>1063c: e30006ccmovwr0, #1740   ; 0x6cc
>10640: e341movtr0, #1
>10644: e14b24d4ldrdr2, [fp, #-68]  ; 0xffbc
>10648: eb7cbl  10440 
>1064c: e3a03000mov r3, #0
>10650: e1a3mov r0, r3
>10654: e24bd004sub sp, fp, #4
>10658: e8bd8800pop {fp, pc}
> -- DISASSAMBLE OPTION 1 --
> 
> 
> 
> -- DISASSAMBLE OPTION 2 --
> 000104f4 :
>104f4: e92d40d0push{r4, r6, r7, lr}
>104f8: e30045d4movwr4, #1492   ; 0x5d4
>104fc: e3404001movtr4, #1
>10500: e3a06000mov r6, #0
>10504: e302720amovwr7, #8714   ; 0x220a
>10508: e3447008

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

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Ah, ok, which opens the question why that isn't done?

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

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin  ---
(In reply to vehre from comment #5)

For the interpretation of (intrinsic) assignment, you have to look at
7.2.1.3:

> The execution of the assignment shall have the same effect as if the
> evaluation of expr and the evaluation of all expressions in variable
> occurred before any portion of the variable is defined by the assignment

This, together with what you already quoted:

> Let's have a look at the standard (F2008, 12.8.2, last sentence):
> 
> In the array case, the values of the elements, if any, of the result are
> the same as would have been obtained if the scalar function had been applied
> separately, in array element order, to corresponding elements of each array
> actual argument.
> 

gives as interpretation:

((i)= plus(c(1), b(i)), i = 1, size(c))
(c(i) = (i), i=1,size(c))

which gives the same result as your second interpretation.

[Bug libgcc/66212] Exception handling broken on powerpc

[andri.yngvason at marel dot com]

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

Andri Yngvason  changed:

   What|Removed |Added

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

--- Comment #4 from Andri Yngvason  ---
I downloaded everything again and started from scratch. I've no idea what was
wrong but now the problem is gone. Mea culpa.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #24 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #23)
> Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
> patch should fix the original conftest.c issue, but debien 4.9-16 problem
> would be an another issue.  Sorry for my confusion.

I am partially to be blamed for that. I initially reported the gcc-5 issue
here, then saw gcc-4.9 failed to build as well and then assumed both were the
same problem.

But in any case, I am super happy you guys are fixing this. I will be back in
Japan in October, so if I have a chance to meet either of you, I owe you some
beer/sake/wine etc :).

Thanks!

[Bug target/51726] LTO and attribute 'selectany'

[jacek at codeweavers dot com]

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

Jacek Caban  changed:

   What|Removed |Added

 CC||jacek at codeweavers dot com

--- Comment #5 from Jacek Caban  ---
It seems like selectany is not supported at all in LTO:

$ cat selectany.c 
__attribute__((selectany)) int i = 0;

$ i686-w64-mingw32-gcc selectany.c selectany.c -flto -shared
/tmp/cchTGZVt.o (symbol from plugin):(.text+0x0): multiple definition of `i'
/tmp/ccAy2OzL.o (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Should I file separated bug?

[Bug fortran/66245] New: ICE on select type with empty type spec

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66245
   Summary: ICE on select type with empty type spec
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This test case with an empty type selector (type is) ...
   program p
  type t; end type
  class(t), allocatable :: x
  call s
   contains
  subroutine s
 select type ( x )
 type is ( )
 end select
  end
   end

and this variation (class is) ...
   program p
  type t; end type
  class(t), allocatable :: x
  call s
   contains
  subroutine s
 select type ( x )
 class is ( )
 end select
  end
   end

yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: gfc_get_default_type(): Bad symbol
'__tmp_UNKNOWN_0'

[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 Ever confirmed|0   |1

[Bug fortran/66244] New: ICE in lhd_set_decl_assembler_name

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 66244
   Summary: ICE in lhd_set_decl_assembler_name
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code snippet ...
   program p
  integer, target :: a(3)
  integer, pointer :: z => a(3)
  z = 0
  print *, z
   end

yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:179

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
The profile files differ in a few bytes.

  9  17 ^O   265 M-5
 10 217 M-^O  44 $
 11 323 M-S  301 M-A
 12 166 v165 u
 21 146 f376 M-~
 22 213 M-^K 233 M-^[
 23 166 v 32 ^Z
 24  14 ^L   107 G

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

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Let's have a look at the standard (F2008, 12.8.2, last sentence):

In the array case, the values of the elements, if any, of the result are
the same as would have been obtained if the scalar function had been applied
separately, in array element order, to corresponding elements of each array
actual argument.

How is this to be interpreted?

This way (pseudo-notation):

(c(i)= plus(c(1), b(i)), i = 1, size(c))

If like above, then the output would be

20, 27, 27, 27, 27

which is what is emitted, when the patch of comment #1 is not applied.

Or like this?

t = c(1)
(c(i) = plus(t, b(i)), i = 1, size(c))

which emits

20, 20, 20, 20, 20

But why is the second version expected, when one formulates this kind of
rhs/lhs dependency? I think the first example is covered by the standard, but I
am not happy with it, because it is not what I would expect, when writing the
code. 

So what do you think?
A third approach could be to add a warning for this kind of lhs/rhs dependency.
How hard would the analysis be?

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
Created attachment 35589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35589&action=edit
pr34999.gcda

[Bug rtl-optimization/66237] [6 regression] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE (internal compiler error)

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-21
   Assignee|unassigned at gcc dot gnu.org  |miyuki at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Mikhail Maltsev  ---
I could reproduce this ICE in somewhat "unnatural" conditions: profile is
generated by an x86_64 executable and used by aarch64 cross-compiler, but the
backtraces match, so I can start fixing it (and setting up QEMU...). If
possible, could you provide the actual profile (.gcda file) generated after
pr34999.x01 invocation? Does it differ from pristine build?

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

--- Comment #5 from chrbr at gcc dot gnu.org ---
ah I see, I was on the 4.8 where toggle_pr was indeed a single pattern.

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

--- Comment #4 from chrbr at gcc dot gnu.org ---
yes it's only for the SH4A fpchg case

[Bug target/65283] [SH] lds fpscr not put in delay slot

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Thanks for the pointer.

Still, if this
(define_attr "in_delay_slot" "yes,no"
 (eq_attr "type" "fpscr_toggle") (const_string "no")

is changed to "yes", the delay-branch will not consider multiple-set insns. 
The "toggle_pr" insn used to be a single set, but now is a multiple-set.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #23 from Kazumoto Kojima  ---
Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
patch should fix the original conftest.c issue, but debien 4.9-16 problem
would be an another issue.  Sorry for my confusion.

[Bug target/65283] [SH] lds fpscr not put in delay slot

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
this is a conservative limitation to avoid a ds schedule problem. 

this is because
(define_attr "in_delay_slot" "yes,no"
 (eq_attr "type" "fpscr_toggle") (const_string "no")

an old analysis (for reference) and regression test:
https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00746.html

[Bug fortran/66238] C/Fortran interoperability broken with -flto

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #0)
> When running the gfortran test suite with -flto, I get the following new
> failures since r223288
> 
I don't have updated to that revision, so that I can't check by myself, but
here are a few possible problems:

For proc_ptr_7, the procedure pointer argument has a variadic number of
arguments on the fortran side, and no argument on the C side.

For c_char_tests, a possible problem is the declaration of arguments as
  character(c_char), value :: foo
This declares a character of len c_char and default kind as far as I know.
According to
https://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Subroutines-and-Functions.html
the canonical declaration is rather:
  character(kind=c_char) :: foo(*)
With the value attribute, I don't know how it should be handled though.

[Bug c++/66243] New: enum class value is allowed to be initialized by value from other enum class

[Predelnik at gmail dot com]

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

Bug ID: 66243
   Summary: enum class value is allowed to be initialized by value
from other enum class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Predelnik at gmail dot com
  Target Milestone: ---

>From my understanding enum class values could be initialized by integer
constant expression (and thus by its own already defined values since they are
implicitly convertible to int in its scope). However g++ compiles the following
code where this value is taken from other completely unrelated enum class and
thus shouldn't be implicitly convertible to integer type in its scope.

enum class A
{
  X
};

enum class B
{
  X = A::X,
};

int main()
{
}

[Bug c/66219] The gcc generated section start/stop pointers become undefined when option -flto is used

[dscao999 at hotmail dot com]

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

--- Comment #2 from Cao Da Shi  ---
This issue poped up when cross compiling systemd-219. It is confirmed that the
missed section has the __attribute__((used)) declared. But still the link will
only pass without "-flto", with all other options exactly the same. The files
are too large to be sent. The link command is as follows:
arm-elf-linux-gnueabi-gcc -shared -Wl,-Map=/tmp/mymap.txt -fPIC -DPIC
pam_systemd_la-pam_systemd.o -Wl,--whole-archive libsystemd-internal.a
libsystemd-shared.a -Wl,--no-whole-archive -Wl,-rpath -lrt -lcap -lm
libpam_misc.so libpam.so -ldl -flto -O2 -Wl,--as-needed -Wl,--no-undefined
-Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now
-Wl,--version-script=pam_systemd.sym -pthread -Wl,-soname -Wl,pam_systemd.so -o
/tmp/pam_systemd.so

$ arm-elf-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-elf-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/cxpkg/cxarm/libexec/gcc/arm-elf-linux-gnueabi/4.8.4/lto-wrapper
Target: arm-elf-linux-gnueabi
Configured with: /home/dscao/build/native/gcc/gcc-4.8.4/configure
--prefix=/opt/cxpkg/cxarm --target=arm-elf-linux-gnueabi
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--with-tune=cortex-a8 --with-arch=armv7-a -with-mode=arm --with-float=hard
--with-fpu=vfp3 --disable-nls --with-system-zlib
--with-sysroot=/var/opt/cxroots/armroot --enable-languages=c,c++
--enable-checking=release --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.8.4 (GCC)

[Bug c++/66211] [5 Regression] Rvalue conversion in ternary operator causes internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] Rvalue |[5 Regression] Rvalue
   |conversion in ternary   |conversion in ternary
   |operator causes internal|operator causes internal
   |compiler error  |compiler error
  Known to fail||5.1.0

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu May 21 13:23:41 2015
New Revision: 223483

URL: https://gcc.gnu.org/viewcvs?rev=223483&root=gcc&view=rev
Log:
2015-05-21  Richard Biener  

PR c++/66211
* match.pd: Guard pattern optimzing (int)(float)int
conversions to apply only on GIMPLE.

* g++.dg/conversion/pr66211.C: New testcase.
* gcc.dg/tree-ssa/forwprop-18.c: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/conversion/pr66211.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-18.c

[Bug target/65283] [SH] lds fpscr not put in delay slot

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-21
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo  ---
BTW, the SH4A fpchg insn has the same problem.

[Bug c++/66211] [5 Regression] Rvalue conversion in ternary operator causes internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] Rvalue |[5 Regression] Rvalue
   |conversion in ternary   |conversion in ternary
   |operator causes internal|operator causes internal
   |compiler error  |compiler error
  Known to fail||5.1.0

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

[Bug ada/66242] Front-end error if exception propagation disabled

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 35588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35588&action=edit
Suggested patch

[Bug ada/66242] New: Front-end error if exception propagation disabled

[simon at pushface dot org]

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

Bug ID: 66242
   Summary: Front-end error if exception propagation disabled
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

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

First detected in GCC 4.9.1 built for arm-eabi on
x86_64-apple-darwin13 (Mac OS X Mavericks) with these pragmas on
System:

   pragma Profile (Ravenscar);
   pragma Restrictions (No_Enumeration_Maps);
   pragma Restrictions (No_Exception_Propagation);
   pragma Restrictions (No_Recursion);

Also observed with GCC 5.1.0, same build.

The demonstrators use

   pragma Restrictions (No_Exception_Propagation);
   with Ada.Finalization;
   package Fin is
  type F is new Ada.Finalization.Controlled with null record;
   end Fin;

and show the problem with the hosted compiler. There are two, because
only the first such error is detected.

(1) Unchecked deallocation

   with Ada.Finalization;
   with Ada.Unchecked_Deallocation;
   with Fin; use Fin;
   procedure Fin_Deallocation is

  type F_P is access F;
  procedure Delete
is new Ada.Unchecked_Deallocation (F, F_P);

  procedure Check_Heap_1 is
 An_F_P : F_P :=
   new F'(Ada.Finalization.Controlled with null record);
  begin
 Delete (An_F_P);
  end Check_Heap_1;

   begin
  Check_Heap_1;
   end Fin_Deallocation;

results in

17.procedure Check_Heap_1 is
18.   An_F_P : F_P :=
19. new F'(Ada.Finalization.Controlled with null record);
20.begin
21.   Delete (An_F_P);
  |
>>> "" is undefined

22.end Check_Heap_1;

The end of the -gnatdg output for Check_Heap_1 is

   begin
  if an_f_p /= null then
 B22b : begin
system__soft_links__abort_defer.all;
B23b : begin
   [constraint_error when
 an_f_p = null
 "access check failed"]
   [type T24b is procedure (object : in out fin__TfC)]
   [subtype T25b is access T24b]
   T25b!(fin__fH!(fin__TfC!(an_f_p.all)._tag).all (2)).all
 (fin__TfC!(an_f_p.all));
exception
   when others =>
  any id := true;<<<
end B23b;
 at end
system__standard_library__abort_undefer_direct;
 end B22b;
 free an_f_p;
 an_f_p := null;
 if  then
[program_error "finalize raised exception"]  <<<
 end if;
  end if;
   end check_heap_1;

which I take to mean that the compiler has tried to generate an
exception handler which is incompatible with pragma Restrictions
(No_Exception_Propagation).

I've traced this to exp_intr.adb, and written a patch which resolves
this problem.

(2) Returning a controlled type

I see also that in exp_ch7.adb all the cases where an exception
handler like this one might be generated are protected by a check for
No_Exception_Propagation, except for one at line 4751 in
Process_Transient_Objects. To demonstrate this,

   with Ada.Finalization;
   with Fin; use Fin;
   procedure Fin_Return_Controlled is
  type R is record
 A, B : F;
  end record;
  function Get_F return R is
  begin
 return (A => F'(Ada.Finalization.Controlled with null record),
 B => F'(Ada.Finalization.Controlled with null record));
  end Get_F;
  An_F : R;
   begin
  An_F := Get_F;
   end Fin_Return_Controlled;

fails as

 8. with Ada.Finalization;
 9. with Fin; use Fin;
10. procedure Fin_Return_Controlled is
11.type R is record
12.   A, B : F;
13.end record;
14.function Get_F return R is
15.begin
16.   return (A => F'(Ada.Finalization.Controlled with null record),
17.   B => F'(Ada.Finalization.Controlled with null record));
18.end Get_F;
19.An_F : R;
20. begin
21.An_F := Get_F;
   |
>>> "" is undefined

22. end Fin_Return_Controlled;

and the corresponding part of the -gnatdg output is

  B26b : declare
  begin
 B27b : begin
T25b := null;
fin_return_controlled__rDF (R18b.all, f => true);
 exception
when others =>
   any id := true;
 end B27b;
 if  then
[program_error "finalize raised exception"]
 end if;
  end B26b;

with the same symptoms.

I have a patch for this too.

The patches apply (with considerable offsets) to GCC 5.1.0, but I
haven't tested them yet (indeed, I've only tested in the arm-eabi
build).

[Bug middle-end/66241] ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[vp at gcc dot gnu.org]

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

--- Comment #1 from Vidya Praveen  ---
Created attachment 35586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35586&action=edit
preprocessed file to reproduce ICE

[Bug middle-end/66241] New: ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())

[vp at gcc dot gnu.org]

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

Bug ID: 66241
   Summary: ICE: verify_type failed while building libstdc++
(dwarfout.c: gen_type_die_with_usage())
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

I'm seeing this while building arm-none-linux-gnueabi/gnueabihf at the stage of
building libstdc++

[...]arm-none-linux-gnueabi/libc/usr/include/bits/types.h:134:30: internal
compiler error: verify_type failed
0xf3eb05 verify_type(tree_node const*)
/work/ws/fsf-trunk/src/gcc/gcc/tree.c:13257
0x942ab4 gen_type_die_with_usage
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20250
0x9414be gen_decl_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20987
0x93faf3 gen_member_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:19945
0x93faf3 gen_struct_or_union_type_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20038
0x93faf3 gen_tagged_type_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20227
0x9432c9 gen_type_die_with_usage
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20381
0x9414be gen_decl_die
/work/ws/fsf-trunk/src/gcc/gcc/dwarf2out.c:20987

This looks similar to bug 66214 but not sure if it's the same. Attaching a
preprocessed file that reproduces this with g++ -g -O0

[Bug target/54236] [SH] Improve addc and subc insn utilization

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
Author: olegendo
Date: Thu May 21 12:36:35 2015
New Revision: 223479

URL: https://gcc.gnu.org/viewcvs?rev=223479&root=gcc&view=rev
Log:
gcc/
PR target/54236
* config/sh/sh.md (*round_int_even): Reject pattern if operands[0] and
operands[1] are the same.

gcc/testsuite/
PR target/54236
* gcc.target/sh/pr54236-2.c: Fix typo in comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54236-2.c

[Bug c/29358] Warning issued two times with snprintf

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Note that my patch 
also fixes this issue.

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[hjl.tools at gmail dot com]

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

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

I am testing this.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

Summary|Multiple issues in  |[4.9/5/6 Regression] [SH]
   |conftest.c prevent build on |Wrong code is generated
   |sh4-linux-gnu   |with stage1 compiler

--- Comment #22 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #21)

OK, I'll commit your patch when all tests are done.
BTW, I'd like to change the summary of the PR to clarify that this is
a 4.9/5/6 regression.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-05-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Marek Polacek  ---
Suspending until then.

[Bug c/66240] New: RFE: extend -falign-xyz syntax

[vda.linux at googlemail dot com]

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

Bug ID: 66240
   Summary: RFE: extend -falign-xyz syntax
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vda.linux at googlemail dot com
  Target Milestone: ---

Experimentally, compilation with
-O2 -falign-functions=17 -falign-loops=17 -falign-jumps=17 -falign-labels=17
results in the following:
- functions are aligned using ".p2align 5,,16" asm directive
- loops/jumps/labels are aligned using ".p2align 5"

-Os -falign-functions=17 -falign-loops=17 -falign-jumps=17 -falign-labels=17
results in the following:
- functions are not aligned
- loops/jumps/labels are aligned using ".p2align 5"

Can this be improved so that in all cases, ".p2align 5,,16" is used? Shouldn't
be that hard...


Next step (what this RFE is all about). -falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment
runs fastest (he tried many other possibilites).

However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/2015 02:47 AM, Linus Torvalds wrote:
> At the same time, I have to admit that I abhor a 64-byte function
> alignment, when we have a fair number of functions that are (much)
> smaller than that.
> 
> Is there some way to get gcc to take the size of the function into
> account? Because aligning a 16-byte or 32-byte function on a 64-byte
> alignment is just criminally nasty and wasteful.

I propose the following: align function to 64-byte boundaries *IF* this does
not introduce huge amount of padding.

GNU as already has support for this:

.align N1,FILL,N3

"The third expression is also absolute, and is also optional.
If it is present, it is the maximum number of bytes that should
be skipped by this alignment directive."

So, what we want is to put something like ".align 64,,7"
before every function. 98% of functions in typical linux kernel have first
instruction 7 or fewer bytes long. Thus, with ".align 64,,7", calling any
function will at a minimum be able to fetch one insn in one L1 read, not two.
And this would be acheved with only ~3.5 bytes per function wasted to padding
on average, whereas ".align 64" would waste 31 byte on average.

Please extend -falign-foo=N syntax to, say, -falign-foo=N,M, which generates
".align M,,N-1" or equivalent.

[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]

[maciej.andrzejewski at data dot pl]

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

--- Comment #1 from Maciej Andrzejewski  ---
It is getting even more interesting.

I have disassabled 4 binaries compiled with options:
1) -mfloat-abi=softfp
2) -mfloat-abi=softfp -O
3) -mfloat-abi=hard
4) -mfloat-abi=hard -O

and from what I understand if we turn ON the optimization the FPU is turned
OFF!
I dont see in assembler that FPU s** registers are used in those two cases
where optimization is turned on:

-- DISASSAMBLE OPTION 1 --
00010570 :
   10570:   e92d4800push{fp, lr}
   10574:   e28db004add fp, sp, #4
   10578:   e24dd040sub sp, sp, #64 ; 0x40
   1057c:   e3032333movwr2, #13107  ; 0x
   10580:   e3432333movtr2, #13107  ; 0x
   10584:   e303movwr3, #13107  ; 0x
   10588:   e3443022movtr3, #16418  ; 0x4022
   1058c:   e14b20fcstrdr2, [fp, #-12]
   10590:   ed5b0b03vldrd16, [fp, #-12]
   10594:   eef77be0vcvt.f32.f64s15, d16
   10598:   ee170a90vmovr0, s15
   1059c:   eba1bl  10428 
   105a0:   ee070a90vmovs15, r0
   105a4:   eef70ae7vcvt.f64.f32d16, s15
   105a8:   ed4b0b05vstrd16, [fp, #-20] ; 0xffec
   105ac:   e30006ccmovwr0, #1740   ; 0x6cc
   105b0:   e341movtr0, #1
   105b4:   e14b21d4ldrdr2, [fp, #-20]  ; 0xffec
   105b8:   eba0bl  10440 
   105bc:   e309399amovwr3, #39322  ; 0x999a
   105c0:   e3443111movtr3, #16657  ; 0x4111
   105c4:   e50b3018str r3, [fp, #-24]  ; 0xffe8
   105c8:   e51b0018ldr r0, [fp, #-24]  ; 0xffe8
   105cc:   eb95bl  10428 
   105d0:   ee070a90vmovs15, r0
   105d4:   eef70ae7vcvt.f64.f32d16, s15
   105d8:   ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
   105dc:   e30006ccmovwr0, #1740   ; 0x6cc
   105e0:   e341movtr0, #1
   105e4:   e14b22d4ldrdr2, [fp, #-36]  ; 0xffdc
   105e8:   eb94bl  10440 
   105ec:   e3032333movwr2, #13107  ; 0x
   105f0:   e3432333movtr2, #13107  ; 0x
   105f4:   e303movwr3, #13107  ; 0x
   105f8:   e3443022movtr3, #16418  ; 0x4022
   105fc:   e14b22fcstrdr2, [fp, #-44]  ; 0xffd4
   10600:   e14b02dcldrdr0, [fp, #-44]  ; 0xffd4
   10604:   eb8abl  10434 
   10608:   e14b03f4strdr0, [fp, #-52]  ; 0xffcc
   1060c:   e30006ccmovwr0, #1740   ; 0x6cc
   10610:   e341movtr0, #1
   10614:   e14b23d4ldrdr2, [fp, #-52]  ; 0xffcc
   10618:   eb88bl  10440 
   1061c:   e309399amovwr3, #39322  ; 0x999a
   10620:   e3443111movtr3, #16657  ; 0x4111
   10624:   e50b3038str r3, [fp, #-56]  ; 0xffc8
   10628:   ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
   1062c:   eef70ae7vcvt.f64.f32d16, s15
   10630:   ec510b30vmovr0, r1, d16
   10634:   eb7ebl  10434 
   10638:   e14b04f4strdr0, [fp, #-68]  ; 0xffbc
   1063c:   e30006ccmovwr0, #1740   ; 0x6cc
   10640:   e341movtr0, #1
   10644:   e14b24d4ldrdr2, [fp, #-68]  ; 0xffbc
   10648:   eb7cbl  10440 
   1064c:   e3a03000mov r3, #0
   10650:   e1a3mov r0, r3
   10654:   e24bd004sub sp, fp, #4
   10658:   e8bd8800pop {fp, pc}
-- DISASSAMBLE OPTION 1 --



-- DISASSAMBLE OPTION 2 --
000104f4 :
   104f4:   e92d40d0push{r4, r6, r7, lr}
   104f8:   e30045d4movwr4, #1492   ; 0x5d4
   104fc:   e3404001movtr4, #1
   10500:   e3a06000mov r6, #0
   10504:   e302720amovwr7, #8714   ; 0x220a
   10508:   e3447008movtr7, #16392  ; 0x4008
   1050c:   e1a4mov r0, r4
   10510:   e1a02006mov r2, r6
   10514:   e1a03007mov r3, r7
   10518:   eba9bl  103c4 
   1051c:   e1a4mov r0, r4
   10520:   e1a02006mov r2, r6
   10524:   e1a03007mov r3, r7
   10528:   eba5bl  103c4 
   1052c:   e1a4mov r0, r4
   10530:   e30f2d38movwr2, #64824  ; 0xfd38
   10534:   e34f2ea1movtr2, #65185  ; 0xfea1
   10538:   e3023209movwr3, #8713   ; 0x2209
   

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Thomas Preud'homme from comment #3)
> Alternatively, you can try the patch proposed at [1] and see if it fixes the
> issue you're facing since it seems to be the same one.
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01901.html

Thomas,

yes the referred patch also fixes this issue.

Thanks!

[Bug c/66230] Using optimizations causes program to segfault

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to gpnuma from comment #8)
> Thanks Markus I didn't think these alignment issues were actually the
> problem, it goes a long way.
> 
> By doing memmoves instead of pointer cast allocations I got rid of the
> segfault, but of course things are much slower... this "undefined behaviour"
> is really treacherous !!
> 
> Is there any way to ensure proper alignment so I don't fall into this trap
> and still benefit from maximum speed ?

I'm afraid there is no general recipe that would ensure proper alignment.
But using memcpy hasn't necessary to be "much slower".
And trading undefined behavior for a little more speed isn't a good idea in
general.

[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Alternatively, you can try the patch proposed at [1] and see if it fixes the
issue you're facing since it seems to be the same one.

[1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01901.html

Best regards.