[Bug target/58158] internal compiler error: in extract_insn, at recog.c:2150 while compiling ImageMagick on mipsel

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug tree-optimization/58164] internal compiler error: in make_decl_rtl, at varasm.c:1147

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58164

--- Comment #2 from Marek Polacek  ---
Similar invalid testcase.

void
foo (void)
{
  int y;
  goto *&y;
}

[Bug objc/57428] Objective C exceptions completely broken in gcc 4.7

[alp at rsu dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57428

Alexander Pyhalov  changed:

   What|Removed |Added

 CC||alp at rsu dot ru

--- Comment #1 from Alexander Pyhalov  ---
I see the similar crash on OpenIndiana (Solaris) with self-compiled gcc 4.7.3.

$ gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.7/lib/gcc/i386-pc-solaris2.11/4.7.3/lto-wrapper
Target: i386-pc-solaris2.11
Configured with:
/export/home/alp/srcs/oi-userland/components/gcc47/gcc-4.7.3/configure
CC=/usr/gcc/4.7/bin/gcc CXX=/usr/gcc/4.7/bin/g++ --prefix=/usr/gcc/4.7
--mandir=/usr/gcc/4.7/share/man --bindir=/usr/gcc/4.7/bin
--libdir=/usr/gcc/4.7/lib --sbindir=/usr/gcc/4.7/sbin
--sbindir=/usr/gcc/4.7/bin --libdir=/usr/gcc/4.7/lib
--libexecdir=/usr/gcc/4.7/lib --host i386-pc-solaris2.11 --build
i386-pc-solaris2.11 --target i386-pc-solaris2.11
--with-boot-ldflags=-R/usr/gcc/4.7/lib --enable-plugins --enable-objc-gc
--enable-languages=c,c++,fortran,lto,objc --enable-ld=no --with-as=/usr/bin/gas
--with-gnu-as --with-build-time-tools=/usr/gnu/i386-pc-solaris2.11/bin
--disable-libitm LDFLAGS=-R/usr/gcc/4.7/lib
Thread model: posix
gcc version 4.7.3 (GCC) 

$ ./test 
Segmentation Fault (core dumped)
$ gdb test core 
GNU gdb 6.8
Copyright (C) 2008 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 "i386-pc-solaris2.11"...
(no debugging symbols found)
Reading symbols from /usr/lib/libobjc.so.4...done.
Loaded symbols for /usr/lib/libobjc.so.4
Reading symbols from /usr/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.1...done.
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
[New process 90521]
#0  0xfef5e6ae in __objc_forward (object=0x8061620, sel=0x80617d4,
args=0x8047d20) at
/export/home/alp/srcs/oi-userland/components/gcc47/gcc-4.7.3/libobjc/sendmsg.c:1127
1127}
(gdb) bt
#0  0xfef5e6ae in __objc_forward (object=0x8061620, sel=0x80617d4,
args=0x8047d20) at
/export/home/alp/srcs/oi-userland/components/gcc47/gcc-4.7.3/libobjc/sendmsg.c:1127
#1  0xfef5f2a1 in __objc_word_forward (rcv=0x8061620, op=0x80617d4) at
/export/home/alp/srcs/oi-userland/components/gcc47/gcc-4.7.3/libobjc/sendmsg.c:1127
#2  0x08051128 in proc ()
#3  0x0805115a in foo ()
#4  0x080511c2 in main ()

[Bug tree-optimization/58164] internal compiler error: in make_decl_rtl, at varasm.c:1147

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58164

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-15
 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.7.3, 4.8.1, 4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.  With trunk:

c.c: In function ‘main’:
c.c:1:22: warning: initialization from incompatible pointer type [enabled by
default]
 int main(){ int* ptr=main; goto *&ptr; }
  ^
c.c:1:1: error: address taken, but ADDRESSABLE bit not set
 int main(){ int* ptr=main; goto *&ptr; }
 ^
ptr
cc1: note: in statement
goto &ptr;
c.c:1:1: internal compiler error: verify_gimple failed
0x959e09 verify_gimple_in_cfg(function*)
/home/marek/src/gcc/gcc/tree-cfg.c:4824
0x8847e4 execute_function_todo
/home/marek/src/gcc/gcc/passes.c:1816
0x8850dc execute_todo
/home/marek/src/gcc/gcc/passes.c:1849
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/58164] New: internal compiler error: in make_decl_rtl, at varasm.c:1147

[dirtyepic at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58164

Bug ID: 58164
   Summary: internal compiler error: in make_decl_rtl, at
varasm.c:1147
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dirtyepic at gentoo dot org

$ cat t.c 
int main(){ int* ptr=main; goto *&ptr; }

$ gcc-4.8.1 -O2 -v t.c
Using built-in specs.
COLLECT_GCC=gcc-4.8.1
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.1/work/gcc-4.8.1/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-cloog --disable-isl-version-check --enable-lto
--disable-nls --with-system-zlib --enable-obsolete --disable-werror
--enable-secureplt --enable-multilib --with-multilib-list=m32,m64
--disable-libmudflap --disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--disable-libquadmath --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.1 p1.0, pie-0.5.6'
Thread model: posix
gcc version 4.8.1 (Gentoo 4.8.1 p1.0, pie-0.5.6) 
COLLECT_GCC_OPTIONS='-O2' '-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/cc1 -quiet -v t.c -quiet -dumpbase
t.c -mtune=generic -march=x86-64 -auxbase t -O2 -version -o /tmp/ccqyPQax.s
GNU C (Gentoo 4.8.1 p1.0, pie-0.5.6) version 4.8.1 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
GNU C (Gentoo 4.8.1 p1.0, pie-0.5.6) version 4.8.1 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 648cea0d1e5918add0977fdeaec87cfb
t.c: In function 'main':
t.c:1:22: warning: initialization from incompatible pointer type [enabled by
default]
 int main(){ int* ptr=main; goto *&ptr; }
  ^
t.c:1:5: internal compiler error: in make_decl_rtl, at varasm.c:1147
 int main(){ int* ptr=main; goto *&ptr; }
 ^

---
or:

$ cat t.c 
int main(){ int ptr=main; goto *&ptr; }

$ gcc-4.8.1 -O2 t.c
t.c: In function 'main':
t.c:1:21: warning: initialization makes integer from pointer without a cast
[enabled by default]
 int main(){ int ptr=main; goto *&ptr; }
 ^
t.c:1:5: internal compiler error: in make_decl_rtl, at varasm.c:1147
 int main(){ int ptr=main; goto *&ptr; }
 ^

---

Fails since at least 4.5.4 -> 4.8 head.  Didn't test trunk.

[Bug libstdc++/58163] [C++11] Pedantic assert on str[str.size()] is wrong in C++11

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163

--- Comment #3 from Paul Pluzhnikov  ---
The fix:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7e66313066525b0ce38e140e6d9c815e19d119bf

I don't believe the test is quite correct:

+// { dg-options "-std=gnu++11 -D_GLIBCXX_DEBUG_PEDANTIC" }

I don't get the assertion (pre-patch) unless I give *both*

  -D_GLIBCXX_DEBUG_PEDANTIC *and* -D_GLIBCXX_DEBUG

[Bug libstdc++/58163] [C++11] Pedantic assert on str[str.size()] is wrong in C++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug target/58160] Power8 fusion support has a bug that shows up in running spec 2006

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58160

--- Comment #3 from Michael Meissner  ---
I forgot to mention, with this patch, I have built and successfully run 403.gcc
and 435.gromacs using the -O2 -m32 -mcpu=power7 -mtune=power8 options that
broke 403.gcc, and also with the -O3 -funroll-loops -m32 -mcpu=power7
-mtune=power8 that broke 435.gromacs.

[Bug target/58160] Power8 fusion support has a bug that shows up in running spec 2006

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58160

--- Comment #2 from Michael Meissner  ---
Created attachment 30659
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30659&action=edit
Proposed patch to fix problem

[Bug libstdc++/58163] [C++11] Pedantic assert on str[str.size()] is wrong in C++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-14
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

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

[Bug libstdc++/58163] New: [C++11] Pedantic assert on str[str.size()] is wrong in C++11

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163

Bug ID: 58163
   Summary: [C++11] Pedantic assert on str[str.size()] is wrong in
C++11
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref b/10322506

/// --- cut ---
#include 

int main()
{
  const std::string cs;
std::string  s;

  if (cs[0] != '\0') return 1;
  if (s[0] != '\0') return 2;

  return 0;
}
/// --- cut ---

Using trunk gcc g++ (GCC) 4.9.0 20130814 (experimental)

g++ -g t.cc -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_DEBUG -std=c++11 && ./a.out
/gcc-svn-install/include/c++/4.9.0/bits/basic_string.h:848:
std::basic_string<_CharT, _Traits, _Alloc>::reference std::basic_string<_CharT,
_Traits, _Alloc>::operator[](std::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator; std::basic_string<_CharT, _Traits,
_Alloc>::reference = char&; std::basic_string<_CharT, _Traits,
_Alloc>::size_type = long unsigned int]: Assertion '__pos < size()' failed.

In C++98:

21.3.4 basic_string element access [lib.string.access]

const_reference operator[](size_type pos) const;
reference operator[](size_type pos);

Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(),
the const version returns charT().

Otherwise, the behavior is undefined.  <<== PEDASSERT catches this.


However, in C++11:

21.4.5 basic_string element access [string.access]

const_reference operator[](size_type pos) const;
reference operator[](size_type pos);

Requires: pos <= size().

Returns: *(begin() + pos) if pos < size(), otherwise a reference to an object
of type T with value charT(); the referenced value shall not be modied.


Note removal of undefined behavior.

gcc-bugs@gcc.gnu.org

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58162

Bug ID: 58162
   Summary: [C++11] bogus error: use of deleted function
'constexpr A::A(const A&)'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref b/10272620

/// --- cut ---
struct A {
 A();
 A(A&&);
};

struct B {
 A const a = A();
};

B b;
/// --- cut ---

Using trunk: g++ (GCC) 4.9.0 20130814 (experimental)

g++ -c -std=c++11 t.cc
t.cc: In constructor ‘constexpr B::B()’:
t.cc:6:8: error: use of deleted function ‘constexpr A::A(const A&)’
 struct B {
^
t.cc:1:8: note: ‘constexpr A::A(const A&)’ is implicitly declared as deleted
because ‘A’ declares a move constructor or move assignment operator
 struct A {
^
t.cc: At global scope:
t.cc:10:3: note: synthesized method ‘constexpr B::B()’ first required here 
 B b;
   ^


Analysys by jdennett

  This is under 8.5p17 (via other sections... 9.2[Class Members]p4 leads
  to 12.6.2, and 12.6.2p8 says "if the entity is a non-static data member
  that has a brace-or-equal-initializer, the entity is initialized as
  specified in 8.5"), and (I believe) should be the same initialization
  as for a local variable declared as

A const a = A();

  (All references above are in the C++14 CD.)

  8.5p17 says:

  "If the destination type is a (possibly cv-qualified) class type:
  — If the initialization is direct-initialization, or if it is
  copy-initialization where the cv-unqualified version of the source type
  is the same class as, or a derived class of, the class of the destination,
  constructors are considered."

  We're in the case of copy-initialization where the cv-unqualified
  version of the source type is A, and the destination type is "const A",
  but arguably "the class of the destination" is A (because const A isn't
  a class).

  So I believe that this should fall into the same case as
  direct-initialization, overload resolution should pick the A::A(A&&)
  move constructor, and all should be good.

  Wild guesses about how this might go wrong in the compiler:

  It might be that G++ is checking whether the cv-unqualified version of
  the source type is the same as the destination type (rather than the same
  as the cv-unqualified version of the destination type, which is the class
  here).  If so, it would fall into the main case of copy-initialization,
  which creates a temporary of the target type.  That should still work,
  but if the temporary were (incorrectly) considered to be a "const A"
  rather than an "A" then initializing from it would attempt to use the
  (deleted) copy constructor.

  Seeing if changing A(A&&) to A(A const&&) changes anything might be
  informative, or having both overloads present.


Changing 'A(A&&);' to 'A(const AA&&);' or adding it as overload does fix
the compilation problem.

Further patch from jdennett:

With the following hack, the testcase compiles.

$ svn diff gcc
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 201651)
+++ gcc/cp/parser.c (working copy)
@@ -23002,7 +23002,10 @@
 if (BRACE_ENCLOSED_INITIALIZER_P (parsed_arg)
 && CONSTRUCTOR_IS_DIRECT_INIT (parsed_arg))
   flags = LOOKUP_NORMAL;
- parsed_arg = digest_init_flags (TREE_TYPE (decl), parsed_arg, flags);
+ // TODO(jdennett): Something better than this, and work out how
+ // to test it.
+ parsed_arg = digest_init_flags (TYPE_MAIN_VARIANT (TREE_TYPE (decl)),
+ parsed_arg, flags);
   }
}

[Bug c++/51912] [C++11] G++ accepts floating point case labels

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51912

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug c++/58161] internal compiler error while compiling SemaDeclCXX.cpp

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58161

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing.

[Bug fortran/58146] Array slice bounds checking

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146

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

> Technically a(n+1:n+4) is within the bounds, the out of bounds comes from
> the loop with a 5-sized array.

The array expressions are not conformable, so it is a bounds
error either way.

[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143

Mikael Pettersson  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||mikpe at it dot uu.se

--- Comment #3 from Mikael Pettersson  ---
This wrong-code started with the PR54937 patch in r192710.  Author CC:d.

[Bug c++/58161] internal compiler error while compiling SemaDeclCXX.cpp

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58161

Andrew Pinski  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #2 from Andrew Pinski  ---
(In reply to SebastiansPublicAddress from comment #0)
> I'm compiling on a raspberry pi (no cross compiling), so this may be caused
> by insufficient memory. But gcc doesn't say so. It just says
> 
> g++-4.7: internal compiler error: Killed (program cc1plus)

That is because the kernel is killing cc1plus when it runs out of memory when a
mmap/malloc happens.  There is not much GCC can do when the kernel decides to
over commit memory to the application and then decides to kill it due to lack
of memory.

[Bug c++/58161] internal compiler error while compiling SemaDeclCXX.cpp

[SebastiansPublicAddress at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58161

--- Comment #1 from SebastiansPublicAddress at googlemail dot com ---
Created attachment 30658
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30658&action=edit
preprocessed file compressed because of file size limit

[Bug c++/58161] New: internal compiler error while compiling SemaDeclCXX.cpp

[SebastiansPublicAddress at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58161

Bug ID: 58161
   Summary: internal compiler error while compiling
SemaDeclCXX.cpp
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SebastiansPublicAddress at googlemail dot com

I'm compiling on a raspberry pi (no cross compiling), so this may be caused by
insufficient memory. But gcc doesn't say so. It just says

g++-4.7: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The full commandline:

g++-4.7 -I/home/pi/projects/llvm/llvm-3.3.build/include
-I/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema
-I/home/pi/projects/llvm/llvm-3.3.src/include
-I/home/pi/projects/llvm/llvm-3.3.src/tools/clang/lib/Sema  -D_DEBUG
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/home/pi/projects/llvm/llvm-3.3.src/tools/clang/lib/Sema/../../include
-I/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema/../../include -O3
-fomit-frame-pointer -fvisibility-inlines-hidden -fno-exceptions -fno-rtti
-fPIC -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing-pedantic
-Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings   
-Wno-maybe-uninitialized -Wno-missing-field-initializers -c -MMD -MP -MF
"/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema/Release+Asserts/SemaDeclCXX.d.tmp"
-MT
"/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema/Release+Asserts/SemaDeclCXX.o"
-MT
"/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema/Release+Asserts/SemaDeclCXX.d"
/home/pi/projects/llvm/llvm-3.3.src/tools/clang/lib/Sema/SemaDeclCXX.cpp -o
/home/pi/projects/llvm/llvm-3.3.build/tools/clang/lib/Sema/Release+Asserts/SemaDeclCXX.o

$ g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.7/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--disable-libitm --enable-plugin --enable-objc-gc --disable-sjlj-exceptions
--with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5+rpi1)

[Bug target/58160] Power8 fusion support has a bug that shows up in running spec 2006

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58160

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-14
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Michael Meissner  ---
In looking at the code for 403.gcc, the compiler spills the addis value to the
stack and then reloads it later.  It would be more optimal to just redo the
addis value.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #5 from Paul Pluzhnikov  ---
Google ref b/6572217

[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #8 from Bill Schmidt  ---
Fixed as r201750.

[Bug middle-end/58145] [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 14 20:34:56 2013
New Revision: 201748

URL: http://gcc.gnu.org/viewcvs?rev=201748&root=gcc&view=rev
Log:
PR tree-optimization/58145
* tree-sra.c (build_ref_for_offset): If prev_base has
TREE_THIS_VOLATILE or TREE_SIDE_EFFECTS, propagate it to MEM_REF.

* gcc.dg/pr58145-1.c: New test.
* gcc.dg/pr58145-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr58145-1.c
trunk/gcc/testsuite/gcc.dg/pr58145-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

Author: jakub
Date: Wed Aug 14 20:36:12 2013
New Revision: 201749

URL: http://gcc.gnu.org/viewcvs?rev=201749&root=gcc&view=rev
Log:
PR tree-optimization/58145
* tree-sra.c (build_ref_for_offset): If prev_base has
TREE_THIS_VOLATILE or TREE_SIDE_EFFECTS, propagate it to MEM_REF.

* gcc.dg/pr58145-1.c: New test.
* gcc.dg/pr58145-2.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr58145-1.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr58145-2.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-sra.c

[Bug target/58160] New: Power8 fusion support has a bug that shows up in running spec 2006

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58160

Bug ID: 58160
   Summary: Power8 fusion support has a bug that shows up in
running spec 2006
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

In running the spec 2006 testsuite with several options, we discovered that
-mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
fault in two benchmarks:

403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32
435.gromacs when built with -O3 -funroll-loops -mcpu=power7 -mtune=power8 -m32

In the gcc case, I tracked it down to the fusion op in the function
strength_reduce in the file loop.c.  It was wanting to use the result of the
addis instruction after the loop.

It wanted to optimize:
lis 10,loop_dump_stream@ha
lwz 6,loop_dump_stream@l(6)
stw 10,24(1)

to:
lis 6,loop_dump_stream@ha
lwz 6,loop_dump_stream@l(6)
stw 10,24(1)

The problem is fusion was implemented using define_peephole, and the register
live notes are not correct when peepholes are done.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

--- Comment #4 from Jonathan Wakely  ---
I think all existing Debug Mode checks only trigger for genuine undefined
behaviour

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[gromer at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

--- Comment #3 from Geoff Romer  ---
What's the standard of review here? If we can only assert on undefined
behavior, even in debug mode, then this just can't be done (although maybe we
should make this undefined in the Standard). If we can assert on behavior
that's technically well-defined, but very likely to lead to undefined behavior,
and very far from accepted usage norms, then I think this is OK (even for
custom deleters). The kinds of uses you're concerned about (e.g. using
p.reset(p.get()) to invoke some operation on *p) seem really marginal to me.

[Bug c++/51912] [C++11] G++ accepts floating point case labels

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51912

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

--- Comment #2 from Jonathan Wakely  ---
I'm also a little concerned that doing a self-reset followed by release() is
indeed valid ... but probably rare enough that we can still assert anyway at
the time of the self-reset.

I think this is a good idea, but we should be careful to do it right.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

--- Comment #1 from Jonathan Wakely  ---
What if the deleter doesn't actually destroy the object, and doing self-reset
is used as a crazy way to trigger the deleter to do something with the pointer,
but not to alter the value of the pointer?

If that's valid then we should only do this for default_delete specializations.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

[gromer at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

Geoff Romer  changed:

   What|Removed |Added

 CC||gromer at google dot com
   Severity|normal  |enhancement

[Bug libstdc++/58159] New: unique_ptr::reset should have debug assertion for "self-reset"

[gromer at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159

Bug ID: 58159
   Summary: unique_ptr::reset should have debug assertion for
"self-reset"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gromer at google dot com

unique_ptr::reset() should have a debug assertion for the case that the input
pointer is not null, and is equal to the pointer already stored. This is
virtually always an error: it violates the basic ownership logic of unique_ptr,
and leaves unique_ptr holding a dangling pointer. Strictly speaking, this is
not undefined behavior in itself, but almost any subsequent operation other
than release() (even destroying the unique_ptr) will produce undefined
behavior, so this seems like a highly defensible condition to assert on, at
least in debug mode.

This kind of error is rare, but it does happen; see e.g.
https://code.google.com/p/chromium/issues/detail?id=162971.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Peter Bergner  ---
The problem is that hardreg 62 (aka FPR30/VSR30) is not set in
CALL_USED_REGISTERS[] because the ABI states it is non-volatile.  But it is
only non-volatile in S[DF]mode and D[DF]mode modes.  It is volatile in V2DFmode
or any other mode where that uses doubleword 1 of the VSR.

Since hardreg 62 is not mentioned in CALL_USED_REGISTERS, df does not detect
the dependency between the xxpermdi setting hardreg 62 and the log() call that
clobbers half of it.  With no dependency between the insns, sched2 goes ahead
and moves the xxpermdi above the call.

[Bug fortran/58146] Array slice bounds checking

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146

--- Comment #5 from Mikael Morin  ---
(In reply to Mikael Morin from comment #4)
> (In reply to Thomas Koenig from comment #0)
> > neither does it do so with -fcheck=all at runtime:
> > 
> There is no out of bound at run time because the scalarizer sets the loop
> bounds according to the array providing the most information; in this case
> the constant array of size 3, so that the loop has only 3 iterations.

This variant should trigger an out of bound runtime error, but it doesn't
either.

program main
  implicit none
  integer :: n
  real, dimension(4) :: a
  n = 0
  call random_number(a)
  if (any(a(n+1:n+4) > [1.0, 2.0, 3.0, 4.0, 5.0])) print *,"Hello!"
end program main


Technically a(n+1:n+4) is within the bounds, the out of bounds comes from the
loop with a 5-sized array.

[Bug fortran/58157] ICE on character function with len given by a PURE function

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-14
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/58146] Array slice bounds checking

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin  ---
(In reply to Thomas Koenig from comment #0)
> neither does it do so with -fcheck=all at runtime:
> 
There is no out of bound at run time because the scalarizer sets the loop
bounds according to the array providing the most information; in this case the
constant array of size 3, so that the loop has only 3 iterations.

[Bug target/58158] New: internal compiler error: in extract_insn, at recog.c:2150 while compiling ImageMagick on mipsel

[aaro.koskinen at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158

Bug ID: 58158
   Summary: internal compiler error: in extract_insn, at
recog.c:2150 while compiling ImageMagick on mipsel
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaro.koskinen at iki dot fi

Created attachment 30657
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30657&action=edit
Source files (original & pre-processed).

Compiler details:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mipsel-linux-gnu/4.8.1/lto-wrapper
Target: mipsel-linux-gnu
Configured with: /home/aaro/los/work/shared/gcc-4.8.1/configure --build=none
--host=mipsel-linux-gnu --target=mipsel-linux-gnu --prefix=/usr --disable-nls
--disable-bootstrap --enable-languages=c,c++ --with-system-zlib --enable-shared
--disable-static --with-arch=loongson2f --with-abi=32 --enable-targets=all
Thread model: posix
gcc version 4.8.1 (GCC)

Steps to reproduce:

$ gcc -O2 mpeg.i
coders/mpeg.c: In function 'WriteMPEGImage':
coders/mpeg.c:625:1: error: unrecognizable insn:
 }
 ^
(insn 223 222 224 26 (set (reg:SI 351 [ D.11743 ])
(if_then_else:SI (ne:CC (reg:CC 67 $fcc0)
(const_int 0 [0]))
(reg:SI 351 [ D.11743 ])
(reg:SI 354))) -1
 (nil))
coders/mpeg.c:625:1: internal compiler error: in extract_insn, at recog.c:2150
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source file is attached.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007

--- Comment #8 from Mikael Morin  ---
Created attachment 30656
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30656&action=edit
tentative hack

For some reason this patch fixes the internal error on comment #6, but not on
comment #4.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007

--- Comment #7 from Mikael Morin  ---
(In reply to Mikael Morin from comment #5)
> I suppose the following is happening (based on Janus' test):
> 
> [...]
>
This may well be wrong as the typebound procedure in the just-submitted reduced
testcase is necessary to trigger the internal error.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007

--- Comment #6 from Mikael Morin  ---
further reduced test below.
Fails with trunk-20130619 and 4.7.3 here.
And works with 4.8-20130416.



module matrix
  type :: sparse_matrix
integer :: max_degree
  end type
end module

module bsr
  use matrix
  type, extends(sparse_matrix) :: bsr_matrix
  contains
procedure :: get_neighbors
  end type
contains
  function get_neighbors (A)
class(bsr_matrix), intent(in) :: A
integer :: get_neighbors(A%max_degree)
  end function
end module

program main
  use matrix
  use bsr
end

[Bug fortran/58157] ICE on character function with len given by a PURE function

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org ---
Slightly further compactified test case:


MODULE fortrand
  IMPLICIT NONE
CONTAINS

  integer PURE FUNCTION strlenf (string)
CHARACTER, INTENT(in) :: string(:)
strlenf = 1
  END FUNCTION

  FUNCTION strtofchar_chararr (string) RESULT (fchar)
CHARACTER, INTENT(in) :: string(:)
CHARACTER(len=strlenf(string)) :: fchar
  END FUNCTION

END MODULE

PROGRAM icetest
  USE fortrand
  IMPLICIT NONE
  print *,strtofchar_chararr((/'c'/)) ! ICE here!!!
END


I can confirm the ICE with various versions between 4.3 and trunk. Curiously
the ICE only appears if the 'string' argument is present (and of type
CHARACTER). Also it disappears when moving 'strtofchar_chararr' out of the
module into the main program.


The backtrace with trunk is:

icetest.f90:20:0: internal compiler error: Segmentation fault
   print *,strtofchar_chararr((/'c'/)) ! ICE here!!!
 ^
0x8bb59f crash_signal
/home/janus/gcc49/trunk/gcc/toplev.c:335
0x7263d8 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/janus/gcc49/trunk/gcc/fold-const.c:1480
0x6f3efa get_inner_reference(tree_node*, long*, long*, tree_node**,
machine_mode*, int*, int*, bool)
/home/janus/gcc49/trunk/gcc/expr.c:6674
0x7286a9 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/janus/gcc49/trunk/gcc/fold-const.c:8044
0x728f37 fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/janus/gcc49/trunk/gcc/fold-const.c:14944
0x5aff7a convert(tree_node*, tree_node*)
/home/janus/gcc49/trunk/gcc/fortran/convert.c:102
0x5c256a gfc_get_dataptr_offset
/home/janus/gcc49/trunk/gcc/fortran/trans-array.c:6250
0x5cd442 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
/home/janus/gcc49/trunk/gcc/fortran/trans-array.c:6910
0x5cdf9e gfc_conv_array_parameter(gfc_se*, gfc_expr*, bool, gfc_symbol const*,
char const*, tree_node**)
/home/janus/gcc49/trunk/gcc/fortran/trans-array.c:7141
0x5e80ab gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:4494
0x5eadfa gfc_conv_function_expr
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:5563
0x5e4819 gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:3554
0x5e97ab gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:4869
0x5eadfa gfc_conv_function_expr
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:5563
0x5e1bef gfc_conv_expr_reference(gfc_se*, gfc_expr*)
/home/janus/gcc49/trunk/gcc/fortran/trans-expr.c:6356
0x5ffe91 gfc_trans_transfer(gfc_code*)
/home/janus/gcc49/trunk/gcc/fortran/trans-io.c:2302
0x5bcad7 trans_code
/home/janus/gcc49/trunk/gcc/fortran/trans.c:1825
0x5fdc28 build_dt
/home/janus/gcc49/trunk/gcc/fortran/trans-io.c:1835
0x5bcaf7 trans_code
/home/janus/gcc49/trunk/gcc/fortran/trans.c:1797
0x5dbb62 gfc_generate_function_code(gfc_namespace*)
/home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:5527

[Bug target/57907] warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch [enabled by default]

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-14
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837

Andrew Pinski  changed:

   What|Removed |Added

 CC||jay.foad at gmail dot com

--- Comment #10 from Andrew Pinski  ---
*** Bug 58152 has been marked as a duplicate of this bug. ***

[Bug target/58152] ARM: unnecessary push before call to noreturn function

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58152

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 10837

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

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #10 from Jorn Wolfgang Rennecke  ---
See also:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00819.html

[Bug fortran/58157] New: ICE on character function with len given by a PURE function

[dcesari69 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157

Bug ID: 58157
   Summary: ICE on character function with len given by a PURE
function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcesari69 at gmail dot com

Created attachment 30655
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30655&action=edit
Fortran source for reproducing ICE

Hello, the attached simplified code contains a module with a CHARACTER function
whose results' length is given by another PURE function, which I assume is
correct Fortran 95 and I have used succesfully in other contexts. The module
compiles well, but as soon as the function is encountered in another piece of
code using the module, I get an ICE (+segfault):


[davide@localhost ~]$ rm -f *.mod; LANG= gfortran -c icetest.f90 
icetest.f90: In function 'icetest':
icetest.f90:34:0: internal compiler error: Segmentation fault
 tkey = strtofchar_chararr(key) ! ICE here!!!
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


It reminds somehow bug 55287:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827, but that one is fixed in
4.9, while this remains. Same bug with older versions of gfortran.

This is my first bug submission to gcc, so please forgive any procedural
mistake. Thank you for your work, Davide

[Bug middle-end/58145] [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations

[hp at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 30653 [details]
> gcc49-pr58145.patch
> 
> Updated patch.

Thank you very much, Jakub!
The missing opportunity to learn trees :) is offset by far by the value of the
promptness of the patch and the right generic incantations for the test-case!

I'll test and regtest this, though the exact change in volatileness won't be
tested beyond the test-case and the code-base where this was spotted.  Still,
apparently the patch can only add volatileness indicators where none was
before, so should be safe even for other branches than trunk.

It's obvious to you and other tree-ssa-savvy people, but IMHO its notable that
fiddling with the test-case reveals that the bug seems limited to
singleton-bit-field-structures of "natural" sizes; 8, 16, 32, (64 etc. where
applicable).  E.g. changing the bit-field-size to 9 or having two bitfields of
16 bits does not trig the bug.

[Bug c++/58156] New: c++11 bogus ambigous overload with variadic template

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58156

Bug ID: 58156
   Summary: c++11 bogus ambigous overload with variadic template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref b/10321377

/// --- cut ---
template 
void Foo(U&...) {}

template 
void Foo(const U&...) {}

void Bar() {
  const int a = 0;
  Foo(a);
}
/// --- cut ---

The test compiles with Clang, errors with current trunk GCC:
g++ (GCC) 4.9.0 20130814 (experimental)


g++ -c t.cc -std=c++11
t.cc: In function ‘void Bar()’:
t.cc:9:14: error: call of overloaded ‘Foo(const int&)’ is ambiguous
Foo(a);
  ^
t.cc:9:14: note: candidates are:
t.cc:2:7: note: void Foo(U& ...) [with T = int; U = {const int}]
  void Foo(U&...) {}
   ^
t.cc:5:7: note: void Foo(const U& ...) [with T = int; U = {int}]
  void Foo(const U&...) {}
   ^

Also broken with gcc-4.7.

[Bug target/58105] wrong code generation for multiversioned functions

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58105

--- Comment #4 from Bernd Edlinger  ---
Sorry to bother you...

With Richard's E-mail today he approved this patch.
Could you as i386-port maintainer please do the check-in for me?

Thanks.

[Bug target/58152] ARM: unnecessary push before call to noreturn function

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58152

--- Comment #1 from Andrew Pinski  ---
This is expected behavior as noreturn functions are not sibcalled optimized. 
The main reason is that even without debugging information, you want to find
out where the noreturn function was called from.

[Bug rtl-optimization/57459] [4.8 Regression] LRA inheritance bug

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Author: vmakarov
Date: Tue Aug 13 16:40:33 2013
New Revision: 201695

URL: http://gcc.gnu.org/viewcvs?rev=201695&root=gcc&view=rev
Log:
2013-08-13  Vladimir Makarov  

Backport from mainline
2013-06-06  Vladimir Makarov  

PR rtl-optimization/57459
* lra-constraints.c (update_ebb_live_info): Fix typo for operand
type when setting live regs.

2013-08-13  Vladimir Makarov  

Backport from mainline
2013-06-06  Vladimir Makarov  

PR rtl-optimization/57459
* gcc.target/i386/pr57459.c: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57459.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/lra-constraints.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/57459] [4.8 Regression] LRA inheritance bug

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459

--- Comment #9 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 30643 [details]
> rh995446.i
> 
> We've got this reported in
> https://bugzilla.redhat.com/show_bug.cgi?id=995446 too.
> I've created a self-contained executable testcase out of that.
> 
> Vlad, can you please backport this to 4.8 branch or are there any issues
> that prevent it?  I'll add the testcase to 4.8/trunk afterwards.

As the patch does not depend on any recent LRA development,  I've committed the
patch into gcc-4_8-branch.  So the problem should be solved for gcc-4.8.

[Bug c/58154] if declaration and definition of a function differ in scope, emit a warning

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

--- Comment #5 from Andreas Schwab  ---
All references are from N1570.

[Bug c/58154] if declaration and definition of a function differ in scope, emit a warning

[alexander.huemer at xx dot vu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

--- Comment #4 from Alexander Huemer  ---
Maybe I really do not correctly understand the difference between storage class
and linkage.
To me it seems like in one case the linkage of a function is inherited from the
declaration, in the other case not.
Again, please state which version of the document you are referring to. I
cannot find what you are talking about in the document I linked.

[Bug c++/58155] New: -Wliteral-suffix warns about tokens which are skipped by preprocessor

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155

Bug ID: 58155
   Summary: -Wliteral-suffix warns about tokens which are skipped
by preprocessor
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: emsr at gcc dot gnu.org

This is valid code:

#define BAZ "baz"
#if 0
"bar"BAZ
#endif
int main() { }

But causes a diagnostic in C++11 mode:

u.cc:3:1: warning: invalid suffix on literal; C++11 requires a space between
literal and string macro [-Wliteral-suffix]
 "foo"BAR
 ^

According to 16.1 [cpp.cond] p6 the group should be skipped and its
preprocessing tokens are ignored, it shouldn't be checked for validity.

[Bug c/58154] if declaration and definition of a function differ in scope, emit a warning

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #3 from Andreas Schwab  ---
The definition has the storage-class specifier static so it gets internal
linkage which conflicts with the external linkage from the preceding
declaration.  See 6.2.2 #4.

[Bug c/58154] if declaration and definition of a function differ in scope, emit a warning

[alexander.huemer at xx dot vu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

Alexander Huemer  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Alexander Huemer  ---
6.2.2 #4 and #5 in which version of the document?
In the one I linked 6.2.2 is a section than contains only subsections, no
content itself.
What would be an example for the quote in my initial post?

If I understand you correctly you say the definition inherits if it is static
or not from it's declaration, in case there is one.
Then why does the following code not compile at all?

int foo(void);

static int foo(void)
{
volatile int a = 3;

return a;
}

$ gcc -Wall -Wextra foo.c
foo.c:3:12: error: static declaration of ‘foo’ follows non-static declaration
foo.c:1:5: note: previous declaration of ‘foo’ was here

[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Eric Botcazou  ---
The exception is correctly handled on modern systems (Linux, recent Darwin) so
this may be a bug in the unwinder.  Older Darwins use an antiquated system
unwinder derived from GCC 4.2 and it has known glitches/incompatibilities.

The recommendation is to stay with the MacAda compiler on this old system, as
newer GCC are not tested on anything older than 10.x for quite some time.

Of course what worked for I/O on VMS decades ago is essentially irrelevant for
modern Unices.

[Bug c/58154] if declaration and definition of a function differ in scope, emit a warning

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
There is no linkage conflict here.  The definition inherits the internal
linkage of the preceding declaration, so the resulting linkage is internal. 
See 6.2.2 #4 and #5.  Don't confuse the concept of linkage with storage-class
specifiers.

[Bug c/58154] New: if declaration and definition of a function differ in scope, emit a warning

[alexander.huemer at xx dot vu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58154

Bug ID: 58154
   Summary: if declaration and definition of a function differ in
scope, emit a warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.huemer at xx dot vu

Hi,

i just stumbled upon a piece of code like this:

static int foo(void);

int foo(void)
{
volatile int a = 3;

return a;
}

According to http://std.dkuug.dk/JTC1/SC22/open/n2620/n2620.txt --> 6.1.2.2 #7
the behavior in this situation is undefined.

   If, within a  translation  unit,  the  same  identifier
   appears   with  both  internal  and  external  linkage,  the
   behavior is undefined.

Steps to Reproduce:
the code above goes into foo.c
$ gcc -Wall -Wextra -c foo.c

Actual Results:
gcc does not emit a warning when compiling with -Wall -Wextra.

Expected Results:
gcc should emit a warning when compiling such code.

[Bug middle-end/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58106

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Mine

[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2

[ExtraLeveLInSoftware at ntlworld dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128

--- Comment #2 from Ellis N. Thomas  
---
Further Information about the Exception

Added extra "others" handler for Unexpected exceptions to TryStdIP3.
Compiled:
bash> gnatmake TryStdIP3.ada 
gcc -c -x ada trystdip3.ada
gnatbind -x trystdip3.ali
gnatlink trystdip3.ali

Ran:
bash> trystdip3
TryStdIP3 from SiRiL Issue 0.22 21-Apr-1989 
Copyright (c) 2013 E.N. Thomas
Started at : 12:45:57  14/ 8/13
Try to get NAME (STANDARD_INPUT)
Try to open CommandFile using: <*stdin>

raised PROGRAM_ERROR : unhandled signal

So the "others" handler has failed to handle this PROGRAM_ERROR!
Although it is reported as an exception, it is not able to be handled in the
normal Ada way, so this seriously compromises the ability to work around this
error.

Consequently, a work-round such as a new version of s-fileio.adb
(system__file_io__open) and/or a-textio.adb (ada__text_io__open) would be
appreciated.

E.N. Thomas/14-Aug-2013

[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2

[ExtraLeveLInSoftware at ntlworld dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128

--- Comment #1 from Ellis N. Thomas  
---
Created attachment 30654
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30654&action=edit
Source code showing problem handling the exception (TryStdIP3)

Further Ada source program, modified as described in the additional comment.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[jnahughes at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

JamesH  changed:

   What|Removed |Added

 CC||jnahughes at googlemail dot com

--- Comment #10 from JamesH  ---
I'd like to add that this is a definite problem when moving a codebase from a
different compiler to gcc. I'm having to individually fix up ={0} cases to
match the content of the structure being initialised, which is a PITA, and I
think against the C standard which I believe allows ={0} as a default zero
initialiser for structs of whatever content.

Therefore, is there any progress on this bug?

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

[temporal at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153

--- Comment #2 from Kenton Varda  ---
> The standard says average case O(1), worst case O(a.size()), so if every
> element in the container has the same key then it's O(n).

I'm not sure that follows.  Yes, the standard says "worst case O(n)", but why
should expect worst-case performance if I have lots of entries with the same
key?  In the absence of explicit language to the contrary, it seems entirely
reasonable to expect unordered_multimap to perform similarly to
unordered_map>, where in fact it turns out to be more like
unordered_map>.

I guess the real bug here is with all of the C++ reference sites that fail to
mention this rather large caveat...  that unordered_multimap supports duplicate
keys, but only as long as there aren't "too many" duplicates.

I think part of the problem might be that people are thinking: "Well, duh, hash
maps perform poorly if lots of keys have the same hash!".  But I don't think
that's quite the same thing.  Unique hash maps perform poorly in that case
because it's necessary to linearly scan through many entries to find the one
that matches the key.  But when looking for a key in a multimap, you stop at
the first match, so even if there are lots of entries with the same key, lookup
can still be O(1).  So, I don't think it's intrinsically true that a
hashtable-based multimap should perform badly when many entries have the same
key.

[Bug target/58067] ICE in GFortran recog.c:2158

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 14 09:09:58 2013
New Revision: 201720

URL: http://gcc.gnu.org/viewcvs?rev=201720&root=gcc&view=rev
Log:
PR target/58067
* config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC
and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle
there also UNSPEC_PLTOFF.

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

Author: jakub
Date: Wed Aug 14 09:29:22 2013
New Revision: 201721

URL: http://gcc.gnu.org/viewcvs?rev=201721&root=gcc&view=rev
Log:
PR target/58067
* config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC
and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle
there also UNSPEC_PLTOFF.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153

--- Comment #1 from Jonathan Wakely  ---
(In reply to Kenton Varda from comment #0)
> I do not know exactly what the standard requires here, but all of the
> references I can find claim that erase(iter) should be average-time O(1),
> and none of them suggest that having a large number of entries with the same
> key should cause trouble.

The standard says average case O(1), worst case O(a.size()), so if every
element in the container has the same key then it's O(n).

> FWIW, it looks like libc++ has the same behavior.  Maybe my expectations
> were wrong, and unordered_multimap was never meant to contain more than a
> couple entries per key?

It supports any number of entries with the same key, you just can't expect O(1)
erase operations in that case.  If you have very many collisions maybe your
choice of key or your choice of container isn't ideal.

[Bug libstdc++/58153] New: unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

[temporal at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153

Bug ID: 58153
   Summary: unordered_multimap::erase(iterator) is not
constant-time when many entries have the same key
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: temporal at gmail dot com

It appears that if an unordered_multimap has k entries with the same key, then
erase(iter) for any of those entries is O(k) rather than constant-time.  The
problem is that _Hashtable::erase() searches through all nodes in the bucket
looking for the one previous to the one being removed.  This is reasonable for
unordered_map, where buckets are expected to have no more than a couple
entries.  But it is surprising for unordered_multimap, whose whole purpose is
to support multiple entries with the same key (and therefore the same bucket).

I do not know exactly what the standard requires here, but all of the
references I can find claim that erase(iter) should be average-time O(1), and
none of them suggest that having a large number of entries with the same key
should cause trouble.

FWIW, it looks like libc++ has the same behavior.  Maybe my expectations were
wrong, and unordered_multimap was never meant to contain more than a couple
entries per key?

[Bug middle-end/58145] [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #30648|0   |1
is obsolete||

--- Comment #2 from Jakub Jelinek  ---
Created attachment 30653
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30653&action=edit
gcc49-pr58145.patch

Updated patch.

[Bug target/58152] New: ARM: unnecessary push before call to noreturn function

[jay.foad at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58152

Bug ID: 58152
   Summary: ARM: unnecessary push before call to noreturn function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.foad at gmail dot com

Created attachment 30652
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30652&action=edit
C source for testcase

On the attached test case I get:

$ gcc -marm -S -O2 ~/mul.c -o - -fomit-frame-pointer -march=armv6
...
mul:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
smullr0, r1, r0, r1
cmpr1, r0, asr #31
bxeqlr
stmfdsp!, {r3, lr}
bloverflow

The stmfd instruction is completely unnecessary.

I'm using gcc built from svn r201719 configured with --target=arm-eabi.

[Bug c++/56260] [C++11] GCC hangs/crashes on potentially invalid source

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56260

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-14
 Ever confirmed|0   |1

[Bug c++/55540] The C++ literal -9223372036854775808 is misinterpreted

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55540

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Thus closing.

[Bug ada/58151] New: "conflict of writable function parameter in construct with arbitrary order of evaluation" is often a spurious error

[prosfilaes at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58151

Bug ID: 58151
   Summary: "conflict of writable function parameter in construct
with arbitrary order of evaluation" is often a
spurious error
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prosfilaes at gmail dot com

Created attachment 30651
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30651&action=edit
Code that shows the error message unless you comment out calculations.adb:21

Compiling the attached code with "gnatmake -gnat2012 solver.adb" gives me

gcc -c -gnat2012 solver.adb
gcc -c -gnat2012 calculations.adb
calculations.adb:21:25: "Is_Route" is undefined
calculations.adb:80:58: conflict of writable function parameter in construct
with arbitrary order of evaluation
calculations.adb:81:58: conflict of writable function parameter in construct
with arbitrary order of evaluation
gnatmake: "calculations.adb" compilation error

"Is_Route" is undefined is quite correct. So comment out that pragma Assert on
line 21. Then gnatmake -gnat2012 solver.adb gives me

gcc -c -gnat2012 calculations.adb
calculations.adb:60:07: warning: variable "Length" is never read and never
assigned
calculations.adb:62:07: warning: variable "Optimal" is never read and never
assigned
gcc -c -gnat2012 problem.adb
gnatbind -x solver.ali
gnatlink solver.ali

Suddenly those lines of code on lines 80 and 81 are not a problem.

This is not something special to this chunk of code; I've been getting this
repeatedly when working in Ada2012 mode, where "conflict of writable function
parameter in construct with arbitrary order of evaluation" goes away after a
fix of a completely different error in a completely different part of the file.