[Bug fortran/47296] I/O Segfault when running out of file descriptors

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #5 from Janne Blomqvist  2011-01-15 09:18:18 
UTC ---
Nice catch.

Looking at the code, when creating a SCRATCH file fails, unix.c:tempfile()
returns -1, then as a result open_external() returns NULL, but then in
open.c:new_unit() even though we have checked that open_external() returns
NULL, we still call unpack_filename(), as well as accessing opp->file_len.

Just to be sure, I suspect it would be prudent to set opp->file to NULL and
opp->file_len to 0 in tempfile() in case fd < 0. Or are we sure that the entire
opp struct is set to 0 sometime before?

[Bug libstdc++/36104] [4.3/4.4/4.5/4.6 Regression] gnu-versioned-namespace is broken

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-01-15 
09:55:21 UTC ---
So, is this now fixed for 4.6+?

[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  2011-01-15 
10:49:30 UTC ---
I think the http://gcc.gnu.org/ml/gcc-cvs/2011-01/msg00186.html check in and
all its follow-ups should be reverted, Java simply doesn't have a va_list type,
so it shouldn't be built.
Instead ix86_local_alignment should add va_list_type_node && to its checks
before using TYPE_MAIN_VARIANT on it.

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-01-15 
11:03:13 UTC ---
Submitted patch: See http://gcc.gnu.org/ml/fortran/2011-01/msg00094.html

There were additional restrictions with BIND(C) - and as Ian pointed out, there
are also issues when using the function as specification expression in
arguments of PUBLIC functions, cf.
http://gcc.gnu.org/ml/fortran/2011-01/msg00100.html

For submodules, one also needs to be careful - as submodules can access PRIVATE
modules of the host. However, as submodules cannot be USE associated and in
order to use them, a "module function/subroutine" is defined in the module, it
is known at compile time whether a submodule exists or not.

Thus, the optimization can be done - but one needs additional checks whether
the function is used in specification expressions (probably only for function
results) and later whether the module itself has submodules or not.

[Bug fortran/47266] Optimization: Declare PRIVATE module procedures as "TREE_PUBLIC = 0" ("static function")

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-15 
11:05:06 UTC ---
Another note: Seemingly, the current patch does not work, if the default access
mode is "PRIVATE" and only if one explicitly sets the privacy. (Which is a
missed optimization.)

[Bug libstdc++/47305] std::vector::erase() destroys the wrong element!

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  2011-01-15 
11:08:06 UTC ---
(In reply to comment #0)
> In the C++ stdlib distribution included with Mac OS X (Darwin 10.5.0 i386), 
> the

GCC 4.2 is no longer maintained, you should either try a current release or
report bugs to Apple.

> implementation of std::vector::erase() from vector.tcc lines 106-116 is shown
> here:
> 
>   template
> typename vector<_Tp, _Alloc>::iterator
> vector<_Tp, _Alloc>::
> erase(iterator __position)
> {
>   if (__position + 1 != end())
> std::copy(__position + 1, end(), __position);
>   --this->_M_impl._M_finish;
>   this->_M_impl.destroy(this->_M_impl._M_finish);
>   return __position;
> }
> 
> 
> Note that "destroy()" will be called for the element that is *last* in the
> vector prior to the call to this erase(), instead of being called for the
> element pointed to by __position.  I believe this is incorrect -- I think it
> should instead call destroy() for the element pointed to by __position.

No, the element at position is overwritten by the call to std::copy()

> For
> simple POD types, this isn't that big of a deal, but for classes where the
> destructors have side effects (such as smart pointers), it can be critical. 
> 
> The following code illustrates the problem:
> 
> 
> #include 
> #include 
> 
> class MyClass
> {
> int m_x;
> public:
>  MyClass(int x) : m_x(x) { }
> ~MyClass()
> {
> std::cerr << "Destroying with m_x=" << m_x << std::endl;
> }
> };
> 
> int main(void)
> {
> std::vector testvect;
> testvect.reserve(8);
> testvect.push_back(MyClass(1));
> testvect.push_back(MyClass(2));
> testvect.push_back(MyClass(3));
> testvect.push_back(MyClass(4));
> testvect.push_back(MyClass(5));
> 
> std::cerr << "ABOUT TO DELETE #3:" << std::endl;
> 
> testvect.erase(testvect.begin() + 2);
> 
> std::cerr << "DONE WITH DELETE." << std::endl;
> 
> return 0;
> }
> 
> 
> When I compile this with g++ version 4.2.1 (no command line arguments) on my
> Mac, it produces the following when I run it:
> 
> Destroying with m_x=1
> Destroying with m_x=2
> Destroying with m_x=3
> Destroying with m_x=4
> Destroying with m_x=5
> ABOUT TO DELETE #3:
> Destroying with m_x=5
> DONE WITH DELETE.
> Destroying with m_x=1
> Destroying with m_x=2
> Destroying with m_x=4
> Destroying with m_x=5

As you can see, the results are correct, the vector contains {1,2,4,5}

> Note that the key line after the "ABOUT TO DELETE #3" message shows that the
> destructor was actually called for the fifth thing I added.  Importantly, the
> destructor for #3 is never called!!

Doesn't matter, the requirements of std::vector do not say that must happen

[Bug tree-optimization/47059] compiler fails to coalesce loads/stores

[rahul at icerasemi dot com]

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

--- Comment #1 from Rahul Kharche  2011-01-15 
12:32:01 UTC ---
Created attachment 22974
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22974
Patch Vs 4.5.2 Rev 167088

[Bug tree-optimization/47059] compiler fails to coalesce loads/stores

[rahul at icerasemi dot com]

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

--- Comment #2 from Rahul Kharche  2011-01-15 
12:43:27 UTC ---
This issue also exists on the trunk. I am in the process of bootstrap testing
this for i686-pc-linux-gnu. I will send out this patch once it checks out.
The attached patch is Vs 4.5.2 Rev 167088.

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-01-15 
13:35:46 UTC ---
On IRC you've mentioned some TLS test issues, were they caused by this patch or
unrelated?

[Bug c++/33558] 'mutable' incorrectly accepted on reference members

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-01-15 
14:41:12 UTC ---
Author: redi
Date: Sat Jan 15 14:41:09 2011
New Revision: 168843

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168843
Log:
2011-01-15  Giovanni Funchal  
Jonathan Wakely  

PR c++/33558
* decl.c (grokdeclarator): Reject mutable reference members.


Added:
trunk/gcc/testsuite/g++.dg/other/pr33558-2.C
trunk/gcc/testsuite/g++.dg/other/pr33558.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/33558] 'mutable' incorrectly accepted on reference members

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #6 from Jonathan Wakely  2011-01-15 
14:42:39 UTC ---
Patch approved by Jason at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00918.html

Fixed for 4.6.0

[Bug fortran/47296] I/O Segfault when running out of file descriptors

[jvdelisle at frontier dot com]

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

--- Comment #6 from jvdelisle at frontier dot com 2011-01-15 14:51:00 UTC ---
> Just to be sure, I suspect it would be prudent to set opp->file to NULL and
> opp->file_len to 0 in tempfile() in case fd<  0. Or are we sure that the 
> entire
> opp struct is set to 0 sometime before?
>

I had the same thought. I believe it is "zeroed" when the opp structure is 
initialized...

at line 449 or so of open.c"

   switch (flags->status)
 {
 case STATUS_SCRATCH:
   if ((opp->common.flags & IOPARM_OPEN_HAS_FILE) == 0)
{
  opp->file = NULL;
  break;
}

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[ramana.r at gmail dot com]

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

--- Comment #8 from Ramana Radhakrishnan  2011-01-15 
15:16:59 UTC ---
On Sat, Jan 15, 2011 at 1:36 PM, jakub at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701
>
> --- Comment #7 from Jakub Jelinek  2011-01-15 
> 13:35:46 UTC ---
> On IRC you've mentioned some TLS test issues, were they caused by this patch 
> or
> unrelated?

Been travelling this week. Should be able to get answers once I can
access my board next week.


cheers
Ramana

>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug c++/46715] template constructor - Compiler Bus error under -O2/-Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.01.15 15:23:16
 Ever Confirmed|0   |1

[Bug tree-optimization/47276] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:857 during compiling glibc.

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  2011-01-15 
15:45:00 UTC ---
Author: hubicka
Date: Sat Jan 15 15:44:56 2011
New Revision: 168844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168844
Log:
PR tree-optimization/47276 
* ipa.c (function_and_variable_visibility): Do not try to mark alias
declarations as needed.
* gcc.dg/pr47276.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr47276.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c
trunk/gcc/testsuite/ChangeLog

[Bug web/47306] New: Wrong name of a programming language used

[tg at mirbsd dot org]

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

   Summary: Wrong name of a programming language used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@mirbsd.org


Hi,

both http://gcc.gnu.org/gcc-4.6/changes.html and
today’s http://gcc.gnu.org/index.html#news pretend
GCC has gained support for the Go programming lan-
guage, whereas it has only gained support for the
Google-Go programming language instead, according
to what I read.

Please see (I hate to point to Wikipedia, but that’s
illustrating the problem) the information at
http://en.wikipedia.org/wiki/Go!_(programming_language)
and correct the attribution. The Go language not in
GCC has been around far longer and as such earlier
naming rights, and it’s wrong for the FSF / GCC-SC
to follow a vendor’s attempt of this hostile takeover.

Thanks in advance!

[Bug tree-optimization/47276] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:857 during compiling glibc.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jan Hubicka  2011-01-15 
15:50:24 UTC ---
Fixed.

[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.15 15:50:48
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  2011-01-15 
15:50:48 UTC ---
Confirmed : For the record the command line options are :

-mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -O3 -mthumb


cheers
Ramana

[Bug fortran/47307] New: be used uninitialized in this function

[jszhao at yeah dot net]

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

   Summary: be used uninitialized in this function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jsz...@yeah.net


Hi there,

With the example code below, gfortran (4.5.0 and 4.6.0) give a strange warning
message with -O2 flag:

> gfortran -Wall -O2 -c readmo.f90
readmo.f90: In function 'readmo':
readmo.f90:4:0: warning: 'convrt' may be used uninitialized in this function

When with -O0, the warning message disappear.

In fact, the array 'lopt' is not initialized in the code, however, the compiler
does not give warning about that. I try the same code with g95, it give a
warning message 'used but not set' about 'lopt'.

Any suggestions or comments? Thanks in advance!

Regards,
Jinsong



subroutine readmo()
 example code readmo.f90 

   implicit none
   real :: convrt
   integer :: i, iflag, j
   integer, dimension(3,5) :: lopt

   iflag = 0
   do i = 1, 5
  do j = 1, 3
 if ( lopt(j,i) < 0 ) then
convrt = 1.0
if ( j > 1 ) convrt = 2.0
iflag = 1
 endif
  enddo
   enddo
   if ( iflag /= 0 ) then
  do i = 1, 5
 write(6,*) i*convrt
  enddo
   endif

end subroutine readmo

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
Summary|[4.5/4.6 Regression]|[4.5.2/4.6 Regression]
   |SpecCpu2000 Ammp segfaults  |SpecCpu2000 Ammp segfaults
   |for ARM with -O3 -mthumb|for ARM with -O3 -mthumb
   Severity|normal  |critical

--- Comment #13 from Eric Botcazou  2011-01-15 
16:06:36 UTC ---
Please consider reverting the reload change on the branch.  I don't think we
want to keep fiddling with reload there.

[Bug debug/47308] New: Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[pluto at agmk dot net]

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

   Summary: Dwarf Error: Cannot find signatured DIE referenced
from DIE at 0x2581 [in module D:\main64.exe]
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


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

mingw testcase:


main.cpp:

#include 
#include 
#include 
#include 
#include 

::LONG CALLBACK vectoredExceptionHandler( ::PEXCEPTION_POINTERS ep )
{
std::printf( "entering vectorized ex. handler 0x%lx...\n",
ep->ExceptionRecord->ExceptionCode );
return EXCEPTION_CONTINUE_SEARCH;
}

::LONG WINAPI unhandledExecptionFilter( ::PEXCEPTION_POINTERS ep )
{
std::printf( "entering unhandled ex. filter 0x%lx...\n",
ep->ExceptionRecord->ExceptionCode );
return EXCEPTION_EXECUTE_HANDLER; // should terminate process.
}

int main()
{
::AddVectoredExceptionHandler( 1, vectoredExceptionHandler );
::SetUnhandledExceptionFilter( unhandledExecptionFilter );
try
{
int i = 42;
std::printf( "throwing int %d...\n", i );
throw i;
}
catch ( int i )
{
std::printf( "catching int %d...\n", i );
}
volatile int* p = 0;
std::printf( "accessing null pointer...\n" );
*p = 0;
return 0;
}

makefile:

CXXFLAGS := -Wall -gdwarf-2 -g2 -fdwarf2-cfi-asm --save-temps

all: main.cpp
/local/devel/toolchain46/x86_64-pc-mingw32/bin/x86_64-pc-mingw32-g++
$(CXXFLAGS) main.cpp -o main64.exe && mv main.s main64.s

clean:
rm -f *.exe


D:\>mingw64\bin\gdb.exe main64.exe
GNU gdb (GDB) 7.1.90.20100730-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
(...)
Breakpoint 1, main () at main.cpp:21
21  in main.cpp
(gdb) disassemble
Dump of assembler code for function main():
=> 0x004015ac <+0>: push   %rbp
   0x004015ad <+1>: push   %r15
   0x004015af <+3>: push   %r14
   0x004015b1 <+5>: push   %r13
   0x004015b3 <+7>: push   %r12
   0x004015b5 <+9>: push   %rdi
   0x004015b6 <+10>:push   %rsi
   0x004015b7 <+11>:push   %rbx
   0x004015b8 <+12>:sub$0x158,%rsp
   0x004015bf <+19>:lea0x80(%rsp),%rbp
   0x004015c7 <+27>:movaps %xmm6,0x30(%rbp)
   0x004015cb <+31>:movaps %xmm7,0x40(%rbp)
   0x004015cf <+35>:movaps %xmm8,0x50(%rbp)
   0x004015d4 <+40>:movaps %xmm9,0x60(%rbp)
   0x004015d9 <+45>:movaps %xmm10,0x70(%rbp)
   0x004015de <+50>:movaps %xmm11,0x80(%rbp)
   0x004015e6 <+58>:movaps %xmm12,0x90(%rbp)
   0x004015ee <+66>:movaps %xmm13,0xa0(%rbp)
   0x004015f6 <+74>:movaps %xmm14,0xb0(%rbp)
   0x004015fe <+82>:movaps %xmm15,0xc0(%rbp)
   0x00401606 <+90>:Dwarf Error: Cannot find signatured DIE
referenced from DIE at 0x2581 [in module D:\main64.exe]


iirc the gcc-4.5 generates correct debuginfo.

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #1 from Pawel Sikora  2011-01-15 16:15:11 
UTC ---
used software:

$ x86_64-pc-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=./x86_64-pc-mingw32-g++
COLLECT_LTO_WRAPPER=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib/gcc/x86_64-pc-mingw32/4.6.0/lto-wrapper
Target: x86_64-pc-mingw32
Configured with: ../configure --target=x86_64-pc-mingw32 --with-arch=core2
--prefix=/local/devel/toolchain46/x86_64-pc-mingw32.host64
--with-sysroot=/local/devel/toolchain46/x86_64-pc-mingw32.host64
--libdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--libexecdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--with-slibdir=/local/devel/toolchain46/x86_64-pc-mingw32.host64/lib
--with-gmp-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-gmp-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--with-mpfr-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-mpfr-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--with-mpc-include=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/include
--with-mpc-lib=/home/users/pluto/alatek/toolchain/trunk/gcc-math-runtime/lib
--disable-multilib --disable-nls --disable-libgomp --disable-libmudflap
--disable-libssp --enable-tls --enable-libstdcxx-allocator=mt
--enable-cxx-flags='-O2 -mcld -gdwarf-4 -g2' --disable-libstdcxx-pch
--disable-lto --disable-plugin --enable-c99 --enable-long-long
--disable-win32-registry --enable-threads=win32 --enable-sjlj-exceptions
--enable-shared --enable-fully-dynamic-string --enable-__cxa_atexit
--enable-languages=c,c++ --enable-checking=release --disable-symvers
--with-long-double-128 --disable-cld --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110113 (experimental) (GCC)

$ ./x86_64-pc-mingw32-as --version
GNU assembler (Linux/GNU Binutils) 2.21.51.0.5.20110104

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||burnus at gcc dot gnu.org
  Component|fortran |middle-end
Summary|be used uninitialized in|Uninitialized in this
   |this function   |function: warning for
   ||initialized, no warning for
   ||uninitialized

--- Comment #1 from Tobias Burnus  2011-01-15 
16:22:27 UTC ---
Move to middle end. From the dump:

readmo ()
{
  integer(kind=4) lopt[15];
  real(kind=4) convrt;
  [...]
  iflag = 0;
  [...]
if (lopt[((integer(kind=8)) j + (integer(kind=8)) i * 3) + -4] < 0)
  {
convrt = 1.0e+0;
iflag = 1;
  }
  if (iflag != 0)
... access convrt ...

Thus, lopt is never set, but not warned for. But convrt is only accessed if it
is set. However, the middle-end (with optimization) only has
  warning: 'convrt' may be used uninitialized in this function

[Bug tree-optimization/45934] [4.6 Regression] g++.old-deja/g++.other/dtor5.C FAILs with -finline-small-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  2011-01-15 
16:37:37 UTC ---
Fixed now?

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #35 from Jan Hubicka  2011-01-15 
16:42:06 UTC ---
I looked briefly into effectivity of the devirtualization bits and they don't
seem to work terribly well.
In GCC 4.3 -O3 copmiled libxul there are 82155 indirect calls.
In mainline -O3 libxul there are 83023 and with LTO there are 87763.

The ipa-prop bits at LTO devirtualize 1 call that is consequently optimized
away (since -fno-devirtualize seems same to -fdevirtualize).

I will give a try http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01214.html

However we _really_ need testcases from Mozilla where devirtualization is valid
and we don't do it.

[Bug c++/47303] [4.6 Regression] ICE: in varpool_node, at varpool.c:134 with -fabi-version=1

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.15 16:51:37
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-01-15 16:51:37 
UTC ---
It is caused by revision 163804:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00095.html

[Bug c++/46977] [4.6 Regression] [C++0x] ICE: SIGSEGV in htab_find_slot_with_hash (hashtab.c:650)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 AssignedTo|aoliva at gcc dot gnu.org   |jason at gcc dot gnu.org

--- Comment #4 from Alexandre Oliva  2011-01-15 
17:20:12 UTC ---
Yours, then ;-)

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #36 from Jan Hubicka  2011-01-15 
17:21:16 UTC ---
Hmm, the patch makes no difference, but I also see failure in its testcase
FAIL: g++.dg/ipa/imm-devirt-1.C scan-tree-dump optimized "= B::.*foo"
FAIL: g++.dg/ipa/imm-devirt-2.C scan-tree-dump optimized "= B::.*foo"
so I will wait for Martin to commit rest of his series and/or update the patch.

[Bug fortran/47295] libquadmath: List __complex128 and constants in the .texi file

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-15 
17:55:35 UTC ---
(In reply to comment #1)
> We do not list the analogous constants for float, double,
> and long double anywhere in the Fortran manual.

Note: The PR is about libquadmath and libquadmath.texi and not about the GNU
Fortran manual.
Cf. http://gcc.gnu.org/onlinedocs/libquadmath/

 * * *

Patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01059.html

[Bug fortran/47296] I/O Segfault when running out of file descriptors

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  2011-01-15 
18:16:33 UTC ---
Unpatched on Cygwin on Windows 7, I do not get the segfault. I also do not get
the OS error.  The assign error mechanism of the test case picks up that there
is a problem.  The windows version does not give an error and sets the tempfile
name string even though no file is opened.  I am doing a rebuild to latest
trunk on the Win7 box, so when that is done, I will see what mechanism we need
to error out on this.

[Bug boehm-gc/47309] New: gcc-4.4.5 fails to build on darwin/ppc due to issues in boehm-gc GC_test_and_set

[jeremyhu at macports dot org]

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

   Summary: gcc-4.4.5 fails to build on darwin/ppc due to issues
in boehm-gc GC_test_and_set
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: boehm-gc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jerem...@macports.org


temp work dir replaced with "..." for better readability:

libtool: compile:  .../build/./gcc/xgcc -B.../build/./gcc/
-B/opt/local/ppc-apple-darwin9/bin/ -B/opt/local/ppc-apple-darwin9/lib/
-isystem /opt/local/ppc-apple-darwin9/include -isystem
/opt/local/ppc-apple-darwin9/sys-include -DHAVE_CONFIG_H
-I.../gcc-4.4.5/boehm-gc/include -fexceptions -Iinclude -I././targ-include
-I.//libc/include -g -pipe -ggdb3 -fexceptions -Iinclude -I././targ-include
-I.//libc/include -c ../../../gcc-4.4.5/boehm-gc/os_dep.c  -fno-common -DPIC -o
.libs/os_dep.o
In file included from .../gcc-4.4.5/boehm-gc/include/private/gc_priv.h:98,
 from ../../../gcc-4.4.5/boehm-gc/os_dep.c:17:
.../gcc-4.4.5/boehm-gc/include/private/gc_locks.h: In function
'GC_test_and_set':
.../gcc-4.4.5/boehm-gc/include/private/gc_locks.h:165: error: 'asm' operand has
impossible constraints

inline static int GC_test_and_set(volatile unsigned int *addr) {
  int oldval;
  int temp = 1; /* locked value */

  __asm__ __volatile__(
   "1:\tlwarx %0,0,%3\n"   /* load and reserve   */
   "\tcmpwi %0, 0\n"   /* if load is */
   "\tbne 2f\n"/*   non-zero, return already set */
   "\tstwcx. %2,0,%1\n"/* else store conditional */
   "\tbne- 1b\n"   /* retry if lost reservation  */
   "\tsync\n"  /* import barrier */
   "2:\t\n"/* oldval is zero if we set   */
  : "=&r"(oldval), "=p"(addr)
  : "r"(temp), "1"(addr)
  : "cr0","memory");
  return oldval;
}

[Bug fortran/47296] I/O Segfault when running out of file descriptors

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  2011-01-15 19:31:17 
UTC ---
I suppose one thing that could be done is to set opp->file and opp->file_len
regardless of whether mkstemp() succeeds or not, that is lines 1987:1093 in
unix.c, and then in open.c:new_unit() one can free opp->file after generating a
suitable error message. 

Even if the file name is automatically generated, maybe it would be helpful to
provide the user with info exactly what failed, e.g. so that the user knows
what failed was opening a file under /tmp which might otherwise not be obvious
to the user.

[Bug c++/47310] New: -mint8 causes avr-g++ to SIGSEGV

[k0l0b0k.void at gmail dot com]

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

   Summary: -mint8 causes avr-g++ to SIGSEGV
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k0l0b0k.v...@gmail.com


For GCC 4.5.1 and 4.5.2 (installed from standard Arch Linux package), I found
simple bug - if you specify -mint8 option as compiler param, you'll get this:

:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


steps to reproduce (Linux/bash):
1. cd /tmp
2. echo "int main() { return 0; }" > test.cpp
3. avr-gcc -mint8 test.cpp
4. got SIGSEGV

avr-g++ will fail too.

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-01-15 
21:50:05 UTC ---
> In fact, the array 'lopt' is not initialized in the code, however, the 
> compiler
> does not give warning about that. I try the same code with g95, it give a
> warning message 'used but not set' about 'lopt'.

Add lopt(1,1) = 0 at the beginning of your code and the g95 warning just
disappears!
So don't rely too much of this kind of warning.

> Any suggestions or comments? Thanks in advance!

Searching bugzilla for "uninitialized" in the subject yields 52 entries for
open pr (not counting those closed as INVALID, DUPLICATE, WONTFIX, ...). I let
you browse the list to check if this pr is a duplicate of one of those (look
for instance to pr24639, my choice is pr27120).

As far as I understand the problem, 
(1) it could be as difficult to solve as running the code itself (think of an
array of 10**9 elements set through a spaghetti code and forgetting to set only
one element). Note this apply also to duplicate initialization (as in Fortran
legalese;-).
(2) the responsibility to use only set variables is on the user, not on the
compiler.

[Bug fortran/47295] libquadmath: List __complex128 and constants in the .texi file

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2011-01-15 21:56:40 UTC ---
On Sat, Jan 15, 2011 at 05:55:36PM +, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47295
> 
> --- Comment #2 from Tobias Burnus  2011-01-15 
> 17:55:35 UTC ---
> (In reply to comment #1)
> > We do not list the analogous constants for float, double,
> > and long double anywhere in the Fortran manual.
> 
> Note: The PR is about libquadmath and libquadmath.texi and not about the GNU
> Fortran manual.

See the Subject line.  Specific this part --> [Bug fortran/47295].
If there isn't a libquad tag, then use Other as in [Bug Other/47295].

[Bug c++/47311] New: [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

   Summary: [C++0x] ICE in tsubst @cp/pt.c:10502
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


current gcc-trunk (r168844) ICEs on my codebase:

10484│ case BOUND_TEMPLATE_TEMPLATE_PARM:
10485│ case TEMPLATE_PARM_INDEX:
10486│   {
10487│ int idx;
10488│ int level;
10489│ int levels;
10490│ tree arg = NULL_TREE;
10491│
10492│ r = NULL_TREE;
10493│
10494│ gcc_assert (TREE_VEC_LENGTH (args) > 0);
10495│ template_parm_level_and_index (t, &level, &idx);
10496│
10497│ levels = TMPL_ARGS_DEPTH (args);
10498│ if (level <= levels)
10499│   {
10500│ arg = TMPL_ARG (args, level, idx);
10501│
10502├>if (arg && TREE_CODE (arg) == ARGUMENT_PACK_SELECT)
10503│   /* See through ARGUMENT_PACK_SELECT arguments. */
10504│   arg = ARGUMENT_PACK_SELECT_ARG (arg);
10505│   }
10506│
10507│ if (arg == error_mark_node)
10508│   return error_mark_node;
10509│ else if (arg != NULL_TREE)
10510│   {
10511│ if (ARGUMENT_PACK_P (arg))
10512│   /* If ARG is an argument pack, we don't actually want to
10513│  perform a substitution here, because substitutions
10514│  for argument packs are only done
10515│  element-by-element. We can get to this point when
10516│  substituting the type of a non-type template
10517│  parameter pack, when that type actually contains
10518│  template parameter packs from an outer template, e.g.,
10519│
/home/users/pluto/alatek/toolchain/trunk/gcc-trunk/gcc/cp/pt.c

(gdb) r
Starting program:
/local/devel/toolchain46/x86_64-gnu-linux.host64/bin/x86_64-gnu-linux-g++ -c
-DHDL_EXPORTS -D_GNU_SOURCE -D_GLIBCXX_DEBUG -D_DEBUG -DBOOST_EXCEPTION_DISABLE
-pthread -Wall -Wno-uninitialized -Wno-deprecated -Wsign-compa
re -Wtype-limits -Woverloaded-virtual -Werror -mcld -fdwarf2-cfi-asm
-feliminate-unused-debug-types -march=x86-64 -O1 -gdwarf-4 -g2
-fno-strict-aliasing -fno-schedule-insns -fno-schedule-insns2 -std=gnu++0x
-fPIC -O2 -I./h -I./factories
-I./utils -I../VCM/h -I../def/h -I../hescore/h -isystem
../../buildenv/linux/gcc-4.6/64/boost-1.44.0/include -I../debugtools/h
-I../au/h -I../dp/h hdlVhdlArchitecture.cpp -o
obj-debug-x86_64-gnu-linux/hdlVhdlArchitecture.o
[New process 17639]
process 17639 is executing new program:
/local/devel/toolchain46/x86_64-gnu-linux.host64/lib64/gcc/x86_64-gnu-linux/4.6.0/cc1plus

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 17639]
0x00436c63 in tsubst (t=0x72fbfb28, args=0x72fbe540,
complain=0, in_decl=0x72fc18a0) at ../../gcc/cp/pt.c:10502
(gdb) bt
#0  0x00436c63 in tsubst (t=0x72fbfb28, args=0x72fbe540,
complain=0, in_decl=0x72fc18a0) at ../../gcc/cp/pt.c:10502
#1  0x0044262c in fixup_template_parm (parm_desc=0x72fbaac8,
idx=, num_parms=2, arglist=0x72fbe540) at
../../gcc/cp/pt.c:3879
#2  0x004428f9 in fixup_template_parms (parms=) at
../../gcc/cp/pt.c:3918
#3  end_template_parm_list (parms=) at
../../gcc/cp/pt.c:3617
#4  0x00477c38 in cp_parser_template_parameter_list
(parser=0x766ed420) at ../../gcc/cp/parser.c:11188
#5  0x00477e0a in cp_parser_type_parameter (parser=0x766ed420,
is_parameter_pack=0x7fffd28f "") at ../../gcc/cp/parser.c:11445
#6  0x00477bfb in cp_parser_template_parameter (parser=0x766ed420)
at ../../gcc/cp/parser.c:11250
#7  cp_parser_template_parameter_list (parser=0x766ed420) at
../../gcc/cp/parser.c:11164
#8  0x004794a3 in cp_parser_template_declaration_after_export
(parser=0x766ed420, member_p=0 '\000') at ../../gcc/cp/parser.c:19932
#9  0x0047c84a in cp_parser_declaration (parser=0x766ed420) at
../../gcc/cp/parser.c:9453
#10 0x0047b915 in cp_parser_declaration_seq_opt (parser=0x766ed420)
at ../../gcc/cp/parser.c:9383
#11 0x0047bab9 in cp_parser_namespace_body (parser=0x766ed420) at
../../gcc/cp/parser.c:13930
#12 cp_parser_namespace_definition (parser=0x766ed420) at
../../gcc/cp/parser.c:13911
#13 0x0047c7f8 in cp_parser_declaration (parser=0x766ed420) at
../../gcc/cp/parser.c:9485
#14 0x0047b915 in cp_parser_declaration_seq_opt (parser=0x766ed420)
at ../../gcc/cp/parser.c:9383
#15 0x0047cb85 in cp_parser_translation_unit () at
../../gcc/cp/parser.c:3463
#16 c_parse_file () at ../../gcc/cp/parser.c:25278
#17 0x004fda75 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1071
#18 0x00727974 in compile_file (argc=62, argv=0x7fffd5f8) at
../../gcc/toplev.c:579
#19 do_compile (arg

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

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

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Andreas Schwab  2011-01-15 22:44:11 
UTC ---
lto_varpool_replace_node has been broken since it was added in r158854.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-01-15 22:53:46 
UTC ---
(In reply to comment #0)
> current gcc-trunk (r168844) ICEs on my codebase:
> 
> accidentally, the --save-temps (or -std=gnu++98) removes the ICE,
> so how can i produce a preprocessed source for full bug report?

-E and -S.

H.J.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-01-15 22:55:38 
UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > current gcc-trunk (r168844) ICEs on my codebase:
> > 
> > accidentally, the --save-temps (or -std=gnu++98) removes the ICE,
> > so how can i produce a preprocessed source for full bug report?
> 
> -E and -S.
> 

Also use valgrind.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #3 from Pawel Sikora  2011-01-15 23:16:13 
UTC ---
Created attachment 22976
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22976
preprocessed source.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #4 from Pawel Sikora  2011-01-15 23:18:07 
UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > current gcc-trunk (r168844) ICEs on my codebase:
> > 
> > accidentally, the --save-temps (or -std=gnu++98) removes the ICE,
> > so how can i produce a preprocessed source for full bug report?
> 
> -E and -S.
> 
> H.J.

ok,
with -E i can produce .ii from .cpp.
with -S i can produce .s from .ii.
the whole compilation (.s from .cpp) ICEs.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #5 from Pawel Sikora  2011-01-15 23:20:41 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > current gcc-trunk (r168844) ICEs on my codebase:
> > > 
> > > accidentally, the --save-temps (or -std=gnu++98) removes the ICE,
> > > so how can i produce a preprocessed source for full bug report?
> > 
> > -E and -S.
> > 
> 
> Also use valgrind.

==28506==
==28507== Memcheck, a memory error detector
==28507== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28507== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==28507== Command:
/local/devel/toolchain46/x86_64-gnu-linux.host64/lib64/gcc/x86_64-gnu-linux/4.6.0/cc1plus
-E -quiet -I ./h -I ./factories -I ./utils -I ../VCM/h -I ../def/h -I
../hescore/h -I ../debugtools/h -I ../au/h -I ../dp/h -D_GNU_SOURCE
-D_REENTRANT -D HDL_EXPORTS -D _GNU_SOURCE -D _GLIBCXX_DEBUG -D _DEBUG -D
BOOST_EXCEPTION_DISABLE -isystem
../../buildenv/linux/gcc-4.6/64/boost-1.44.0/include hdlVhdlArchitecture.cpp
-mcld -march=x86-64 -std=gnu++0x -Wall -Wno-uninitialized -Wno-deprecated
-Wsign-compare -Wtype-limits -Woverloaded-virtual -Werror -fdwarf2-cfi-asm
-feliminate-unused-debug-types -fno-strict-aliasing -fno-schedule-insns
-fno-schedule-insns2 -fPIC -gdwarf-4 -g2 -fworking-directory -O1 -O2
==28507==

parse_type_DIE: confused by:
 <1><1444a3e>: DW_TAG_array_type
 DW_AT_type: 8 byte signature: 36 56 52 8f ec 5e fc e3
 DW_AT_sibling : <1444a52>

--28507-- WARNING: Serious error when reading debug info
--28507-- When reading debug info from
/local/devel/toolchain46/x86_64-gnu-linux.host64/lib64/gcc/x86_64-gnu-linux/4.6.0/cc1plus:
--28507-- parse_type_DIE: confused by the above DIE

vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x61 0x7 0x0

==28507== valgrind: Unrecognised instruction at address 0xb43594.
==28507== Your program just tried to execute an instruction that Valgrind
==28507== did not recognise.  There are two possible reasons for this.
==28507== 1. Your program has a bug and erroneously jumped to a non-code
==28507==location.  If you are running Memcheck and you just saw a
==28507==warning about a bad jump, it's probably your program's fault.
==28507== 2. The instruction is legitimate but Valgrind doesn't handle it,
==28507==i.e. it's Valgrind's fault.  If you think this is the case or
==28507==you are not sure, please let us know and we'll try to fix it.
==28507== Either way, Valgrind will now raise a SIGILL signal which will
==28507== probably kill your program.
hdlVhdlArchitecture.cpp:1:0: internal compiler error: Illegal instruction

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #6 from Pawel Sikora  2011-01-15 23:27:22 
UTC ---
(In reply to comment #5)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > current gcc-trunk (r168844) ICEs on my codebase:
> > > > 
> > > > accidentally, the --save-temps (or -std=gnu++98) removes the ICE,
> > > > so how can i produce a preprocessed source for full bug report?
> > > 
> > > -E and -S.
> > > 
> > 
> > Also use valgrind.
> 
> ==28506==
> ==28507== Memcheck, a memory error detector
> ==28507== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==28507== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
> ==28507== Command:
> /local/devel/toolchain46/x86_64-gnu-linux.host64/lib64/gcc/x86_64-gnu-linux/4.6.0/cc1plus
> -E -quiet -I ./h -I ./factories -I ./utils -I ../VCM/h -I ../def/h -I
> ../hescore/h -I ../debugtools/h -I ../au/h -I ../dp/h -D_GNU_SOURCE
> -D_REENTRANT -D HDL_EXPORTS -D _GNU_SOURCE -D _GLIBCXX_DEBUG -D _DEBUG -D
> BOOST_EXCEPTION_DISABLE -isystem
> ../../buildenv/linux/gcc-4.6/64/boost-1.44.0/include hdlVhdlArchitecture.cpp
> -mcld -march=x86-64 -std=gnu++0x -Wall -Wno-uninitialized -Wno-deprecated
> -Wsign-compare -Wtype-limits -Woverloaded-virtual -Werror -fdwarf2-cfi-asm
> -feliminate-unused-debug-types -fno-strict-aliasing -fno-schedule-insns
> -fno-schedule-insns2 -fPIC -gdwarf-4 -g2 -fworking-directory -O1 -O2
> ==28507==
> 
> parse_type_DIE: confused by:
>  <1><1444a3e>: DW_TAG_array_type
>  DW_AT_type: 8 byte signature: 36 56 52 8f ec 5e fc e3
>  DW_AT_sibling : <1444a52>
> 
> --28507-- WARNING: Serious error when reading debug info
> --28507-- When reading debug info from
> /local/devel/toolchain46/x86_64-gnu-linux.host64/lib64/gcc/x86_64-gnu-linux/4.6.0/cc1plus:
> --28507-- parse_type_DIE: confused by the above DIE
> 
> vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x61 0x7 0x0
> 
> ==28507== valgrind: Unrecognised instruction at address 0xb43594.
> ==28507== Your program just tried to execute an instruction that Valgrind
> ==28507== did not recognise.  There are two possible reasons for this.
> ==28507== 1. Your program has a bug and erroneously jumped to a non-code
> ==28507==location.  If you are running Memcheck and you just saw a
> ==28507==warning about a bad jump, it's probably your program's fault.
> ==28507== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==28507==i.e. it's Valgrind's fault.  If you think this is the case or
> ==28507==you are not sure, please let us know and we'll try to fix it.
> ==28507== Either way, Valgrind will now raise a SIGILL signal which will
> ==28507== probably kill your program.
> hdlVhdlArchitecture.cpp:1:0: internal compiler error: Illegal instruction

looks like valgrind problem with sse42 opcode:

http://bugs.kde.org/show_bug.cgi?id=262995

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-01-16 00:18:48 
UTC ---
(In reply to comment #6)
> 
> looks like valgrind problem with sse42 opcode:
> 

Disable SSE4 code to debug this.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #8 from Pawel Sikora  2011-01-16 00:38:34 
UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > 
> > looks like valgrind problem with sse42 opcode:
> > 
> 
> Disable SSE4 code to debug this.

i've removed the HAVE_SSE4 stuff from libcpp configures and now
valgrind reports following log for standard compilation:

==23474== Invalid read of size 8
==23474==at 0xB43513: search_line_sse2 (lex.c:382)
==23474==by 0xB4360E: _cpp_clean_line (lex.c:665)
==23474==by 0xB44027: _cpp_get_fresh_line (lex.c:1884)
==23474==by 0xB4580D: _cpp_lex_direct (lex.c:1949)
==23474==by 0xB46686: _cpp_lex_token (lex.c:1823)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==23474==by 0x47C9AB: c_parse_file (parser.c:25095)
==23474==by 0x4FDA74: c_common_parse_file (c-opts.c:1071)
==23474==by 0x727973: toplev_main (toplev.c:579)
==23474==  Address 0x53128b8 is 0 bytes after a block of size 408 alloc'd
==23474==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==23474==by 0xB6D49C: xrealloc (xmalloc.c:179)
==23474==by 0xB37F5F: _cpp_convert_input (charset.c:1734)
==23474==by 0xB402F2: read_file (files.c:648)
==23474==by 0xB4150A: _cpp_stack_file (files.c:723)
==23474==by 0xB38D60: do_include_common (directives.c:792)
==23474==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==23474==by 0xB466A4: _cpp_lex_token (lex.c:1835)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==23474== 
==23474== Invalid read of size 8
==23474==at 0xB43529: search_line_sse2 (lex.c:394)
==23474==by 0xB4360E: _cpp_clean_line (lex.c:665)
==23474==by 0xB44027: _cpp_get_fresh_line (lex.c:1884)
==23474==by 0xB4580D: _cpp_lex_direct (lex.c:1949)
==23474==by 0xB46686: _cpp_lex_token (lex.c:1823)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==23474==by 0x47CA22: c_parse_file (parser.c:425)
==23474==by 0x4FDA74: c_common_parse_file (c-opts.c:1071)
==23474==by 0x727973: toplev_main (toplev.c:579)
==23474==  Address 0x531cd00 is 160 bytes inside a block of size 163 alloc'd
==23474==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==23474==by 0xB6D49C: xrealloc (xmalloc.c:179)
==23474==by 0xB37F5F: _cpp_convert_input (charset.c:1734)
==23474==by 0xB402F2: read_file (files.c:648)
==23474==by 0xB4150A: _cpp_stack_file (files.c:723)
==23474==by 0xB38D60: do_include_common (directives.c:792)
==23474==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==23474==by 0xB466A4: _cpp_lex_token (lex.c:1835)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==23474==
==23474== Invalid read of size 8
==23474==at 0xB43529: search_line_sse2 (lex.c:394)
==23474==by 0xB4360E: _cpp_clean_line (lex.c:665)
==23474==by 0xB43C02: _cpp_skip_block_comment (lex.c:922)
==23474==by 0xB46319: _cpp_lex_direct (lex.c:2073)
==23474==by 0xB46686: _cpp_lex_token (lex.c:1823)
==23474==by 0xB384FA: check_eol (directives.c:222)
==23474==by 0xB398A7: do_endif (directives.c:1998)
==23474==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==23474==by 0xB466A4: _cpp_lex_token (lex.c:1835)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==  Address 0x555b6e8 is 12,536 bytes inside a block of size 12,543
alloc'd
==23474==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==23474==by 0xB6D49C: xrealloc (xmalloc.c:179)
==23474==by 0xB37F5F: _cpp_convert_input (charset.c:1734)
==23474==by 0xB402F2: read_file (files.c:648)
==23474==by 0xB4150A: _cpp_stack_file (files.c:723)
==23474==by 0xB38D60: do_include_common (directives.c:792)
==23474==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==23474==by 0xB466A4: _cpp_lex_token (lex.c:1835)
==23474==by 0xB48CF7: cpp_get_token (macro.c:1240)
==23474==by 0xB48F8F: cpp_get_token_with_location (macro.c:1352)
==23474==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==23474==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==23474==

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[pluto at agmk dot net]

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

--- Comment #2 from Pawel Sikora  2011-01-16 01:05:20 
UTC ---
without SSE2 vectorized lexer:

==2012== Invalid read of size 8
==2012==at 0xB43064: search_line_acc_char (lex.c:263)
==2012==by 0xB434FE: _cpp_clean_line (lex.c:669)
==2012==by 0xB43F17: _cpp_get_fresh_line (lex.c:1888)
==2012==by 0xB456FD: _cpp_lex_direct (lex.c:1953)
==2012==by 0xB46576: _cpp_lex_token (lex.c:1827)
==2012==by 0xB48BE7: cpp_get_token (macro.c:1240)
==2012==by 0xB48E7F: cpp_get_token_with_location (macro.c:1352)
==2012==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==2012==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==2012==by 0x47CA22: c_parse_file (parser.c:425)
==2012==by 0x4FDA74: c_common_parse_file (c-opts.c:1071)
==2012==by 0x727973: toplev_main (toplev.c:579)
==2012==  Address 0x531cd00 is 160 bytes inside a block of size 163 alloc'd
==2012==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==2012==by 0xB6D38C: xrealloc (xmalloc.c:179)
==2012==by 0xB37F5F: _cpp_convert_input (charset.c:1734)
==2012==by 0xB402F2: read_file (files.c:648)
==2012==by 0xB4150A: _cpp_stack_file (files.c:723)
==2012==by 0xB38D60: do_include_common (directives.c:792)
==2012==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==2012==by 0xB46594: _cpp_lex_token (lex.c:1839)
==2012==by 0xB48BE7: cpp_get_token (macro.c:1240)
==2012==by 0xB48E7F: cpp_get_token_with_location (macro.c:1352)
==2012==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==2012==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==2012==
==2012==
==2012==  Attach to debugger ? --- [Return/N/n/Y/y/C/c]  y
==2012== starting debugger with cmd: gdb --nw /proc/2013/fd/1014 2013
GNU gdb (GDB) PLD Linux (7.2-1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pld-linux".
For bug reporting instructions, please see:
...
Reading symbols from /proc/2013/fd/1014...done.
Attaching to program: /proc/2013/fd/1014, process 2013
Reading symbols from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so...done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
Reading symbols from
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so...done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
Reading symbols from /lib64/libc.so.6...Reading symbols from
/usr/lib/debug/lib64/libc-2.12.2.so.debug...done.
done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug/lib64/ld-2.12.2.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00b43064 in search_line_acc_char (s=, end=) at ../../libcpp/lex.c:263
263   val = *++p;
(gdb) bt
#0  0x00b43064 in search_line_acc_char (s=,
end=) at ../../libcpp/lex.c:263
#1  0x00b434ff in _cpp_clean_line (pfile=0x521d260) at
../../libcpp/lex.c:669
#2  0x00b43f18 in _cpp_get_fresh_line (pfile=0x521d260) at
../../libcpp/lex.c:1888
#3  0x00b456fe in _cpp_lex_direct (pfile=0x521d260) at
../../libcpp/lex.c:1953
#4  0x00b46577 in _cpp_lex_token (pfile=0x521d260) at
../../libcpp/lex.c:1827
#5  0x00b48be8 in cpp_get_token (pfile=0x521d260) at
../../libcpp/macro.c:1240
#6  0x00b48e80 in cpp_get_token_with_location (pfile=0x521d260,
loc=0x4141184) at ../../libcpp/macro.c:1352
#7  0x004f9f83 in c_lex_with_flags (value=0x4141188, loc=0x4141184,
cpp_flags=0x4141182 "", lex_flags=2) at ../../gcc/c-family/c-lex.c:302
#8  0x00463830 in cp_lexer_get_preprocessor_token (lexer=, token=0x4141180) at ../../gcc/cp/parser.c:548
#9  0x0047ca23 in cp_lexer_new_main () at ../../gcc/cp/parser.c:425
#10 cp_parser_new () at ../../gcc/cp/parser.c:3197
#11 c_parse_file () at ../../gcc/cp/parser.c:25275
#12 0x004fda75 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1071
#13 0x00727974 in compile_file (argc=62, argv=0x7fefff608) at
../../gcc/toplev.c:579
#14 do_compile (argc=62, argv=0x7fefff608) at ../../gcc/toplev.c:1874
#15 toplev_main (argc=62, argv=0x7fefff608) at ../../gcc/toplev.c:1937
#16 0x04e48cbd in __libc_start_main (main=0x50bdb0 , argc=62,
ubp_av=0x7fefff608, init=, fini=,
rtld_fini=, stack_end=0x7fefff5f8) at libc-start.c:226
#17 0x00402889 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) p p
$1 = (const word_type *) 0x531cd00
(gdb) l
258   int i = acc_char_index (t, val);
259   if (i >= 0)
260 return (const uchar *)p + i;
261 }
262
263   val = *++p;
264 }
265 

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[pluto at agmk dot net]

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

--- Comment #3 from Pawel Sikora  2011-01-16 01:09:21 
UTC ---
(In reply to comment #2)
> without SSE2 vectorized lexer:
> 
> ==2012== Invalid read of size 8
(...)

ahhh, comment for wrong PR. please ignore.

[Bug c++/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #9 from Pawel Sikora  2011-01-16 01:10:32 
UTC ---
without SSE2 vectorized lexer:

==2012== Invalid read of size 8
==2012==at 0xB43064: search_line_acc_char (lex.c:263)
==2012==by 0xB434FE: _cpp_clean_line (lex.c:669)
==2012==by 0xB43F17: _cpp_get_fresh_line (lex.c:1888)
==2012==by 0xB456FD: _cpp_lex_direct (lex.c:1953)
==2012==by 0xB46576: _cpp_lex_token (lex.c:1827)
==2012==by 0xB48BE7: cpp_get_token (macro.c:1240)
==2012==by 0xB48E7F: cpp_get_token_with_location (macro.c:1352)
==2012==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==2012==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==2012==by 0x47CA22: c_parse_file (parser.c:425)
==2012==by 0x4FDA74: c_common_parse_file (c-opts.c:1071)
==2012==by 0x727973: toplev_main (toplev.c:579)
==2012==  Address 0x531cd00 is 160 bytes inside a block of size 163 alloc'd
==2012==at 0x4C25322: realloc (vg_replace_malloc.c:525)
==2012==by 0xB6D38C: xrealloc (xmalloc.c:179)
==2012==by 0xB37F5F: _cpp_convert_input (charset.c:1734)
==2012==by 0xB402F2: read_file (files.c:648)
==2012==by 0xB4150A: _cpp_stack_file (files.c:723)
==2012==by 0xB38D60: do_include_common (directives.c:792)
==2012==by 0xB3A260: _cpp_handle_directive (directives.c:491)
==2012==by 0xB46594: _cpp_lex_token (lex.c:1839)
==2012==by 0xB48BE7: cpp_get_token (macro.c:1240)
==2012==by 0xB48E7F: cpp_get_token_with_location (macro.c:1352)
==2012==by 0x4F9F82: c_lex_with_flags (c-lex.c:302)
==2012==by 0x46382F: cp_lexer_get_preprocessor_token (parser.c:548)
==2012==
==2012==
==2012==  Attach to debugger ? --- [Return/N/n/Y/y/C/c]  y
==2012== starting debugger with cmd: gdb --nw /proc/2013/fd/1014 2013
GNU gdb (GDB) PLD Linux (7.2-1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pld-linux".
For bug reporting instructions, please see:
...
Reading symbols from /proc/2013/fd/1014...done.
Attaching to program: /proc/2013/fd/1014, process 2013
Reading symbols from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so...done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
Reading symbols from
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so...done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
Reading symbols from /lib64/libc.so.6...Reading symbols from
/usr/lib/debug/lib64/libc-2.12.2.so.debug...done.
done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug/lib64/ld-2.12.2.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00b43064 in search_line_acc_char (s=, end=) at ../../libcpp/lex.c:263
263   val = *++p;
(gdb) bt
#0  0x00b43064 in search_line_acc_char (s=,
end=) at ../../libcpp/lex.c:263
#1  0x00b434ff in _cpp_clean_line (pfile=0x521d260) at
../../libcpp/lex.c:669
#2  0x00b43f18 in _cpp_get_fresh_line (pfile=0x521d260) at
../../libcpp/lex.c:1888
#3  0x00b456fe in _cpp_lex_direct (pfile=0x521d260) at
../../libcpp/lex.c:1953
#4  0x00b46577 in _cpp_lex_token (pfile=0x521d260) at
../../libcpp/lex.c:1827
#5  0x00b48be8 in cpp_get_token (pfile=0x521d260) at
../../libcpp/macro.c:1240
#6  0x00b48e80 in cpp_get_token_with_location (pfile=0x521d260,
loc=0x4141184) at ../../libcpp/macro.c:1352
#7  0x004f9f83 in c_lex_with_flags (value=0x4141188, loc=0x4141184,
cpp_flags=0x4141182 "", lex_flags=2) at ../../gcc/c-family/c-lex.c:302
#8  0x00463830 in cp_lexer_get_preprocessor_token (lexer=, token=0x4141180) at ../../gcc/cp/parser.c:548
#9  0x0047ca23 in cp_lexer_new_main () at ../../gcc/cp/parser.c:425
#10 cp_parser_new () at ../../gcc/cp/parser.c:3197
#11 c_parse_file () at ../../gcc/cp/parser.c:25275
#12 0x004fda75 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1071
#13 0x00727974 in compile_file (argc=62, argv=0x7fefff608) at
../../gcc/toplev.c:579
#14 do_compile (argc=62, argv=0x7fefff608) at ../../gcc/toplev.c:1874
#15 toplev_main (argc=62, argv=0x7fefff608) at ../../gcc/toplev.c:1937
#16 0x04e48cbd in __libc_start_main (main=0x50bdb0 , argc=62,
ubp_av=0x7fefff608, init=, fini=,
rtld_fini=, stack_end=0x7fefff5f8) at libc-start.c:226
#17 0x00402889 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) p p
$1 = (const word_type *) 0x531cd00
(gdb) l
258   int i = acc_char_index (t, val);
259   if (i >= 0)
260 return (const uchar *)p + i;
261 }
262
263   val = *++p;
264 }
265 

[Bug preprocessor/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org, davem at davemloft dot
   ||net, rth at gcc dot gnu.org

--- Comment #10 from H.J. Lu  2011-01-16 01:18:58 
UTC ---
We have

static const uchar *
search_line_acc_char (const uchar *s, const uchar *end ATTRIBUTE_UNUSED)
{

But it never checks the buffer end. It looks bogus to me.

[Bug preprocessor/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[zsojka at seznam dot cz]

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

--- Comment #11 from Zdenek Sojka  2011-01-16 01:24:19 
UTC ---
(In reply to comment #9)
> without SSE2 vectorized lexer:
> 
> ==2012== Invalid read of size 8
> ==2012==at 0xB43064: search_line_acc_char (lex.c:263)

That is probably not causing the crash.

(In reply to comment #8)
> ==23474== Invalid read of size 2
> ==23474==at 0x436C63: tsubst (pt.c:10502)

But this is.


For your preprocessed source from comment #3 I get:
$ g++ hdlVhdlArchitecture.ii -std=c++0x
In file included from ./h/hdlVhdlArchitecture.hpp:6:0,
 from hdlVhdlArchitecture.cpp:1:
./h/hdlHolderMapVectorAdapter.hpp:122:118: internal compiler error: tree check:
accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10500
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(r168843, x86_64-linux, yes,rtl,df checking)

[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from John David Anglin  2011-01-16 
01:36:17 UTC ---
Why has main_test disappeared?

[Bug preprocessor/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

--- Comment #12 from Pawel Sikora  2011-01-16 01:36:29 
UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > without SSE2 vectorized lexer:
> > 
> > ==2012== Invalid read of size 8
> > ==2012==at 0xB43064: search_line_acc_char (lex.c:263)
> 
> That is probably not causing the crash.

0x00b43064 in search_line_acc_char (s=, end=) at ../../libcpp/lex.c:263
263   val = *++p;
(gdb) p p
$1 = (const word_type *) 0x531cd00

(gdb) up
#1  0x00b434ff in _cpp_clean_line (pfile=0x521d260) at
../../libcpp/lex.c:669
669   s = search_line_fast (s, buffer->rlimit);

(gdb) p buffer->rlimit
$2 = (const unsigned char *) 0x531cd02 "\n"

(gdb) down
#0  0x00b43064 in search_line_acc_char (s=,
end=) at ../../libcpp/lex.c:263
263   val = *++p;

(gdb) disassemble $rip,+16
Dump of assembler code from 0xb43064 to 0xb43074:
=> 0x00b43064 :   mov(%rsi),%rax

this is 6-bytes past-the-end access.

> For your preprocessed source from comment #3 I get:
> $ g++ hdlVhdlArchitecture.ii -std=c++0x
> In file included from ./h/hdlVhdlArchitecture.hpp:6:0,
>  from hdlVhdlArchitecture.cpp:1:
> ./h/hdlHolderMapVectorAdapter.hpp:122:118: internal compiler error: tree 
> check:
> accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10500
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 
> (r168843, x86_64-linux, yes,rtl,df checking)

hmm, i must increase the checking level in my build...

[Bug preprocessor/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[zsojka at seznam dot cz]

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

--- Comment #13 from Zdenek Sojka  2011-01-16 01:39:57 
UTC ---
Created attachment 22977
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22977
reduced testcase

Doesn't need C++0x mode.

Compiler output:
$ gcc testcase2.C 
testcase2.C:3:56: internal compiler error: tree check: accessed elt 2 of
tree_vec with 1 elts in tsubst, at cp/pt.c:10500
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r168843 - crash
4.5 r168785 - OK

[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  2011-01-16 
01:53:25 UTC ---
dave@gsyprf11:~/gcc-4.6/objdir/gcc/testsuite/gcc$ less 20010124-1.res
3
20010124-1.o 3
70 e5ddcfb3 PREEMPTED_IR main_test
76 e5ddcfb3 PREEMPTED_IR g
101 e5ddcfb3 PREEMPTED_IR f
20010124-1-lib.o 3
104 af7ae83d PREVAILING_DEF_IRONLY f
118 af7ae83d PREVAILING_DEF_IRONLY g
144 af7ae83d PREEMPTED_IR inside_main
main.o 3
70 bb83b83f PREVAILING_DEF main
76 bb83b83f PREVAILING_DEF_IRONLY main_test
79 bb83b83f PREVAILING_DEF_IRONLY inside_main

[Bug target/47312] New: [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in expand_ternary_op, at
optabs.c:656 with -flto -mno-sse -mxop and
__builtin_fmaf()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


-- testcase.c ---
int main ()
{
  return __builtin_fmaf(1e+38F, 1e+38F, 0);
}
-

Compiler output:
$ gcc -O -flto -mno-sse -mxop testcase.c 
In file included from testcase.c:1:0,
 from :0:
testcase.c: In function 'main':
testcase.c:3:24: internal compiler error: in expand_ternary_op, at optabs.c:656
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper:
/mnt/svn/gcc-trunk/binary-168843-lto-fortran-checking-yes-rtl-df/bin/gcc
returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Tested revisions:
r168843 - crash
4.5 r168785 - OK

[Bug preprocessor/47311] [C++0x] ICE in tsubst @cp/pt.c:10502

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #14 from Pawel Sikora  2011-01-16 02:16:59 
UTC ---
0d432ee0d0d07e9c17b69e06afc1be9d65f57546 is the first bad commit:

commit 0d432ee0d0d07e9c17b69e06afc1be9d65f57546
Author: dodji 
Date:   Tue Nov 2 12:44:19 2010 +

Restore canonical type comparison for dependent type(def)s

This patch restores canonical type comparison for dependent types and
then dependent typedefs. After this patch, two template type
parameters T are equal if they have the same index, level, *and*
number of sibling parameters. The novelty is to take in account the
number of sibling parameters.

To do this we first build the template parameters w/o taking in
account their number of siblings. When we know the number of template
parameters we fix up each template parameter with the number of
slibling parameters and we build the appropriate canonical types
accordingly. The patch fixes the fallouts deemed necessary.

This fixes PR c++/45606 but actually fixes all the previous bugs
related to dependent typedef comparison we had since we started to
properly representing dependent typedefs.

[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |ktietz at gcc dot gnu.org
   |gnu.org |

--- Comment #14 from Alexandre Oliva  2011-01-16 
03:13:32 UTC ---
Kai, Jakub, are you going to act on this, or would you like me to take it over?
 Please reassign it as appropriate, thanks.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |aoliva at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Alexandre Oliva  2011-01-16 
03:15:35 UTC ---
Looking into it, noncommittal for the time being.

[Bug rtl-optimization/47299] Widening multiply optimization generates bad code

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #2 from Matthias Klose  2011-01-16 03:51:05 
UTC ---
4.5/4.6 regression

[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list

[patrick.a.moran at gmail dot com]

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

--- Comment #3 from Patrick Moran  2011-01-16 
04:10:26 UTC ---
Confirmed that the code does in fact work with boost 1.42 on gcc 4.6.0.  I
guess that makes this already fixed.

[Bug c++/47252] GCC Segfaults when boost/range.hpp is included and deduced parameter is a initializer_list

[patrick.a.moran at gmail dot com]

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

Patrick Moran  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED