[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

[dongsheng.song at gmail dot com]

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

--- Comment #8 from Dongsheng Song  ---
It's hard to understand SEH reqiure unwind table in DWARF 2 format. can you
give me a brief description ?

Your patch does not help:

$ cat << EOF |  ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -O2 -o
`mktemp` -c -x c++ -fasynchronous-unwind-tables - >/dev/null
> #pragma GCC target("sse4a")
> EOF
:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH

$ ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc49/libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure
--prefix=/home/cauchy/cross/x86_64-windows-gcc49
--with-sysroot=/home/cauchy/cross/x86_64-windows-gcc49
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-w64-mingw32 --disable-multilib --disable-nls
--enable-checking=release --enable-languages=c,c++,fortran --with-arch=core2
--with-tune=generic
Thread model: win32
gcc version 4.9.0 20131206 (experimental) (GCC)

Build the gcc 4.9 x64 native compiler from the gcc 4.9 cross compiler still
failed:

x86_64-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp
-I/home/cauchy/vcs/svn/gcc/trunk/gmp
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpc/src 
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include 
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include
-I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -I. -I.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp
-I/home/cauchy/vcs/svn/gcc/trunk/gmp
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpc/src 
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include 
-I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include
-I/home/cauchy/vcs/svn/gcc/trunk/isl/include \
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c
In file included from
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1495,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/minwindef.h:146,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:8,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69,
 from
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29:
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:28:
sorry, unimplemented: -mno-fentry isn't compatible with SEH
 #pragma GCC target("sse4.2")
^
make[2]: *** [host-mingw32.o] Error 1
make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc'
make[1]: *** [install-strip-gcc] Error 2
make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc'
make: *** [install-strip] Error 2

$ svn info mingw-w64/trunk/ gcc/trunk/
Path: mingw-w64/trunk
URL: svn://svn.code.sf.net/p/mingw-w64/code/trunk
Repository Root: svn://svn.code.sf.net/p/mingw-w64/code
Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1
Revision: 6392
Node Kind: directory
Schedule: normal
Last Changed Author: ktietz70
Last Changed Rev: 6392
Last Changed Date: 2013-12-05 18:06:07 +0800 (Thu, 05 Dec 2013)

Path: gcc/trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee

[Bug sanitizer/59061] Port leaksanitizer

[kcc at gcc dot gnu.org]

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

--- Comment #40 from Kostya Serebryany  ---
Thanks for the feedback!
Is there anything else left in this bug? 
If not, please close this one and open another for the next problem(s)

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #39 from Joost VandeVondele  
---
(In reply to Sergey Matveev from comment #37)
> I've patched LSan to use the real memset(). At least on my machine this
> brought no performance improvement compared to kcc's latest change (just FYI
> - not trying to make any point).

After the latest sanitizer merge, I see a significant reduction in the overhead
of -fsanitize=leak (overhead went down from ~20% to <5%). Nice!

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

[dongsheng.song at gmail dot com]

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

--- Comment #15 from Dongsheng Song  ---
gcc 4.7.x never have such issue.

for gcc 4.8.x or trunk, I did not build multilib long ago.
because I can not build multilib which x64 use SEH, and x86 use SJLJ. I must
build with SJLJ for x64 and x86.

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[achurch+gcc at achurch dot org]

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

--- Comment #6 from Andrew Church  ---
Still broken for me, sorry.  Using SVN r205727 with the patch, the assembly now
looks like:

 <_bar>:
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   83 e4 f0and$0xfff0,%esp
   6:   50  push   %eax
   7:   b8 1c 10 00 00  mov$0x101c,%eax
   c:   e8 00 00 00 00  call   11 <_bar+0x11>
d: DISP32   ___chkstk_ms
  11:   29 c4   sub%eax,%esp
  13:   8b 84 24 e4 ef ff ffmov-0x101c(%esp),%eax

so it's using the stack pointer but the offset is in the wrong direction. 
Should "0 - allocate" be just "allocate" in the plus_constant() calls?

[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32

[kcc at gcc dot gnu.org]

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

Kostya Serebryany  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kcc at gcc dot gnu.org

--- Comment #1 from Kostya Serebryany  ---
Thanks for the report, H.J. I'll try to respond properly on Monday (-ish). 
Long term, everyone would benefit if you could setup a public build bot
upstream.

[Bug c++/59404] New: declaration shadowing template parameter wrongly accepted

[sami.liedes at iki dot fi]

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

Bug ID: 59404
   Summary: declaration shadowing template parameter wrongly
accepted
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sami.liedes at iki dot fi

Hi,

This code compiles with gcc -std=c++11 (but is rejected by clang++):

-
template 
struct A {
template
void f() {
typedef int T;
}
};

void g() {
A a;
a.f();
}
-

However if the third line (template) is removed, GCC correctly
rejects the code because typedef int T shadows the template parameter T.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.8.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-7'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--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-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --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 4.8.2 (Debian 4.8.2-7)

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
A small run-time testcase.  It went into an finite loop at -O.

---
[hjl@gnu-mic-2 pr59379]$ cat main.c 
#include 
typedef unsigned long int __cpu_mask;
void *
__attribute__((malloc, noinline))
gomp_malloc (size_t s)
{
  return malloc (s);
}
typedef struct
{
  __cpu_mask __bits[1024 / (8 * sizeof (__cpu_mask))];
} cpu_set_t;
unsigned long gomp_cpuset_size __attribute__ ((visibility ("hidden")));
cpu_set_t *gomp_cpusetp __attribute__ ((visibility ("hidden")));
static unsigned long gomp_get_cpuset_size;
void
__attribute__ ((noinline))
gomp_init_num_threads (void)
{
  gomp_cpuset_size = 8;
  gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
  do
{
  gomp_get_cpuset_size = gomp_cpuset_size;
  unsigned long i;
  for (i = gomp_cpuset_size * 8; i; i--)
if ((__extension__
 ({ size_t __cpu = (i - 1);
  __cpu < 8 * (gomp_cpuset_size)
  ? const __cpu_mask *) ((gomp_cpusetp)->__bits))[((__cpu) / (8 *
sizeof (__cpu_mask)))] & ((__cpu_mask) 1 << ((__cpu) % (8 * sizeof
(__cpu_mask)) != 0
  : 0;
  })))
  break;
  gomp_cpuset_size = i) + (8 * sizeof (__cpu_mask)) - 1) / (8 * sizeof
(__cpu_mask))) * sizeof (__cpu_mask));
  return;
}
  while (1);
}
int
main ()
{
  gomp_init_num_threads ();
  return 0;
}
[hjl@gnu-mic-2 pr59379]$ make run
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/ -O -o x main.c
./x
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
---

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[iwamatsu at nigauri dot org]

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

--- Comment #6 from Nobuhiro Iwamatsu  ---
(In reply to Oleg Endo from comment #5)
> (In reply to Nobuhiro Iwamatsu from comment #4)
> > Oleg and Kojima-san, thanks for your work.
> > 
> > Yes, I was building on SH native.
> > And I am using gcc 4.6.3 version in the host.
> 
> Iwamatsu-san, if you have some time, could you please try building GCC 4.9? 
> I'm sorry, but I don't have the right setup at hand to do it myself at the
> moment.

Sure. I will build gcc 4.9 soon. 
When I get result, I report this bug.

> 
> Also, please notice that the current GCC 4.8 branch has some known problems
> in the SH parts (produces wrong code) -- I'm working on back porting some
> patches from 4.9.

I see. 
I am looking forward to your backport patch!

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

[ktietz at gcc dot gnu.org]

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

--- Comment #14 from Kai Tietz  ---
Does this problem still exists for you with current 4.7 branch?
For me recent bootstrap multilib 64-bit, and 32-bit are working without issues
on 4.7.x

[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

[tmsriram at google dot com]

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

--- Comment #4 from Sriraman Tallam  ---
Here is the problem. GCC adds target-specific builtins on demand. The FMA
target-specific builtin __builtin_ia32_vfmaddpd gets added via this
declaration:

void fun() __attribute__((target("fma")));

Specifically, the builtin __builtin_ia32_vfmaddpd gets added when
ix86_add_new_builtins is called from ix86_valid_target_attribute_tree when
processing this target attribute.

Now, when the vectorizer is processing the builtin "__builtin_fma" in function
other_fn(), it checks to see if this function is vectorizable and calls
ix86_builtin_vectorized_function in i386.c. That returns the builtin stored
here:


   case BUILT_IN_FMA:
  if (out_mode == DFmode && in_mode == DFmode)
{
  if (out_n == 2 && in_n == 2)
return ix86_builtins[IX86_BUILTIN_VFMADDPD];
  

ix86_builtins[IX86_BUILTIN_VFMADDPD] would have contained NULL_TREE had the
builtin not been added by the previous target attribute. That is why the code
works if we remove the previous declaration.

The fix then is to not just return the builtin but to also check if the current
function's isa allows the use of the builtin. For instance, this patch would
solve the problem:

@@ -33977,7 +33977,13 @@ ix86_builtin_vectorized_function (tree fndecl, tre
   if (out_mode == DFmode && in_mode == DFmode)
 {
   if (out_n == 2 && in_n == 2)
-return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+{
+  if (ix86_builtins_isa[IX86_BUILTIN_VFMADDPD].isa
+  & global_options.x_ix86_isa_flags)
+return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+  else
+return NULL_TREE;
+}


but there are many instances of this usage in ix86_builtin_vectorized_function.
I will make a patch to cover all these cases and send for review.

[Bug lto/50351] An internal compiler error when building gcc4.6 using "-flto -fuse-linker-plugin" on Win7 mingw64 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #6 from Kai Tietz  ---
I rechecked reported issue with current trunk-version and didn't saw this ICE
anymore.  Also with newer 4.7 version I can't reproduce issue.

Could you please retest and tell me if issue is still reproducable for you?

[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-06
 Ever confirmed|0   |1

--- Comment #7 from Kai Tietz  ---
Issue is that for SEH-target we need to generate dw2 unwind-information so that
-fasynchronous-unwind-tables works proper.

Following patch should fix that:

Index: i386.c
===
--- i386.c  (Revision 205719)
+++ i386.c  (Arbeitskopie)
@@ -3698,6 +3698,9 @@ ix86_option_override_internal (bool main_args_p,
 {
   if (opts->x_optimize >= 1 && !opts_set->x_flag_omit_frame_pointer)
opts->x_flag_omit_frame_pointer = !USE_X86_64_FRAME_POINTER;
+  if (opts->x_flag_asynchronous_unwind_tables == 1
+ && TARGET_SEH)
+   opts->x_flag_unwind_tables = 1;
   if (opts->x_flag_asynchronous_unwind_tables == 2)
opts->x_flag_unwind_tables
  = opts->x_flag_asynchronous_unwind_tables = 1;

[Bug c++/59403] New: [4.8.2] Segmentation fault in crash_signal

[boaz at alum dot mit.edu]

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

Bug ID: 59403
   Summary: [4.8.2] Segmentation fault in crash_signal
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boaz at alum dot mit.edu

Our project compiles OK with 4.8.1 ; however switching to 4.8.2 causes g++ to
segfault !!  When "-v -save-temps" is added to the command line options, the
compilation passes OK !!


$ uname -a
Linux ws-boaz 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64
x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/paraccel/gcc_4_8_2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/paraccel/gcc_4_8_2
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.8.2 (GCC)

---

$ g++ -c -g -DXEN_DEBUG -W -Wall -Werror -fdiagnostics-show-option
-Wno-error=uninitialized -Wno-error=strict-overflow -Wno-error=strict-aliasing
-Wno-unused-local-typedefs -I /home/paraccel/branches/gcc_4_8_2/obj/utils -L
/home/paraccel/branches/gcc_4_8_2/obj/utils -DLINUX -DSYS=B4_2
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/mb
-I/home/paraccel/branches/gcc_4_8_2/src/sys
-I/home/paraccel/branches/gcc_4_8_2/src/xen_utils
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/libpq
-I/home/paraccel/branches/gcc_4_8_2/src/backup
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/catalog
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/commands
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/storage
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/nodes
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/access
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/utils
-I/home/paraccel/branches/gcc_4_8_2/obj/pg
-I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include
-I/home/paraccel/branches/gcc_4_8_2/src/sysmgr
-I/home/paraccel/branches/gcc_4_8_2/obj/backup
/home/paraccel/branches/gcc_4_8_2/src/backup/backupdb.cpp
In file included from
/home/paraccel/branches/gcc_4_8_2/src/xen_utils/xen_global.hpp:11:0,
 from
/home/paraccel/branches/gcc_4_8_2/src/xen_utils/xen_except.hpp:33,
 from
/home/paraccel/branches/gcc_4_8_2/src/backup/backupdb.cpp:32:
/home/paraccel/branches/gcc_4_8_2/src/xen_utils/bigint.hpp:17:7: internal
compiler error: Segmentation fault
 class Bigint
   ^
0x890fdf crash_signal
../.././gcc/toplev.c:332
0x6b2239 add_name_attribute
../.././gcc/dwarf2out.c:15722
0x6b2239 modified_type_die
../.././gcc/dwarf2out.c:10197
0x6b3c8b add_type_attribute
../.././gcc/dwarf2out.c:16497
0x6be2e9 gen_formal_parameter_die
../.././gcc/dwarf2out.c:17089
0x6bec16 gen_formal_types_die
../.././gcc/dwarf2out.c:17185
0x6aba6a gen_subprogram_die
../.././gcc/dwarf2out.c:17919
0x6afa28 gen_decl_die
../.././gcc/dwarf2out.c:19994
0x6b1570 gen_member_die
../.././gcc/dwarf2out.c:19045
0x6b1570 gen_struct_or_union_type_die
../.././gcc/dwarf2out.c:19117
0x6b1570 gen_tagged_type_die
../.././gcc/dwarf2out.c:19307
0x6b1c8e gen_type_die_with_usage
../.././gcc/dwarf2out.c:19454
0x6b0112 gen_decl_die
../.././gcc/dwarf2out.c:20017
0x7ff915 rest_of_type_compilation(tree_node*, int)
../.././gcc/passes.c:215
0x52c1d7 finish_struct_1(tree_node*)
../.././gcc/cp/class.c:6444
0x52cdfc finish_struct(tree_node*, tree_node*)
../.././gcc/cp/class.c:6609
0x5459c6 cp_parser_class_specifier_1
../.././gcc/cp/parser.c:18412
0x5459c6 cp_parser_class_specifier
../.././gcc/cp/parser.c:18620
0x5459c6 cp_parser_type_specifier
../.././gcc/cp/parser.c:13682
0x5587b5 cp_parser_decl_specifier_seq
../.././gcc/cp/parser.c:11007
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*** Error code 1

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[ktietz at gcc dot gnu.org]

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

--- Comment #5 from Kai Tietz  ---
Yeah, the issue is the use of frame-pointer ...  instead we should use here
stack-pointer relative addressing as we are that way realigned stack-pointer
agnostic.

Following patch solves the issue.  Could you give it a try?

Index: i386.c
===
--- i386.c(Revision 205719)
+++ i386.c(Arbeitskopie)
@@ -10934,18 +10934,21 @@ ix86_expand_prologue (void)
 }
   m->fs.sp_offset += allocate;

+  /* Use stack_pointer_rtx for relative addressing so that code
+ works for realigned stack, too.  */
   if (r10_live && eax_live)
 {
-  t = choose_baseaddr (m->fs.sp_offset - allocate);
+  t = plus_constant (Pmode, stack_pointer_rtx, 0 - allocate);
   emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
   gen_frame_mem (word_mode, t));
-  t = choose_baseaddr (m->fs.sp_offset - allocate - UNITS_PER_WORD);
+  t = plus_constant (Pmode, stack_pointer_rtx,
+ 0 - allocate - UNITS_PER_WORD);
   emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
   gen_frame_mem (word_mode, t));
 }
   else if (eax_live || r10_live)
 {
-  t = choose_baseaddr (m->fs.sp_offset - allocate);
+  t = plus_constant (Pmode, stack_pointer_rtx, 0 - allocate);
   emit_move_insn (gen_rtx_REG (word_mode,
(eax_live ? AX_REG : R10_REG)),
   gen_frame_mem (word_mode, t));

[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.

[ma...@linux-mips.org]

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

--- Comment #8 from Maciej W. Rozycki  ---
Richard,

 I wasn't aware integer promotions applied here, thanks for pointing it
out.  New code is therefore correct while old one was not.  Unfortunately
neither -fwrapv nor -funsafe-loop-optimizations changes anything.

  Maciej

[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Dec  5 23:28:25 2013
New Revision: 205723

URL: http://gcc.gnu.org/viewcvs?rev=205723&root=gcc&view=rev
Log:
PR c++/59044
PR c++/59052
* pt.c (most_specialized_class): Use the partially instantiated
template for deduction.  Drop the TMPL parameter.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/partial14.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c

[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Dec  5 23:28:25 2013
New Revision: 205723

URL: http://gcc.gnu.org/viewcvs?rev=205723&root=gcc&view=rev
Log:
PR c++/59044
PR c++/59052
* pt.c (most_specialized_class): Use the partially instantiated
template for deduction.  Drop the TMPL parameter.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/partial14.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/pt.c

[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Thu Dec  5 22:46:36 2013
New Revision: 205720

URL: http://gcc.gnu.org/viewcvs?rev=205720&root=gcc&view=rev
Log:
PR c++/59044
PR c++/59052
* pt.c (most_specialized_class): Use the partially instantiated
template for deduction.  Drop the TMPL parameter.

Added:
trunk/gcc/testsuite/g++.dg/template/partial14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Dec  5 22:46:36 2013
New Revision: 205720

URL: http://gcc.gnu.org/viewcvs?rev=205720&root=gcc&view=rev
Log:
PR c++/59044
PR c++/59052
* pt.c (most_specialized_class): Use the partially instantiated
template for deduction.  Drop the TMPL parameter.

Added:
trunk/gcc/testsuite/g++.dg/template/partial14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.9.0

[Bug sanitizer/59402] New: [4.9 Regression] bootstrap failure on x32

[hjl.tools at gmail dot com]

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

Bug ID: 59402
   Summary: [4.9 Regression] bootstrap failure on x32
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

r205700 breaks bootstrap for x32:

http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00118.html

2 patches are posted at

http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00525.html

as well as

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131202/197727.html

[Bug target/51523] LTO keeps unneeded functions (mingw32 target)

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Kai Tietz  ---
Ok, due it is a linker-bug, I close this bug as invalid.
If it is shown later that issue is however caused by gcc, please re-open.

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
I also tested the modified case with NAG 5.3.2(951).
It agrees with gfortran.

I now wonder whether there is something special about
allocatable function results.

[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-05
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
This reduced test case also fails with 4.8.1:


  implicit none

  type t
   procedure(), pointer, nopass :: a,b
  end type

end



with the following error:


*** Error in `/usr/lib/gcc/x86_64-linux-gnu/4.8/f951': double free or
corruption (fasttop): 0x01bddec0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f326bd12996]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z15gfc_free_symbolP10gfc_symbol+0x58)[0x5bc048]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1f4]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1e2]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1eb]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z18gfc_free_namespaceP13gfc_namespace+0x4b)[0x5bbebb]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z17gfc_symbol_done_2v+0x10)[0x5bc460]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z10gfc_done_2v+0x9)[0x579299]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z14gfc_parse_filev+0x6ea)[0x58c88a]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5c8306]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x8a5906]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z11toplev_mainiPPc+0x9ba)[0x8a73ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f326bcb3de5]
/usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x51eebf]

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
(In reply to Sergio Losilla from comment #2)
> There should be no need to deallocate. From the excerpt you copied: "If the
> variable is an allocated allocatable variable, it is deallocated if expr is
> an array of different shape".

shape(-3:3) == shape (-2:4) == shape(1:7)

Shape is UBOUND-LBOUND+1.

> For the second, the obtained shape should *always* be the same. It looks
> like gfortran will not touch LHS if it is allocated and has the same size as
> RHS. And that should not be the case.

No, gfortran is right here, see above.

> By the way, the Intel compiler is quite crazy. Version 11 something works as
> expected in a platform I have access to, but 12 and 13 fail one or both
> assignments!

Funny!  Would you please report to the Intel forum?

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
An example where the base address is retrieved from the GBR in one basic block,
but used in different basic blocks:

struct tcb_t
{
  int x, y, z, w;
};

int test_01 (int a, tcb_t* b, int c)
{
  tcb_t* tcb = (tcb_t*)__builtin_thread_pointer ();

  return (a & 5) ? tcb->x : tcb->w;
}

By coincidence it produces correct code:

mov r4,r0
tst #5,r0
bf  .L7
mov.l   @(12,gbr),r0
rts
nop
.L7:
rts
mov.l   @(0,gbr),r0

A proper fix for this would be to collect all "leaf values" for the address
registers in question from all predecessor basic blocks as it's done in the
function sh_optimize_sett_clrt::find_last_ccreg_values in
sh_optimize_sett_clrt.cc.

[Bug fortran/59398] Wrong bounds for allocatable result and for

[loximann at gmail dot com]

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

--- Comment #2 from Sergio Losilla  ---
There should be no need to deallocate. From the excerpt you copied: "If the
variable is an allocated allocatable variable, it is deallocated if expr is an
array of different shape".

For the second, the obtained shape should *always* be the same. It looks like
gfortran will not touch LHS if it is allocated and has the same size as RHS.
And that should not be the case.

By the way, the Intel compiler is quite crazy. Version 11 something works as
expected in a platform I have access to, but 12 and 13 fail one or both
assignments!

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
Sergio,

I'm not sure about the first assignment, but the behavior in
the second case is certainly correct.

On the first assignment, a is not allocated.
On the second assignment, the shape of the RHS is the same,
so you get the same result.

If you modify your program as follows:

program return_allocatable
implicit none

real, allocatable :: a(:)

real, parameter :: b(-2:4)=[1,2,3,4,5,6,7]

a=foo(3)
print*,lbound(a),':',ubound(a)
deallocate (a)

a=b
print*,lbound(a),':',ubound(a)
deallocate (a)

contains
function foo(n)
integer :: n
real, allocatable :: foo(:)

allocate(foo(-3:n))

foo=n
end function
end program


You get:

   1 :   7
  -2 :   4

which is what you also get with Intel v14 and Crayftn 8.2.1.
However, xlf 14.1.0.5 agrees with you:

 -3 : 3
 -2 : 4

F2k8 states:

7.2.1.3 Interpretation of intrinsic assignments

If the variable is an unallocated allocatable array, expr shall have the same
rank. If the variable is an allocated
allocatable variable, it is deallocated if expr is an array of different shape, 
...
If the variable is or becomes an unallocated allocatable variable, it is then
allocated with
...
• if expr is an array, the shape of expr with each lower bound equal to the
corresponding element of
  LBOUND (expr ).

Thus the assignment from the allocatable function result is broken.

[Bug target/59401] New: [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

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

Bug ID: 59401
   Summary: [SH] GBR addressing mode optimization produces wrong
code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

The GBR addressing mode optimization which was added in 4.8 is buggy.
The following example:

struct tcb_t
{
  int x, y, z, w;
};

int test_00 (int a, tcb_t* b)
{
  tcb_t* tcb = (a & 5) ? (tcb_t*)__builtin_thread_pointer () : b;

  return tcb->w + tcb->x;
}

compiled with -O2 results in:

mov.l   @(12,gbr),r0
mov r0,r2
mov.l   @(0,gbr),r0
rts
add r2,r0

which is obviously wrong code.  This is because sh_find_base_reg_disp in sh.c
will step insns outside the current basic block without any further
considerations.  This is only OK to do if the predecessor basic block has a
fall through edge to the current basic block (i.e. there are no labels in
between).  Otherwise the address reg in question might be set in multiple basic
blocks which must be analyzed.
In the above test case GBR addressing modes can't be used actually.

[Bug target/59400] New: [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on big endian with FPU

[olegendo at gcc dot gnu.org]

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

Bug ID: 59400
   Summary: [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on
big endian with FPU
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

The test case gcc.c-torture/compile/pr55921.c has been failing for a while on
big endian targets with an FPU (e.g. SH4) when compiled with -O0.
Little endian seems OK.

typedef union
{
  _Complex float cf;
  long long ll;
} ucf;

void
foo (ucf *in, ucf *out, _Complex float r)
{
  int i;
  ucf ucf1;
  _Complex float cf;

  ucf1.ll = in[i].ll;
  __asm ("" : "=r" (cf) : "r" (ucf1.ll));
  cf *= r;
  __asm ("" : "=r" (ucf1.ll) : "r" (cf));
  out[i].ll = ucf1.ll;
}

compiled with -O0 -m4 -mb:

sh_tmp.cpp: In function 'foo':
sh_tmp.cpp:641:3: error: 'asm' operand requires impossible reload
   __asm ("" : "=r" (cf) : "r" (ucf1.ll));
   ^
sh_tmp.cpp:641:3: error: 'asm' operand requires impossible reload
sh_tmp.cpp:643:3: error: 'asm' operand requires impossible reload
   __asm ("" : "=r" (ucf1.ll) : "r" (cf));
   ^
sh_tmp.cpp:643:3: error: 'asm' operand requires impossible reload

[Bug target/59189] [SH] machine_dependent_reorg (sh_reorg) creates broken basic block structures

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Maybe adding a "conditional far branch" insn, as mentioned in PR 54762, would
fix this problem, or at least parts of it.

[Bug ada/36939] Build Failure Ada SH2e

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #22 from Oleg Endo  ---
I think this actual problem is the same as PR 34040.

[Bug middle-end/27906] reload allocates register of live register variable to earlyclobber output

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #2 from Oleg Endo  ---
I've tried this on rev 205674 (4.9) and it seems that time has fixed the issue.

[Bug middle-end/59399] ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-12-05
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Ouch.  Reproduced on ppc64.

[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))

[tmsriram at google dot com]

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

Sriraman Tallam  changed:

   What|Removed |Added

 CC||davidxl at google dot com

--- Comment #3 from Sriraman Tallam  ---
Removing the target attributes and using -ffast-math -ftree-vectorize -mfma on
the command line is still not producing vfmadd132sd insn. Investigating.

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Dec  5 19:39:39 2013
New Revision: 205718

URL: http://gcc.gnu.org/viewcvs?rev=205718&root=gcc&view=rev
Log:
2013-12-05  Vladimir Makarov  

PR rtl-optimization/59317
* lra-constraints.c (in_class_p): Don't ignore insn with constant
as a source.

2013-12-05  Vladimir Makarov  

PR rtl-optimization/59317
* testsuite/gcc.target/mips/pr59317.c: New.


Added:
trunk/gcc/testsuite/gcc.target/mips/pr59317.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
(In reply to Francois-Xavier Coudert from comment #11)
> As far as I can say, the targets with this problem are: avr, bfin, h8300,
> picochip and sh (for some subtargets of sh).
> 
> On avr, bfin, h8300 and picochip, we're doomed anyway because there is no
> double-sized type at all. On sh, we could use long double math calls.
> 
> I'm making this into an enhancement; it will probably be very painful,
> because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and
> DOUBLE_TYPE_SIZE == 64.

I think it would be easier to leave DOUBLE_TYPE_SIZE == 64 in all cases and use
software fp if the hardware can't do double precision.  If users insist on
doubles being automatically truncated to floats then there should be a compiler
switch for that.  E.g. on SH we have -m4-single-only option to control this. 
On SH2E code would then use hardware fp for floats and software fp for doubles
by default.

[Bug target/49468] SH Target: inefficient integer abs code

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #11 from Oleg Endo  ---
I think this can be closed.

[Bug middle-end/59399] ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner  ---
More hopefully useful gdb output:

(gdb) pr decl_rtl
(reg:DI 123 [ D.2805+-4 ])

(gdb) ptree exp
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xfffafec0690 precision
32 min  max 
pointer_to_this >
used ignored SI file bug.ii line 2 col 1 size  unit size 
align 32 context 
(reg:DI 123 [ D.2805+-4 ])>

(gdb) p DECL_MODE (exp)
$8 = SImode

(gdb) ptree ssa_name
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xfffafec0690 precision
32 min  max 
pointer_to_this >
visited var def_stmt _3 = UBSAN_CHECK_ADD
(j_1(D), i_2(D));

version 3>

[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

[tmsriram at google dot com]

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

--- Comment #3 from Sriraman Tallam  ---
JFYI, I am seeing this issue even in gcc-4.7.

[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
*** Bug 59052 has been marked as a duplicate of this bug. ***

[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jason Merrill  ---
This is indeed the same issue as 59044.

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

[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements

[pthaugen at gcc dot gnu.org]

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

--- Comment #12 from Pat Haugen  ---
Working on PowerPC also.

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Nobuhiro Iwamatsu from comment #4)
> Oleg and Kojima-san, thanks for your work.
> 
> Yes, I was building on SH native.
> And I am using gcc 4.6.3 version in the host.

Iwamatsu-san, if you have some time, could you please try building GCC 4.9? 
I'm sorry, but I don't have the right setup at hand to do it myself at the
moment.

Also, please notice that the current GCC 4.8 branch has some known problems in
the SH parts (produces wrong code) -- I'm working on back porting some patches
from 4.9.

[Bug target/59343] miscompiled for loop in sh4 target (-Os)

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
(In reply to gcc-bugzilla-f5d8 from comment #0)
> Created attachment 31327 [details]
> miscompilation testcase
> 
> The attached testcase miscompiles on sh4 target if build with -Os
> 

BTW thanks for the test case.  It's an interesting case for further
optimizations of the sh_treg_combine pass (see PR 51244 comment 72).

[Bug middle-end/59399] New: ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow

[bergner at gcc dot gnu.org]

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

Bug ID: 59399
   Summary: ICE in expand_expr_real_1 with -m64
-fsanitize=signed-integer-overflow
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org

On powerpc64-linux, I'm seeing a failure in the ubsan testsuite that causes an
ICE in expand_real_1, line 9484.  A simplified test case is:

[bergner@igoo BUGS]$ cat bug.ii 
void
foo (int i, int j)
{
  volatile int k = j + i;
}

[bergner@igoo BUGS]$ /home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc/cc1plus
-fpreprocessed -quiet -m64 -fsanitize=signed-integer-overflow bug.ii 
bug.ii: In function ‘void foo(int, int)’:
bug.ii:4:22: internal compiler error: in expand_expr_real_1, at expr.c:9484
   volatile int k = j + i;
  ^
0x107c1d2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.c:9484
0x107b9d57 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.c:7927
0x109590af expand_expr
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.h:453
0x1095a383 ubsan_expand_si_overflow_addsub_check(tree_code,
gimple_statement_base*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:182
0x1095b30f expand_UBSAN_CHECK_ADD
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:436
0x1095b467 expand_internal_call(gimple_statement_base*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:476
0x106071ab expand_call_stmt
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:2185
0x1060b9d3 expand_gimple_stmt_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:3154
0x1060c20f expand_gimple_stmt
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:3306
0x106149eb expand_gimple_basic_block
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5146
0x106170db gimple_expand_cfg
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5712
0x10617aff execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5932

We're dying in the gcc_assert below:

  /* Get the signedness to be used for this variable.  Ensure we get
 the same mode we got when the variable was declared.  */
  if (code == SSA_NAME
  && (g = SSA_NAME_DEF_STMT (ssa_name))
  && gimple_code (g) == GIMPLE_CALL)
{
  gcc_assert (!gimple_call_internal_p (g));
  pmode = promote_function_mode (type, mode, &unsignedp,
 gimple_call_fntype (g),
 2);
}

The debugger shows g to be:

(gdb) p *g
$1 = {code = GIMPLE_CALL, no_warning = 0, visited = 0, nontemporal_move = 0,
plf = 0, modified = 0, 
  has_volatile_ops = 0, subcode = 64, uid = 0, location = 2147483648, num_ops =
5, bb = 0xfffb0070208, 
  next = 0xfffb00a00a0, prev = 0xfffb00a00a0}

[Bug fortran/59398] New: Wrong bounds for allocatable result and for

[loximann at gmail dot com]

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

Bug ID: 59398
   Summary: Wrong bounds for allocatable result and for
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loximann at gmail dot com

The lower bounds of the result of an allocatable array-valued function are
always set to 1.

Also, I discovered that if LHS is allocated and has the same size as RHS, the
bounds are not changed.

This code illustrates it:

program return_allocatable
implicit none

real, allocatable :: a(:)

real, parameter :: b(-2:4)=[1,2,3,4,5,6,7]

a=foo(3)
print*,lbound(a),':',ubound(a)

a=b
print*,lbound(a),':',ubound(a)

contains
function foo(n)
integer :: n
real, allocatable :: foo(:)

allocate(foo(-3:n))

foo=n
end function
end program

The expected output is
-3:3
-2:4
but instead I get
1:7
1:7

[Bug ipa/58253] IPA-SRA creates calls with different arguments that the callee accepts

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Thu Dec  5 18:07:08 2013
New Revision: 205715

URL: http://gcc.gnu.org/viewcvs?rev=205715&root=gcc&view=rev
Log:
2013-12-05  Martin Jambor  

PR ipa/58253
* ipa-prop.c (ipa_modify_formal_parameters): Create decls of
non-BLKmode in their naturally aligned type.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Dec  5 18:03:44 2013
New Revision: 205714

URL: http://gcc.gnu.org/viewcvs?rev=205714&root=gcc&view=rev
Log:
PR sanitizer/59333
PR sanitizer/59397
* ubsan.c: Include rtl.h and expr.h.
(ubsan_encode_value): Add new parameter.  If expanding, assign
a stack slot for DECL_RTL of the temporary and call expand_assignment.
Handle BOOLEAN_TYPE and ENUMERAL_TYPE.
(ubsan_build_overflow_builtin): Adjust ubsan_encode_value call.
* ubsan.h (ubsan_encode_value): Adjust declaration.
* internal-fn.c (ubsan_expand_si_overflow_addsub_check): Move
ubsan_build_overflow_builtin above expand_normal call.  Surround this call
with push_temp_slots and pop_temp_slots.
(ubsan_expand_si_overflow_neg_check): Likewise.
(ubsan_expand_si_overflow_mul_check): Likewise.
testsuite/
* c-c++-common/ubsan/pr59333.c: New test.
* c-c++-common/ubsan/pr59397.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr59397.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c
trunk/gcc/ubsan.h

[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Dec  5 18:03:44 2013
New Revision: 205714

URL: http://gcc.gnu.org/viewcvs?rev=205714&root=gcc&view=rev
Log:
PR sanitizer/59333
PR sanitizer/59397
* ubsan.c: Include rtl.h and expr.h.
(ubsan_encode_value): Add new parameter.  If expanding, assign
a stack slot for DECL_RTL of the temporary and call expand_assignment.
Handle BOOLEAN_TYPE and ENUMERAL_TYPE.
(ubsan_build_overflow_builtin): Adjust ubsan_encode_value call.
* ubsan.h (ubsan_encode_value): Adjust declaration.
* internal-fn.c (ubsan_expand_si_overflow_addsub_check): Move
ubsan_build_overflow_builtin above expand_normal call.  Surround this call
with push_temp_slots and pop_temp_slots.
(ubsan_expand_si_overflow_neg_check): Likewise.
(ubsan_expand_si_overflow_mul_check): Likewise.
testsuite/
* c-c++-common/ubsan/pr59333.c: New test.
* c-c++-common/ubsan/pr59397.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c
trunk/gcc/testsuite/c-c++-common/ubsan/pr59397.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c
trunk/gcc/ubsan.h

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

[olegendo at gcc dot gnu.org]

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

--- Comment #72 from Oleg Endo  ---
The original test case in PR 59343 is an interesting one with regard to T bit
optimizations (or the lack thereof):

void validate_number (char **numbertext)
{
  char *ptr = *numbertext;
  int valid = (ptr != 0) && (*ptr);

  for ( ; valid && *ptr; ++ptr)
valid = (*ptr >= '0');

  if (!valid)
*numbertext = 0;
}

with -Os -m4 -mb it is compiled to:

_validate_number:
mov.l   @r4,r2// [bb 2]
tst r2,r2
bt/s.L2
mov #0,r1


mov.b   @r2,r1// [bb 3]
tst r1,r1
mov #-1,r1
negcr1,r1

.L2:  // [bb 4]
mov #47,r3

.L3:  // [bb 5]
tst r1,r1
bt  .L4

mov.b   @r2+,r1   // [bb 6]
tst r1,r1
bt/s.L8

cmp/gt  r3,r1 // [bb 7]

bra .L3
movtr1

.L4:
mov.l   r1,@r4   // [bb 8]
.L8:
rts
nop


The basic block starting with L3 (bb 5) has three different r1 inputs from [bb
2], [bb 3] and [bb 7].  When sh_treg_combine tries to trace r1 starting in [bb
5]:

tracing (reg/v:SI 1 r1 [orig:185 valid ] [185])

[bb 5]
set of reg not found.  empty BB?

[bb 4]
set of reg not found (cstore)
set not found - aborting trace

Instead it should skip [bb 4] as it doesn't modify r1 or T bit and check [bb 3]
and [bb 2].  Because the setcc insns are not the same in [bb 2], [bb 3] and [bb
7], it would try to eliminate the cstores.  However, in [bb 2] there is no real
cstore but a constant load, which can be replaced with a clrt or sett insn
respectively.  The resulting code could be something like:

mov.l   @r4,r2
mov #0,r1
tst r2,r2
bt/s.L2 // (*)
clrt

mov.b   @r2,r1
tst r1,r1
movtr1
tst r1,r1// T = !T
.L2:
mov #47,r3
.L3:
bf  .L4

mov.b   @r2+,r1
tst r1,r1
bt/s.L8
bra .L3
cmp/gt  r3,r1
.L4:
mov.l   r1,@r4
.L8:
rts
nop

(*) The clrt insn actually has to be inserted before the conditional branch,
which is impossible as it modifies the branch condition.  Putting it into the
delay slot however is OK, which is usually done by the DBR pass.  A special
"branch and set/clear T" pseudo insn would be required (requires SH2+) which
produces the sequence above.  A more complicated way would be to create new
basic blocks.

The basic block reordering or similar RTL pass and the clrt/sett optimization
pass should then be able to simplify the code further to:

mov.l   @r4,r2
tst r2,r2
bf/s.L4
mov #0,r1

mov.b   @r2,r1
tst r1,r1
bt/s.L4
mov #47,r3
.L3:
mov.b   @r2+,r1
tst r1,r1
bt/s.L8
cmp/gt  r3,r1
bt  .L3
.L4:
mov.l   r1,@r4
.L8:
rts
nop

[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #5)
> How fast is your box?  I'm using 4  processors on a calxeda system...  It's
> painful, particularly when the first calxeda box's disk died, thus losing my
> build trees & test results.

I'm using a Chromebook with 2 Cortex-A15s.

I think it took about 5-6 hours to bootstrap last time I tried.
I have a feeling your system might be faster :(

[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
How fast is your box?  I'm using 4  processors on a calxeda system...  It's
painful, particularly when the first calxeda box's disk died, thus losing my
build trees & test results.

[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Working on this again.  I'm on the 4th iteration of the fix.  Bootstrapping on
ARM boxes is painfully slow :(

[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #3)
> Working on this again.  I'm on the 4th iteration of the fix.  Bootstrapping
> on ARM boxes is painfully slow :(

I could bootstrap a patch on arm-none-linux-gnueabihf if you'd like.

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[nheghathivhistha at gmail dot com]

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

--- Comment #6 from David Kredba  ---
I "reduced" it to this:

/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -O2 -ggdb -pipe -march=native
-mtune=native -flto=4 -fuse-linker-plugin  -Wnon-virtual-dtor -Wno-long-long
-Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common
-Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
-fvisibility-inlines-hidden -Wl,--enable-new-dtags -Wl,--no-undefined -lc 
-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe
-march=native -mtune=native -flto=4 -fuse-linker-plugin -shared
-Wl,-soname,kigpart.so -o lib/kigpart.so
CMakeFiles/kigpart.dir/scripting/python_scripter.o -L/usr/lib64/qt4
/usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkutils.so.4.11.4 -lpython2.7
/usr/lib64/libboost_python-2.7-mt.so /usr/lib64/libktexteditor.so.4.11.4
/usr/lib64/libkemoticons.so.4.11.4 /usr/lib64/libkidletime.so.4.11.4
/usr/lib64/libkcmutils.so.4.11.4 /usr/lib64/libkprintutils.so.4.11.4
/usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkio.so.5.11.4
/usr/lib64/qt4/libQtNetwork.so /usr/lib64/qt4/libQtXml.so
/usr/lib64/libnepomukutils.so.4.11.4 /usr/lib64/libnepomuk.so.4.11.4
/usr/lib64/libkdeui.so.5.11.4 /usr/lib64/qt4/libQtGui.so
/usr/lib64/qt4/libQtSvg.so -lsoprano /usr/lib64/libkdecore.so.5.11.4
/usr/lib64/qt4/libQtCore.so -lpthread /usr/lib64/qt4/libQtDBus.so
-Wl,-rpath,/usr/lib64/qt4: -nostdlib
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

All othe object files removed not let the ICE away. When python_scripter.o
removed and other object files present on link command it did this:

/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base
const*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function
`__gnu_cxx::new_allocator::allocate(unsigned long, void const*)
[clone .isra.61]':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:104:
undefined reference to `operator new(unsigned long)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base
const*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `void std::vector
>::_M_range_initialize
>(std::_Rb_tree_const_iterator,
std::_Rb_tree_const_iterator, std::forward_iterator_tag) [clone
.isra.90]':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:102:
undefined reference to `std::__throw_bad_alloc()'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base
const*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function
`__gnu_cxx::new_allocator::allocate(unsigned long, void const*)
[clone .isra.61]':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:104:
undefined reference to `operator new(unsigned long)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270:
undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base
const*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110:
undefined reference to `operator delete(void*)'
/tmp/ccXU2sDY.ltrans13.ltrans.o: In function `void std::vector
>::_M_range_initialize
>(std::_Rb_tree_const_iterator,
std::_Rb_tree_const_iterator, std::forward_iterator_tag) [clone
.isra.90]':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:102:
undefined reference to `std::__throw_bad_alloc()'
/tmp/cc

[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Reduced testcase for c-c++-common:

typedef enum E { A = -1 } e;
int
foo (void)
{
  e e = A;
  return e + 1;
}

[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-12-05
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Yeah, the problem is that we don't handle ENUMERAL_TYPEs (nor BOOLEAN_TYPEs). 
Will be fixed as a part of PR59333 fix.  Thanks for report.

[Bug sanitizer/59397] New: ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow

[burnus at gcc dot gnu.org]

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

Bug ID: 59397
   Summary: ICE in ubsan_encode_value, at ubsan.c:143 for
-fsanitize=signed-integer-overflow
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org

Created attachment 31388
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31388&action=edit
C++ test case, run as g++ -fsanitize=signed-integer-overflow

The attached test case fails with:

$ g++ -fsanitize=signed-integer-overflow -S test12.ii

test12.ii: In function 'int s_vectorizeLoop()':
test12.ii:15:29: internal compiler error: in ubsan_encode_value, at ubsan.c:143
   dir = three::direction( t + dir );
 ^
0xbc9f03 ubsan_encode_value(tree_node*)
../../gcc/ubsan.c:143
0xbcb814 ubsan_build_overflow_builtin(tree_code, unsigned int, tree_node*,
tree_node*, tree_node*)
../../gcc/ubsan.c:667
0xa2c020 ubsan_expand_si_overflow_addsub_check(tree_code,
gimple_statement_base*)
../../gcc/internal-fn.c:175

[Bug target/59396] [avr] Wrong warning with ISR() and -flto

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target||avr
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-05
 Ever confirmed|0   |1

[Bug target/59396] New: [avr] Wrong warning with ISR() and -flto

[gjl at gcc dot gnu.org]

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

Bug ID: 59396
   Summary: [avr] Wrong warning with ISR() and -flto
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org

Created attachment 31387
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31387&action=edit
isr.c: The C source

Following source will throw a warning if compiled, e.g., 

$ avr-gcc isr.c -mmcu=atmega8 -flto


#define __INTR_ATTRS used, externally_visible

#define ISR(vector,...) \
void vector (void) __attribute__ ((signal,__INTR_ATTRS)) __VA_ARGS__; \
void vector (void)

#define ADC_vect __vector_14


ISR (ADC_vect)
{
}

int main()
{
return 0;
}


The defines are copy-pased from AVR-Libc and are the most common way to define
interrupt service routines: Use ISR() with a isr vector name.

The warning is:

In function '__vector_14':
isr.c:10:1: warning: '_vector_14' appears to be a misspelled signal handler
[enabled by default]
 ISR (ADC_vect)
 ^

[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
  Known to work||4.7.2, 4.9.0
Summary|internal compiler error |[4.8 Regression] internal
   |(memory access error)   |compiler error (memory
   ||access error)
  Known to fail||4.8.3

--- Comment #1 from Joost VandeVondele  
---
fails with 4.8.3, works with trunk and 4.7

[Bug fortran/59395] New: internal compiler error (memory access error)

[demarchie at web dot de]

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

Bug ID: 59395
   Summary: internal compiler error (memory access error)
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demarchie at web dot de

I receive an ICE when compiling this source code with 4.8.1 and 4.8.2:

module mymod
  implicit none

  integer, parameter :: k = selected_real_kind(1,1) ! no bug with k = 4

  type t
   integer   :: m   ! can't swap this line with next one
   procedure(f), pointer, nopass :: a,b ! have to be at least two of them
  end type

  interface
integer function f(n)
  integer :: n
end function
  end interface

end module mymod

program test
  use mymod
end program test

*

Output from gfortran source.f90 -save-temps -v

1 gfortran 4.8.1 on OpenBSD/macppc

Driving: egfortran source.f90 -save-temps -v -l gfortran -l m
Using built-in specs.
COLLECT_GCC=egfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-unknown-openbsd5.4/4.8.1/lto-wrapper
Target: powerpc-unknown-openbsd5.4
Configured with: /usr/obj/ports/gcc-4.8.1/gcc-4.8.1/configure --enable-libgcj
--without-jar --verbose --program-transform-name='s,^,e,' --disable-nls
--disable-checking --with-system-zlib --disable-libmudflap --disable-libgomp
--disable-tls --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld
--with-gnu-as --enable-threads=posix --enable-wchar_t --with-gmp=/usr/local
--enable-languages=c,c++,fortran,objc,java --disable-libstdcxx-pch --enable-cpp
--enable-shared --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man
--infodir=/usr/local/info --localstatedir=/var --disable-silent-rules
Thread model: posix
gcc version 4.8.1 (GCC) 
COLLECT_GCC_OPTIONS='-save-temps' '-v'
 /usr/local/libexec/gcc/powerpc-unknown-openbsd5.4/4.8.1/f951 source.f90 -quiet
-dumpbase source.f90 -auxbase source -version -fintrinsic-modules-path
/usr/local/lib/gcc/powerpc-unknown-openbsd5.4/4.8.1/finclude -o source.s
GNU Fortran (GCC) version 4.8.1 (powerpc-unknown-openbsd5.4)
compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.8.1 (powerpc-unknown-openbsd5.4)
compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=131072
f951 in free(): error: chunk is already free 0x86f96060
f951 in malloc(): error: recursive call
egfortran: internal compiler error: Abort trap (program f951)
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


2 gfortran 4.8.2-1 from fink on macppc OS 10.4

Angesteuert: /sw/bin/gfortran -mmacosx-version-min=10.4 source.f90 -save-temps
-v -l gfortran -shared-libgcc
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=/sw/bin/gfortran
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/lto-wrapper
Ziel: powerpc-apple-darwin8.11.0
Konfiguriert mit: ../gcc-4.8.2/configure --prefix=/sw AS=odas
AS_FOR_TARGET=odas NM_FOR_TARGET=odnm LD_FOR_TARGET=odld AR_FOR_TARGET=odar
LIPO_FOR_TARGET=odlipo OBJDUMP_FOR_TARGET=odobjdump RANLIB_FOR_TARGET=odranlib
STRIP_FOR_TARGET=odstrip --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 --with-dwarf2
--disable-libjava-multilib --disable-libquadmath
Thread-Modell: posix
gcc-Version 4.8.2 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-save-temps' '-v'
'-shared-libgcc'
 /sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/f951 source.f90
-fPIC -quiet -dumpbase source.f90 -mmacosx-version-min=10.4 -auxbase source
-version -fintrinsic-modules-path
/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/finclude -o source.s
GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0)
kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version
3.1.2, MPC-Version 1.0.1.
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0)
kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version
3.1.2, MPC-Version 1.0.1.
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[address=61707265 pc=00826c94]
source.f90: In Funktion »main«:
source.f90:20:0: interner Compiler-Fehler: Speicherzugriffsverletzung [*]
   use mymod
 ^
libbacktrace could not find exe

[Bug middle-end/58956] [4.7/4.8 Regression] wrong code at -O1 and above (affecting gcc 4.6 to trunk)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  5 13:10:20 2013
New Revision: 205709

URL: http://gcc.gnu.org/viewcvs?rev=205709&root=gcc&view=rev
Log:
2013-12-05  Richard Biener  

Backport from mainline
2013-11-19  Richard Biener  

PR middle-end/58956
* tree-ssa-ter.c (find_replaceable_in_bb): Avoid forwarding
loads into stmts that may clobber it.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58956.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-ssa-ter.c

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #3 from Dmitry G. Dyachenko  ---
first FAIL r205461

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #16 from Marek Polacek  ---
(In reply to Jan-Benedict Glaw from comment #15)
> Some fallout for an unused variable, see eg.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 :
> 
> g++ -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC 
> -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
> -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc
> -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include
> -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
> -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
> -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o
> c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF
> c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c
> ../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node*
> c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’:
> ../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’
> [-Werror=unused-variable]
> tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE,
>  ^
> cc1plus: all warnings being treated as errors

Should be fixed now.

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[jpakkane at gmail dot com]

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

--- Comment #5 from jpakkane at gmail dot com ---
I retried this with Gcc 4.8.2 on trusty and no longer get the crash. I have not
tried to reproduce David Kredba's issue so that might still remain.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-05
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
Btw, the change suggests a workaround - use -fwrapv.  And indeed, the
loop does not terminate for c == 32768, but that's a "bug" in the testcase,
  signed short < 32768
is always true (both promote to int, and i++ wraps at 32767).

That i++ now correctly wraps 'defined' also means that IV analysis is
pessimized as it can not assume that 'i' does not wrap nor can it assume
that the loop terminates.

But that's just the awkward way the testcase is written (without the
C standard in mind ...).

You may also try -funsafe-loop-optimizations that makes us optimistically
assume IVs don't overflow and loops terminate.

"confirmed", but I think this one needs more analysis on _what_ transform
we want to happen and then get assessment on if that is a valid transform
at all.

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[octoploid at yandex dot com]

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

--- Comment #4 from Markus Trippelsdorf  ---
I've tested this on my Gentoo box and cannot reproduce the issue
on trunk or gcc-4.8 branch. 
So it is most likely already fixed.

[Bug c++/59394] Unused code generated

[smal.root at gmail dot com]

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

--- Comment #1 from smalcom  ---
Created attachment 31386
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31386&action=edit
generated assembly

[Bug c++/59394] New: Unused code generated

[smal.root at gmail dot com]

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

Bug ID: 59394
   Summary: Unused code generated
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smal.root at gmail dot com
Target: AVR

Created attachment 31385
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31385&action=edit
source code

GCC:
avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.8.2/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-4.8.2/configure
--disable-cloog-version-check --disable-install-libiberty --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions
--disable-linker-build-id --disable-nls --disable-werror --enable-__cxa_atexit
--enable-checking=release --enable-clocale=gnu --enable-cloog-backend=isl
--enable-gnu-unique-object --enable-gold --enable-languages=c,c++
--enable-ld=default --enable-lto --enable-plugin --enable-shared
--infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --prefix=/usr --target=avr --with-as=/usr/bin/avr-as
--with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld --with-plugin-ld=ld.gold
--with-system-zlib
Thread model: single
gcc version 4.8.2 (GCC) 

OS:
Arch Linux 
Linux 3.12.0-1-ARCH #1 SMP PREEMPT Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux

Command line:
avr-gcc -Wall -mmcu=atxmega64a3 -DF_CPU=1600UL  -mno-interrupts -Os
-pedantic-errors -pedantic -std=c++11 -Wfatal-errors -Wall   
-I/usr/avr/include  -c main.cpp -o obj/Release/main.o
main.cpp: In function 'int main()':
main.cpp:55:21: warning: variable 'tval32' set but not used
[-Wunused-but-set-variable]
   volatile uint32_t tval32;
 ^
avr-g++  -o bin/Release/lambda_test.elf obj/Release/main.o   -mmcu=atxmega64a3
-Wl,-Map=bin/Release/lambda_test.map,--cref  
Output size is 7,92 KB
Running project post-build steps
avr-size bin/Release/lambda_test.elf
   text   databssdechexfilename
850  0   2400   3250cb2   
bin/Release/lambda_test.elf
avr-objdump -h -S bin/Release/lambda_test.elf > bin/Release/lambda_test.lss
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 1 warnings (0 minutes, 0 seconds)

Source file: attached main.cpp
Generated assembly: attached lambda_test.lss

Problem.
A. As you can see in generated assembly:
1. function Sort_OldStyle(_Z13Sort_OldStylev) contain(as inline) functions Sort
and Sort_OldStyle_Internal
2. function Sort_NewStyle(_Z13Sort_NewStylev) contain(as inline) functions Sort
and lambda-expression

B. But also generated code contain unneded:
1. function Sort(_Z4SortPV5SPairS1_PFvRS0_E)
2. function Sort_OldStyle_Internal(_Z22Sort_OldStyle_InternalRV5SPair)
3. lambda-expression(_ZZ13Sort_NewStylevENUlRV5SPairE_4_FUNES1_)

Why gcc include functions from B-list if they already exist in functions of
list A? Also why gcc use inline for function Sort and don't use call with -Os
used?

[Bug c++/59381] ICE in get_expr_operands, in tree-ssa-operands.c:1035

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed in 4.7.3.

[Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work|4.8.2   |
Summary|[4.9 Regression] ICE on |[4.7/4.8/4.9 Regression]
   |valid code at -O1 and above |ICE on valid code at -O1
   |on x86_64-linux-gnu |and above on
   ||x86_64-linux-gnu
  Known to fail||4.8.2

--- Comment #3 from Jakub Jelinek  ---
This really is 4.7+ regression, you just need --enable-checking=yes compiler on
the branches to reproduce (otherwise it is a silent wrong-code ? ).
I'll have a look soon.

[Bug tree-optimization/59387] wrong code (hangs) at -Os on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-05
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

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

[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-12-05
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Can you try a GCC 4.9 prerelease?  The usual workaround is to disable debuginfo
generation.

And yes, reducing the testcase to a few input files is necessary - you
can bisect the linker inputs by adding -r -nostdlibs (performing a partial
link).

[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-05
 Ever confirmed|0   |1
  Known to fail||4.7.3, 4.8.2, 4.9.0

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

[Bug target/59393] [4.8/4.9 regression] mips16 code size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||mips16
   Target Milestone|--- |4.8.3

--- Comment #1 from Richard Biener  ---
  :
  s_4 = &key_3(D)->S[0];
...
  _15 = _14 * 8;
  _16 = s_4 + _15;
  _17 = *_16;
...
  _21 = _20 * 8;
  _22 = s_4 + _21;
  _23 = *_22;
...

formerly we'd have created

  _17 = MEM[key_3].S[_14];
...
  _23 = MEM[key_3].S[_20];

which isn't a valid transform.  That eventually gets us better addressing
mode selection?  At RTL this probably (didn't verify) re-associates the
key_3 + offsetof(S) + index * 8 expression to a more suitable way and
by-passes the multiple-use restriction of combine (forwprop here un-CSEs
key_3 + offsetof(S)).

In a loop IVOPTs would be the one to utilize target addressing mode
information and eventually generate a TARGET_MEM_REF.  In non-loops
we have SLSR (gimple-ssa-strength-reduction.c) that could serve as a
vehicle to generate TARGET_MEM_REFs (it doesn't).

In the end I would point at RTL forwprop which is supposed to improve
addressing-mode selection.  At least on x86_64 I see

leaq144(%rsi), %rax
...
xorq4096(%rax,%rbx,8), %r8
addl6144(%rax,%r9,8), %r8d

as well (and %rsi is live as well), instead of folding the 144 into
the dereference offset.

forwprop sees

(insn 8 5 9 2 (parallel [
(set (reg/v/f:DI 85 [ s ])
(plus:DI (reg/v/f:DI 991 [ key ])
(const_int 144 [0x90])))
(clobber (reg:CC 17 flags))
...
(insn 20 19 21 3 (set (reg:DI 998 [ *_22 ])
(mem:DI (plus:DI (mult:DI (reg:DI 995)
(const_int 8 [0x8]))
(reg/v/f:DI 85 [ s ])) [2 *_22+0 S8 A64]))
...

and then combine folds in an additional addition:

Trying 18 -> 20:
Successfully matched this instruction:
(set (reg:DI 998 [ *_22 ])
(mem:DI (plus:DI (plus:DI (mult:DI (reg:DI 994 [ D.1883 ])
(const_int 8 [0x8]))
(reg/v/f:DI 85 [ s ]))
(const_int 2048 [0x800])) [2 *_22+0 S8 A64]))

but of course doesn't consider insn 8 (it's cross basic-block and it has
multiple uses).

Now there isn't any further forwprop pass after combine (which would maybe
now fold in the addition - not sure).  Certainly ira/lra/reload do not
consider materializing the def in-place either instead of spilling it
for you.

Not sure how the situation is on mips16, but in the end RTL optimizers
are supposed to fixup anything related to addressing mode selection.

[Bug sanitizer/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org
  Component|bootstrap   |sanitizer
 Resolution|--- |FIXED

--- Comment #7 from Dmitry Gorbachev  ---
.

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[robert.suchanek at imgtec dot com]

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

--- Comment #5 from Robert Suchanek  ---
Dump attached. 

Ah, it's not triggered on mips16-linux target but mips-elf. I double checked it
with the same svn revision.

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[robert.suchanek at imgtec dot com]

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

--- Comment #4 from Robert Suchanek  ---
Created attachment 31384
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31384&action=edit
LRA dump for testcase

[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin

[y.gribov at samsung dot com]

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

--- Comment #5 from Yury Gribov  ---
Mac should be fine now. Jack, could you check and close?

[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin

[ygribov at gcc dot gnu.org]

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

--- Comment #4 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Dec  5 10:00:47 2013
New Revision: 205699

URL: http://gcc.gnu.org/viewcvs?rev=205699&root=gcc&view=rev
Log:
2013-12-05  Yury Gribov  

PR sanitizer/59369
* c-c++-common/asan/pr59063-1.c: Disable on non-Linux platforms.
* c-c++-common/asan/pr59063-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/pr59063-1.c
trunk/gcc/testsuite/c-c++-common/asan/pr59063-2.c

[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place

[y.gribov at samsung dot com]

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

--- Comment #6 from Yury Gribov  ---
Dmitry, please close if trunk works for you.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jbg...@lug-owl.de]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 CC||jbg...@lug-owl.de

--- Comment #15 from Jan-Benedict Glaw  ---
Some fallout for an unused variable, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 :

g++ -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../../gcc/gcc/../libbacktrace-o c-family/c-common.o -MT
c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo
../../../gcc/gcc/c-family/c-common.c
../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node*
c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’:
../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’
[-Werror=unused-variable]
tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE,
 ^
cc1plus: all warnings being treated as errors

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org
  Known to work||4.9.0
Summary|[4.7, 4.8, 4.9 Regression]  |[4.7, 4.8 Regression]
   |regcprop incorrectly looks  |regcprop incorrectly looks
   |through parallel register   |through parallel register
   |swap operation  |swap operation
  Known to fail|4.9.0   |

--- Comment #14 from Steven Bosscher  ---
fixed on trunk, see comment #13

[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place

[ygribov at gcc dot gnu.org]

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

--- Comment #5 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Dec  5 09:56:03 2013
New Revision: 205698

URL: http://gcc.gnu.org/viewcvs?rev=205698&root=gcc&view=rev
Log:
2013-12-05  Yury Gribov  

PR sanitizer/59368
* Makefile.am (gcc_version): Added gcc_version.
* Makefile.in: Regenerate.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/Makefile.am
trunk/libsanitizer/Makefile.in

[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #10)
> Maybe it works now.

PASSes on arm* now, thanks.

[Bug tree-optimization/59374] [4.8 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 Regression]|[4.8 Regression]
   |-ftree-slp-vectorize breaks |-ftree-slp-vectorize breaks
   |unique_ptr's move   |unique_ptr's move
   |constructor |constructor
  Known to fail|4.9.0   |

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

[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0

--- Comment #10 from Richard Biener  ---
Maybe it works now.

[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  5 09:20:51 2013
New Revision: 205696

URL: http://gcc.gnu.org/viewcvs?rev=205696&root=gcc&view=rev
Log:
2013-12-05  Richard Biener  

PR tree-optimization/56787
* gcc.dg/vect/pr56787.c: Adjust to not require vector float
division.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr56787.c

[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  5 09:12:29 2013
New Revision: 205694

URL: http://gcc.gnu.org/viewcvs?rev=205694&root=gcc&view=rev
Log:
2013-12-05  Richard Biener  

PR tree-optimization/59374
* tree-vect-data-refs.c (vect_slp_analyze_data_ref_dependence):
Commonize known and unknown dependence case fixing the allowed
read-write dependence case and dropping code that should not
matter.

* gcc.dg/torture/pr59374-1.c: New testcase.
* gcc.dg/torture/pr59374-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr59374-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr59374-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

Summary|[4.8/4.9 Regression]|[4.8 Regression] failure
   |failure building CP2K at|building CP2K at -flto -O2
   |-flto -O2   |

--- Comment #13 from Joost VandeVondele  
---
The 4.9 problem is gone, not sure which revision fixed this, the only thing I
noticed was this comment.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c195

and I have now a couple of LTO builds as part of our daily gcc tester, so I'll
notice quickly if it regresses.

Not sure if it is worth keeping the bug open for 4.8, I guess there will be
other issues popping up with 4.8 anyway.

[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin

[glider at google dot com]

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

--- Comment #3 from Alexander Potapenko  ---
Should be fine to disable this test on Darwin due to what Yury said.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
enough --enable-checking=yes

[Bug c/55125] segfault when declaration of the struct's array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Marek Polacek  ---
Closing.