[Bug lto/53470] [4.8 LTO] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2012-05-25 06:59:33 UTC ---
same problem with BDF

cp /build/vin/binutils/build/gold/ld-new
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld
[vocms123] /build/vin/newb/CMSSW_6_0_X_2012-05-14-1400 $ c++ -g -flto -O2 -fPIC
iceDebug.o -shared -o bha.so -std=gnu++11 -msse3 -Wl,-v
collect2 version 4.8.0 20120524 (experimental) [trunk revision 187822]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld -plugin
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/liblto_plugin.so
-plugin-opt=/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/innocent/cc4re4Jl.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -shared -o
bha.so /usr/lib/../lib64/crti.o
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbeginS.o
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../..
iceDebug.o -v -lstdc++ -lm -lgcc_s -lc -lgcc_s
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtendS.o
/usr/lib/../lib64/crtn.o
GNU gold (GNU Binutils 2.22.52.20120515) 1.11
In file included from
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/checked_delete.hpp:51:0,
 from :322:
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/smart_ptr/detail/sp_counted_impl.hpp:
In member function 'get_deleter':
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/smart_ptr/detail/sp_counted_impl.hpp:84:5:
internal compiler error: in splice_child_die, at dwarf2out.c:4264
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: c++ returned 1 exit status
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: fatal error: lto-wrapper
failed
collect2: error: ld returned 1 exit status

[vocms123] /build/vin/newb/CMSSW_6_0_X_2012-05-14-1400 $ cp
/build/vin/binutils/build/ld/ld-new
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld
[vocms123] /build/vin/newb/CMSSW_6_0_X_2012-05-14-1400 $ c++ -g -flto -O2 -fPIC
iceDebug.o -shared -o bha.so -std=gnu++11 -msse3 -Wl,-v
collect2 version 4.8.0 20120524 (experimental) [trunk revision 187822]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld -plugin
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/liblto_plugin.so
-plugin-opt=/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/innocent/cc8URSUA.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -shared -o
bha.so /usr/lib/../lib64/crti.o
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbeginS.o
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../..
iceDebug.o -v -lstdc++ -lm -lgcc_s -lc -lgcc_s
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtendS.o
/usr/lib/../lib64/crtn.o
GNU ld (GNU Binutils) 2.22.52.20120515
In file included from
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/checked_delete.hpp:51:0,
 from :322:
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/smart_ptr/detail/sp_counted_impl.hpp:
In member function 'get_deleter':
/build/ge/new-binutils/a/slc5_amd64_gcc470/external/boost/1.49.0-cms3/include/boost/smart_ptr/detail/sp_counted_impl.hpp:84:5:
internal compiler error: in splice_child_die, at dwarf2out.c:4264
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: c++ returned 1 exit status
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/53482] -mtune=pentium[pro, 2, 3, 4], insn does not satisfy constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  2012-05-25 
07:52:01 UTC ---
Went latent on the trunk with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186861
but I believe this is just the PR53358 bug.

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

[Bug target/53358] [4.7/4.8 Regression] ICE due to TARGET_READ_MODIFY_WRITE peephole2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ncahill_alt at yahoo dot
   ||com

--- Comment #5 from Jakub Jelinek  2012-05-25 
07:52:01 UTC ---
*** Bug 53482 has been marked as a duplicate of this bug. ***

[Bug lto/53470] [4.8 LTO] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #4 from Markus Trippelsdorf  
2012-05-25 08:33:01 UTC ---
Here is a small testcase:

markus@x4 tmp % cat test.ii
class sp_counted_base;
class shared_count {
  sp_counted_base *pi_;
public:
  template shared_count(Y) : pi_() {}
  ~shared_count() {}
};
template struct shared_ptr {
  T element_type;
  template shared_ptr(Y) : pn(0) {}
  shared_count pn;
};
template class ECGetterBase;
template struct ExtensionCord {
  struct Holder {
ECGetterBase *getter_;
  };
  ExtensionCord() : holder_(new Holder) {}

  shared_ptr holder_;
};
ExtensionCord a;

markus@x4 tmp % c++ -flto -g test.ii
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4264
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0/c++ returned 1 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

[dodji at seketeli dot org]

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

--- Comment #5 from dodji at seketeli dot org  
2012-05-25 08:37:05 UTC ---
> The typedef has been there as kind of static assertion.
> IMHO it would be better to replace it with
> extern char check_count[(N == 2 || N == 4) * 2 - 1];
> or something similar.

Right.  Here is the follow-up I have posted to the list:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01684.html

[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-25
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/53473] [C++11] static constexpr noexcept cannot be specialized

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  2012-05-25 08:53:36 
UTC ---
Does the standard allow exceptions in constexpr? A throw is not exactly a
return statement, but according to the rule "constexpr function shall satisfy
[...] exactly one return statement" I'd expect a constexpr function can never
throw anyway. Thus the noexcept itself seems to make no sense in the first
place.

[Bug c++/53473] [C++11] static constexpr noexcept cannot be specialized

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-05-25 09:07:20 UTC ---
(In reply to comment #2)
> Does the standard allow exceptions in constexpr? A throw is not exactly a
> return statement, but according to the rule "constexpr function shall satisfy
> [...] exactly one return statement" I'd expect a constexpr function can never
> throw anyway. Thus the noexcept itself seems to make no sense in the first
> place.

No, both concepts of constant expressions and exception-specifications are
independent decisions. The following is a perfectly valid constexpr function:

#include 

constexpr int validating_abs(int val) noexcept(false)
{ return val < 0 ? throw std::runtime_error("negative") : val; }

int main()
{
  constexpr int v1 = validating_abs(1); // OK
  constexpr int v2 = validating_abs(-1); // Error
  int v = -1;
  try {
int v3 = validating_abs(v); // OK, runtime validation
  } catch (std::runtime_error&) {}
}

It is just a fact, that the "effective expression" is relevant when we consider
constant expressions and throw expressions, like for v2. But constexpr
functions can also be called in non-constant contexts - like for v3 - where
this restriction does not exist.

[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2012-05-25 
09:24:12 UTC ---
Author: ebotcazou
Date: Fri May 25 09:24:08 2012
New Revision: 187874

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187874
Log:
PR ada/52362
* config.gcc (i[34567]86-*-mingw* | x86_64-*-mingw*): Set gas and
gnu_ld variables to yes.
* configure.ac (HAVE_GNU_LD): Move to after config.gcc inclusion.
(HAVE_GNU_AS): Likewise.
* config.in: Regenerate.
* configure: Likewise.
ada/
* link.c (__gnat_object_file_option): Set to "-Wl,@" for GNU linker.
(__gnat_using_gnu_linker): Delete.
* gnatlink.adb (Gnatlink): Declare Object_File_Option_Ptr here...
Declare Object_File_Option string constant and Using_GNU_response_file
boolean constant.
(Process_Binder_File): ...instead of here.  Delete Using_GNU_Linker,
Opening and Closing local variables.  Do not handle the GNU linker
specially.
(Write_RF): New procedure to write into the response file.  Escape some
characters if a GNU response file is used.  Keep track of error status.
Invoke Write_RF to write into the response file.  Delete the file only
if the link was successful.
* mlib-utl.adb: Do not `with' package System.
(Gcc): Likewise.  Declare Object_File_Option string constant and
Using_GNU_response_file boolean constant.
(Write_RF): Take a string instead of address and length.  Escape some
characters if a GNU response file is used.
Invoke Write_RF to write into the response file.  Delete the file only
if the link was successful.  Do not warn if it cannot be deleted.

Added:
trunk/gcc/testsuite/gnat.dg/lto14.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnatlink.adb
trunk/gcc/ada/link.c
trunk/gcc/ada/mlib-utl.adb
trunk/gcc/config.gcc
trunk/gcc/config.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/testsuite/ChangeLog

[Bug c++/53473] [C++11] static constexpr noexcept cannot be specialized

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-05-25 
09:44:45 UTC ---
Yes, odd indeed.

Oddly, Clang barfs on the testcase with a similar error:

t.cc:6:34: error: conflicting types for 'foo'

[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  2012-05-25 
09:58:42 UTC ---
It seems to me that this issue is dealt with by the patch I have proposed at
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01389.html.  The discussion on
that patch is still going on.

Could you please try that patch and reply to the discussion there to say if it
address the issue on your target?

Thanks.

[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2012-05-25 
10:07:27 UTC ---
Author: ebotcazou
Date: Fri May 25 10:07:23 2012
New Revision: 187877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187877
Log:
PR ada/52362
* config.gcc (i[34567]86-*-mingw* | x86_64-*-mingw*): Set gas and
gnu_ld variables to yes.
* configure.ac (HAVE_GNU_LD): Move to after config.gcc inclusion.
(HAVE_GNU_AS): Likewise.
* config.in: Regenerate.
* configure: Likewise.
ada/
* link.c (__gnat_object_file_option): Set to "-Wl,@" for GNU linker.
(__gnat_using_gnu_linker): Delete.
* gnatlink.adb (Gnatlink): Declare Object_File_Option_Ptr here...
Declare Object_File_Option string constant and Using_GNU_response_file
boolean constant.
(Process_Binder_File): ...instead of here.  Delete Using_GNU_Linker,
Opening and Closing local variables.  Do not handle the GNU linker
specially.
(Write_RF): New procedure to write into the response file.  Escape some
characters if a GNU response file is used.  Keep track of error status.
Invoke Write_RF to write into the response file.  Delete the file only
if the link was successful.
* mlib-utl.adb: Do not `with' package System.
(Gcc): Likewise.  Declare Object_File_Option string constant and
Using_GNU_response_file boolean constant.
(Write_RF): Take a string instead of address and length.  Escape some
characters if a GNU response file is used.
Invoke Write_RF to write into the response file.  Delete the file only
if the link was successful.  Do not warn if it cannot be deleted.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/lto14.adb
  - copied unchanged from r187874, trunk/gcc/testsuite/gnat.dg/lto14.adb
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/ada/ChangeLog
branches/gcc-4_7-branch/gcc/ada/gnatlink.adb
branches/gcc-4_7-branch/gcc/ada/link.c
branches/gcc-4_7-branch/gcc/ada/mlib-utl.adb
branches/gcc-4_7-branch/gcc/config.gcc
branches/gcc-4_7-branch/gcc/config.in
branches/gcc-4_7-branch/gcc/configure
branches/gcc-4_7-branch/gcc/configure.ac
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug ada/52362] gnat.dg/lto8.adb FAILs with gas/gld

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Botcazou  2012-05-25 
10:16:46 UTC ---
Thanks for reporting the problem.

[Bug c++/52725] error: capture of non-variable (in regards to a variable)

[steffen_moeller at gmx dot de]

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

Steffen Möller  changed:

   What|Removed |Added

 CC||steffen_moeller at gmx dot
   ||de

--- Comment #2 from Steffen Möller  2012-05-25 
10:33:51 UTC ---
Hello, I have something similar in the OpenMM code
(https://simtk.org/home/openmm), with no ()s following the "new" as in


template 
struct CUDAStream : public SoADeviceObject
{
unsigned int_length;
unsigned int_subStreams;  # line 68
unsigned int_stride;
T** _pSysStream;
T** _pDevStream;
T*  _pSysData;
T*  _pDevData;
std::string _name;
CUDAStream(int length, int subStreams = 1, std::string name="");
CUDAStream(unsigned int length, unsigned int subStreams = 1, std::string
name="");
CUDAStream(unsigned int length, int subStreams = 1, std::string name="");
CUDAStream(int length, unsigned int subStreams = 1, std::string name="");
virtual ~CUDAStream();
void Allocate();
void Deallocate();
void Upload();
void Download();
void CopyFrom(const CUDAStream& src);
void Collapse(unsigned int newstreams = 1, unsigned int interleave = 1);
T& operator[](int index);
};

[...]

template 
void CUDAStream::Allocate()
{
cudaError_t status;
_pSysStream =   new T*[_subStreams];  # line 125
_pDevStream =   new T*[_subStreams];
_pSysData = new T[_subStreams * _stride];

status = cudaMalloc((void **) &_pDevData, _stride * _subStreams *
sizeof(T));
RTERROR(status, (_name+": cudaMalloc in CUDAStream::Allocate
failed").c_str());

for (unsigned int i = 0; i < _subStreams; i++)
{
_pSysStream[i] = _pSysData + i * _stride;
_pDevStream[i] = _pDevData + i * _stride;
}
}

for which 4.6.3 (Debian 4.6.3-5) happily crunches but 4.7 (Debian 4.7.0-9)
gives me

cd
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/obj-x86_64-linux-gnu/platforms/cuda/sharedTarget
&& /usr/local/bin/c++   -DOpenMMCuda_EXPORTS -DOPENMM_LIBRARY_NAME=OpenMM
-DOPENMM_MAJOR_VERSION=1 -DOPENMM_MINOR_VERSION=0 -DOPENMM_BUILD_VERSION=0
-DOPENMM_SVN_REVISION=\"exported\" -DOPENMM_COPYRIGHT_YEARS=\"2008\"
-DOPENMM_AUTHORS=\"Peter.Eastman\" -O3 -DNDEBUG -fPIC
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/src
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/src
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/validate/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/reference/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/lbfgs/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/sfmt/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/lepton/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/quern/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/libraries/jama/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/olla/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/openmmapi/include
-I/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/./include   
-DOPENMMCUDA_BUILDING_SHARED_LIBRARY -o
CMakeFiles/OpenMMCuda.dir/__/__/__/src/cuda/kApplyConstraints.cu_OpenMMCuda_generated.cpp.o
-c
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/obj-x86_64-linux-gnu/src/cuda/kApplyConstraints.cu_OpenMMCuda_generated.cpp
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./src/kernels//cudatypes.h:
In member function ‘virtual void CUDAStream::Allocate()’:
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./src/kernels//cudatypes.h:125:27:
error: capture of non-variable ‘CUDAStream::_subStreams’ 
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./src/kernels//cudatypes.h:68:10:
note: ‘unsigned int CUDAStream::_subStreams’ declared here
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./src/kernels//cudatypes.h:126:27:
error: capture of non-variable ‘CUDAStream::_subStreams’ 
/homeLvm/moeller/alioth/debichem/experimental/openmm-4.1/platforms/cuda/./src/kernels//cudatypes.h:68:10:
note: ‘unsigned int CUDAStream::_subStreams’ declared here
make[3]: ***
[platforms/cuda/sharedTarget/CMakeFiles/OpenMMCuda.dir/__/__/__/src/cuda/kApplyConstraints.cu_OpenMMCuda_generated.cpp.o]
Error 1


Thanks and regards,

Steffen

[Bug c++/52725] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|error: capture of   |error: "capture of
   |non-variable (in regards to |non-variable" for
   |a variable) |new-expression incorrectly
   ||parsed as lambda-expression

--- Comment #3 from Jonathan Wakely  2012-05-25 
11:09:37 UTC ---
N.B. I've changed the Summary, the "non-variable" in the diagnostic refers to a
non-automatic variable, in this case a data member, which isn't allowed in a
lamdba capture. The problem is not that the error says a member variable is a
non-variable, it's that a new-expression is mistaken for a lambda-expresion.


(In reply to comment #2)
> Hello, I have something similar in the OpenMM code
> (https://simtk.org/home/openmm), with no ()s following the "new" as in

Please provide a minimal, complete example, those snippets do not allow your
report to be reproduced or confirmed.  This seems to be equivalent but works
fine:

template 
struct CUDAStream
{
unsigned int_subStreams;
T** _pSysStream;
void Allocate();
};

template 
void CUDAStream::Allocate()
{
_pSysStream =   new T*[_subStreams];
}

[Bug target/53474] [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-05-25 11:30:08 UTC ---
Sure: a i386-pc-solaris2.10 bootstrap completed with this patch without
issues.

Thanks.
Rainer

[Bug bootstrap/53472] contrib/compare-debug should strip out .comment section

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2012-05-25 
11:47:08 UTC ---
Author: hjl
Date: Fri May 25 11:47:05 2012
New Revision: 187879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187879
Log:
Remove any .comment sections if the first cmp failed

PR bootstrap/53472
* contrib/compare-debug (remove_comment): New function.
Remove any .comment sections if the first cmp failed.

Modified:
trunk/contrib/ChangeLog
trunk/contrib/compare-debug

[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jason at redhat dot com
  Component|lto |debug
   Target Milestone|--- |4.8.0
Summary|[4.8 LTO] ICE when linking  |[4.8 Regression] ICE when
   |with -g in  |linking with -g in
   |splice_child_die, at|splice_child_die, at
   |dwarf2out.c:4264|dwarf2out.c:4264

--- Comment #5 from H.J. Lu  2012-05-25 12:31:12 
UTC ---
It is caused by revision 187106:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00102.html

[Bug bootstrap/53472] contrib/compare-debug should strip out .comment section

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from H.J. Lu  2012-05-25 12:37:35 
UTC ---
Fixed.

[Bug c++/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-25
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth  2012-05-25 
12:53:17 UTC ---
Regression test results on x86_64-apple-darwin12 are at
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg02331.html. Note that the
remaining cfstring failures are PR53283.

[Bug target/53435] (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly

[kyukhin at gcc dot gnu.org]

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

--- Comment #4 from Kirill Yukhin  2012-05-25 
13:03:21 UTC ---
Author: kyukhin
Date: Fri May 25 13:03:18 2012
New Revision: 187881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187881
Log:
2012-05-21  Alexander Ivchenko  

   PR target/53435
   * config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
   (ix86_expand_vec_perm): Use int mode instead of float.
   (expand_vec_perm_pshufb): Remove handling of useseless type
   conversion.


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

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz  2012-05-25 13:14:57 
UTC ---
Is there any good specification about that vtable (and vbtable) layout of msc? 
I assume there might be more things needed to be adjusted so that here
binary-compatibility can be achieved.

[Bug target/53435] (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly

[kyukhin at gcc dot gnu.org]

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

--- Comment #5 from Kirill Yukhin  2012-05-25 
13:34:12 UTC ---
Author: kyukhin
Date: Fri May 25 13:34:07 2012
New Revision: 187882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187882
Log:
2012-05-25  Alexander Ivchenko  

PR target/53435
* config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
(ix86_expand_vec_perm): Use int mode instead of float.


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

[Bug debug/53453] darwin linker expects both AT_name and AT_comp_dir debug notes

[howarth at nitro dot med.uc.edu]

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

--- Comment #14 from Jack Howarth  2012-05-25 
13:38:12 UTC ---
Revised patch with Jakub's documentation correction posted at
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01710.html.

[Bug c++/53484] New: [c++11] Wrong auto in lambdas in function templates

[omawarisan.bokudesu at live dot jp]

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

 Bug #: 53484
   Summary: [c++11] Wrong auto in lambdas in function templates
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: omawarisan.bokud...@live.jp


In the following program, auto is deduced to be int&, while int is expected.

template 
void f(T x){
   [&]{
   std::cout << x << std::endl;
   auto y = x;
   y = 100;
   std::cout << x << std::endl;
   }();
}

int main(){ f(0); }

output:
0
100

In non-template functions, it doesn't occur.


revision r187865

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/user/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/user/gcc-trunk
--disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran
--with-gmp=/home/user/gcc-trunk/src/build/backends
--with-mpfr=/home/user/gcc-trunk/src/build/backends
--with-mpc=/home/user/gcc-trunk/src/build/backends
Thread model: posix
gcc version 4.8.0 20120525 (experimental) (GCC)

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  2012-05-25 
14:09:00 UTC ---
> 
> Basically, the current encoding of the map requires that a new location
> encoding in a map must always be the last location of that map.  You
> cannot insert a location in the "middle" of an existing map.

Just continuing with the thought-experiment... would it be possible to
duplicate the current line-table, then start re-encoding locations from the
last location before the interesting character, and simply stop when the
interesting character is reached? Then switch line-tables on the fly before
giving the diagnostic, and switch back to the original line-table after it.

I guess Clang has a different encoding for source locations, because it seems
they are generating new location indexes on the fly.

> I guess that would take re-processing the whole compilation unit,
> starting from the location map that you have changed.  And, just handling
> locations wouldn't be enough, we'd need to basically re-tokenize the
> files that are re-processed, because the locations are primarily carried
> by instances of cpp_token, and we need the locations of these tokens to
> be updated.
> 
> That doesn't seem practical.

Practical because of complexity, ugliness or computation time?


> > And I am not sure this will handle well the case of split strings and macro
> > expansion, like Clang does.
> 
> Yeah.  Which makes me think that maybe we might want to introduce a new
> way to represent string literal tokens in libcpp, that keeps the
> underlying raw format.  There would be a character oriented iterator API
> for that string literal representation.  And that iterator API could
> provide its user with the file/line/column information for the current
> character.  And one could pass any such iterator to some of the
> diagnostic routines.

This sounds interesting, but I still do not understand how it can handle macro
expansions. Could you elaborate?

[Bug c/52952] Wformat location info is bad (wrong column number)

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2012-05-25 
14:17:41 UTC ---
I guess the C/C++ FEs could for non-trivial string literals put into a hash
table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
token for that string, then the diagnostic code could go from there.
Trivial string literal above would be a string literal that doesn't have any
prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
and didn't need to be translated.  So, printf ("%.*d"); (the common case)
wouldn't have to be recorded, while printf (R"<<<(%)>>>" "." R"(*)" "d"); would
need that.  For "trivial" string literals you'd just shift the locus by the
offset, for non-trivial look up the tokens and process them again, looking at
where the corresponding byte would appear to come from.

[Bug c++/53484] [4.7/4.8 Regression] [c++11] Wrong auto in lambdas in function templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.6.3
   Keywords||rejects-valid, wrong-code
   Last reconfirmed||2012-05-25
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|[c++11] Wrong auto in   |[4.7/4.8 Regression]
   |lambdas in function |[c++11] Wrong auto in
   |templates   |lambdas in function
   ||templates
  Known to fail||4.7.0, 4.8.0

--- Comment #1 from Jonathan Wakely  2012-05-25 
14:49:55 UTC ---
Regression against 4.6.3

Possibly related, the example in [expr.prim.lambda]/18 fails to compile with
4.7 and 4.8

void f3() {
float x, &r = x;
[=] { // x and r are not captured (appearance in a decltype operand is not
an odr-use)
decltype(x) y1; // y1 has type float
decltype((x)) y2 = y1; // y2 has type float const& because this lambda
// is not mutable and x is an lvalue
decltype(r) r1 = y1; // r1 has type float& (transformation not
considered)
decltype((r)) r2 = y2; // r2 has type float const&
};
}

[Bug target/53474] [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org 2012-05-25 15:07:09 UTC ---
Author: uros
Date: Fri May 25 15:07:02 2012
New Revision: 187885

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187885
Log:
PR target/53474
* config/i386/i386.c (ix86_print_operand) : Print '.' here.
: Print '.' only for C and c.


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

[Bug c/53485] New: gcc -O -mavx generates illegal instruction on win64

[ian at nasoftware dot co.uk]

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

 Bug #: 53485
   Summary: gcc -O -mavx generates illegal instruction on win64
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@nasoftware.co.uk


Created attachment 27495
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27495
preprocessed source

Compiling the attached program with optimization and AVX for Win64 generates an
illegal instruction. The same code runs correctly on Win32 and on Linux64.

$ x86_64-w64-mingw32-gcc -m64 -mavx bug.c -O -g -o bug.exe -Wall -Wextra
-save-temps
$ ./bug.exe
BUG PROGRAM START: We should get this message once.
DEBUG fun1 start...
Illegal instruction
$ gdb bug.exe
(gdb) r
Starting program: C:\cygwin\home\nas/bug.exe
[New Thread 2436.0x38c]
BUG PROGRAM START: We should get this message once.
DEBUG fun1 start...

Program received signal SIGILL, Illegal instruction.
fun1 () at bug.c:95
95 v1 = vfone;
(gdb) x/i $pc
=> 0x4015e7 :  vmovaps 0x7b11(%rip),%ymm0# 0x409100
(gdb) p $rip
$1 = (void (*)()) 0x4015e7 
(gdb) info frame
Stack level 0, frame at 0x22fe40:
 rip = 0x4015e7 in fun1 (bug.c:95); saved rip 0x40171b
 called by frame at 0x22fe70
 source language c.
 Arglist at 0x22fe30, args:
 Locals at 0x22fe30, Previous frame's sp is 0x22fe40
 Saved registers:
  rbx at 0x22fe20, rsi at 0x22fe28, rbp at 0x22fe30, rip at 0x22fe38, xmm15 at
0x22fe38

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\nas\mingw64\bin\x86_64-w64-mingw32-gcc.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/nas/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.3/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/drangon/work/mingw-w64-dgn/source/gcc/configure
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls
--enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/drangon/work/mingw-w64-dgn/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--prefix=/home/drangon/work/mingw-w64-dgn/target
--with-sysroot=/home/drangon/work/mingw-w64-dgn/target
Thread model: win32
gcc version 4.6.3 20120225 (prerelease) (GCC)


I have also tried the mingw64 cross compiler from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/
gcc version 4.8.0 20120509 (experimental) (GCC) 
and I get the same error (though I need to use -O3)

If I download an older version,
gcc version 4.5.4 20111030 (prerelease) [svn/rev.180676 - mingw-w64/oz] (GCC) 
then I don't get the illegal instruction.

[Bug target/53474] [4.8 regression] Solaris/x86 bootstrap with Sun as broken: j.e

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-05/msg01737.htm
   ||l
 Resolution||FIXED

--- Comment #4 from Uros Bizjak  2012-05-25 15:14:28 
UTC ---
Fixed.

[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  2012-05-25 
15:13:50 UTC ---
It didn't work because you've used the patch as svn commit message instead of
ChangeLog entry.
Anyway, would it be possible to have a testcase for the gcc testsuite too?

[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from William J. Schmidt  
2012-05-25 15:37:27 UTC ---
(In reply to comment #13)
> It didn't work because you've used the patch as svn commit message instead of
> ChangeLog entry.

Whoops, found a new kind of mistake to make. :)

> Anyway, would it be possible to have a testcase for the gcc testsuite too?

I've been trying, but so far haven't been able to come up with anything other
than the enormous "reduced" testcase.  Seems it may require a combination of
templates and inlining to get the bitfield access in the right form to exhibit
the bug, but I haven't figured it out yet.  Ideas welcome.

[Bug c/53485] gcc -O -mavx generates illegal instruction on win64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  2012-05-25 15:49:05 
UTC ---
(In reply to comment #0)
> Created attachment 27495 [details]
> preprocessed source
> 
> Compiling the attached program with optimization and AVX for Win64 generates 
> an
> illegal instruction. The same code runs correctly on Win32 and on Linux64.
> 
> $ x86_64-w64-mingw32-gcc -m64 -mavx bug.c -O -g -o bug.exe -Wall -Wextra
> -save-temps
> $ ./bug.exe
> BUG PROGRAM START: We should get this message once.
> DEBUG fun1 start...
> Illegal instruction
> $ gdb bug.exe
> (gdb) r
> Starting program: C:\cygwin\home\nas/bug.exe
> [New Thread 2436.0x38c]
> BUG PROGRAM START: We should get this message once.
> DEBUG fun1 start...
> 
> Program received signal SIGILL, Illegal instruction.
> fun1 () at bug.c:95
> 95 v1 = vfone;
> (gdb) x/i $pc
> => 0x4015e7 :  vmovaps 0x7b11(%rip),%ymm0# 0x409100
> (gdb) p $rip
> $1 = (void (*)()) 0x4015e7 
> (gdb) info frame
> Stack level 0, frame at 0x22fe40:
>  rip = 0x4015e7 in fun1 (bug.c:95); saved rip 0x40171b

It looks like 0x7b11(%rip) isn't aligned to 16 byte.

[Bug c++/53486] New: ICE compiling code using lambdas as default argument

[jpalecek at web dot de]

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

 Bug #: 53486
   Summary: ICE compiling code using lambdas as default argument
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jpale...@web.de


When compiling the attached file with g++-4.7, (or the last snapshot available
in Debian, that is from 20120501), I get the following internal compiler error:

benchmark_test.cpp:424:26: internal compiler error: in tsubst_copy, at
cp/pt.c:12077
   simple_regression reg;
  ^

The full output is:

-*- mode: compilation; default-directory: "~/benchmark/" -*-
Compilation started at Fri May 25 16:18:54

LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH g++ -g --std=c++0x benchmark_test.cpp
benchmark_test.cpp: In instantiation of 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, int,
func_type&, data_vector_type&, timer_type&, error_type&,
variable_function_type&, random_type&) [with ResultType = std::vector;
Args = boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer;
error_type = const double; variable_function_type = const
main()::; random_type = const
boost::random::xor_combine_engine, 0, boost::random::linear_feedback_shift_engine, 0>, 0, boost::random::linear_feedback_shift_engine, 0>]':
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, long
int, func_type&, data_vector_type&, timer_type&, error_type&,
variable_function_type&, boost::parameter::aux::use_default_tag) [with
ResultType = std::vector; Args = boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer;
error_type = const double; variable_function_type = const
main()::]'
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, int,
func_type&, data_vector_type&, timer_type&, error_type&,
variable_function_type&) [with ResultType = std::vector; Args =
boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer;
error_type = const double; variable_function_type = const
main()::]'
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, int,
func_type&, data_vector_type&, timer_type&, error_type&) [with ResultType =
std::vector; Args = boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer;
error_type = const double]'
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, long
int, func_type&, data_vector_type&, timer_type&,
boost::parameter::aux::use_default_tag) [with ResultType = std::vector;
Args = boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer]'
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, int,
func_type&, data_vector_type&, timer_type&) [with ResultType =
std::vector; Args = boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list; timer_type = const clock_timer]'
benchmark_test.cpp:404:1:   required from 'ResultType
boost_param_default_415benchmark_regress(ResultType (*)(), const Args&, long
int, func_type&, data_vector_type&, boost::parameter::aux::use_default_tag)
[with ResultType = std::vector; Args =
boost::parameter::aux::arg_list >, boost::parameter::aux::arg_list >,
boost::parameter::aux::arg_list
>, boost::parameter::aux::empty_arg_list> > >; func_type = const
main()::; data_vector_type = const
boost::assign_detail::generic_list]'
be

[Bug rtl-optimization/53487] New: [4.8 Regression] Unrecognizable insn for conditional move

[wschmidt at gcc dot gnu.org]

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

 Bug #: 53487
   Summary: [4.8 Regression] Unrecognizable insn for conditional
move
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
pins...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 27496
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27496
Reduced testcase

The attached test (reduced from 456.hmmer) fails to compile beginning with
r187183, as shown:

wschmidt@bns:~/delta> gcc -c -o cluster.o  -m64 -O3 -mcpu=power7 -ffast-math
-misel cluster.i
cluster.i: In function ‘Cluster’:
cluster.i:30:1: error: unrecognizable insn:
 }
 ^
(insn 156 155 157 8 (set (reg:SI 289)
(if_then_else:SI (ge (reg:SF 291)
(const_double:SF 0.0 [0x0.0p+0]))
(subreg/s:SI (reg/v:DI 258 [ i+-4 ]) 4)
(subreg/s:SI (reg/v:DI 265 [ row+-4 ]) 4))) -1
 (nil))
cluster.i:30:1: internal compiler error: in extract_insn, at recog.c:2130
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This form of conditional move insn isn't recognized on powerpc64 because the
floating-point comparison is incompatible with a conditional move of integer
arguments.  Prior to this revision, code generation recognized the
incompatibility and did not generate the conditional move.

r187183 is:

2012-05-04  Andrew Pinski  

* expr.c (get_def_for_expr_class): New function.
(convert_tree_comp_to_rtx): New function.
(expand_cond_expr_using_cmove): New function.
(expand_expr_real_2 ): Call
expand_cond_expr_using_cmove first and return if it succeeds.
Remove the check for HAVE_conditional_move since we should have
already converted it to a conditional move.
* config/i386/i386.c (ix86_expand_int_movcc): Disallow comparison
modes of DImode for 32bits and TImode.

[Bug rtl-optimization/53487] [4.8 Regression] Unrecognizable insn for conditional move

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.8.0

[Bug c++/53488] New: Incorrect code generated when capturing a constant by reference in a lambda

[jpalecek at web dot de]

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

 Bug #: 53488
   Summary: Incorrect code generated when capturing a constant by
reference in a lambda
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jpale...@web.de


Created attachment 27497
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27497
Preprocessed source

I have the following source:

jirka@debian:~/benchmark$ cat error.cpp 
#include 

template
void f()
{
  const int i=sizeof(T);
  auto fun = [&] { std::cout << i << std::endl; };
  fun();
}

int main()
{
  f();
  return 0;
}

When I compile and run this program, it outputs garbage (instead of
sizeof(double)):

jirka@debian:~/benchmark$ g++-4.7 --std=c++0x error.cpp
jirka@debian:~/benchmark$ ./a.out 
134514706

Changing f to a nontemplate, i to be nondependent ot captured by value produces
correct output.

[Bug other/53489] New: suggest a feature for gcc.

[tal.regev at gmail dot com]

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

 Bug #: 53489
   Summary: suggest a feature for gcc.
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tal.re...@gmail.com


Hi,
I don't know if is the right place to make a suggestion.
If it not, please write me the right place to do so.
Anyway I want to suggest a feature for gcc.
It will be nice if it can add in a website like in sourceforge or google code,
they have a nice table for bugs and features.

I see GCC is support a Java language and it combine with GCJ
http://gcc.gnu.org/java/

why not to do the same with C#?
there is a GNU project that implement a C#
http://www.gnu.org/software/dotgnu/ 

And there is open source project that do the same (maybe it will help) 
http://www.mono-project.com/Main_Page

thanks for your hard work.

[Bug rtl-optimization/53487] [4.8 Regression] Unrecognizable insn for conditional move

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from William J. Schmidt  2012-05-25 
16:09:43 UTC ---
Dumps show that the ICE occurs in the first pass following expand.

[Bug rtl-optimization/53487] [4.8 Regression] Unrecognizable insn for conditional move

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

  Attachment #27496|0   |1
is obsolete||

--- Comment #2 from William J. Schmidt  2012-05-25 
16:13:29 UTC ---
Created attachment 27498
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27498
Reduced testcase in text/plain

Replaced attachment with one in text/plain format.

[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-25
Version|unknown |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-05-25 
16:16:25 UTC ---
The bug rpeorting guidelines ask for the output of 'gcc -v' so we at least know
which version you're using, "g++-4.7" isn't very useful. I'm assuming 4.7.0

[Bug c++/53486] ICE compiling code using lambdas as default argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-25
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-05-25 
16:17:53 UTC ---
No attached file, no testcase, no version, no 'gcc -v' output. Please see the
bug reporting instructions.

[Bug other/53489] suggest a feature for gcc.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-25
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  2012-05-25 
16:21:45 UTC ---
(In reply to comment #0)
> It will be nice if it can add in a website like in sourceforge or google code,
> they have a nice table for bugs and features.

GCC already has a website and a bug database (you used it to submit this
request!)  What do you mean?

> 
> I see GCC is support a Java language and it combine with GCJ
> http://gcc.gnu.org/java/
> 
> why not to do the same with C#?

What do you mean by "the same"?

If the mono team wanted to contribute their compiler to GCC they would do.

You'll need to be clearer what you are suggesting, as noone is going to work on
a vague suggestion that they can't understand.  If you can't even be bothered
to escribe your idea properly why should anyone be bothered to work on it?

[Bug middle-end/53008] abort in _ITM_getTMCloneSafe

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez  2012-05-25 
17:14:31 UTC ---
Author: aldyh
Date: Fri May 25 17:14:25 2012
New Revision: 187887

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187887
Log:
PR middle-end/53008
* trans-mem.c (ipa_tm_create_version_alias): Output new_node if
accessed indirectly.
(ipa_tm_create_version): Same.


Added:
trunk/gcc/testsuite/gcc.dg/tm/pr53008.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/trans-mem.c

[Bug objc++/53441] [4.8 Regression] obj-c++.dg/ivar-invalid-type-1.mm ICE

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org 2012-05-25 17:29:38 UTC ---
Author: uros
Date: Fri May 25 17:29:33 2012
New Revision: 187888

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187888
Log:
PR obj-c++/53441
* decl.c (grokdeclarator): Check that current_class_type is non-NULL
before calling constructor_name_p.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug objc++/53441] [4.8 Regression] obj-c++.dg/ivar-invalid-type-1.mm ICE

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-05/msg01449.htm
   ||l
 Resolution||FIXED

--- Comment #4 from Uros Bizjak  2012-05-25 17:34:42 
UTC ---
Fixed

[Bug target/53487] [4.8 Regression] Unrecognizable insn for conditional move

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #3 from Andrew Pinski  2012-05-25 
17:53:00 UTC ---
The target needs to reject the cases in movsicc it cannot handle the
comparisons.  The x86 and arm backends have been fixed to do exactly this.

[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda

[jpalecek at web dot de]

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

--- Comment #2 from Jiří Paleček  2012-05-25 17:54:00 
UTC ---
The bug occurs with these compiler versions:

jirka@debian:~/benchmark$ g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-9'
--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 --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.0 (Debian 4.7.0-9) 

jirka@debian:~/benchmark$
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.8.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20120501-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
--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic
--disable-werror --enable-checking=yes --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.0 20120501 (experimental) [trunk revision 187013] (Debian
20120501-1)

[Bug c++/53486] ICE compiling code using lambdas as default argument

[jpalecek at web dot de]

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

--- Comment #2 from Jiří Paleček  2012-05-25 17:55:39 
UTC ---
Sorry for the missing test file, it was somehow lost in the bug submission
process. The compiler version is

jirka@debian:~/benchmark$
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.8.0/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20120501-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
--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic
--disable-werror --enable-checking=yes --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.0 20120501 (experimental) [trunk revision 187013] (Debian
20120501-1)

[Bug c++/53486] ICE compiling code using lambdas as default argument

[jpalecek at web dot de]

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

--- Comment #3 from Jiří Paleček  2012-05-25 17:58:50 
UTC ---
Created attachment 27499
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27499
Compressed source file

Sorry again, the file was too big.

[Bug c++/53490] New: Segmentation Fault when accessing std::set

[ja11sop at yahoo dot co.uk]

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

 Bug #: 53490
   Summary: Segmentation Fault when accessing std::set
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja11...@yahoo.co.uk


The following g++ 4.7 compiled code, when executed on x86_64 Debian Sid,
segfaults.

The code is a reduced sample from a much larger code-base of production code
that ran ok with gcc4.6. With more time I could reduce it further but this
already consistently hits the problem and produces a useful back trace.

I have this as a blocker because all our application code essentially executes
something similar to this and so now all our applications segfault when built
with gcc4.7. Also I cannot come up with a trivial work-around without
re-writing large parts of the code base.

CODE:
//--

// Boost Library Includes
#include 
#include 
#include 
#include 

// C++ Standard Library Includes
#include 
#include 


typedef boost::property_tree::ptree property_tree_t;
typedef boost::shared_ptr  shared_property_tree_t;

void store_properties( int argc, const char* argv[] )
{
typedef boost::program_options::options_description options_description_t;
typedef boost::program_options::variables_map   variables_t;

options_description_t Options( "Base Options" );
Options.add_options()( "help,h", "Display Help" );

variables_t Variables( new variables_t() );

boost::program_options::parsed_options ParsedOptions = parse_command_line(
argc, argv, Options );
boost::program_options::store( ParsedOptions, Variables );
boost::program_options::notify( Variables );
}


typedef std::string string_t;
typedef std::set  string_set_t;
typedef boost::shared_ptr shared_string_set_t;

shared_string_set_t get_unique_keys( const string_t& Key, const
property_tree_t& PropertyTree )
{
if( auto Children = PropertyTree.get_child_optional( Key ) )
{
shared_string_set_t Values( new string_set_t() );

for( auto& Child : *Children )
{
// This line is required for the segfault
Values->insert( Child.first );
}
return Values;
}
return shared_string_set_t();
}


int main( int argc, char* argv[] )
{
const char* DummyArgv[] = { "std_set_bug_test", "--help", 0 };

shared_property_tree_t PropertyTree =
boost::make_shared();

store_properties( 2, DummyArgv );

// No need to call this code
//auto UniqueKeys = get_unique_keys( "log.sink", *PropertyTree );

return 0;
}

//--

Code compiled with:

-Wall -g -std=c++11

Linked *statically* with the boost 1.49 program_options library.

BACKTRACE:
Program received signal SIGSEGV, Segmentation fault.
0x77933427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x77933427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0046412d in std::_Rb_tree_iterator::operator--
(this=0x7fffdc60)
at /usr/include/c++/4.7/bits/stl_tree.h:203
#2  0x00462caa in std::pair, bool>
std::_Rb_tree,
std::less, std::allocator
>::_M_insert_unique(std::string const&) ()
#3  0x00461b25 in std::set,
std::allocator >::insert(std::string const&) ()
#4  0x0047aeb1 in boost::program_options::store (options=..., xm=...,
utf8=false)
at libs/program_options/src/variables_map.cpp:98
#5  0x00460350 in store_properties(int, char const**) ()
#6  0x004606ab in main ()
(gdb)

[Bug c++/53486] ICE compiling code using lambdas as default argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever Confirmed|1   |0

--- Comment #4 from Jonathan Wakely  2012-05-25 
18:13:29 UTC ---
Thanks. 

If the file's too big to upload maybe it's a hint you should try to reduce it
to something more manageable, as requested in the bug reporting instructions:
http://gcc.gnu.org/bugs/minimize.html

[Bug c++/53490] Segmentation Fault when accessing std::set

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #1 from Jonathan Wakely  2012-05-25 
18:15:59 UTC ---
(Blocker means it blocks a GCC release, so changing priority.)

Is the progam_options library built with -std=c++11 ?

[Bug c++/53490] Segmentation Fault when accessing std::set

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-05-25 
18:22:16 UTC ---
I only tried briefly but couldn't reproduce a crash with boost 1.47, will try
later with boost 1.49

[Bug rtl-optimization/53373] [4.8 regression] ICE on valid code with -mavx

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Bernd Schmidt  2012-05-25 
18:23:37 UTC ---
Fixed.

[Bug c++/53486] ICE compiling code using lambdas as default argument

[jpalecek at web dot de]

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

--- Comment #5 from Jiří Paleček  2012-05-25 18:29:19 
UTC ---
If I got a minimal testcase, but a slightly different error message, what
should I do?

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  2012-05-25 
18:32:40 UTC ---
Looks like an earlier dce pass (during .ce2) leaves a dead insn lying around.
Bug in DCE?

[Bug c++/53491] New: internal compiler error: in build_target_expr_with_type, at cp/tree.c:587

[k.lingaard at samsung dot com]

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

 Bug #: 53491
   Summary: internal compiler error: in
build_target_expr_with_type, at cp/tree.c:587
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k.linga...@samsung.com


While doing something stupid (always the case, ain't it?) the compiler barfed
on me:

#include 
#include 

using namespace std;

int main()
{
typedef std::priority_queue > EventQueue;
EventQueue m;

uint64_t result = 0;
result += m.pop();

return 0;
}


Yeah, I know, you can't += on a function returning 'void', but, since the
compiler croaked, I thought I'd submit a minor bug on it.  


% g++  -O3 -W -Wall -std=c++11 -Wall -Wextra -Winline -Werror -Winit-self
-Wno-sequence-point -Wno-inline gcc_bug.cpp
gcc_bug.cpp: In function ‘int main()’:
gcc_bug.cpp:13:21: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:587
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/sarc/spa/tools/gcc-470/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/sarc/spa/tools/gcc-470/
--with-mpc=/sarc/spa/tools/gcc-470/ --with-mpfr=/sarc/spa/tools/gcc-470/
--with-gmp=/sarc/spa/tools/gcc-470/ : (reconfigured) ../gcc-4.7.0/configure
--prefix=/sarc/spa/tools/gcc-470/ --with-mpc=/sarc/spa/tools/gcc-470/
--with-mpfr=/sarc/spa/tools/gcc-470/ --with-gmp=/sarc/spa/tools/gcc-470/ :
(reconfigured) ../gcc-4.7.0/configure --enable-languates=c,c++
--prefix=/sarc/spa/tools/gcc-470/ --with-mpc=/sarc/spa/tools/gcc-470/
--with-mpfr=/sarc/spa/tools/gcc-470/ --with-gmp=/sarc/spa/tools/gcc-470/ :
(reconfigured) ../gcc-4.7.0/configure --enable-languages=c,c++
--prefix=/sarc/spa/tools/gcc-470/ --with-mpc=/sarc/spa/tools/gcc-470/
--with-mpfr=/sarc/spa/tools/gcc-470/ --with-gmp=/sarc/spa/tools/gcc-470/
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-05-25 20:03:51 
UTC ---
Created attachment 27500
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27500
Preprocessed source

This preprocessed source from the bootstrap fails with -g -O2
-fprofile-generate:

~/gcc-build/gcc/cc1plus -O2 -fprofile-generate -quiet gcov.ii 
../../gcc-svn/trunk/gcc/gcov.c:2348:1: internal compiler error: vector
VEC(inline_edge_summary_t,base) index domain error, in inline_edge_summary at
ipa-inline.h:200
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-25
 Ever Confirmed|0   |1

--- Comment #8 from Uros Bizjak  2012-05-25 20:05:57 
UTC ---
Confirmed on x86_64-pc-linux-gnu with:

Target: x86_64-unknown-linux-gnu
gcc version 4.8.0 20120525 (experimental) [trunk revision 187887] (GCC)

[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #3 from Daniel Krügler  
2012-05-25 20:09:20 UTC ---
An interesting aspect of this example is that when using gcc 4.8.0 20120520
(experimental) compiled in C++11 mode with -Wall it produces the warning

"7|warning: 'i' is used uninitialized in this function [-Wuninitialized]"

where line 7 is the line of the lambda-expression and producing an output of:

0

[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak  2012-05-25 20:10:54 
UTC ---
(gdb) bt
#0  internal_error (gmsgid=0x1214dd8 "vector %s %s domain error, in %s at
%s:%u") at ../../gcc-svn/trunk/gcc/diagnostic.c:951
#1  0x00ef31a9 in vec_assert_fail (op=0x11d3093 "index",
struct_name=0xfa61d0 "VEC(inline_edge_summary_t,base)", file=,
line=200, 
function=0xfa6fd0 "inline_edge_summary") at
../../gcc-svn/trunk/gcc/vec.c:528
#2  0x0079114e in VEC_inline_edge_summary_t_base_index (ix_=, vec_=, file_=, line_=,
function_=)
at ../../gcc-svn/trunk/gcc/ipa-inline.h:145
#3  inline_edge_summary (edge=) at
../../gcc-svn/trunk/gcc/ipa-inline.h:199
#4  cgraph_propagate_frequency_1 (node=0x7109b138, data=0x7fffdb20) at
../../gcc-svn/trunk/gcc/cgraph.c:1805
#5  0x00794810 in cgraph_for_node_and_aliases (node=0x7109b138,
callback=0x790f10 ,
data=0x7fffdb20, 
include_overwritable=true) at ../../gcc-svn/trunk/gcc/cgraph.c:1633
#6  0x00794a92 in cgraph_propagate_frequency (node=0x7109b138) at
../../gcc-svn/trunk/gcc/cgraph.c:1839
#7  0x00930487 in symtab_remove_unreachable_nodes
(before_inlining_p=, file=0x0) at
../../gcc-svn/trunk/gcc/ipa.c:455
#8  0x0079b6a0 in ipa_passes () at
../../gcc-svn/trunk/gcc/cgraphunit.c:1853

[Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  2012-05-25 
20:26:20 UTC ---
Author: ebotcazou
Date: Fri May 25 20:26:11 2012
New Revision: 187892

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187892
Log:
PR lto/52178
* tree-inline.c (remap_gimple_op_r): Fix handling of FIELD_DECL.
* tree.c (RETURN_TRUE_IF_VAR): Do not return true for PLACEHOLDER_EXPR.

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

[Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #26 from Eric Botcazou  2012-05-25 
20:28:13 UTC ---
Author: ebotcazou
Date: Fri May 25 20:28:10 2012
New Revision: 187893

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187893
Log:
PR lto/52178
* tree-inline.c (remap_gimple_op_r): Fix handling of FIELD_DECL.
* tree.c (RETURN_TRUE_IF_VAR): Do not return true for PLACEHOLDER_EXPR.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/tree-inline.c
branches/gcc-4_7-branch/gcc/tree.c

[Bug c++/53490] Segmentation Fault when accessing std::set

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #3 from Daniel Krügler  
2012-05-25 20:29:48 UTC ---
At least for a mingw built of boost 1.49 and with gcc 4.8.0 20120520
(experimental) I get no runtime problem.

[Bug c++/53491] internal compiler error: in build_target_expr_with_type, at cp/tree.c:587

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-05-25 20:42:45 UTC ---
This error also exists in gcc 4.8.0 20120520 (experimental) with the slightly
modified error location (-Wall -std=c++11):

"12|internal compiler error: in build_target_expr_with_type, at cp/tree.c:602"

[Bug c++/53490] Segmentation Fault when accessing std::set

[ja11sop at yahoo dot co.uk]

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

--- Comment #4 from Jamie Allsop  2012-05-25 
22:04:13 UTC ---
(In reply to comment #1)
> (Blocker means it blocks a GCC release, so changing priority.)
> 
> Is the progam_options library built with -std=c++11 ?

Thanks for fixing the priority. It was a vanilla bjam build of boost 1.49, so
no -std=c++11.

[Bug c++/53490] Segmentation Fault when accessing std::set

[ja11sop at yahoo dot co.uk]

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

--- Comment #5 from Jamie Allsop  2012-05-25 
22:16:41 UTC ---
(In reply to comment #2)
> I only tried briefly but couldn't reproduce a crash with boost 1.47, will try
> later with boost 1.49

For clarity I should say I just tried with a vanilla build of 1.47 and get
essentially the same backtrace here.

Program received signal SIGSEGV, Segmentation fault.
0x77933427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x77933427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00464233 in std::_Rb_tree_iterator::operator--
(this=0x7fffdc60)
at /usr/include/c++/4.7/bits/stl_tree.h:203
#2  0x00462db0 in std::_Rb_tree, std::less,
std::allocator >::_M_insert_unique
(this=0x6a4540, __v=...)
at /usr/include/c++/4.7/bits/stl_tree.h:1295
#3  0x00461c2b in std::set,
std::allocator >::insert (
this=0x6a4540, __x=...) at /usr/include/c++/4.7/bits/stl_set.h:415
#4  0x0047afb5 in boost::program_options::store (options=..., xm=...,
utf8=false)
at libs/program_options/src/variables_map.cpp:98
#5  0x00460480 in store_properties (argc=2, argv=0x7fffe0b0) at
program_options_test.cpp:31
#6  0x004607db in main (argc=1, argv=0x7fffe1c8) at
program_options_test.cpp:64
(gdb)

[Bug c++/53491] internal compiler error: in build_target_expr_with_type, at cp/tree.c:587

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-25
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2012-05-25 
22:51:33 UTC ---
Eh, eh, the compiler barfed and croaked (or a mix) because of this:

  gcc_assert (!VOID_TYPE_P (type));

Should be easy to fix, then.

[Bug c++/53492] New: [g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 ] internal compiler error: in retrieve_specialization, at cp/pt.c:985

[endight at gmail dot com]

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

 Bug #: 53492
   Summary: [g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 ] internal
compiler error: in retrieve_specialization, at
cp/pt.c:985
Classification: Unclassified
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: endi...@gmail.com


Created attachment 27501
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27501
Preprocessed source stored into /tmp/ccTNE1Sa.out file, please attach this to
your bugreport.

template
struct foo{
struct bat;
template
class quux;
};

template
class foo::bat
{};

template<>
template
class foo::quux{
quux(typename foo::bat*){}
};


template
struct buz: public foo::template bar{};

int main()
{
foo::quux lol; // bug
}
// gives this
../main.cpp: In instantiation of 'foo::quux':
../main.cpp:24:22:   instantiated from here
../main.cpp:15:2: internal compiler error: in retrieve_specialization, at
cp/pt.c:985

[Bug c++/53491] [4.7/4.8 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
Summary|internal compiler error: in |[4.7/4.8 Regression] ICE in
   |build_target_expr_with_type |build_target_expr_with_type
   |, at cp/tree.c:587  |, at cp/tree.c:587

--- Comment #3 from Paolo Carlini  2012-05-25 
23:14:39 UTC ---
This is enough:

struct M
{
  void pop();
};

int main()
{
  int result = 0;
  M m;

  result += m.pop();
}

looks like a Regression.

[Bug c++/32054] Storage classes on anonymous unions in classes

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2012-05-25 23:40:17 UTC ---
Author: paolo
Date: Fri May 25 23:40:10 2012
New Revision: 187902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187902
Log:
/cp
2012-05-25  Paolo Carlini  

PR c++/32054
* parser.c (cp_parser_member_declaration): A storage class is not
allowed in a declaration of an anonymous aggregate in a class scope.

/testsuite
2012-05-25  Paolo Carlini  

PR c++/32054
* g++.dg/other/anon-union3.C: New.


Added:
trunk/gcc/testsuite/g++.dg/other/anon-union3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/32054] Storage classes on anonymous unions in classes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Paolo Carlini  2012-05-25 
23:42:28 UTC ---
Fixed for 4.8.0.

[Bug c++/53490] Segmentation Fault when accessing std::set

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-05-26 
00:02:13 UTC ---
(In reply to comment #4)
> It was a vanilla bjam build of boost 1.49, so
> no -std=c++11.

Then technically that's not supported, since there are no guarantees of
link-compatibility between -std=c++98 and -std=c++11 code (but I'm not aware of
any specific reasons it wouldn't work for a std::set)

(In reply to comment #5)
> For clarity I should say I just tried with a vanilla build of 1.47 and get
> essentially the same backtrace here.

I don't think the build of boost 1.47 I used earlier was non-vanilla in any
way, and I get no segfault on Fedora 16 using the system's
boost-static-1.47.0-6.fc16.x86_64.rpm with:

~/gcc/4.7/bin/g++ j.cc -std=c++11 -Wl,-Bstatic -lboost_program_options
-Wl,-Bdynamic

Is it significant that you link statically? Does it fail in the same way if you
link dynamically?

[Bug c++/53491] [4.7/4.8 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #4 from Paolo Carlini  2012-05-26 
00:13:50 UTC ---
On it.

[Bug c++/53493] New: [4.7 regression] Compiling with -Os excludes PROGMEM array from generated object file (__attribute__((__progmem__)))

[jwatte at gmail dot com]

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

 Bug #: 53493
   Summary: [4.7 regression] Compiling with -Os excludes PROGMEM
array from generated object file
(__attribute__((__progmem__)))
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwa...@gmail.com


I'm using AVR-GCC 4.7.0-1 from Arch Linux, if it matters. 

When compiling with -Os (which is pretty much a must for most source code,) an
exported data array declared as PROGMEM will be removed by the compiler! 

Compare without -Os: 

Code:
$ avr-gcc -mmcu=atmega328p -c foo.cpp -o foo.o && avr-objdump -s foo.o 

foo.o: file format elf32-avr 

Contents of section .progmem.data: 
  666f6f00 foo.
Contents of section .comment: 
  00474343 3a202847 4e552920 342e372e  .GCC: (GNU) 4.7. 
 0010 3000 0.  


to with -Os: 

Code:
$ avr-gcc -Os -mmcu=atmega328p -c foo.cpp -o foo.o && avr-objdump -s foo.o 

foo.o: file format elf32-avr 

Contents of section .comment: 
  00474343 3a202847 4e552920 342e372e  .GCC: (GNU) 4.7. 
 0010 3000 0.  


Here is foo.cpp: 

Code:
#include  

unsigned char const foo[4] PROGMEM = { 'f', 'o', 'o', 0 }; 



Must I add some magic GNU make hack to my makefiles to not pass -Os for these
files? That's fairly cumbersome  
Is this a known bug? Is there a patch?

[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2012-05-26 
01:50:09 UTC ---
(In reply to comment #3)
> Could you please try that patch and reply to the discussion there to say if it
> address the issue on your target?

It does thanks, see the reply.