[Bug tree-optimization/58180] New: [4.9 regression] ICE in obj_type_ref_class, at tree.c:11876

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

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

Bug ID: 58180
   Summary: [4.9 regression] ICE in obj_type_ref_class, at
tree.c:11876
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: jh at suse dot cz
Target: m68k-*-*

Broken by r201789.

libtool: compile:  /daten/aranym/gcc/test/./gcc/xgcc
-B/daten/aranym/gcc/test/./gcc/ -B/daten/cross/m68k-linux/m68k-linux/bin/
-B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
/daten/cross/m68k-linux/m68k-linux/include -isystem
/daten/cross/m68k-linux/m68k-linux/sys-include
/daten/aranym/gcc/gcc/libobjc/accessors.m -c -I.
-I/daten/aranym/gcc/gcc/libobjc -O2 -g -W -Wall -Wwrite-strings
-Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions
-I/daten/aranym/gcc/gcc/libobjc/../gcc
-I/daten/aranym/gcc/gcc/libobjc/../gcc/config -I../.././gcc
-I/daten/aranym/gcc/gcc/libobjc/../libgcc -I../libgcc
-I/daten/aranym/gcc/gcc/libobjc/../include -fgnu-runtime  -fPIC -DPIC -o
.libs/accessors.o
/daten/aranym/gcc/gcc/libobjc/accessors.m: In function ‘objc_getProperty’:
/daten/aranym/gcc/gcc/libobjc/accessors.m:127:11: internal compiler error: in
obj_type_ref_class, at tree.c:11876
result = RETAIN (*(pointer_to_ivar));
   ^
0xb27f56 obj_type_ref_class(tree_node*)
../../gcc/gcc/tree.c:11876

(gdb) p ref@entry
$2 = (tree) 0x76b765a0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
HI
size 
unit size 
align 16 symtab 0 alias set -1 canonical type 0x76b7d150
arg-types 
chain 
chain >>>
pointer_to_this >
unsigned SI
size 
unit size 
align 16 symtab 0 alias set -1 canonical type 0x76b7d1f8>

arg 0 
unsigned SI size  unit size

align 16 symtab 0 alias set -1 canonical type 0x76b0>
used unsigned ignored SI file /daten/aranym/gcc/gcc/libobjc/accessors.m
line 127 col 4 size  unit size 
align 16 context 
chain 
used unsigned ignored SI file
/daten/aranym/gcc/gcc/libobjc/accessors.m line 127 col 4 size  unit size 
align 16 context 
chain >> arg 1 
arg 2  constant 0>>

[Bug tree-optimization/58180] [4.9 regression] ICE in obj_type_ref_class, at tree.c:11876

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

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

--- Comment #1 from Andreas Schwab  ---
Created attachment 30667
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30667&action=edit
Preprocessed source

[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
confirmed on x86_64-darwin10/12.
possibly something needs to be updated in the emutls implementation?

$ nm -g gcc/libgcov.a |grep gcov_indirect_call_callee
00a0 D ___emutls_v.__gcov_indirect_call_callee

[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #2)
> confirmed on x86_64-darwin10/12.
> possibly something needs to be updated in the emutls implementation?
> 
> $ nm -g gcc/libgcov.a |grep gcov_indirect_call_callee
> 00a0 D ___emutls_v.__gcov_indirect_call_callee

.. at least, 
pass_ipa_profile is running _after_ pass_ipa_lower_emutls.

[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER

[heroxbd at sohu dot com]

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

Benda Xu  changed:

   What|Removed |Added

 CC||heroxbd at sohu dot com

--- Comment #4 from Benda Xu  ---
(In reply to Jakub Jelinek from comment #2)
> Just use -Wl,-dynamic-linker=/whatever/ld.so 

-Wl,-dynamic-linker=/whatever/ld.so cannot be set permanently. It requires a
wrapper to inject such argument all the time, which is ugly.

> or you could use --with-specs configure option.

Builtin specs of GCC is already very complicated (output from gcc-4.7.3
-dumpspecs on amd64):

...

*link:
%{!static:--eh-frame-hdr} %{m32|mx32:;:-m elf_x86_64}   
%{m32:-m elf_i386}%{mx32:-m elf32_x86_64}  
%{shared:-shared}   %{!shared: %{!static:   %{rdynamic:-export-dynamic}
  %{m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/lib/ld-linux.so.2}}}
  %{m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/lib64/ld-linux-x86-64.so.2}}}
  %{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:/libx32/ld-linux-x32.so.2
%{static:-static}}

...

writing an equivalent specs with prefixed dynamic linker is horrible.

Please consider sopport dynamic linker prefix by an extra configure option.

[Bug target/58132] x86-64 gcc generate wrong movabs code for intel syntax

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg00669.htm
   ||l
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.4

--- Comment #1 from Uroš Bizjak  ---
Fixed everywhere.

[Bug c++/58178] variant function name was used for user defined constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Normally both _ZN4baseC2Ev and _ZN4baseC1Ev are emitted, with the latter being
an alias for the former.  Works just fine on Linux at least.

[Bug tree-optimization/58180] [4.9 regression] ICE in obj_type_ref_class, at tree.c:11876

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|m68k-*-*|
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-17
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |blocker

--- Comment #2 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin10. Looking at
http://gcc.gnu.org/ml/gcc-regression/2013-08/ r201789 breaks bootstrap on most
if not all platforms.

[Bug tree-optimization/58180] [4.9 regression] ICE in obj_type_ref_class, at tree.c:11876

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
Dup of 58179.

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

[Bug middle-end/58179] [4.9 Regression] obj_type_ref ICE building libobjc

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #2 from Dominique d'Humieres  ---
*** Bug 58180 has been marked as a duplicate of this bug. ***

[Bug middle-end/58179] [4.9 Regression] obj_type_ref ICE building libobjc

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P1
   Severity|normal  |blocker

--- Comment #3 from Dominique d'Humieres  ---
Broken by r201789, bootstrapping with objc fails.

[Bug c++/58130] [C++11] Compilation fails using "const decltype(...)& getter() const {...}"

[vittorio.romeo at outlook dot com]

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

Vittorio Romeo  changed:

   What|Removed |Added

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

--- Comment #3 from Vittorio Romeo  ---
This is not a bug, sorry for reporting it. 
I've ran some tests and it was my fault.

[Bug middle-end/58179] [4.9 Regression] obj_type_ref ICE building libobjc

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Mine. Looking into it now.  Obviously obj-C uses OBJ_TYPE_REF in an unexpected
way.

[Bug c++/58181] New: A bug in lambda expression

[fimbul77 at gmail dot com]

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

Bug ID: 58181
   Summary: A bug in lambda expression
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fimbul77 at gmail dot com

Following the code:

#include 
#include 

int main()
{
assert(std::get<0>(
[]() {
int x = 0;
return std::forward_as_tuple([=]() -> int {
return x;
});
}()
)() == 0);
}

The assertion fails in gcc.(but only gcc4.6.4 succeed it)
But I think it must be success.
The variable x in [=]() -> int { return x; } should not garbage.
It may be a lambda expression bug.

Wandbox
http://melpon.org/wandbox/permlink/MRhUXl888hCZAQcx

[Bug c++/58181] A bug in lambda expression

[fimbul77 at gmail dot com]

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

--- Comment #1 from fimbul77 at gmail dot com ---
sorry, my code was wrond.

Following the code :
#include 
#include 

int main()
{
static const auto factory = []() {
int x = 0;

return [=]() mutable {
return std::forward_as_tuple(
   [&]() -> int { return x; }
   );
};
};

auto f1 = factory();
assert(std::get<0>(f1())() == 0); // f1.x == 0
}

[Bug c++/58181] A bug in lambda expression

[fimbul77 at gmail dot com]

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

fimbul77 at gmail dot com changed:

   What|Removed |Added

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

--- Comment #2 from fimbul77 at gmail dot com ---
 It was my mistake.

[Bug c++/58181] A bug in lambda expression

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
My understanding is that the presented program has undefined behaviour and that
its assertion may fail or may not. The reason being that the outer lambda
expression has return type std::tuple (where LI stands for an invented
name for the inner lambda closure type), but during runtime the reference in
the tuple refers to a temporary of LI created within the operator() body of the
outer lambda closure type LO that has been gone out of existence after the
function call has been finished.

The following code represents a translation of the single expression to
equivalent C++ code w/o use of any lambda expressions:

#include 
#include 

struct LI
{
  LI(int x) : x(x) {}
  int operator()() const { return x; }
  int x;
};

struct LO
{
  std::tuple operator()() const
  {
int x = 0;
return std::forward_as_tuple(LI(x));
  }
};

int main()
{
  assert(std::get<0>(LO{}())() == 0);
}

This rewrite makes the invalid code more obvious.

[Bug fortran/58182] New: ICE with global binding name used as a FUNCTION

[abensonca at gmail dot com]

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

Bug ID: 58182
   Summary: ICE with global binding name used as a FUNCTION
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following leads to an ICE with gfortran 4.9.0 (r201758):

$ cat mod1.F90
module fg
  use, intrinsic :: iso_c_binding
contains
  function fffi(f)
interface
   function f() bind(c)
   end function f
end interface
  end function fffi
end module fg

$ cat mod2.F90
module f
  use fg
end module f

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130815 (experimental) (GCC) 

$ gfortran -c mod1.F90 -o mod1.o
$ gfortran -c mod2.F90 -o mod2.o
f951: internal compiler error: Segmentation fault
0x95dcbf crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x556f38 gfc_verify_binding_labels
../../gcc-trunk/gcc/fortran/resolve.c:10117
0x579e23 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x565df3 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14422
0x561a80 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14489
0x563774 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14482
0x563774 resolve_symbol
../../gcc-trunk/gcc/fortran/resolve.c:13257
0x579e23 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x565bd2 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14392
0x561a80 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14489
0x54e6ef gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x58a9f5 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The "BIND(C)" seems to be necessary for the ICE to happen.

Also, if I place both modules in the same file the ICE does not happen and a
suitable error message is reported:

$ cat mod1.F90 mod2.F90 > mod12.F90
$ gfortran -c mod12.F90 -o mod12.o
mod12.F90:11.8:

module f
1
mod12.F90:6.7:

   function f() bind(c)
   2
Error: Global binding name 'f' at (1) is already being used as a FUNCTION at
(2)

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-17
Summary|ICE with global binding |[4.9 Regression] ICE with
   |name used as a FUNCTION |global binding name used as
   ||a FUNCTION
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. There is no ICE nor error with revision 198750 (2013-05-09).
Revision 199418 (2013-05-29) gives the ICE.

[Bug c/58183] New: Missing uninitialized warning

[ash.winner.92 at gmail dot com]

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

Bug ID: 58183
   Summary: Missing uninitialized warning
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ash.winner.92 at gmail dot com

No uninitialized variable warning is displayed when compiling the following
code :

#include

int main() {
int i;
while(i++<10)
printf("%d Hello World!\n", i);
return 0;
}

using the following command :

gcc -Wuninitialized test.c 


This is the output of gcc -v :

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-2ubuntu1' --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
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--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.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[tg at mirbsd dot org]

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

--- Comment #19 from Thorsten Glaser  ---
Created attachment 30668
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30668&action=edit
Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1

This issue still appears with GCC 4.8

In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries the
build with -O1 then -O0 to mask this issue, but the underlying issue is still
unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I need to
port said patch, until someone finds out what precisely is going on here.

g++ -c x.cc -std=c++0x -fno-exceptions ⇒ compiles fine
g++ -c x.cc -std=c++0x -fno-exceptions -O2 ⇒ ICEs:
In file included from ../../../include/QtCore/qlist.h:1:0,
 from
../../../include/QtCore/../../src/corelib/tools/qhash.h:47,
 from ../../../include/QtCore/qhash.h:1,
 from ../../../include/QtCore/../../src/corelib/io/qdebug.h:46,
 from ../../../include/QtCore/qdebug.h:1,
 from ditaxmlgenerator.cpp:46:
../../../include/QtCore/../../src/corelib/tools/qlist.h: In member function
‘void QList::append(const T&) [with T = Section]’:
../../../include/QtCore/../../src/corelib/tools/qlist.h:521:1: internal
compiler error: in cselib_record_set, at cselib.c:2373
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccUYfyzd.out file, please attach this to
your bugreport.

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[mikpe at it dot uu.se]

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

--- Comment #20 from Mikael Pettersson  ---
(In reply to Thorsten Glaser from comment #19)
> Created attachment 30668 [details]
> Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1
> 
> This issue still appears with GCC 4.8
> 
> In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries
> the build with -O1 then -O0 to mask this issue, but the underlying issue is
> still unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I
> need to port said patch, until someone finds out what precisely is going on
> here.

Please try compiling with -O2 -fno-auto-inc-dec before dropping to -O1 or -O0.

[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158

[tg at mirbsd dot org]

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

--- Comment #21 from Thorsten Glaser  ---
-fno-auto-inc-dec helps, thanks!

[Bug c++/58184] New: Pointer to overloaded function is non-deduced context

[aschepler at gmail dot com]

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

Bug ID: 58184
   Summary: Pointer to overloaded function is non-deduced context
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aschepler at gmail dot com

Created attachment 30669
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30669&action=edit
Sample c++ code

The attached program is ill-formed, but g++ 4.8.1 compiles it with no warnings.

g++ -v
Using built-in specs.
COLLECT_GCC=g++
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='Ubuntu
4.8.1-2ubuntu1~12.04' --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 --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 --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --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.1 (Ubuntu 4.8.1-2ubuntu1~12.04) 

No output from either command:
g++ -std=c++03 -pedantic -Wall -Wextra main.cpp
g++ -std=c++11 -pedantic -Wall -Wextra main.cpp

Template parameter U cannot be deduced in the expression using f.  I believe
this is true in both C++03 and C++11, although C++11 states it more clearly.

[C++03 14.8.3/2 ; C++11 14.8.2.5/2]
Type deduction is done independently for each P/A pair, and the deduced
template argument values are then combined.

[C++03 14.8.2.4/16]
A template-argument can be deduced from a pointer to function or pointer to
member function argument if the set of overloaded functions does not contain
function templates and at most one of a set of overloaded functions provides a
unique match.

[C++11 14.8.2.1/6]
When P is a function type, pointer to function type, or pointer to member
function type:
 - If the argument is an overload set containing one or more function
templates, the parameter is treated as a non-deduced context.
 - If the argument is an overload set (not containing function templates),
trial argument deduction is attempted using each of the members of the set.  If
deduction succeeds for only one of the overload set members, that member is
used as the argument value for the deduction.  If deduction succeeds for more
than one member of the overload set the parameter is treated as a non-deduced
context.

[C++11 14.8.2.1/8]
Example:
// Ambiguous deduction causes the second function parameter to be a
// non-deduced context.
template  int f(T, T (*p)(T));
int g(int);
char g(char);
int i = f(1, g);  // calls f(int, int (*)(int))

[End Standard quotes.]

Note the final example from C++11 is essentially the same as my example, except
that there is no other template parameter to be deduced, so type deduction
still succeeds.

Also, the current behavior leads to some strange inconsistencies.  The order of
function parameters generally plays no role in type deduction, but if you
reverse the order of f's parameters and arguments in my example, g++ will
reject it.

[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Jan Hubicka  ---
The secret plan was to not use TLS for emutls. I did not introduce new use of
TLS, just use what was already in tree-profile.c:
  if (targetm.have_tls)
DECL_TLS_MODEL (ic_void_ptr_var) =
  decl_default_tls_model (ic_void_ptr_var);

and I think have_tls should be true only for non-emutls targets.
on libgcov time we use
#ifdef HAVE_CC_TLS
__thread
#endif

There seems to be macro USE_EMUTLS specifying if we have real TLS or emuTLS.

I am not sure what of the two tests passes.  Perhaps it will help to replace
#ifdef HAVE_CC_TLS
__thread
#endif
#if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS)
__thread
#endif

[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
mine.

[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Jan Hubicka from comment #4)
> The secret plan was to not use TLS for emutls.

OK - I'll take a look at what should be used for the test...

> There seems to be macro USE_EMUTLS specifying if we have real TLS or emuTLS.
> 
> I am not sure what of the two tests passes.  Perhaps it will help to replace
> #ifdef HAVE_CC_TLS
> __thread
> #endif
> #if defined(HAVE_CC_TLS) && !defined (USE_EMUTLS)
> __thread
> #endif

... seems plausible, will try it on my next build cycle.

BTW, I wonder what it would take to make it work with emutls?

[Bug middle-end/58179] [4.9 Regression] obj_type_ref ICE building libobjc

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug fortran/58100] Spurious "DO loop at (1) will be executed zero times" warning

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
To fix this would require folding of the IF in the front end,
something that we rely on the middle end to do.

[Bug c++/58083] [4.8/4.9 Regression] ICE with lambda as default parameter of a template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed in r201822 (trunk) and r201823 (4.8).

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 54367 depends on bug 58083, which changed state.

Bug 58083 Summary: [4.8/4.9 Regression] ICE with lambda as default parameter of 
a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58083

   What|Removed |Added

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

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

[edward.c.wang at compdigitec dot com]

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

Edward Wang  changed:

   What|Removed |Added

 CC||edward.c.wang at compdigitec 
dot c
   ||om

--- Comment #7 from Edward Wang  ---
Still reproducible for me as well with the 20130811 snapshot:

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: 6083
Node Kind: directory
Schedule: normal
Last Changed Author: ktietz70
Last Changed Rev: 6082
Last Changed Date: 2013-08-13 11:05:52 -0400 (Tue, 13 Aug 2013)

i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I../../../mingw-sources/mingw-w64/mingw-w64-crt  -m32
-I../../../mingw-sources/mingw-w64/mingw-w64-crt/include -D_CRTBLD
-I/usr/i686-w64-mingw32/include  -pipe -std=gnu99 -Wall -Wextra -Wformat
-Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration
-Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT
intrincs/lib32_libkernel32_a-__movsb.o -MD -MP -MF
intrincs/.deps/lib32_libkernel32_a-__movsb.Tpo -c -o
intrincs/lib32_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo
'../../../mingw-sources/mingw-w64/mingw-w64-crt/'`intrincs/__movsb.c
In file included from
/usr/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/usr/i686-w64-mingw32/i686-w64-mingw32/include/intrin.h:59,
 from
../../../mingw-sources/mingw-w64/mingw-w64-crt/intrincs/__movsb.c:1:
/usr/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/4.9.0/include/ia32intrin.h:54:9:
internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633
 #pragma GCC target("sse4.2")
 ^
0x813eb4b c_builtin_function_ext_scope(tree_node*)
../../../mingw-sources/gcc-4.9-20130811/gcc/c/c-decl.c:3633
0x8487a83 add_builtin_function_common
../../../mingw-sources/gcc-4.9-20130811/gcc/langhooks.c:561
0x8847827 ix86_add_new_builtins
../../../mingw-sources/gcc-4.9-20130811/gcc/config/i386/i386.c:27508
0x8847827 ix86_valid_target_attribute_tree(tree_node*)
../../../mingw-sources/gcc-4.9-20130811/gcc/config/i386/i386.c:4832
0x8206225 ix86_pragma_target_parse
../../../mingw-sources/gcc-4.9-20130811/gcc/config/i386/i386-c.c:385
0x81ea4e8 handle_pragma_target
../../../mingw-sources/gcc-4.9-20130811/gcc/c-family/c-pragma.c:805
0x81820f1 c_parser_pragma
../../../mingw-sources/gcc-4.9-20130811/gcc/c/c-parser.c:8972
0x8193324 c_parser_external_declaration
../../../mingw-sources/gcc-4.9-20130811/gcc/c/c-parser.c:1345
0x8193d43 c_parser_translation_unit
../../../mingw-sources/gcc-4.9-20130811/gcc/c/c-parser.c:1251
0x8193d43 c_parse_file()
../../../mingw-sources/gcc-4.9-20130811/gcc/c/c-parser.c:11223
0x81e7c94 c_common_parse_file()
../../../mingw-sources/gcc-4.9-20130811/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [intrincs/lib32_libkernel32_a-__movsb.o] Error 1
make[3]: Leaving directory
`/media/data/build/mingw-build/mingw-w64/mingw-w64-crt'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/media/data/build/mingw-build/mingw-w64/mingw-w64-crt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/data/build/mingw-build/mingw-w64'
make: *** [all] Error 2

[Bug fortran/58185] New: ICE when selector in SELECT TYPE is non-polymorphic

[jwmwalrus at gmail dot com]

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

Bug ID: 58185
   Summary: ICE when selector in SELECT TYPE is non-polymorphic
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com

With gfortran 4.8/4.9, I get an ICE for the following (invalid) code:

module mod1
implicit none
save

contains
subroutine dosomething(array)
!class(*), intent(IN) :: array
integer, intent(IN) :: array
select type (a => array)
type is (integer)
type is (real)
class default
stop
end select
end subroutine
end module


Bug #54435 seems similar, but is marked as fixed.

System information follows:

...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v &&
apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd
lrwxrwxrwx 1 root staff 35 Aug 17 21:16 /usr/local/bin/gfortran-4.9 ->
../../lib/gcc-snapshot/bin/gfortran*
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20130731-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --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.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-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 --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 20130731 (experimental) [trunk revision 201378] (Debian
20130731-1) 
gfortran-4.8:
  Installed: 4.8.1-9
  Candidate: 4.8.1-9
  Version table:
 *** 4.8.1-9 0
200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
 4.8.1-2 0
500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
gcc-snapshot:
  Installed: 20130731-1
  Candidate: 20130731-1
  Version table:
 *** 20130731-1 0
200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
Description:Debian GNU/Linux testing (jessie)
Release:testing

[Bug c++/58119] [4.7/4.8/4.9 Regression] Invalid ambiguous default type conversion with only a single invalid conversion listed.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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