[Bug c/39389] Build failed with ICE

[monaka at monami-software dot com]

--- 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 Kind: directory
Schedule: normal
Last Changed Author: gccadmin
Last Changed Rev: 144656


-- 

monaka at monami-software dot com changed:

   What|Removed |Added

Summary|Build failed with ICE   |Build failed with ICE


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

[Bug c/39389] Build failed with ICE

[monaka at monami-software dot com]

--- 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] New: Build failed with ICE

[monaka at monami-software dot com]

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/./gcc/ -nostdinc
-B/Users/monaka/m32c/build-osx/gcc/m32c-elf/newlib/ -isystem
/Users/monaka/m32c/build-osx/gcc/m32c-elf/newlib/targ-include -isystem
/Users/monaka/m32c/sources/gcc/newlib/libc/include
-B/Users/monaka/m32c/build-osx/gcc/m32c-elf/libgloss/m32c
-L/Users/monaka/m32c/build-osx/gcc/m32c-elf/libgloss/libnosys
-L/Users/monaka/m32c/sources/gcc/libgloss/m32c -B/pizza4/m32c-elf/bin/
-B/pizza4/m32c-elf/lib/ -isystem /pizza4/m32c-elf/include -isystem
/pizza4/m32c-elf/sys-include -c -DHAVE_CONFIG_H -g -O2-mcpu=m32cm  -I.
-I../../../../../sources/gcc/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic 
../../../../../sources/gcc/libiberty/regex.c -o regex.o
In file included from ../../../../../sources/gcc/libiberty/regex.c:638:
../../../../../sources/gcc/libiberty/regex.c: In function
ebyte_regex_compilef:
../../../../../sources/gcc/libiberty/regex.c:2638: warning: large integer
implicitly truncated to unsigned type
../../../../../sources/gcc/libiberty/regex.c:3173: warning: large integer
implicitly truncated to unsigned type
../../../../../sources/gcc/libiberty/regex.c:3185: warning: large integer
implicitly truncated to unsigned type
../../../../../sources/gcc/libiberty/regex.c: In function
ebyte_re_match_2_internalf:
../../../../../sources/gcc/libiberty/regex.c:7481: internal compiler error: in
gen_add2_insn, at optabs.c:4733
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [regex.o] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libiberty] Error 2
make: *** [all] Error 2


-- 
   Summary: Build failed with ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: monaka at monami-software dot com
 GCC build triplet: i386-apple-darwin9.6.0
  GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: m32c-unknown-elf


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

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

[rob1weld at aol dot com]

--- 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 20090218 (experimental) [lto revision 144462] (lto merged
> with rev 144262) testsuite on ia64-suse-linux-gnu
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02766.html 
> Rob

I tried with the 'trunk' (instead of 'lto') and found the same issue.


Here is my Host Compiler and the head of it's 'spec':

# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 

# gcc -dumpspecs 2>&1 | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*}  %{Wa,*:%*} %{m32:--32}
%{m64:--64}



The workaround that I applied enabled me to compile gcc _without_ making
any changes to the source code. I utilized a bit of spec file magic
and a bit of Environment trickery.

1. Build and install gmp / mpfr in default location.

2. Set LD_LIBRARY_PATH=/usr/local/lib

3. Build gcc and it will fail here:

checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
...

The config.log will say:
/tmp/cc21sHKa.s:35: Error: cannot represent relocation type BFD_RELOC_64


4. Fix your "../gcc_build/gcc/specs" file so the top two lines are this:

*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*}  %{Wa,*:%*} %{m32:--32}
%{!m32:%{!m64:--64}}  %{!mno-sse2avx:%{mavx:-msse2avx}}
%{msse2avx:%{!mavx:-msse2avx}}

(You may need to adjust it to suit your ./configure options. The important
part is to change "%{m64:--64}" to "%{!m32:%{!m64:--64}}" ).


5. Continue the make and it will fail here:

checking for x86_64-unknown-linux-gnu-gcc...
/mnt/drive2/gcc_build_64/./gcc/xgcc -B/mnt/drive2/gcc_build_64/./gcc/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/bin/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/lib/ -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/include -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
...

This time the config.log will not seem to indicate the problem but if 
you add a "-v" to the gcc command that fails you will see that 'cc1'
is looking for "libgmp" in /usr/local/lib . If you use the "file"
command on 'xgcc' or the new 'cc1' you will find that they are 64-Bit
executables. Set 'LD_LIBRARY_PATH=/usr/local/lib64' and re-make.


6. When stage2 finishes and everything is moved to prev-gcc check
that you don't loose you 'spec' setting of "%{!m32:%{!m64:--64}}"
or you will need to type "make" again.

The build will complete without further intervention and without 
having made any alterations to the trunk source code.


I "grepped the trunk" and found that some parts of some scripts do check 
if one is using "LD_LIBRARY_PATH_32" and "LD_LIBRARY_PATH_64" but these
'unofficial' (and useful) Environment Variables are not used in all parts
of the gcc build -- thus the need to hand-alter your "LD_LIBRARY_PATH" as 
the compiler second-stages itself and converts from a 32-Bit gcc (your
Host Compiler) and becomes a full-fledged 64-Bit executable.


Solution:

If the Makefile's "$(SPECS)" target would check that the dumpspecs
it is getting (from a prior version of gcc (the Host Compiler)) is
compatible with a 64 bit build (and fix it if needed) _and_ if
the scripts / Makefiles would toss a "64" on the tail of any
"LD_LIBRARY_PATH" paths as the compiler evolves from 32 to 64 bit
then it would all work without any intervention.


I'll leave it to _others_ to decide if gcc < 4.4.x is a Regression for 
not having their spec files suitable to build later revisions of gcc.

This revision of gcc (4.4.x) needs a 'sed' script to rewrite the 'spec' 
file and do sanity checking. The scripts also need to 'promote' the
library directory path from 32 to 64 as the Compiler changes it's strips.


Rob


-- 


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

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

[rob1weld at aol dot com]

--- 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 bootstrap/39388] New: trunk revision 144629 - Multilibs missing

[rob1weld at aol dot com]

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 "Debian GNU/Linux, kernel 2.6.xx-i386":

2. Configure and build gcc like this:

# gcc/xgcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib
--disable-stage1-checking --enable-checking=release --with-gmp=/usr/local
--with-mpfr=/usr/local


3. Boot 64-Bit using Grub entry "Debian GNU/Linux, kernel 2.6.xx-amd64":

4. Configure and build gcc like this:

# gcc/xgcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed_64
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib
--disable-stage1-checking --enable-checking=release --with-gmp=/usr/local
--with-mpfr=/usr/local


5. Note that only the "--prefix" (and Boot Mode) is changed. Now
check the sizes on the installed directories, see a BIG difference:

# du -ah /mnt/drive2/gcc_build/ | tail -1
2.4G

# du -ah /mnt/drive2/gcc_installed/ | tail -1
541M

# du -ah /mnt/drive2/gcc_build_64/ | tail -1
3.9G/mnt/drive2/gcc_build_64/

# du -ah /mnt/drive2/gcc_installed_64/ | tail -1
931M/mnt/drive2/gcc_installed_64/


6. Check why the installed sizes are so different:

# find /mnt/drive2/gcc_installed/ | sort > list_gcc_installed.txt

# find /mnt/drive2/gcc_installed_64/ | sort > list_gcc_installed_64.txt

# diff -Naur list_gcc_installed.txt list_gcc_installed_64.txt >
list_gcc_installed_32vs64.txt


7. Now use Gedit (or other editor) to match up the directories and
check why the sizes are so different. It seems that even though
we use "--enable-multilib" we do not build the same alternate
libraries in both Modes, we are lazier in the 32-Bit Mode.


8. The result is this:

When we build gcc, with the OS in the 64-Bit Boot Mode, we also 
build a couple of "32" directories (but not others that maybe we 
should build).

When we build gcc, with the OS in the 32-Bit Boot Mode, we fail
to build some "64" directories and this results in an incomplete
"Multilib-version" of gcc.


I am not confused that a few more features are available in one Boot 
Mode or the other, nor that the size of the executables are going to 
be different, this has been taken into consideration.

I examined the 'diffs' and see that we are building a 
"x86_64-pc-linux-gnu/32/bits" directory but no corresponding
"i686-pc-linux-gnu/64/bits" directory.

I examined the 'diffs' and see that we are building a 
"x86_64-pc-linux-gnu/4.4.0/32" directory but no corresponding
"i686-pc-linux-gnu/4.4.0/32" directory.


The "x86_64-pc-linux-gnu/4.4.0/32/" directory ONLY contains:
"x86_64-pc-linux-gnu/4.4.0/32/adainclude/*"
"x86_64-pc-linux-gnu/4.4.0/32/adalib/*"
"x86_64-pc-linux-gnu/4.4.0/32/crt*" and these _few_ files:
"x86_64-pc-linux-gnu/4.4.0/32/libgcc.a"
"x86_64-pc-linux-gnu/4.4.0/32/libgcc_eh.a"
"x86_64-pc-linux-gnu/4.4.0/32/libgcov.a"
"x86_64-pc-linux-gnu/4.4.0/32/libgfortranbegin.a"
"x86_64-pc-linux-gnu/4.4.0/32/libgfortranbegin.la"

where are the rest (of the libraries and alternate directories)
for the multilibs on Platform "i686-pc-linux-gnu" ?

See the attachment.

Rob


-- 
   Summary: trunk revision 144629 - Multilibs missing
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[rwild at gcc dot gnu dot org]

--- 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 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]

--- 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=39387

[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]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-05 21:25:12
   date||
   Target Milestone|--- |4.4.0


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

[Bug debug/39387] New: [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]

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).


-- 
   Summary: [4.4 Regression] Wrong DW_AT_decl_line on
DW_TAG_imported* for using directives in C+ functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

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

[jxyang at cs dot utah dot edu]

--- 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 target/39386] New: different computation results for O1 and O0 executables

[jxyang at cs dot utah dot edu]

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 final result
is 00. On the other hand, if the program is compiled with "avr-gcc
-mmcu=atmega128 -O1", the final result is 0xFF. Compiling at O2 gives me 0xFF
too.

Obviously, avr-gcc compiled the program wrong at one of the these optimization
levels.

This bug is observed in avr studio 4.15.


-- 
   Summary: different computation results for O1 and O0 executables
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jxyang at cs dot utah dot edu
 GCC build triplet: --target=avr --with-gnu-ld --with-gnu-as --enable-
languages=c,c+
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr


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

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

[pinskia at gcc dot gnu dot org]

--- 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++'s exception handler contains a thread local data variable
(global).
So when a thread is created and this function is called ld.so creates a memory
location for this variable.  When the thread is destroyed (finished), glibc
should have freed the memory location for this variable.  libstdc++ is not in
control of creating or freeing this variable at all. It is up to libc to do
that.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|libstdc++   |middle-end
 Resolution||INVALID


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

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

[pinskia at gcc dot gnu dot org]

--- 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 -isystem.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[fgiasson1 at yahoo dot ca]

--- 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 libstdc++/39366] Memory Leak in Exception Handling

[pinskia at gcc dot gnu dot org]

--- 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 threads here really.


-- 


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

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

[fgiasson1 at yahoo dot ca]

--- 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 mechanims, it leaks.

glibc has nothing to do with exceptions... I believe that it is worth it to
look at the static __thread freeing mechanism and see if it covers exceptions
[can you point me this code?]. There were no static __thread variables in the
exception mechanism in 6.0.3, but now in 6.0.10 there are. If it is not in
libstdc++, maybe it is a bug in the compiler?


-- 


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

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

[jason at gcc dot gnu dot org]

--- 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:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[jason at gcc dot gnu dot org]

-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-18 20:25:43 |2009-03-05 18:25:12
   date||


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

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

[pinskia at gcc dot gnu dot org]

--- 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.org/bugzilla/show_bug.cgi?id=39366

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

[fgiasson1 at yahoo dot ca]

--- 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 the bug description, the problem is not
present when using libstdc++ 6.0.3, but is present when using libstdc++ 6.0.9
or 6.0.10.

This is not a Valgrind but, running the testcase I provided definitively shows
a growing memory usage.

Thanks in advance for your time


-- 

fgiasson1 at yahoo dot ca changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

[dgsteffen at numerica dot us]

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, U = U]’:
../../../util/base/Test/testcrash.C:21: internal compiler error: in
gen_type_die_with_usage, at dwarf2out.c:13635
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compilation command:

/opt/Numerica_share/compilers/4.3.3/bin/c++ -c -ansi -pipe -fPIC
-ftemplate-depth-150 -Wno-long-long -Wall -Wno-parentheses -pedantic
-Woverloaded-virtual -Wredundant-decls -ggdb -O2 -ffast-math -march=pentium4
-msse2 -mfpmath=sse,387 -mmmx -malign-double -m32 -D_REENTRANT -D_THREAD_SAFE
-pthread  testcrash.C

Compiler info:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.3/configure
--prefix=/home/dgsteffen/dave/opt/compilers/.gcc-4.3.3-32 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-system-zlib
Thread model: posix
gcc version 4.3.3 (GCC)

Source code (testcrash.C)
#include 

const struct nullptr_t
{
  // convert to ordinary pointer
  template operator T*() const { return 0; }

  // convert to pointer-to-member
  template operator T U::*() const { return 0; }

} nullptr = {};

template inline
bool operator==(const nullptr_t lhs, T U::* rhs) { return rhs == 0; }

using namespace std;

int main()
{

  if ( nullptr == 0 )
cout << "Works" << endl;
}


-- 
   Summary: ICE in gen_type_die_with_usage
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgsteffen at numerica dot us


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

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

[jason at gcc dot gnu dot org]

--- 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/show_bug.cgi?id=17410

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

[jason at gcc dot gnu dot org]

-- 

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 |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-05 15:08:17
   date||


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

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

[jason at gcc dot gnu dot org]

-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-10-28 01:53:06 |2009-03-05 15:08:00
   date||


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

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

[jason at gcc dot gnu dot org]

--- 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 gcc dot gnu dot |jason at gcc dot gnu dot org
   |org |


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

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

[jakub at gcc dot gnu dot org]

--- 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
   for (local_decl = BLOCK_VARS (stmt);
local_decl != NULL_TREE;
local_decl = TREE_CHAIN (local_decl))
-set_decl_abstract_flags (local_decl, setting);
+/* Don't mark local static variables, those are shared between all
+   inline/cloned copies.  */
+if (TREE_CODE (local_decl) != VAR_DECL || !TREE_STATIC (local_decl))
+  set_decl_abstract_flags (local_decl, setting);

   for (subblock = BLOCK_SUBBLOCKS (stmt);
subblock != NULL_TREE;

works well for this testcase, the abstract DIE has DW_AT_location attribute for
the local variable and DIEs for the ctor clones don't have any DIEs for this
variable.  But it creates worse output for C:
extern void f (int *);
static inline __attribute__((always_inline)) void foo (void)
{
  static int staticvar1[4];
  f (staticvar1);
}

void bar (void)
{
  foo ();
}

void baz (void)
{
  foo ();
  foo ();
}

Before the patch the abstract fn DIE contains a DIE for the static variable
without DW_AT_location and the spots that inline this fn has DIE for the static
variable with DW_AT_abstract_origin and DW_AT_location (the same in all cases).
After the patch the abstract fn DIE's static variable DIE contains
DW_AT_location, the spots that inline this have DIE for the static variable
without DW_AT_abstract_origin and again with DW_AT_location.  I'd say either
the abstract origin DIE shouldn't contain DW_AT_location, but then all spots
that use it should contain DW_AT_abstract_origin and DW_AT_location, or the
abstract origin DIE should contain DW_AT_location and the clones shouldn't
contain the DIE at all.  So, I've tried a different patch:

--- tree-cfg.c.jj22009-03-05 09:44:31.0 +0100
+++ tree-cfg.c2009-03-05 14:57:46.0 +0100
@@ -1799,11 +1799,11 @@ remove_useless_stmts_bind (gimple_stmt_i
   tree var = NULL_TREE;
   /* Even if there are no gimple_bind_vars, there might be other
  decls in BLOCK_VARS rendering the GIMPLE_BIND not useless.  */
-  if (block)
+  if (block && !BLOCK_NUM_NONLOCALIZED_VARS (block))
 for (var = BLOCK_VARS (block); var; var = TREE_CHAIN (var))
   if (TREE_CODE (var) == IMPORTED_DECL)
 break;
-  if (var)
+  if (var || (block && BLOCK_NUM_NONLOCALIZED_VARS (block)))
 gsi_next (gsi);
   else
 {

which prevents removing GIMPLE_BINDs that contain BLOCK_NONLOCALIZED_VARS in
its gimple_bind_block (tree-ssa-live.c BLOCK removal does the same thing).
Unfortunately this doesn't solve the original bug, because the abstract
FUNCTION_DECL in the C++ ctor clone case is marked DECL_ABSTRACT already by the
C++ FE, so when dwarf2out_abstract_function is called on it, was_abstract is
true and so everything is set to DECL_ABSTRACT, but not reset afterwards.
This means the VAR_DECL in clone's BLOCK_NONLOCALIZED_VARS has DECL_ABSTRACT
set and thus won't have DW_AT_location emitted.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

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

[algrant at acm dot org]

--- 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 c/39384] sizeof object with zero-length array ignores initializer

[algrant at acm dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[algrant at acm dot org]

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 benefit from clarification, as otherwise it's natural to
want to use sizeof to find out how big the object actually ended up as.


-- 
   Summary: sizeof object with zero-length array ignores initializer
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org


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

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

[jason at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED


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

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

[jason at gcc dot gnu dot org]

--- 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): New fn.
* cp-tree.h: Declare it.
* cp-objcp-common.c (cp_expr_size): Use it.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-objcp-common.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/testsuite/ChangeLog


-- 


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

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

[hjl dot tools at gmail dot com]

--- 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

 CC||balrogg at gmail dot com


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

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

[hjl dot tools at gmail dot com]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[hjl dot tools at gmail dot com]

--- 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

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

[joseph at codesourcery dot com]

--- 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 
> ---
> > 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):

Standard C does not permit initializing the flexible array member.


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

--- 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
member may have an incomplete array type; this is called a flexible array
member. With two exceptions, the flexible array member is ignored. First,
the size of the structure shall be equal to the offset of the last element of
an otherwise identical structure that replaces the flexible array member
with an array of unspecified length.106)


-- 


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

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

[jakub at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED


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

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

[algrant at acm dot org]

--- 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 the operand, or it isn't determined from the type.  Current GCC behavior
is to have it not return the size of the operand.  That's a valid point of 
view but it does mean one needs to take care when using sizeof on such
objects, and it's worth documenting.


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

--- 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) reads:

2 The sizeof operator yields the size (in bytes) of its operand, which may be
an expression or the parenthesized name of a type. The size is determined from
the type of the operand. The result is an integer. If the type of the operand
is a variable length array type, the operand is evaluated; otherwise, the
operand is not evaluated and the result is an integer constant.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[jakub at gcc dot gnu dot org]

--- 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_bind): Don't remove GIMPLE_BINDs
with blocks containing IMPORTED_DECLs in BLOCK_VARS.

* g++.dg/debug/dwarf2/imported-module-3.C: New test.
* g++.dg/debug/dwarf2/imported-module-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-3.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c


-- 


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

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

[algrant at acm dot org]

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 benefit from clarification, as otherwise it's natural to
want to use sizeof to find out how big the object actually ended up as.


-- 
   Summary: sizeof object with zero-length array ignores initializer
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org


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

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

[rob1weld at aol dot com]

+++ 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 Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux >>2.6.26.1<< system on 2009-01-04.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B


# gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_trunk/configure --prefix=/mnt/drive2/gcc_installed
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-multilib
--disable-stage1-checking --enable-checking=release --with-gmp=/usr/local
--with-mpfr=/usr/local
Thread model: posix
gcc version 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) 


=== libstdc++ tests ===
Running target unix
FAIL: abi_check
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)


Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC)
testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00511.html

Rob


-- 
   Summary: FAIL: abi_check on trunk revision 144629
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[hubicka at ucw dot cz]

--- 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-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 with a
> cross-compiler, somebody with hppa-linux access needs to debug it.

I've just run across interesting memory corruption in Ada: by
duplicating DECL node for nested function we ended up with pointer to
ggc_freeded DECL_STRUCT_FUNCTION.  I have patch to always make functions
nonlocal that might solve this problem as well (as we get methods for
C++ local classes).  I am just on the way to Prague, but I will break it
up from my tree then.

Honza


-- 


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

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

[jakub at gcc dot gnu dot org]

--- 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 right fix will be not mark TREE_STATIC VAR_DECLs in
set_block_abstract_flags as abstract.


-- 


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

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

[jakub at gcc dot gnu dot org]

--- 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_AT_decl_line
.long   0xe2# DW_AT_type
.byte   0x9 # DW_AT_location
.byte   0x3 # DW_OP_addr
.quad   _ZZN1AC1EiE10staticvar1

Looking into it.


-- 

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 |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to work||4.1.2 4.2.3
   Last reconfirmed|-00-00 00:00:00 |2009-03-05 10:54:03
   date||
Summary|Missing DW_AT_location for  |[4.3/4.4 Regression] Missing
   |constructor static variable |DW_AT_location for
   ||constructor static variable
   Target Milestone|--- |4.4.0


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

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

[rguenth at gcc dot gnu dot org]

--- 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 idea as well, instead you should use proper inputs and outputs with
register constraints.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[rguenth at gcc dot gnu dot org]

--- 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

  Known to fail||4.3.3 4.4.0


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

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

[rguenth at gcc dot gnu dot org]

--- 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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||3.3.6
  Known to work||2.95.4
   Last reconfirmed|-00-00 00:00:00 |2009-03-05 10:35:56
   date||
Summary|Incorrectly rejects |[4.2/4.3/4.4 Regression]
   |switch((unsigned|Incorrectly rejects
   |int)boolvar)|switch((unsigned
   ||int)boolvar)
   Target Milestone|--- |4.2.5


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

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

[spam dot spam dot spam dot spam at free dot fr]

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-enum -Wfloat-equal -s
-O2
-c ../arbre.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_arbre.c arbre.o -o check_arbre
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-c ../sequence.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-c ../liste.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_sequence.c sequence.o arbre.o liste.o -o check_sequence
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_liste.c liste.o arbre.o -o check_liste

In the second case ('check' program installed in '/tmp/logiciel-check-0.9.6') :
In this case, I use the correct environment variables :
$export LD_LIBRARY_PATH="/tmp/logiciel-check-0.9.6/usr/lib:${LD_LIBRARY_PATH}"
$export LIBRARY_PATH="/tmp/logiciel-check-0.9.6/usr/lib:${LIBRARY_PATH}"
$export CPATH="/tmp/logiciel-check-0.9.6/usr/include:${CPATH}"
and because I am french I add :
$export LANG=en_GB.UTF-8

$ make
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-c ../arbre.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_arbre.c arbre.o -o check_arbre
In file included from check_arbre.c:1:
/tmp/logiciel-check-0.9.6/usr/include/check.h:211:27: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:222:23: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:227:14: warning: anonymous
variadic macros were introduced in C99
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-c ../sequence.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-c ../liste.c
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_sequence.c sequence.o arbre.o liste.o -o check_sequence
In file included from check_sequence.c:1:
/tmp/logiciel-check-0.9.6/usr/include/check.h:211:27: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:222:23: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:227:14: warning: anonymous
variadic macros were introduced in C99
gcc -ansi -Wall -W -pedantic -Wmain -Wextra -Wwrite-strings -Wstrict-prototypes
-Wno-missing-braces -Wswitch -Wswitch-default -Wswitch-enum -Wfloat-equal -s
-O2
-lcheck check_liste.c liste.o arbre.o -o check_liste
In file included from check_liste.c:1:
/tmp/logiciel-check-0.9.6/usr/include/check.h:211:27: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:222:23: warning: anonymous
variadic macros were introduced in C99
/tmp/logiciel-check-0.9.6/usr/include/check.h:227:14: warning: anonymous
variadic macros were introduced in C99

Do you understand why the warnings ARE in one case and ARN'T in the other?
Thank you.


-- 
   Summary: The warning: anonymous variadic macros were introduced
in C99 disapear
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spam dot spam dot spam dot spam at free dot fr


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

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

[aph at gcc dot gnu dot org]

--- 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++/39380] New: All programs that link Java and C++ libraries fail when optimized

[aph at gcc dot gnu dot org]

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.


-- 
   Summary: All programs that link Java and C++ libraries fail when
optimized
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org


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

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

[jakub at gcc dot gnu dot org]

--- 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=39379

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

[jakub at gcc dot gnu dot org]

-- 

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 |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-05 08:56:40
   date||
   Target Milestone|--- |4.4.0


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

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

[jakub at gcc dot gnu dot org]

// { 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 DW_TAG_imported* tags, regression from 4.3.x.


-- 
   Summary: [4.4 Regression] DW_TAG_imported* no longer emitted
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

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

[zhijie dot t at gmail dot com]

--- 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&filter=0
> seems to show it as a chronic intermittent problem in early 3.x series, on a
> variety of platforms.  Still, it could be that changes in the cygwin compiler
> hid/masked the problem in different revisions.
> These are all pretty old and obsolete versions I'm afraid and the problem 
> isn't
> likely to get fixed now if it hasn't been so far.  It might be worth futzing
> with the build flags and seeing if you can get it working with different -O
> options.
>   cheers,
> DaveK
Hi, all
I met with the same problem. and I'v tried to change -O2 to -O in the makefile
under the dir like /tmp/build/gcc. It does works. 
If have time, i will try the detail -O2 optimization flags specified and see
which flag causes this problem.

cheers!
Roger


-- 


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

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

[jakub at gcc dot gnu dot org]

--- 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 with a
cross-compiler, somebody with hppa-linux access needs to debug it.


-- 


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