[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-05 08:07 --- Can you reproduce it with stage1 cc1plus (or non-bootstrapped cc1plus) built by some older gcc, or only with stage2/stage3 cc1plus? Wonder if cc1plus hasn't been miscompiled. In any case, as this can't be reproduced

[Bug middle-end/38299] internal error: segmentation fault

--- Comment #5 from zhijie dot t at gmail dot com 2009-03-05 08:42 --- (In reply to comment #4) > I'm not so sure (that it's cygwin specific). > http://www.google.co.uk/search?q=locale_facets.tcc++internal++error:+Segmentation+fault&hl=en&client=firefox-a&rls=org.mozilla:en-US:official&f

[Bug debug/39379] New: [4.4 Regression] DW_TAG_imported* no longer emitted

// { dg-do compile } // { dg-options "-g -dA" } // { dg-final { scan-assembler "DW_TAG_imported" } } namespace A { int v; } int f () { int i; { using namespace A; v++; i = v - 1; } return i; } int main () { using namespace A; v++; return v - 1; } no longer emits any

[Bug debug/39379] [4.4 Regression] DW_TAG_imported* no longer emitted

-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org

[Bug debug/39379] [4.4 Regression] DW_TAG_imported* no longer emitted

--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-05 09:01 --- Created an attachment (id=17398) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17398&action=view) gcc44-pr39379.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=393

[Bug c++/39380] New: All programs that link Java and C++ libraries fail when optimized

The attached testcase fails. This happens because we now instantiate template functions based on possibly_inlined_p() rather than DECL_INLINE. In turn this causes us to generate catch blocks for C++ exceptions, and these can't be mixed in the same translation unit as Java exceptions. --

[Bug c++/39380] All programs that link Java and C++ libraries fail when optimized

--- Comment #1 from aph at gcc dot gnu dot org 2009-03-05 09:44 --- Created an attachment (id=17399) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17399&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39380

[Bug c/39381] New: The warning: anonymous variadic macros were introduced in C99 disapear

Hello, I get warnings compiling my own C89 project that uses C99 check.h. If 'check' program is installed in the default path, when I compile my project : $ make gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes -Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-e

[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-05 10:35 --- Confirmed. 2.95.4 only (incorrectly) warned about an out-of-range case value: /space/rguenther/install/gcc-2.95/bin/g++ -S t.C t.C: In function `void foo(bool)': t.C:5: warning: case value out of range -- rguen

[Bug debug/39372] Missing DW_AT_location for constructor static variable

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-05 10:39 --- It doesn't work with FSF 4.3.3 for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/39375] asm with a "=X" output overwrites the output

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-05 10:42 --- You need to use a "memory" clobber instead. "=X" (params[1]) says to GCC that the asm operand 0 should be stored to params[1], which it does (it allocates %eax to it). Note that plain use of %eax and %dx is a bad i

[Bug debug/39372] [4.3/4.4 Regression] Missing DW_AT_location for constructor static variable

--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-05 10:54 --- But in FSF 4.1.2 and 4.2.3 I see: .uleb128 0xe# (DIE (0x161) DW_TAG_variable) .ascii "staticvar1\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (pr39372.C) .byte 0xb # DW_

[Bug debug/39372] [4.3/4.4 Regression] Missing DW_AT_location for constructor static variable

--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-05 11:14 --- Ah, the reason why it didn't fail with 4.1.x and older 4.2.x/4.3.x is PR27574. Before that change set_decl_abstract_flags saw error_mark_node DECL_INITIAL and so didn't dive into the blocks, now it does. Guess the ri

[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1

--- Comment #9 from hubicka at ucw dot cz 2009-03-05 11:18 --- Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1 > --- Comment #8 from jakub at gcc dot gnu dot org 2009-03-05 08:07 --- > Can you reproduce it with stage1 cc1plus (or non-bootst

[Bug libstdc++/39382] New: FAIL: abi_check on trunk revision 144629

+++ This bug was initially created as a clone of Bug #38834 +++ abi_check is failing on Debian 5.0 (booted 32-Bit) with newer Kernel: # uname -a Linux debian 2.6.28-i386 #1 SMP PREEMPT Wed Mar 4 12:42:00 PST 2009 i686 GNU/Linux # /lib/libc.so.6 GNU C Library stable release version 2.7, by Rol

[Bug c/39383] New: sizeof object with zero-length array ignores initializer

Example from docs: struct f1 { int x; int y[]; } f1 = { 1, { 2, 3, 4 } }; Currently sizeof(f1) == sizeof(int) rather than 4*sizeof(int), i.e. sizeof the object is determined by the type only, not the actual object size taking into account its initializer. If this is intentional the docs could b

[Bug debug/39379] [4.4 Regression] DW_TAG_imported* no longer emitted

--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-05 12:50 --- Subject: Bug 39379 Author: jakub Date: Thu Mar 5 12:50:36 2009 New Revision: 144640 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144640 Log: PR debug/39379 * tree-cfg.c (remove_useless_stmts

[Bug c/39383] sizeof object with zero-length array ignores initializer

--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-03-05 13:06 --- > Currently sizeof(f1) == sizeof(int) rather than 4*sizeof(int), i.e. > sizeof the object is determined by the type only, not the actual object > size taking into account its initializer. That's C. 6.5.3.4 (2) r

[Bug c/39383] sizeof object with zero-length array ignores initializer

--- Comment #2 from algrant at acm dot org 2009-03-05 13:19 --- No, the case is an extension to C. 6.5.3.4 was obviously written without this case in mind. In this case "the size... of its operand" cannot be "determined from the type". Either sizeof doesn't return the (real) size of t

[Bug debug/39379] [4.4 Regression] DW_TAG_imported* no longer emitted

--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-05 13:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c/39383] sizeof object with zero-length array ignores initializer

--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-05 13:31 --- > No, the case is an extension to C. 6.5.3.4 was obviously written without this > case in mind. Not at all, see 6.7.2.1 (16): 16 As a special case, the last element of a structure with more than one named membe

[Bug c/39383] sizeof object with zero-length array ignores initializer

--- Comment #4 from joseph at codesourcery dot com 2009-03-05 13:53 --- Subject: Re: sizeof object with zero-length array ignores initializer On Thu, 5 Mar 2009, ebotcazou at gcc dot gnu dot org wrote: > --- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-05 13:31 > --

[Bug c/39373] attribute ((aligned)) for stack variables is ignored without warning

--- Comment #3 from hjl dot tools at gmail dot com 2009-03-05 14:02 --- Reopen it since it only works for x86 in gcc 4.4. -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c/39373] attribute ((aligned)) for stack variables is ignored without warning

--- Comment #4 from hjl dot tools at gmail dot com 2009-03-05 14:02 --- *** This bug has been marked as a duplicate of 16660 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

--- Comment #16 from hjl dot tools at gmail dot com 2009-03-05 14:02 --- *** Bug 39373 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added -

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

--- Comment #17 from jason at gcc dot gnu dot org 2009-03-05 14:10 --- Subject: Bug 38908 Author: jason Date: Thu Mar 5 14:10:07 2009 New Revision: 144643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144643 Log: PR c++/38908 * class.c (is_really_empty_class):

[Bug c++/38908] [4.4 regression] Unexplained "'' is used uninitialized in this function" warning in cc1plus -m64

--- Comment #18 from jason at gcc dot gnu dot org 2009-03-05 14:32 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c/39384] New: sizeof object with zero-length array ignores initializer

Example from docs: struct f1 { int x; int y[]; } f1 = { 1, { 2, 3, 4 } }; Currently sizeof(f1) == sizeof(int) rather than 4*sizeof(int), i.e. sizeof the object is determined by the type only, not the actual object size taking into account its initializer. If this is intentional the docs could b

[Bug c/39384] sizeof object with zero-length array ignores initializer

--- Comment #1 from algrant at acm dot org 2009-03-05 14:48 --- Unwanted duplicate entry of 39383 caused by refreshing browser page. *** This bug has been marked as a duplicate of 39383 *** -- algrant at acm dot org changed: What|Removed |Added --

[Bug c/39383] sizeof object with zero-length array ignores initializer

--- Comment #5 from algrant at acm dot org 2009-03-05 14:48 --- *** Bug 39384 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383

[Bug debug/39372] [4.3/4.4 Regression] Missing DW_AT_location for constructor static variable

--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-05 15:02 --- This is harder than I thought. My first attempt: --- integrate.c.xx2009-02-20 15:36:24.0 +0100 +++ integrate.c2009-03-05 15:46:23.0 +0100 @@ -173,7 +173,10 @@ set_block_abstract_flags (tree stmt, int

[Bug c++/6057] expression mangling doesn't work for operator new

--- Comment #7 from jason at gcc dot gnu dot org 2009-03-05 15:07 --- Mine! -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mmitchel at gc

[Bug c++/12909] ambiguity in mangling vector types

-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org

[Bug c++/29773] name mangling for nested functions is wrong

-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org

[Bug c++/17410] Specialization of nested template rejected because of unrelated declaration

--- Comment #8 from jason at gcc dot gnu dot org 2009-03-05 16:08 --- The bug is in lookup_template_class's search for a matching partial instantiation; it finds Outer::Inner and assumes it's Outer::Inner without checking the innermost template args. -- http://gcc.gnu.org/bugzilla/s

[Bug c++/39385] New: ICE in gen_type_die_with_usage

ICE on the following code (part of an emulation of C++0X nullptr). I think the code should fail to compile, but am not completely sure. Error message: C++ ../../../util/base/Test/testcrash.o ../../../util/base/Test/testcrash.C: In member function ‘nullptr_t::operator T U::*() const [with T = T,

[Bug libstdc++/39366] Memory Leak in Exception Handling

--- Comment #3 from fgiasson1 at yahoo dot ca 2009-03-05 18:04 --- Andrew, Thanks for your answer. I did the test you suggested and there is no leak associated to it, so I believe this pretty much sorts out the possibility that a bug in libc leads to the leak. Moreover, as I said in th

[Bug libstdc++/39366] Memory Leak in Exception Handling

--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-05 18:08 --- Lets look at the source: static __thread abi::__cxa_eh_globals global; return &global; So I still think this is a bug in glibc. Look how we just return the address to TLS variable. -- http://gcc.gnu.o

[Bug c++/13504] Cannot mangle structure access operator

-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org

[Bug c++/20123] mangled name of typeid doesn't encode cv-qualifer.

--- Comment #4 from jason at gcc dot gnu dot org 2009-03-05 18:35 --- Jody's comment is correct; typeid represents the cv-unqualified type of the expression, which for an array lvalue means removing the cv qualifiers from the array. -- jason at gcc dot gnu dot org changed:

[Bug libstdc++/39366] Memory Leak in Exception Handling

--- Comment #5 from fgiasson1 at yahoo dot ca 2009-03-05 19:37 --- Yes but this static __thread variable must be freed somehow when the thread exits. static __thread variables instantiated elsewhere but in exceptions do not cause leaks. However, when allocated in the exception handling

[Bug libstdc++/39366] Memory Leak in Exception Handling

--- Comment #6 from pinskia at gcc dot gnu dot org 2009-03-05 19:43 --- (In reply to comment #5) > Yes but this static __thread variable must be freed somehow when the thread > exits. They are freed when the thread is destroyed or should be. The compiler does not know much about thread

[Bug libstdc++/39366] Memory Leak in Exception Handling

--- Comment #7 from fgiasson1 at yahoo dot ca 2009-03-05 20:02 --- OK but shouldn't libstdc++ handle static __thread variables cleaning for exceptions? libc doesn't know about exceptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39366

[Bug c/39381] The warning: anonymous variadic macros were introduced in C99 disapear

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-05 20:08 --- This is because if the header is installed in the system includes directory GCC does not warn about extensions. If you want to have /tmp/logiciel-check-0.9.6/usr/include in the system include directories use -isyste

[Bug middle-end/39366] Memory Leak in Exception Handling

--- Comment #8 from pinskia at gcc dot gnu dot org 2009-03-05 20:11 --- (In reply to comment #7) > OK but shouldn't libstdc++ handle static __thread variables cleaning for > exceptions? libc doesn't know about exceptions. Again there is no problem with the libstdc++ source. So libstdc+

[Bug target/39386] New: different computation results for O1 and O0 executables

This is seen on the version of avr-gcc 4.3.3 that gets built by the script that comes with FemtoOS 0.88. The program performs simple arithmatic and logical operations on a global variable, and store the result in register R30:R31. If the program is compiled with "avr-gcc -mmcu=atmega128 -O0", the

[Bug target/39386] different computation results for O1 and O0 executables

--- Comment #1 from jxyang at cs dot utah dot edu 2009-03-05 21:22 --- Created an attachment (id=17400) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17400&action=view) mis-calculated program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386

[Bug debug/39387] New: [4.4 Regression] Wrong DW_AT_decl_line on DW_TAG_imported* for using directives in C+ functions

For namespace A { int i; } void f () { using namespace A; i++; } with -g -dA g++ 4.3 used correct .byte 0x9 # DW_AT_decl_line for DW_TAG_imported*, but 4.4 uses .byte 0xb # DW_AT_decl_line (which is the end of the function, not the location of the using namespace directive). -

[Bug debug/39387] [4.4 Regression] Wrong DW_AT_decl_line on DW_TAG_imported* for using directives in C+ functions

-- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reco

[Bug debug/39387] [4.4 Regression] Wrong DW_AT_decl_line on DW_TAG_imported* for using directives in C+ functions

--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-05 21:25 --- Created an attachment (id=17401) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17401&action=view) gcc44-pr39387.patch Patch I'm going to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=393

[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate

--- Comment #7 from rwild at gcc dot gnu dot org 2009-03-05 21:36 --- updated patch here: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805

[Bug bootstrap/39388] New: trunk revision 144629 - Multilibs missing

In trunk revision 144629 there is a large size discrepancy of _installed_ gcc depending on first part of triplet when building Multi-lib which is neither explained by size of executables nor differencing of the directories. To reproduce (on Debian Lenny 5.0): 1. Boot 32-Bit using Grub entry "D

[Bug bootstrap/39388] trunk revision 144629 - Multilibs missing

--- Comment #1 from rob1weld at aol dot com 2009-03-05 22:23 --- Created an attachment (id=17402) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17402&action=view) Edited diff of comparison between Multilibs produced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39388

[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64

--- Comment #8 from rob1weld at aol dot com 2009-03-05 22:59 --- (In reply to comment #7) > (In reply to comment #6) > > Broken: x86_64-pc-linux-gnu > > Works: i686-pc-linux-gnu > > Rob > Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu): > Results for 4.4.0 20090

[Bug c/39389] New: Build failed with ICE

Builds failed with ICE. configuration is follows: ../../sources/gcc/configure --prefix=/pizza4 --target=m32c-elf --enable-languages=c --with-gmp=/opt/gcc4build --with-mpfr=/opt/gcc4build Error message is like this: /Users/monaka/m32c/build-osx/gcc/./gcc/xgcc -B/Users/monaka/m32c/build-osx/gcc/./gc

[Bug c/39389] Build failed with ICE

--- Comment #1 from monaka at monami-software dot com 2009-03-06 03:35 --- Created an attachment (id=17403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17403&action=view) .i file that causes ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39389

[Bug c/39389] Build failed with ICE

--- Comment #2 from monaka at monami-software dot com 2009-03-06 03:36 --- The svn information about the source tree is : Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 144657 Node