[Bug pending/27092] New: Compiling a special asm-statment will fail if -O1 -fgcse is set.

[gcc-bugzilla at gcc dot gnu dot org]

NOTE: Defaulting component because reported component no longer exists
When compile with gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c,
there will be the error:

[EMAIL PROTECTED]:~/src/qemu-bug$ gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c
qemu-bug.c: In function `main':
qemu-bug.c:2: error: inconsistent operand constraints in an `asm'
qemu-bug.c:2: error: inconsistent operand constraints in an `asm'

Without -fgcse, there will no error, -O2 -fno-gcse does work as well.

Environment:
System: Linux Pegasos 2.6.16 #3 PREEMPT Sat Apr 8 18:28:12 CEST 2006 ppc
GNU/Linux
Architecture: ppc


host: powerpc-unknown-linux-gnu
build: powerpc-unknown-linux-gnu
target: powerpc-unknown-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal
--prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-softfloat powerpc-linux-gnu

How-To-Repeat:
# 1 "qemu-bug.c"
# 1 ""
# 1 ""
# 1 "qemu-bug.c"
inline void stl(void *ptr, int v) {
__asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*(unsigned long *)ptr) : "r"
(v), "r" (ptr));
}

int main () {
  unsigned long *sp, *u_platform;
  char *k_platform;



  stl(sp, (unsigned long)(0)); stl(sp+1, (unsigned long)(0));;

  if (k_platform)
stl(sp, (unsigned long)(15)); stl(sp+1, (unsigned long)((unsigned long)
u_platform));;
  return 0;
}


-- 
   Summary: Compiling a special asm-statment will fail if -O1 -fgcse
is set.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: didischuster at arcor dot de
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug c/27289] New: Gcc produces spurious -Wuninitialized warning compiling gdb

[gcc-bugzilla at gcc dot gnu dot org]

When building gdb with -Werror, the compile fails due to what looks
like a spurious warning from using -Wuninitialized.  I've reduced the
testcase down to a minimal one, hopefully preserving the original
cause of the warning.

Environment:
System: Linux puffer.diveadx.com 2.6.16-1.2069_FC4smp #1 SMP Tue Mar 28
12:47:32 EST 2006 i686 i686 i386 GNU/Linux
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /src/latest/trunk/src/gcc/configure -v
--prefix=/opt/local/latest/trunk --enable-languages=c,c++
--cache-file=.././config.cache --srcdir=/src/latest/trunk/src/gcc

How-To-Repeat:

/* Run as:

 $ gcc -c -O2 -Wuninitialized bug.c
 bug.c: In function ‘foo’:
 bug.c:19: warning: ‘tmp_obstack.chunk_size’ may be used uninitialized
in this function
*/

struct obstack
{
  long chunk_size;
};

static struct obstack dont_print_statmem_obstack;

void
foo (int dont_print_statmem, int start)
{
  int i;
  struct obstack tmp_obstack;

  if (dont_print_statmem == 0)
{
  tmp_obstack = dont_print_statmem_obstack;
}

  for (i = start; i < 7; i++)
{
}

  if (dont_print_statmem == 0)
{
  dont_print_statmem_obstack = tmp_obstack;
}
}


-- 
   Summary: Gcc produces spurious -Wuninitialized warning compiling
gdb
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fnf at specifix 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=27289

[Bug other/27348] New: memcmp reads past end of strings

[gcc-bugzilla at gcc dot gnu dot org]

If you use memcmp to compare strings, it does not stop reading when it
finds the terminating null byte of the shortest string, which can
trigger an attempt to read unallocated memory.  I'd recommend
replacing instances of memcmp on strings with strncmp, which won't
attempt to read past the end of the shortest string.

Environment:
System: Linux puffer.diveadx.com 2.6.16-1.2069_FC4smp #1 SMP Tue Mar 28
12:47:32 EST 2006 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /src/latest/trunk/src/gcc/configure -v
--prefix=/opt/local/latest/trunk --enable-languages=c,c++
--cache-file=.././config.cache --srcdir=/src/latest/trunk/src/gcc

How-To-Repeat:

As an example, build gengtype with mudflap and run it.  It will
detect lots of reads by memcmp past the end of a string.


--- Comment #1 from fnf at specifix dot com  2006-04-28 11:53 ---
Fix:

Heres an example fix for gengtype.c

Index: gengtype.c
===
RCS file: /cvsroots/latest/src/gcc/gcc/gengtype.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 gengtype.c
--- gengtype.c  15 Mar 2006 20:17:05 -  1.1.1.4
+++ gengtype.c  28 Apr 2006 10:48:11 -
@@ -1179,7 +1179,7 @@
   size_t i;
   for (i = 1; i < NUM_BASE_FILES; i++)
if ((size_t)(slashpos - basename) == strlen (lang_dir_names [i])
-   && memcmp (basename, lang_dir_names[i], strlen (lang_dir_names[i]))
== 0)
+   && strncmp (basename, lang_dir_names[i], strlen
(lang_dir_names[i])) == 0)
   {
 /* It's in a language directory, set that language.  */
 bitmap = 1 << i;
@@ -1272,7 +1272,7 @@
   size_t i;

   for (i = 0; i < NUM_BASE_FILES; i++)
-   if (memcmp (basename, lang_dir_names[i], strlen (lang_dir_names[i])) ==
0
+   if (strncmp (basename, lang_dir_names[i], strlen (lang_dir_names[i]))
== 0
&& basename[strlen(lang_dir_names[i])] == '/')
  return base_files[i];


-- 
   Summary: memcmp reads past end of strings
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fnf at specifix 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=27348

[Bug c++/27369] New: tree check ICE when attribute externally_visible used

[gcc-bugzilla at gcc dot gnu dot org]

When compiling a C++ program (for the AVR target) that defines interrupt
vectors using the externally_visible attribute, I get this ICE message:

avrlib/bits/atmega128_usart.cpp:20: internal compiler error: tree check:
expected tree that contains 'decl minimal' structure, have 'omp_atomic'  in
eq_node, at cgraph.c:175

Environment:
System: Darwin Neds-Mini.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7
16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc
host: powerpc-apple-darwin8.6.0
build: powerpc-apple-darwin8.6.0
target: avr-unknown-none
configured with:
/opt/local/var/db/dports/build/_Users_ned_src_darwinports_dports_cross_avr-gcc/work/gcc-4.2-20060429/configure
--prefix=/opt/local --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --target=avr --program-prefix=avr-
--with-included-gettext --enable-obsolete
--with-gxx-include-dir=/opt/local/avr/include/c++/4.2-20060429/
--disable-libssp --enable-languages=c,c++

How-To-Repeat:

Compile the attached hw.ii file with:

avr-g++ -fno-exceptions -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -ggdb -O2 -Wall -Wextra -Wshadow -mmcu=atmega128 -xc++ -c -o hw.o
hw.ii


--- Comment #1 from ned at bike-nomad dot com  2006-05-01 14:38 ---
Fix:

Remove the externally_visible attributes on the vector definitions (lines 1998
to 2020) 
in attached file hw.ii and recompile:

sed -e '1998,2020s/, externally_visible//' hw.ii > hwgood.cpp

avr-g++ -fno-exceptions -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -ggdb -O2 -Wall -Wextra -Wshadow -mmcu=atmega128 -xc++ -c -o
hwgood.o hwgood.cpp


-- 
   Summary: tree check ICE when attribute externally_visible used
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ned at bike-nomad dot com
 GCC build triplet: powerpc-apple-darwin8.6.0
  GCC host triplet: powerpc-apple-darwin8.6.0
GCC target triplet: avr-unknown-none


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

[Bug target/27540] New: libgomp fails to configure on IRIX 5.3

[gcc-bugzilla at gcc dot gnu dot org]

Current mainline fails to bootstrap on IRIX 5.3:

configure: error: Pthreads are required to build libgomp
make[1]: *** [configure-target-libgomp] Error 1

Environment:
System: IRIX lyra 5.3 11091812 IP22 mips



host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.15 --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,objc,ada --disable-libmudflap

How-To-Repeat:
Try to bootstrap on IRIX 5.3.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2006-05-10 
21:22 ---
Fix:
Since IRIX 5 doesn't have libpthread (and never will), libgomp should only
be enable for *-*-irix6* in toplevel configure.in.  I'll propose a patch
shortly.  Strictly speaking, libpthread was only introduced in patches to
IRIX 6.2, but older IRIX 6.[012] systems are probably completely gone by
now and can thus be ignored.


-- 
   Summary: libgomp fails to configure on IRIX 5.3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix5.3
  GCC host triplet: mips-sgi-irix5.3
GCC target triplet: mips-sgi-irix5.3


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

[Bug c++/27813] New: ICE while building a public released package from source

[gcc-bugzilla at gcc dot gnu dot org]

I was trying to install the amule-2.0.3-r4 package from source in my gentoo
linux.
The package is public so if it could be a package error it should be reported
on their web site, but it is not.
I send this bug directly to you gcc-team, without interesting the gentoo
forums, cause it is reproducible just with preprocessed source.
Download attachment with precompiled source from:
http://82.57.174.182/pub/gcc-bug-attachment.tbz2

Environment:
System: Linux localhost 2.6.14-hardened-r8 #5 Sun May 21 19:37:30 Local time
zone must be set--see zic manu i586 AMD-K6(tm) 3D processor GNU/Linux
Architecture: i586
AMD-K6(tm) 3D 400 MHz processor
128 MB RAM
Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)

host: i586-pc-linux-gnu
build: i586-pc-linux-gnu
target: i586-pc-linux-gnu
configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure
--prefix=/usr --bindir=/usr/i586-pc-linux-gnu/gcc-bin/3.4.5
--includedir=/usr/lib/gcc/i586-pc-linux-gnu/3.4.5/include
--datadir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4.5
--mandir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4.5/man
--infodir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/i586-pc-linux-gnu/3.4.5/include/g++-v3
--host=i586-pc-linux-gnu --build=i586-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu

How-To-Repeat:
$ gcc preprocessed-source.cpp
In file included from /usr/include/wx-2.6/wx/event.h:27,
 from /usr/include/wx-2.6/wx/app.h:20,
 from amule.h:38,
 from ECSpecialTags.cpp:40:
ECSpecialTags.h: In member function `void CValueMap::CreateTag(ec_tagname_t,
CMD4Hash, CECTag*)':
ECSpecialTags.h:115: internal compiler error: in sweep_string_variable, at
protector.c:1158
Please submit a full bug report,
with preprocessed source if appropriate.


--- Comment #1 from exio82 at gmail dot com  2006-05-29 22:55 ---
Fix:
Don't ask me :-)


-- 
   Summary: ICE while building a public released package from source
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: exio82 at gmail dot com
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug libstdc++/27931] New: valgrind reports memleak when std::ios:sync_with_stdio(false)

[gcc-bugzilla at gcc dot gnu dot org]

A memory leak happens when  std::ios::sync_with_stdio(false);
valgrind:
...
==13644==
==13644== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==13644== malloc/free: in use at exit: 122,880 bytes in 6 blocks.
==13644== malloc/free: 6 allocs, 0 frees, 122,880 bytes allocated.
==13644== For counts of detected errors, rerun with: -v
==13644== searching for pointers to 6 not-freed blocks.
==13644== checked 96,388 bytes.
==13644==
==13644== 24,576 bytes in 3 blocks are still reachable in loss record 1 of 2
==13644==at 0x401BCC9: operator new[](unsigned) (vg_replace_malloc.c:197)
==13644==by 0x4090D7B: std::basic_filebuf
>::_M_allocate_internal_buffer() (in 
/usr/lib/libstdc++.so.6.0.8)
==13644==by 0x4098805: (within /usr/lib/libstdc++.so.6.0.8)
==13644==by 0x40862D6: std::ios_base::sync_with_stdio(bool) (in
/usr/lib/libstdc++.so.6.0.8)
==13644==by 0x8048712: main (in ...)
==13644==
==13644==
==13644== 98,304 bytes in 3 blocks are still reachable in loss record 2 of 2
==13644==at 0x401BCC9: operator new[](unsigned) (vg_replace_malloc.c:197)
==13644==by 0x4090D2E: std::basic_filebuf >::_M_allocate_internal_buffer() (in 
/usr/lib/libstdc++.so.6.0.8)
==13644==by 0x40981F5: (within /usr/lib/libstdc++.so.6.0.8)
==13644==by 0x40863B4: std::ios_base::sync_with_stdio(bool) (in
/usr/lib/libstdc++.so.6.0.8)
==13644==by 0x8048712: main (in ...)
==13644==
==13644== LEAK SUMMARY:
==13644==definitely lost: 0 bytes in 0 blocks.
==13644==  possibly lost: 0 bytes in 0 blocks.
==13644==still reachable: 122,880 bytes in 6 blocks.
==13644== suppressed: 0 bytes in 0 blocks.

Environment:
System: Linux penelope 2.6.15-1-k7 #2 Mon Mar 6 15:42:39 UTC 2006 i686
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu

How-To-Repeat:
// run with valgrind --leak-check=full --show-reachable=yes 
#include 
int 
main(void)
{
  std::ios::sync_with_stdio(false);
  std::cout << "testing" << std::endl;
  return 0;
}


--- Comment #1 from mirko dot maischberger at gmail dot com  2006-06-07 
14:40 ---
Fix:
std::ios::sync_with_stdio(true);


-- 
   Summary: valgrind reports memleak when
std::ios:sync_with_stdio(false)
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mirko dot maischberger at gmail dot com
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug ada/27936] New: gnatbind fails to link on Tru64 UNIX

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping current mainline with Ada included fails on Tru64 UNIX V5.1B
when linking gnatbind:

/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -Werror -fno-common   -DHAVE_CONFIG_H  -o gnatbind
ada/b_gnatb.o ada/adaint.o ada/argv.o ada/exit.o ada/cio.o ada/cstreams.o
ada/env.o ada/final.o ada/init.o ada/initialize.o ada/seh_init.o ada/link.o
ada/targext.o ada/raise.o ada/tracebak.o ada/a-except.o ada/ada.o
ada/a-elchha.o ada/ali-util.o ada/ali.o ada/alloc.o ada/atree.o ada/bcheck.o
ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o ada/casing.o
ada/csets.o ada/debug.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o
ada/erroutc.o ada/fmap.o ada/fname.o ada/g-hesora.o ada/g-htable.o
ada/g-os_lib.o ada/g-string.o ada/g-utf_32.o ada/gnat.o ada/gnat!
 bind.o ada/gnatvsn.o ada/hostparm.o ada/interfac.o ada/lib.o ada/namet.o
ada/nlists.o ada/opt.o ada/osint-b.o ada/osint.o ada/output.o ada/rident.o
ada/s-addope.o ada/s-assert.o ada/s-carun8.o ada/s-casuti.o ada/s-crc32.o
ada/s-crtl.o ada/s-exctab.o ada/s-htable.o ada/s-imgenu.o ada/s-mastop.o
ada/s-memory.o ada/s-parame.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o
ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o
ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-wchcnv.o
ada/s-wchcon.o ada/s-wchjis.o ada/scng.o ada/scans.o ada/sdefault.o ada/sinfo.o
ada/sinput.o ada/sinput-c.o ada/snames.o ada/stand.o ada/stringt.o
ada/switch-b.o ada/switch.o ada/style.o ada/styleg.o ada/stylesw.o ada/system.o
ada/table.o ada/targparm.o ada/tree_io.o ada/types.o ada/uintp.o ada/uname.o
ada/urealp.o ada/widechar.o prefix.o version.o \
 ../libcpp/libcpp.a  -liconv ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lexc 
system__pure_exceptions___elabs
system__pure_exceptions_E
collect2: ld returned 1 exit status
make[3]: *** [gnatbind] Error 1

This happens since at least 20060503.

With nm, I find that those symbols are referenced in b_gnat[1b].o, but
defined in s-purexc.o which isn't linked:

b_gnat1.o

system__pure_exceptions_E|  | U | 
system__pure_exceptions___elabs  |  | U | 

b_gnatb.o

system__pure_exceptions_E|  | U | 
system__pure_exceptions___elabs  |  | U | 

s-purexc.o

$system__pure_exceptions___elabs..ng |  | N | 
system__pure_exceptions_E| 0004 | C | 
system__pure_exceptions___elabs  | 0016 | T | 0008

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2006-06-07 
18:02 ---
Fix:
Add ada/s-purexc.o to ada/Make-lang.in (GNATBIND_OBJS).

If this is considered the correct fix, I'll submit a proper patch.


-- 
   Summary: gnatbind fails to link on Tru64 UNIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug ada/27937] New: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping mainline on Solaris 10/x86 (configured for
i686-pc-solaris2.10 to work around the still unfixed PR target/26146) fails
compiling several Ada files:

/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/
-B/vol/gcc/i686-pc-solaris2.10/bin/ -B/vol/gcc/i686-pc-solaris2.10/lib/
-isystem /vol/gcc/i686-pc-solaris2.10/include -isystem
/vol/gcc/i686-pc-solaris2.10/sys-include -c -g -O2 -fPIC  -W -Wall -gnatpg 
a-stwifi.adb -o a-stwifi.o
virtual memory exhausted: Not enough space

If one observes the compilation with top, one can see that VM usage grows
to 4 GB before gnat1 dies.  Compiling with -O instead works.

This is a regression from the 4.1 branch.

Environment:
System: SunOS afrika 5.10 Generic_Patch i86pc i386 i86pc
Architecture: i86pc


host: i686-pc-solaris2.10
build: i686-pc-solaris2.10
target: i686-pc-solaris2.10
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/usr/sfw/bin/gas --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,objc,ada --host i686-pc-solaris2.10 --build
i686-pc-solaris2.10 --target i686-pc-solaris2.10 --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: i686-pc-solaris2.10
  GCC host triplet: i686-pc-solaris2.10
GCC target triplet: i686-pc-solaris2.10


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

[Bug boehm-gc/27963] New: [4.2 Regression] libjava fails to build if it isn't built by default

[gcc-bugzilla at gcc dot gnu dot org]

Trying to bootstrap mainline on IRIX 6.5 with java included failed since
boehm-gc (which is required for libjava) isn't built:

In file included from /vol/gcc/src/gcc-dist/libjava/include/jvm.h:25,
 from /vol/gcc/src/gcc-dist/libjava/include/java-interp.h:14,
 from /vol/gcc/src/gcc-dist/libjava/defineclass.cc:23:
./include/java-gc.h:30:53: error: gc_ext_config.h: No such file or directory

This happens due to this change:

2006-06-06  David Ayers  <[EMAIL PROTECTED]>

PR libobjc/13946
* Makefile.def: Add dependencies for libobjc which boehm-gc.
* Makefile.in: Regenerate.
* configure.in: Add --enable-objc-gc at toplevel and have it
enable boehm-gc for Objective-C.
Remove target-boehm-gc from libgcj.
Add target-boehm-gc to target_libraries.
Add target-boehm-gc to noconfigdirs where ${libgcj}
is specified.

On platforms (like IRIX 6), where libjava just isn't built *by default*,
unconditionally adding boehm-gc to noconfigdirs inhibits building boehm-gc
completely, though it could build and is required for libjava.

This is a regression from the 4.1 branch.

Environment:
System: IRIX64 columba 6.5 07010238 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.16.1 --enable-libgcj
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described.


-- 
   Summary: [4.2 Regression] libjava fails to build if it isn't
built by default
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug libgcj/28189] New: [4.1/4.2 Regression] Many libjava execution tests time out on Tru64 UNIX

[gcc-bugzilla at gcc dot gnu dot org]

Between 20050805 and 20060208, many libjava execution tests started to time
out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the
following test results:

http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html

While the current 4.0 branch is fine

http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01353.html

both the 4.1 branch and mainline still suffer from the problem:

http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00817.html
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00818.html

This is a serious regression and can cause testing to take about 5 days.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap and test as described above.


-- 
   Summary: [4.1/4.2 Regression] Many libjava execution tests time
out on Tru64 UNIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug libgcj/28190] New: [4.2 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection

[gcc-bugzilla at gcc dot gnu dot org]

Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28:

/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src/.libs
-B/vol/gcc/mips-sgi-irix6.5/bin/ -B/vol/gcc/mips-sgi-irix6.5/lib/ -isystem
/vol/gcc/mips-sgi-irix6.5/include -isystem
/vol/gcc/mips-sgi-irix6.5/sys-include -mabi=32 -DHAVE_CONFIG_H -I.
-I/vol/gcc/src/gcc-dist/libjava -I./include -I./gcj
-I/vol/gcc/src/gcc-dist/libjava -Iinclude
-I/vol/gcc/src/gcc-dist/libjava/include
-I/vol/gcc/src/gcc-dist/libjava/classpath/include -Iclasspath/include
-I/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm
-I/vol/gcc/src/gcc-dist/libjava/../boehm-gc/include -I../boehm-gc/include
-I/vol/gcc/src/gcc-dist/libjava/libltdl -I/vol/gcc/src/gcc-dist/libjava/libltdl
-I/vol/gcc/src/gcc-dist/libjava/.././libjava/../gcc -I/vol/gcc/src/g!
 cc-dist/libjava/../zlib -I/vol/gcc/src/gcc-dist/libjava/../libffi/include
-I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers
-Wswitch-enum -D_FILE_OFFSET_BITS=64 -I/vol/X11/include -Wextra -Wall
-D_GNU_SOURCE "-DPREFIX=\"/vol/gcc\"" "-DLIBDIR=\"/vol/gcc/lib\""
"-DJAVA_HOME=\"/vol/gcc\""
"-DBOOT_CLASS_PATH=\"/vol/gcc/share/java/libgcj-4.2.0.jar\""
"-DJAVA_EXT_DIRS=\"/vol/gcc/share/java/ext\""
"-DGCJ_ENDORSED_DIRS=\"/vol/gcc/share/java/gcj-endorsed\""
"-DGCJ_VERSIONED_LIBDIR=\"/vol/gcc/lib/gcj-4.2.0\"" "-DPATH_SEPARATOR=\":\""
"-DLIBGCJ_DEFAULT_DATABASE=\"/vol/gcc/lib/../lib/gcj-4.2.0/classmap.db\""
"-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.2.0/classmap.db\""
"-DTOOLEXECLIBDIR=\"/vol/gcc/lib/../lib\"" -g -O2 -mabi=32 -MT
java/lang/natDouble.lo -MD -MP -MF java/lang/.deps/natDouble.Tpo -c
/vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc   -DPIC -o
java/lang/.libs/natDouble.o
In file included from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
classpath/include/config-int.h:327:1: warning: "INT8_MIN" redefined
In file included from /usr/include/inttypes.h:242,
 from classpath/include/config-int.h:23,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
/usr/include/stdint.h:64:1: warning: this is the location of the previous
definition
In file included from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
classpath/include/config-int.h:328:1: warning: "INT16_MIN" redefined
In file included from /usr/include/inttypes.h:242,
 from classpath/include/config-int.h:23,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
/usr/include/stdint.h:65:1: warning: this is the location of the previous
definition
In file included from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
classpath/include/config-int.h:329:1: warning: "INT32_MIN" redefined
In file included from /usr/include/inttypes.h:242,
 from classpath/include/config-int.h:23,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
/usr/include/stdint.h:66:1: warning: this is the location of the previous
definition
In file included from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
classpath/include/config-int.h:330:1: warning: "INT64_MIN" redefined
In file included from /usr/include/inttypes.h:242,
 from classpath/include/config-int.h:23,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33,
 from
/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29,
 from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26:
/usr/incl

[Bug c/28233] New: internal compiler error: in make_decl_rtl, at varasm.c:752

[gcc-bugzilla at gcc dot gnu dot org]

An array of 64K labels triggers the error.

Environment:
System: FreeBSD FreeBSD.jphartmann.net 6.1-RELEASE FreeBSD 6.1-RELEASE
#1: Sat Jun 17 11:51:42 CEST 2006
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/KERNEL i386



host: i386-unknown-freebsd6.1
build: i386-unknown-freebsd6.1
target: i386-unknown-freebsd6.1
configured with: ../gcc-4.1.1/configure --prefix=/home/john --with-cpu=i686

How-To-Repeat:
There is no preprocessor statements in the failing program.
f/home/john/src/testing:make ts.s
cc -S -fverbose-asm -finline -Winline -Wall -O2 -fno-unroll-loops
-fno-unroll-all-loops -g -o ts.s ts.c
ts.c: In function `main':
ts.c:17: warning: unused variable `ic'
ts.c:22: internal compiler error: in make_decl_rtl, at varasm.c:752
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake: *** [ts.s] Error 1
f/home/john/src/testing:gcc --version
gcc (GCC) 4.1.1
Copyright (C) 2006 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.


--- Comment #1 from jphartmann at gmail dot com  2006-07-03 12:05 ---
Fix:
No known circumvention.  I tried switch statements, but they
run the compiler out of storage after a while.  Apologies for
generating this by hand.  My system i mail-challenged.


-- 
   Summary: internal compiler error: in make_decl_rtl, at
varasm.c:752
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jphartmann at gmail dot com
 GCC build triplet: i386-unknown-freebsd6.1
  GCC host triplet: i386-unknown-freebsd6.1
GCC target triplet: i386-unknown-freebsd6.1


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

[Bug target/28285] New: [4.2 Regression] duplicate case value in alpha_swapped_comparison operator

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping current mainline on Tru64 UNIX fails in stage1 as of 20060705:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I. -I.
-I/vol/gcc/src/gcc/gcc -I/vol/gcc/src/gcc/gcc/.
-I/vol/gcc/src/gcc/gcc/../include -I/vol/gcc/src/gcc/gcc/../libcpp/include
-I/vol/gnu/obj/gmp-4.1.3/mpfr -I/vol/gnu/obj/gmp-4.1.3
-I/vol/gcc/src/gcc/gcc/../libdecnumber -I../libdecnumberinsn-preds.c -o
insn-preds.o
/vol/gcc/src/gcc/gcc/config/alpha/predicates.md: In function
`alpha_swapped_comparison_operator':
/vol/gcc/src/gcc/gcc/config/alpha/predicates.md:571: error: duplicate case
value
/vol/gcc/src/gcc/gcc/config/alpha/predicates.md:570: error: previously used
here
make[3]: *** [insn-preds.o] Error 1

Inspecting the generated insn-preds.c (alpha_swapped_comparison_operator),
there are indeed two case GTU entries.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as above.


-- 
   Summary: [4.2 Regression] duplicate case value in
alpha_swapped_comparison operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug libstdc++/28290] New: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping current mainline as of 20060705 fails on Tru64 UNIX V5.1B
when trying to genererate the PCH file for extc++.h:

/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs
-B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -B/vol/gcc/share/alpha-dec-osf5.1b/lib/
-isystem /vol/gcc/share/alpha-dec-osf5.1b/include -isystem
/vol/gcc/share/alpha-dec-osf5.1b/sys-include -Winvalid-pch -Wno-deprecated -x
c++-header -g -O2  -mieee
-I/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/alpha-dec-osf5.1b
-I/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include
-I/vol/gccsrc/src/gcc/libstdc++-v3/libsupc++
/vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/extc++.h -O2 -g -o
./alpha-dec-osf5.1b/bits/extc++.h.gch/O2g.gch; 
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:57:
error: 'iconv_t' does not name a type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:67:
error: 'descriptor_type' does not name a type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:70:
error: 'descriptor_type' does not name a type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:147:
error: ISO C++ forbids declaration of 'descriptor_type' with no type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:147:
error: expected ';' before '&' token
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151:
error: expected `;' before 'const'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151:
error: ISO C++ forbids declaration of 'descriptor_type' with no type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151:
error: expected ';' before '&' token
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:155:
error: expected `;' before 'protected'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:
In constructor '__gnu_cxx::encoding_state::encoding_state()':
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:86:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_in_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:86:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_out_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:
In constructor '__gnu_cxx::encoding_state::encoding_state(const char*, const
char*, int, int, int)':
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:92:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_in_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:92:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_out_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:
In copy constructor '__gnu_cxx::encoding_state::encoding_state(const
__gnu_cxx::encoding_state&)':
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:104:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_in_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:104:
error: class '__gnu_cxx::encoding_state' does not have any field named
'_M_out_desc'
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:
In member function 'bool __gnu_cxx::encoding_state::good() const':
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:121:
error: 'descriptor_type' does not name a type
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:122:
error: '_M_in_desc' was not declared in this scope
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:122:
error: '__err' was not declared in this scop

[Bug libgomp/28296] New: libgomp fails to configure on Tru64 UNIX

[gcc-bugzilla at gcc dot gnu dot org]

libgomp just doesn't configure any more on Tru64 UNIX V5.1B:

configure: error: Pthreads are required to build libgomp

This is due to the last configure.ac change:

2006-07-05  Eric Christopher  <[EMAIL PROTECTED]>

* configure.ac: Depend addition of -pthread on host OS.
* configure: Regenerate.

which list the -pthread flag during the compile test, so both pthread tests
fail now:

configure:8315:  /vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/
-B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -B/vol/gcc/share/alpha-dec-osf5.1b/lib/
-isystem /vol/gcc/share/alpha-dec-osf5.1b/include -isystem
/vol/gcc/share/alpha-dec-osf5.1b/sys-include -o conftest -O2 -g -O2  -mieee  
conftest.c  >&5
In file included from conftest.c:25:
/vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/include/pthread.h:339:4: error:
#error "Please compile the module including pthread.h with -pthread"

Before that patch, -pthread was included and the test succeeded.

I think this tweaking of pthread detection in libgomp must stop: this
introduces problems all over the place.  I suppose there are some tested
autoconf macros to achieve this correctly on all platforms.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: libgomp fails to configure on Tru64 UNIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug target/28307] New: [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX

[gcc-bugzilla at gcc dot gnu dot org]

While investigating the root cause of PR libgcj/28189, I noticed that both
on the 4.1 branch and on mainline (where the libjava testsuite timeouts
occur) the boehm-gc test had started failing as well (which easily goes
unnoticed due to PR boehm-gc/11412): gctest fails like this:

Key creation failed 18446744073709551615
Test failed
FAIL: gctest

It turns out that this happens when pthread_key_create returns -1.
Printing errno at this point reveals that errno is 0, which is unexpected
and shouldn't happen with the function from libpthread.

Upon further investigation, it turned out that the pthread function
definitions from gthr-posix.c aren't marked weak any more, so the dummy
function definitions make it into libgcc.a and libgcc_s.so.1, which of
course every usage of the real pthread functions.  This was introduce by
this patch and it's successors:

2005-11-09  Alexandre Oliva  <[EMAIL PROTECTED]>

PR other/4372
* gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h,
gthr-tpf.h: Define __gthrw.  For all identifiers that might
be weak, introduce weakrefs or non-weak aliases with __gthrw,
and prefix all uses with __ghtrw.

Before that change, there were #pragma weak declarations for all functions
defined in gthr-posix.c, so those definitions became weak.  Afterwards,
those declarations were lost and the definitions became strong.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Investigate e.g. the pthread_key_create definition in libgcc.a and
libgcc_s.so.1 with stdump:

On the 4.0 branch, it is marked weak:

6. (file  0) (0x10) pthread_key_create Proc   Text   symref (indexNil) 
(weakext)

while on mainline and the 4.1 branch this is lost:

6. (file  0) (0x10) pthread_key_create Proc   Text   symref (indexNil)


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2006-07-07 
17:06 ---
Fix:
I'm currently testing the following patch (which is difficult due to lots
of other unrelated breakage on mainline ;-).  It probably needs some
cleanup and comments, but gives the basic idea.

Index: gthr-posix.c
===
--- gthr-posix.c(revision 115230)
+++ gthr-posix.c(working copy)
@@ -28,6 +28,7 @@ Software Foundation, 51 Franklin Street,

 #include "tconfig.h"
 #include "tm.h"
+# define __gthrw_pragma(pragma) _Pragma (#pragma)
 /* Define so we provide weak definitions of functions used by libobjc only. 
*/
 #define _LIBOBJC_WEAK
 #include "gthr.h"
Index: gthr-posix.h
===
--- gthr-posix.h(revision 115230)
+++ gthr-posix.h(working copy)
@@ -59,8 +59,12 @@ typedef pthread_mutex_t __gthread_recurs
 #endif

 #if SUPPORTS_WEAK && GTHREAD_USE_WEAK
+# ifndef __gthrw_pragma
+#  define __gthrw_pragma(pragma)
+# endif
 # define __gthrw2(name,name2,type) \
-  static __typeof(type) name __attribute__ ((__weakref__(#name2)));
+  static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
+  __gthrw_pragma(weak name2)
 # define __gthrw_(name) __gthrw_ ## name
 #else
 # define __gthrw2(name,name2,type)


-- 
   Summary: [4.1/4.2 Regression] pthread functions in libgcc not
weak any more on Tru64 UNIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug libstdc++/28344] New: [4.2 Regression] Use of __alpha in tr1/random breaks Tru64 UNIX bootstrap

[gcc-bugzilla at gcc dot gnu dot org]

libstdc++ fails to bootstrap on Tru64 UNIX as of 20060710:

/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src/.libs
-B/vol/gcc/share/alpha-dec-osf4.0f/bin/ -B/vol/gcc/share/alpha-dec-osf4.0f/lib/
-isystem /vol/gcc/share/alpha-dec-osf4.0f/include -isystem
/vol/gcc/share/alpha-dec-osf4.0f/sys-include -Winvalid-pch -Wno-deprecated -x
c++-header -g -O2  -mieee
-I/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/alpha-dec-osf4.0f
-I/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include
-I/vol/gccsrc/src/gcc/libstdc++-v3/libsupc++ -O2 -g
/vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h -o
alpha-dec-osf4.0f/bits/stdtr1c++.h.gch/O2g.gch
/vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h:30:25:
warning:
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/alpha-dec-osf4.0f/bits/stdc++.h.gch/O0g.gch:
not used because `__NO_INLINE__' not defined
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/include/tr1/random:1983:
error: expected ',' or '...' before numeric constant

This happens because tr1/random uses __alpha

  template
class gamma_distribution
{
[...]
  explicit
  gamma_distribution(const result_type& __alpha = result_type(1))
  : _M_alpha(__alpha)

which is predefined as 1 on Tru64 UNIX (and probably other alpha systems).

This was introduced by this patch:

2006-07-06  Paolo Carlini  <[EMAIL PROTECTED]>

* include/tr1/random (class gamma_distribution<>): Add.

Environment:
System: OSF1 haydn V4.0 1229 alpha
Machine: alpha

host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build
alpha-dec-osf4.0f --target alpha-dec-osf4.0f
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2006-07-11 
15:29 ---
Fix:
This patch works around this issue:

Index: libstdc++-v3/include/tr1/random
===
--- libstdc++-v3/include/tr1/random (revision 115313)
+++ libstdc++-v3/include/tr1/random (working copy)
@@ -46,6 +46,8 @@
 #include 
 #include 

+#undef __alpha
+
 namespace std
 {
 _GLIBCXX_BEGIN_NAMESPACE(tr1)


-- 
   Summary: [4.2 Regression] Use of __alpha in tr1/random breaks
Tru64 UNIX bootstrap
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug c/28368] New:

[gcc-bugzilla at gcc dot gnu dot org]

-std=c89 doesn't warn about gcc's "?:" extension

Environment:
System: Linux rho 2.6.15-1-amd64-k8 #2 Tue Mar 7 06:53:26 UTC 2006 x86_64
GNU/Linux
Architecture: x86_64


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: /mirror/d/gcc/configure --disable-nls
--prefix=/p/p/gcc-2006-06-29.18h54 --disable-multilib --enable-languages=c

How-To-Repeat:

For example, I expected this to fail:

  echo 'int main() { return 3 ?: 1; }' > k.c
  gcc -W -Wall -std=c89 k.c

With --pedantic, I do get a warning:

  $ gcc --pedantic -std=c89 k.c
  k.c: In function 'main':
  k.c:1: warning: ISO C forbids omitting the middle term of a ?: expression

I suppose that using -std=c99 should evoke a warning, too.


-- 
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at meyering dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/38405] New: Regression (silent failure) handling bitfield in ternary

[gcc-bugzilla at gcc dot gnu dot org]

In the context of a function returning int, and rfp->signed is a
one-bit field,
return rfp->signed_flag ? 1 : 0;
yields -1.  This is an optimization problem, seen with -O2 but not -O1.
Isolated to -ftree-vrp.  Not seen in gcc-4.3 or earlier.

Environment:
System: Linux recycle 2.6.26-1-amd64 #1 SMP Sat Oct 18 15:27:18 UTC 2008 x86_64
GNU/Linux



host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/configure -v --with-pkgversion='Debian 20081130-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk
--enable-gtk-cairo --disable-plugin
--with-java-home=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.4-1.5.0.0/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/gcc-snapshot/jvm
--with-jvm-jar-dir=/usr/lib/gcc-snapshot/jvm-exports
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-mpfr
--enable-cld --disable-werror --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

How-To-Repeat:

Short way:

$ gcc -Wall -O1 -ftree-vrp ternbug.c -o ternbug && ./ternbug
Hello world: -1
FAIL
$ 

Long way:

$ /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.4.0/cc1 -fpreprocessed
ternbug.i -quiet -dumpbase ternbug.c -mtune=generic -auxbase ternbug -O1
-ftree-vrp -version -o ternbug.s
GNU C (Debian 20081130-1) version 4.4.0 20081130 (experimental) [trunk revision
142292] (x86_64-linux-gnu)
compiled by GNU C version 4.4.0 20081130 (experimental) [trunk revision
142292], GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ef8facef55b835d47393957737fa78a4
$ as -V -Qy -o ternbug.o ternbug.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103
$ /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.4.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
ternbug /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.4.0/crtbegin.o
-L/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.4.0
-L/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.4.0/../../../../lib
-L/lib/../lib -L/usr/lib/../lib
-L/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.4.0/../../.. ternbug.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.4.0/crtend.o
/usr/lib/../lib/crtn.o
$ ./ternbug
Hello world: -1
FAIL
$ 

Minimal test case, ternbug.{c,i}:

extern int printf (__const char *__restrict __format, ...);

struct vpiBinaryConst {
 int signed_flag :1;
 int sized_flag :1;
};

int binary_get(int code, struct vpiBinaryConst *rfp)
{
 switch (code) {
  case 1:
   return rfp->signed_flag ? 1 : 0;
  default:
   printf("error: %d not supported\n", code);
   return 0;
 }
}


--- Comment #1 from ldoolitt at recycle dot lbl dot gov  2008-12-04 17:36 
---
Fix:
Work around by reducing optimization, e.g., from -O2 to -O1


-- 
   Summary: Regression (silent failure) handling bitfield in ternary
   Product: gcc
   Version: 4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ldoolitt at recycle dot lbl dot gov
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/38687] New: wrong-code in loop optimization

[gcc-bugzilla at gcc dot gnu dot org]

Example program works with option -O1, but not with -O2
Problem occurs with gcc 4.3.2 and 4.4.0, but not with 4.2.4

Environment:
System: Linux andiunx 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008
i686 GNU/Linux

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure

How-To-Repeat:
Compile the following program with
gcc -O2 foobar.c

extern int printf (__const char *__restrict __format, ...);

int
main ()
{
  int j;

  for (j = 1; j > 0; j += j)
printf("%d\n",j);
  return 0;
}


--- Comment #1 from andikies at t-online dot de  2009-01-01 15:36 ---
Fix:
Do not use -O2 option.


-- 
   Summary: wrong-code in loop optimization
   Product: gcc
   Version: 4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andikies at t-online dot de
 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=38687

[Bug c/40204] New: segfault with bitfields in structs

[gcc-bugzilla at gcc dot gnu dot org]

Compiling the following (nonsense but valid) code triggers an internal
compiler error.

Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009 
i686 GNU/Linux

How-To-Repeat:
Compile the following:

-- snip --
struct s {
unsigned int a : 4;
unsigned int b : 28;
};

void f()
{
char c;
struct s s;
s.a = (c >> 4) & ~(1<<4);
}
-- snip --

$ gcc -Wall -c bug.c 
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See  for instructions.


--- Comment #1 from michael at walle dot cc  2009-05-19 22:16 ---
Fix:
not known


-- 
   Summary: segfault with bitfields in structs
   Product: gcc
   Version: 3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at walle dot cc


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

[Bug c++/40512] New: Compilation stops on valid code with ICE

[gcc-bugzilla at gcc dot gnu dot org]

compile the attached code with the -std=c++0x flag.

Environment:
System: Linux x 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux



host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --prefix=/home/x/gcc-4.4-20090616
--enable-languages=,c,c++,

How-To-Repeat:
template 
class M {
T v;
public:
T & operator[](unsigned) { return v; } 
T const & operator[](unsigned) const { return v; }

template 
auto mg(M o)
-> M
{
typedef M res_t;
return res_t();
}
template 
auto operator*(M const & o) const
-> M
{
typedef M res_t;
return res_t();
}
};

int main(int, char *[])
{
typedef M<2, 2, int> xt;
M<3, 2, xt> hv;
M<4, 3, xt> vv;
hv.mg(vv);
}


--- Comment #1 from pooly at ural2 dot hszk dot bme dot hu  2009-06-21 
21:32 ---
Fix:
Replace o[0] with oT() on line 10.


-- 
   Summary: Compilation stops on valid code with ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pooly at ural2 dot hszk dot bme dot hu
 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=40512

[Bug other/40736] New: Fix for err_bad_typedef.c libffi test failure

[gcc-bugzilla at gcc dot gnu dot org]

 err_bad_typedef.c leads to a call to initialize_aggregate with
 arg->elemnts==NULL. This sets ptr on line 46 of
 libffi/src/prep_cif.c to NULL, which is then dereferenced on
 line 48.

Environment:
System: Linux dps 2.6.30.1-nofb #3 SMP PREEMPT Tue Jul 7 13:26:53 BST 2009
x86_64 GNU/Linux
Architecture: x86_64

host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../gcc/trunk/configure -C --prefix=/usr --enable-hshared
--enab
le-languages=c,c++,fortran,java,objc --no-create --no-recursion

How-To-Repeat:
 Run the err_bad_typedef.c test case in the libffi test
 suite. It is an expected failure.


--- Comment #1 from dps at simpson dot demon dot co dot uk  2009-07-13 
20:36 ---
Fix:
The following patch turns err_bad_typedef.c test case into an
unexpected pass and the pacthed version passes all the tests the
current version does. I= am assuming that ptr==NULL is not meant
to happen so failure is the appropriate response.

--- libffi/src/prep_cif.c.dist  2009-06-04 22:31:11.003714944 +0100
+++ libffi/src/prep_cif.c   2009-07-13 02:00:43.956506574 +0100
@@ -44,6 +44,8 @@
FFI_ASSERT(arg->alignment == 0);

ptr = &(arg->elements[0]);
+  if (ptr == NULL)
+  return FFI_BAD_TYPEDEF;

while ((*ptr) != NULL)
  {


-- 
   Summary: Fix for err_bad_typedef.c libffi test failure
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/41021] New: [ARM] Suboptimal code generated to store a struct

[gcc-bugzilla at gcc dot gnu dot org]

A simple function to store a small struct ends up writing the struct to
memory twice unnecessarily (plus writing it for real the third time).

The function's args are passed in r0-r3 (with r1-r3 being the struct).
It compiles to a sequence containing the following loads and stores,
among others:

 [1] stmfd   sp!, {r0, r1, r2, r4, r5}
 [2] stmia   r0, {r1, r2, r3}
 [3] ldmia   r0, {r0, r1, r2}
 [4] stmia   r3, {r0, r1, r2}
 [5] ldmfd   sp!, {r1, r2, r3, r4, r5}

[2] and [3] seem the most egregious. (r0 points to stack space.)
However, [1] and [5] are odd too; I don't know why it's taking the time
to preserve r1-r3. Line [4] is the line that's actually necessary.

Adjusting the optimization level can eliminate the extra saves in [1],[5],
but all optimization levels seem to perform the extra save in [2],[3].

Environment:
System: OpenBSD underhill..org 4.4 UNDERHILL#1 i386



host: i386-unknown-openbsd4.4
build: i386-unknown-openbsd4.4
target: arm-none-elf
configured with: ../gcc-4.4.1/configure --with-system-zlib --disable-nls
--target=arm-none-elf --prefix=/usr/local/cross/arm-elf --enable-languages=c
--with-cpu=arm7tdmi --with-newlib --with-gmp=/usr/local --with-mpfr=/usr/local
--with-gnu-as --with-gnu-ld --disable-libssp
--enable-version-specific-runtime-libs

How-To-Repeat:

$ arm-none-elf-gcc -mcpu=arm7tdmi -mthumb-interwork  -Os  -Wa,-alhd  -c 
rstore.c

struct queue {
unsigned short used;
struct queue_entry {
unsigned short aux;
void (*func)(int);
int arg;
} entries[16];
};

void enqueue(struct queue *q, struct queue_entry ent)
{
q->entries[q->used++] = ent;
}


-- 
   Summary: [ARM] Suboptimal code generated to store a struct
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wiml at  dot org
 GCC build triplet: i386-unknown-openbsd4.4
  GCC host triplet: i386-unknown-openbsd4.4
GCC target triplet: arm-none-elf


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

[Bug ada/24880] New: (Ada) Conversion of user-defined integer type with Size fixed causes crashes

[gcc-bugzilla at gcc dot gnu dot org]

Explicit conversion from a numeric integer Type to Integer causes a crash of
gcc
when the type is defined with a Size representation clause.
The bug disappears if the representation clause is removed or
if the range begins with 0.

Environment:
System: Linux simone 2.6.12.051101 #1 Tue Nov 1 17:19:34 CET 2005 i686
GNU/Linux
Debian testing gnat-4.0 Version: 4.0.2-2
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu

How-To-Repeat:
 File demo2.adb
procedure Demo2 is
   S : constant := Integer'Size;
   type Regoff_T is range -1 .. 2 ** (S-1);
   for Regoff_T'Size use S;
   B : Integer;
   C : Regoff_T;
begin
   B := Integer (C);
end Demo2;
- The crash message
~ gnatmake demo2
gcc-4.0 -c demo2.adb
gcc-4.0: Internal error: Erreur de segmentation (program gnat1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.

gnatmake: "demo2.adb" compilation error
 with gnat version 3.4
~ gnatmake demo2
gcc-3.4 -c demo2.adb
demo2.adb:6:04: warning: "C" is never assigned a value
gnatbind -x demo2.ali
gnatlink demo2.ali
--


--- Comment #1 from nicolas dot boulenguez at free dot fr  2005-11-15 19:55 
---
Fix:
none


-- 
   Summary: (Ada) Conversion of user-defined integer type with Size
fixed causes crashes
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolas dot boulenguez at free dot fr
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug target/24913] New: undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[gcc-bugzilla at gcc dot gnu dot org]

The G4 PowerPC processor does not support the (full) GPOPT instruction
set that can be activated with -mpowerpc-gpopt. The documentation is not
explicitly clear on which (current) processors support this instruction set -
or any of the other additional/extended/optional sets like those selected with
-mpowerpc-gfxopt, -mstrings, -mmultiple, etc.

Earlier versions of gcc (until at least 4.0.0 4061) used to ignore
-mpowerpc-gpopt on the G4, judging from the assembly they produce (a simple
y=sqrt(x) statement is enough). Gcc 4.0.1 5301 has a new, undocumented
behaviour: it changes the target cpu to ppc970. The resulting code crashes on a
G4, of course. This happens even when the compiler was instructed to compile
for a G4, i.e. when invoked with -mcpu=G4 -mpowerpc-gpopt (the order is
irrelevant).

Environment:
System: Darwin Zygiella.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh
powerpc



host: powerpc-apple-darwin7
build: powerpc-apple-darwin7
target: powerpc-apple-darwin7
configured with: /Volumes/Debian/gcc/gcc401build/../gcc-401-5301/configure
--prefix=/usr/local/gnu/gcc/4.0.1 --enable-languages=c,c++,objc,obj-c++,f95
--build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7
--target=powerpc-apple-darwin7

How-To-Repeat:
Invoked the compiler with -mpowerpc-gpopt on a simple source file like
the example below. On a G4, the resulting fsqrt instruction that is generated
for the sqrt expression will crash. This also happens when compiled with
-mcpu=G4 -mpowerpc-gpopt .

###
#include 
#include 
#include 

main( int argc, char *argv[] )
{ double x, y, z;
  long long a, b;
if( argc>= 2 ){
sscanf( argv[1], "%lf", &x );
sscanf( argv[2], "%lf", &y );
}
else{
x= drand48() * 10.0;
y= drand48() * 5.0;
}
if( y== 0.5 ){
z= sqrt(x);
}
else{
z= pow( x, y );
}
printf( "pow(%g,%g)=%g\n", x, y, z );
a= x;
b= y;
printf( "(long long)(%lld * %lld) = %lld\n", a, b, a*b );
exit(0);
}
###


--- Comment #1 from vsxo at hotmail dot com  2005-11-17 16:47 ---
Fix:
The workaround is not to give the instruction. There are several
solutions. The documentation should be made up to date in this aspect; *also*
for -mpowerpc-gfxopt -mnew-mnemonics -mstring -mmultiple -misel). A good
additional solution would be to output a warning or error when selecting
incompatible instruction sets and target cpus. (Rationale: -mcpu=G4 -mmmx also
gives an abortive error...)
Ideally, a warning would also be given when an option is selected that
cause the resulting code to (potentially) crash on the host CPU (this used to
be the case under Irix), (even) in the absence of a specific cpu selector.


-- 
   Summary: undocumented new CPU upgrade by -mpowerpc-gpopt
overrides user-selected -mcpu= setting
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vsxo at hotmail dot com
 GCC build triplet: powerpc-apple-darwin7
  GCC host triplet: powerpc-apple-darwin7
GCC target triplet: powerpc-apple-darwin7


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

[Bug bootstrap/25002] New: build breaks if no `NAN'

[gcc-bugzilla at gcc dot gnu dot org]

This gcc version always requires that system have at least one
floating value that is usable as `NAN' - in its own headers or
specified in build configuration.  In this system with this compiler
it is not the case.  Can not obtain `NAN' value at all.  When trying
to compute it dynamically, the process just gets  signal, so can not even obtain the value in it and copy
into `NAN' definition.

Environment:
System: OSF1 . V5.1 2650 alpha

Machine:
Using native `CC=cc', `CFLAGS='-pthread -g''.
host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: ../gcc-4.0.2/configure --disable-nls --disable-libgcj
--enable-languages=c,c++,objc

How-To-Repeat:
gmake[1]: Entering directory `gcc-4.0.2-e/build-alpha-dec-osf5.1b/libiberty'
make bootstrap
cc -c -DHAVE_CONFIG_H -pthread -g  -I.
-I../../../gcc-4.0.2/libiberty/../include  
../../../gcc-4.0.2/libiberty/floatformat.c -o floatformat.o
cc: Error: ../../../gcc-4.0.2/libiberty/floatformat.c, line 319: In this
statement, the libraries on this platform do not yet support compile-time
evaluation of the constant expression "0.0/0.0". (constfoldns)
dto = NAN;
--^
gmake[1]: *** [floatformat.o] Error 1

The preprocessed line 319 is as follows.

dto =  ( 0.0 / 0.0 ) ;


--- Comment #1 from gin at mo dot msk dot ru  2005-11-23 15:02 ---
Fix:

Do not have patch currently.  Most likely gcc has to check whether
`NAN' value exists, and compile some code in `floatformat.c' only if
it is the case.  Or at least allow to disable compiling that code in
build configuration.


-- 
   Summary: build breaks if no `NAN'
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug rtl-optimization/25130] New: 4.1: miscompilation in loop optimization

[gcc-bugzilla at gcc dot gnu dot org]

hi -

The current gcc in the 4.1 branch (svn rev 107578) miscompiles the following
source with -O3 -fno-strict-aliasing:

---
// g++ -O3  -g -fno-strict-aliasing -o x x.cc 

inline void* operator new(unsigned, void* __p) throw() { return __p; }
extern "C" int printf (...);

struct _Deque_base
{
  _Deque_base()
  {
_M_impl._M_start_cur = new int;
_M_impl._M_finish_cur = _M_impl._M_start_cur;
printf ("");
  }

  ~_Deque_base() {
printf ("", _M_impl._M_start_node);
  }

  struct _Deque_impl
  {
int* _M_start_cur;
int _M_start_node;
int* _M_finish_cur;
  };
  _Deque_impl _M_impl;
};

struct deque : public _Deque_base {};

struct ClusterContainerStandard
{
  deque _clusters;
  virtual void add_cluster() { }
};

int main( )
{
  {
ClusterContainerStandard box;
  }
  printf ("aaa\n");

  {
deque clusters;
if (clusters._M_impl._M_start_cur)
{
  ::new(static_cast(clusters._M_impl._M_finish_cur)) int(0);
  ++clusters._M_impl._M_finish_cur;
}
printf ("%p %p\n",
clusters._M_impl._M_start_cur, clusters._M_impl._M_finish_cur);
  }
  return 0;
}
---

I expect the two pointer values printed by this program to differ by 4.
Instead, they are identical:

$ g++ -o x -O3 -fno-strict-aliasing x.cc
$ ./x
aaa
0x804a018 0x804a018
$


Here is the relevant excerpt from the generated code, starting just
after the printf("aaa\n") call:

movl$4, (%esp)
call_Znwj ; new int
movl%eax, -24(%ebp)   ; assign to start_cur
movl%eax, -16(%ebp)   ; assign to finish_cur
movl$.LC0, (%esp)
callprintf; empty printf
.LEHE0:
movl-24(%ebp), %eax   ; test start_cur
testl   %eax, %eax
je  .L12
movl-16(%ebp), %eax   ; test finish_cur --- part of the new()
testl   %eax, %eax
je  .L6
movl$0, (%eax); *finish_cur = 0
movl-16(%ebp), %eax   ; (a redundant move)  [1]
.L6:
addl$4, -16(%ebp) ; ++finish_cur
.L4:
movl%eax, 8(%esp) ; OOPS --- here we're using the value [2]
  ; of finish_cur before the increment!
movl-24(%ebp), %eax
movl$.LC2, (%esp)
movl%eax, 4(%esp)
.LEHB1:
callprintf


Looking at the RTL dumps, the problem first seems to appear after the
loop2_done pass.  Here's an excerpt from that file, starting
at the insn corresponding to [1] above and continuing to [2].
Note that after the increment, there's a branch around an insn
that reloads the value of finish_cur from memory before the
printf call --- without that jump, the program would work correctly.
That jump is not present in the previous RTL dump, loop2_unswitch.


(insn 122 56 57 2 (set (reg:SI 79 [ clusters.D.1787._M_impl._M_finish_cur ])
(mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
._M_impl._M_start_node+0 S4 A32])) 34 {*movsi_1} (nil)
(nil))
;; End of basic block 2, registers live:
 (nil)

;; Start of basic block 3, registers live: (nil)
(code_label 57 122 58 3 6 "" [1 uses])

(note 58 57 59 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(note 59 58 60 3 ("x.cc") 48)

(insn 60 59 128 3 x.cc:48 (parallel [
(set (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.1787._M_impl._M_finish_cur+0 S4 A32])
(plus:SI (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.1787._M_impl._M_finish_cur+0 S4 A32])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 148 {*addsi_1} (nil)
(nil))

(jump_insn 128 60 129 3 (set (pc)
(label_ref 61)) -1 (nil)
(nil))
;; End of basic block 3, registers live:
 (nil)

(barrier 129 128 127)

;; Start of basic block 4, registers live: (nil)
(code_label 127 129 126 4 12 "" [1 uses])

(note 126 127 121 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 121 126 61 4 (set (reg:SI 79 [ clusters.D.1787._M_impl._M_finish_cur ])
(mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
._M_impl._M_start_node+0 S4 A32])) 34 {*movsi_1} (nil)
(nil))
;; End of basic block 4, registers live:
 (nil)

;; Start of basic block 5, registers live: (nil)
(code_label 61 121 62 5 4 "" [1 uses])

(note 62 61 63 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(note 63 62 65 5 ("x.cc") 51)

(insn 65 63 66 5 x.cc:51 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S4 A32])
(reg:SI 79 [ clusters.D.1787._M_impl._M_finish_cur ])) 34 {*movsi_1}
(nil)
(nil))

Environment:
System: Linux karma 2.6.14.2sss #1 PREEMPT Mon Nov 21 10:03:24 EST 2005 i686
i686 i386 GNU/Linux
Architecture: i686


ho

[Bug c/25334] New: The example for flexible array member doesn't work.

[gcc-bugzilla at gcc dot gnu dot org]

Using an example from the GCC documentation doesn't work. I don't know if the
documentation is broken
or the compiler.

Environment:
System: FreeBSD inchoate.localdomain 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat
Oct 8 10:25:52 CST 2005 root@:/usr/obj/usr/src/sys/INCHOATE i386

host: i386-portbld-freebsd7.0
build: i386-portbld-freebsd7.0
target: i386-portbld-freebsd7.0
configured with: ./..//gcc-4.1-20051202/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=41
--libdir=/usr/local/lib/gcc/i386-portbld-freebsd7.0/4.1.0
--with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd7.0/4.1.0/include/c++/
--disable-shared --disable-libgcj --prefix=/usr/local i386-portbld-freebsd7.0

How-To-Repeat:
This file is based on the example in section 5.12 of the manual (Arrays of Zero
length)

cat >test.c
#include 

int
main(int argc, char **argv) {
struct foo { int x; int y[]; };

struct foo a = { 1, { 2, 3, 4 } };

printf("sizeof(a) = %d\n", sizeof(a));
}

[EOT]

~> gcc41 test.c -o test
[inchoate 11:55] ~ >gcc41 test.c -o test
test.c: In function 'main':
test.c:7: error: non-static initialization of a flexible array member
test.c:7: error: (near initialization for 'a')

gcc 3.4.4 gives the same result.


--- Comment #1 from darius at dons dot net dot au  2005-12-10 01:37 ---
Fix:
Depends whether the compiler or the documentation is wrong :)


-- 
   Summary: The example for flexible array member doesn't work.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darius at dons dot net dot au
 GCC build triplet: i386-portbld-freebsd7.0
  GCC host triplet: i386-portbld-freebsd7.0
GCC target triplet: i386-portbld-freebsd7.0


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

[Bug c/25350] New: Can't include mmintrin.h

[gcc-bugzilla at gcc dot gnu dot org]

  when trying to include file mmintrin.h in any file, compilation fails with
the following message:

mmintrin.h: In function '_mm_add_si64':
mmintrin.h:280: error: can't convert between vector values of different size
mmintrin.h: In function '_mm_sub_si64':
mmintrin.h:382: error: can't convert between vector values of different size

It works okay with older versions of gcc, and fails with 4.2.0 20051211
both with the
include file that ships with it and with it's older versions.

Environment:
System: Linux amazonia 2.6.10-5-386 #1 Mon Oct 10 11:15:41 UTC 2005 i686
GNU/Linux
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc/configure --enable-languages=c --disable-nls
--prefix=/home/glauber/usr

How-To-Repeat:
create a file containing the single directive #include  and
compile it 
with gcc -msse  


-- 
   Summary: Can't include mmintrin.h
   Product: gcc
   Version: 2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: glommer at gmail 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=25350

[Bug fortran/25412] New: gfortran 4.0.2 seg fault

[gcc-bugzilla at gcc dot gnu dot org]

Segmentation fault:

#gfortran4.0 -c wave.f90
wave.f90:80: internal compiler error: Segmentation fault

I believe this worked under gfortran 4.0.

Environment:
System: Linux FUME.WPI.EDU 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../configure --prefix=/usr/local --exec-prefix=/usr/local
--program-suffix=4.0 --without-java

How-To-Repeat:

Just attempt to compile it. Here's the processed source code:

-snip
!#define debug

! to be costumized by user (usually done in the makefile)---
!#define vector  compile for vector machine
!#define essluse ESSL instead of LAPACK
!#define single_BLAS use single prec. BLAS

!#define wNGXhalfgamma only wavefunctions (X-red)
!#define wNGZhalfgamma only wavefunctions (Z-red)

!#define 1 charge stored in REAL array (X-red)
!#define NGZhalf charge stored in REAL array (Z-red)
!#define NOZTRMM replace ZTRMM by ZGEMM
!#define REAL_to_DBLEconvert REAL() to DBLE()
!#define MPI compile for parallel machine with MPI
!- end of user part 
!
!   charge density: half grid mode X direction
!
!
!   charge density real
!
!
!   wavefunctions: full grid mode
!
!
!   wavefunctions complex
!
!
!   common definitions
!









!
! RCS:  $Id: wave.F,v 1.6 2002/08/14 13:59:43 kresse Exp $
!
!  this module contains the routines required to setup
!  the distribution of wavefunctions over  and all basic routines
!  handling wavedes etc.
!
!***
  MODULE WAVE
  USE prec
  USE mpimy
  INCLUDE "wave.inc"
  CONTAINS

!===
!  initialize and descriptor for the wavefunctions
!  mainly allocation
!===

  SUBROUTINE ALLOCWDES(WDES,LEXTEND)
  USE prec
  IMPLICIT NONE

  INTEGER NK
  TYPE (wavedes)  WDES
  INTEGER NRPLWV,NKPTS,NCOL
  LOGICAL LEXTEND

  NRPLWV=WDES%NGDIM
  NKPTS =WDES%NKPTS
  NCOL  =WDES%NCOL  

  ALLOCATE(
WDES%NPLWKP(NKPTS),WDES%NGVECTOR(NKPTS),WDES%NPLWKP_TOT(NKPTS),WDES%NINDPW(NRPLWV,NKPTS))
  IF (NCOL>0) THEN
ALLOCATE(WDES%PL_INDEX(NCOL,NKPTS),WDES%PL_COL(NCOL,NKPTS))
  ELSE
NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL)
  ENDIF

  IF (LEXTEND) THEN
!-MM- changes to accommodate spin spirals
! original statement
!   ALLOCATE( WDES%DATAKE(NRPLWV,NKPTS), &
! 
WDES%IGX(NRPLWV,NKPTS),WDES%IGY(NRPLWV,NKPTS),WDES%IGZ(NRPLWV,NKPTS))
ALLOCATE(WDES%DATAKE(NRPLWV,NKPTS,2), &
  &   
WDES%IGX(NRPLWV,NKPTS),WDES%IGY(NRPLWV,NKPTS),WDES%IGZ(NRPLWV,NKPTS))
!-MM- end of alteration
  ELSE
NULLIFY(WDES%DATAKE)
NULLIFY(WDES%IGX); NULLIFY(WDES%IGY); NULLIFY(WDES%IGZ)
NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL)
  END IF
  END SUBROUTINE

!===
!  deallocate a  descriptor for the wavefunctions
!===

  SUBROUTINE DEALLOCWDES(WDES,LEXTEND)
  USE prec
  IMPLICIT NONE
  TYPE (wavedes)  WDES
  LOGICAL LEXTEND

  DEALLOCATE( WDES%NPLWKP,WDES%NGVECTOR,WDES%NPLWKP_TOT,WDES%NINDPW)

  IF (WDES%NCOL>0) THEN
DEALLOCATE(WDES%PL_INDEX,WDES%PL_COL)
NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL)
  ENDIF
  IF (LEXTEND) THEN
DEALLOCATE( WDES%DATAKE,WDES%IGX,WDES%IGY,WDES%IGZ)
NULLIFY(WDES%DATAKE)
NULLIFY(WDES%IGX); NULLIFY(WDES%IGY); NULLIFY(WDES%IGZ)
  END IF
  END SUBROUTINE


!===
!  initialize the projector part of the descriptor for the
!  wavefunctions
!===

  SUBROUTINE WDES_SET_NPRO(WDES,T_INFO,P)
  USE prec
  USE  mpimy
  USE  poscar
  USE  pseudo

  TYPE (wavedes)  WDES
  TYPE (type_info) :: T_INFO
  TYPE (potcar)   P(T_INFO%NTYP)
! local varibles
  INTEGER NALLOC,NPRO_TOT,NT,NI,NIS,NODE_TARGET,NPRO, &
 LMMAXC,NIONS,LASTTYP

  WDES%NIONS = T_INFO%NIONS
  WDES%NTYP  = T_INFO%NTYP
  WDES%NITYP =>T_INFO%NITYP
  ALLOCATE(WDES%LMMAX(WDES%NTYP))
  DO NT=1,T_INFO%NTYP
WDES%LMMAX(NT)=P(NT)%LMMAX
  ENDDO
  WDES%NPRO  =SUM(WDES%LMMAX*WDES%NITYP)
  WDES%NPRO_TOT=SUM(WDES%LMMAX*WDES%NITYP)
  WDES%NPROD =WDES%NPRO


  WDES%NPRO  =WDES%NPRO  *WDES%NRSPINORS
  WDES%NPRO_TOT=WDES%NPRO_TOT*WDES%NRSPINORS

[Bug other/25551] New: gcov incorrect count for lone return in block

[gcc-bugzilla at gcc dot gnu dot org]

gcov incorrectly shows that a lone return statement inside a block
has executed when in fact it has not

Environment:
System: Linux mercury.acucorp.com 2.4.18-27.8.0smp #1 SMP Fri Mar 14 07:13:13
EST 2003 i686 athlon i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-4.0.2/configure --prefix=/usr/local/gcc-4.0.2

How-To-Repeat:
Compile the following program, run it, then run gcov on the source:

gcc -fprofile-arcs -ftest-coverage -o foo foo.c
./foo
gcov -b foo.c

--- foo.c:

#include 

static void
foo(int num)
{
if (num <= 1) {
/* uncomment following line to get correct results */
//  printf("num <= 1\n");

/* this return is never executed, but gcov says it is */
return;
}

printf("num > 1\n");
} /* foo */


int
main(void)
{
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
return 0;
}

--- foo.c.gcov:

-:0:Source:foo.c
-:0:Graph:foo.gcno
-:0:Data:foo.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
-:3:static void
-:4:foo(int num)
function foo called 7 returned 100% blocks executed 100%
7:5:{
7:6:if (num <= 1) {
branch  0 taken 100% (fallthrough)
branch  1 taken 0%
-:7:/* uncomment following line to get correct results */
-:8://  printf("num <= 1\n");
-:9:
-:   10:/* this return is never executed, but gcov says it is
*/
7:   11:return;
-:   12:}
-:   13:
7:   14:printf("num > 1\n");
call0 returned 100%
-:   15:} /* foo */
-:   16:
-:   17:
-:   18:int
-:   19:main(void)
function main called 1 returned 100% blocks executed 100%
1:   20:{
1:   21:foo(3);
call0 returned 100%
1:   22:foo(3);
call0 returned 100%
1:   23:foo(3);
call0 returned 100%
1:   24:foo(3);
call0 returned 100%
1:   25:foo(3);
call0 returned 100%
1:   26:foo(3);
call0 returned 100%
1:   27:foo(3);
call0 returned 100%
1:   28:return 0;
-:   29:}


--- Comment #1 from mark at acucorp dot com  2005-12-23 18:57 ---
Fix:
unknown


-- 
   Summary: gcov incorrect count for lone return in block
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at acucorp 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=25551

[Bug bootstrap/25589] New: can not configure CFLAGS_FOR_TARGET

[gcc-bugzilla at gcc dot gnu dot org]

Flags that are passed to newly built gcc when compiling code for
target system during are determined by value of `CFLAGS_FOR_TARGET'
makefile variable as defined in top level `Makefile'.  `CFLAGS' in
that `Makefile' are passed on for use with old compiler used to
bootstrap gcc.

Can not configure `CFLAGS_FOR_TARGET' value at all, that is, can not
change its value and nothing more by passing arguments to / setting
variables in `configure'.  Top level `Makefile.in' just
unconditionally duplicates `$(CFLAGS)' into it.  Thus the same flags
are passed to completely different compilers.  If old compiler is not
a gnu one, its flags does not have to be recognized by newly built gcc
at all.  In this case target code does not build at all like this.

checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
gmake: *** [configure-intl] Error 1
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
gmake: *** [configure-libiberty] Error 1

The worst is sometimes gcc maintainers themselves tell users to
specify weird flags to native compiler - like pinskia at gcc dot gnu
dot org did on 2005-11-23 15:04 in
:

> the problem is that you need to supply -ieee to the
> compiler.

gcc does not recognize it.

How-To-Repeat:

That particular case of needing `-ieee' flag not recognized by gcc is
described in .


--- Comment #1 from gin at mo dot msk dot ru  2005-12-28 15:53 ---
Fix:

One workaround is described in that same
: to put these
weird flags in `CC' value as passed to `configure', and leave in
`CFLAGS' only those recognized by gcc, if any.  If put all flags in
`CC', why have separate `CFLAGS' variable at all?

The other is explicitly set `CFLAGS_FOR_TARGET' in `make' command
line.

gmake CFLAGS_FOR_TARGET='-O2 -pthread -g  -mieee' bootstrap;


-- 
   Summary: can not configure CFLAGS_FOR_TARGET
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru


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

[Bug c/25682] New: ICE when using (int)(&((S*)0)->field) as array size

[gcc-bugzilla at gcc dot gnu dot org]

A 'field offset' macro which has worked so far (up to gcc-3.4.3) now
causes an ICE.

Environment:
System: Linux suse2 2.4.19-64GB-SMP #1 SMP Mon Oct 21 18:48:05 UTC 2002 i686
unknown
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-4.0.2/configure --prefix=/usr/local/gnu/gcc/4.0.2
--enable-languages=c,c++

How-To-Repeat:
Compile the program below with 'gcc -c':
//
typedef struct {
char name;
} S;
void f()
{
char a[(int)&(((S*)8)->name)];
} 
//
The compiler output is:
bug.c: In function 'f':
bug.c:5: internal compiler error: in tree_low_cst, at tree.c:3850


--- Comment #1 from yuvalk at mainsoft dot com  2006-01-05 21:39 ---
Fix:
Use the GCC offsetof macro from stddef.h


-- 
   Summary: ICE when using (int)(&((S*)0)->field) as array size
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuvalk at mainsoft 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=25682

[Bug c++/25687] New: pwlib 1.8.7 does not build on alpha due with -Os

[gcc-bugzilla at gcc dot gnu dot org]

While building the pwlib package on alpha, the following problem
occured:
   
http://buildd.debian.org/fetch.php?&pkg=pwlib&ver=1.8.7-1&arch=alpha&stamp=1131832002&file=log&as=raw
The build does involve a testrun after linking the library. This
testrun is compiling and executing the hello-world sample application. The same
problem could be duplicated with the pwlib CVS HEAD code (1.9.0) and was
tracked down to be happening with the default -Os optimization. The backtrace
is for the 1.9.0 compile:

(sid)[EMAIL PROTECTED]:~/src/pwlib-1.9.0$ gdb 
samples/hello_world/obj_*_r/hello
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "alpha-linux"...r
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program:
/usr/local/src/pwlib-1.9.0/samples/hello_world/obj_linux_alpha_r/hello 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 13665)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16384 (LWP 13665)]
0x0001200c2e80 in vtable for P_YUV422_YUV422 ()
(gdb) bt
#0  0x0001200c2e80 in vtable for P_YUV422_YUV422 ()
#1  0x0001200a4574 in PFactory::GetInstance ()
at pfactory.h:338
#2  0x0001200a4a88 in PFactory::Register
([EMAIL PROTECTED], worker=0x12010a080) at pfactory.h:275
#3  0x0001200a4b0c in Worker (this=0x12010a080, [EMAIL PROTECTED],
singleton=Variable "singleton" is not available.
) at pfactory.h:263
#4  0x00012009e144 in __static_initialization_and_destruction_0
(__initialize_p=Variable "__initialize_p" is not available.
) at ../../ptclib/http.cxx:476
#5  0x0001200b53b8 in __do_global_ctors_aux ()
#6  0x00012000b598 in _init ()
#7  0x0001200b5254 in __libc_csu_init ()
#8  0x0001200b5254 in __libc_csu_init ()
#9  0x02029ce8 in ?? () from /lib/ld-linux.so.2
#10 0x0001200b5254 in __libc_csu_init ()
Cannot access memory at address 0x1200fe8f0
(gdb)

Environment:
System: Linux cyclop 2.6.12-1-alpha-generic #1 Tue Sep 6 22:36:56 UTC 2005
alpha GNU/Linux
Architecture: alpha


host: alpha-unknown-linux-gnu
build: alpha-unknown-linux-gnu
target: alpha-unknown-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release alpha-linux-gnu

How-To-Repeat:
Rebuilding pwlib&samples/hello will hit that bug each time.


--- Comment #1 from kk at zyklop dot kk dot de  2006-01-06 04:49 ---
Fix:
Replace -Os by -O2 (as was patched for 1.8.7-2). See last entry in:
   
http://svn.debian.org/wsvn/pkg-voip/pwlib/trunk/debian/patches/01_alpha.dpatch?op=file&rev=0&sc=0


As this is my first use of gccbug, please ask for more information if I have
obviously forgotten something. ;)


-- 
   Summary: pwlib 1.8.7 does not build on alpha due with -Os
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kk at zyklop dot kk dot de
 GCC build triplet: alpha-unknown-linux-gnu
  GCC host triplet: alpha-unknown-linux-gnu
GCC target triplet: alpha-unknown-linux-gnu


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

[Bug pending/25870] New: GCC 3.4.5 java compiler bootstrap failure.

[gcc-bugzilla at gcc dot gnu dot org]

NOTE: Defaulting component because reported component no longer exists
When list of languages has java (--enable-languages=c,c++,ada,f77,objc,java)
passed then make bootstrap fails on java with the following error:

Making all in gcj
make[5]: Entering directory
`/root/gcc-build/x86_64-slackware-linux/32/libjava/gcj'
make[5]: Leaving directory
`/root/gcc-build/x86_64-slackware-linux/32/libjava/gcj'
Making all in include
make[5]: Entering directory
`/root/gcc-build/x86_64-slackware-linux/32/libjava/include'
make[5]: Leaving directory
`/root/gcc-build/x86_64-slackware-linux/32/libjava/include'
make[5]: Entering directory `/root/gcc-build/x86_64-slackware-linux/32/libjava'
/bin/sh ./libtool --tag=CXX --mode=compile /root/gcc-build/gcc/xgcc
-shared-libgcc -B/root/gcc-build/gcc/ -nostdinc++
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src/.libs
-B/usr/x86_64-slackware-linux/bin/ -B/usr/x86_64-slackware-linux/lib/ -isystem
/usr/x86_64-slackware-linux/include -isystem
/usr/x86_64-slackware-linux/sys-include  -m32 -DHAVE_CONFIG_H -I.
-I../../../../gcc-3.4.5/libjava -I./include -I./gcj
-I../../../../gcc-3.4.5/libjava -Iinclude
-I../../../../gcc-3.4.5/libjava/include -I/root/gcc-3.4.5/boehm-gc/include 
-DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1
-DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1
-DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -DUSE_MMAP=1  
-I../../../../gcc-3.4.5/libjava/libltdl -I../../../../gcc-3.4.5/libjava/libltdl
 -I../../../../gcc-3.4.5/libjava/.././libjava/../gcc
-I../../../../gcc-3.4.5/libjava/../zlib -I../../../../gcc-!
 3.4.5/libjava/../libffi/include -I../libffi/include  -O2 -g -O2 -fno-rtti
-fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum -ffloat-store
-fno-omit-frame-pointer  -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE
-DPREFIX="\"/usr\"" -DLIBDIR="\"/usr/lib\""
-DBOOT_CLASS_PATH="\"/usr/share/java/libgcj-3.4.5.jar\"" -g -O2 -D_GNU_SOURCE 
-m32 -c ../../../../gcc-3.4.5/libjava/jni.cc
/bin/sh ./libtool --tag=CXX --mode=compile /root/gcc-build/gcc/xgcc
-shared-libgcc -B/root/gcc-build/gcc/ -nostdinc++
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src/.libs
-B/usr/x86_64-slackware-linux/bin/ -B/usr/x86_64-slackware-linux/lib/ -isystem
/usr/x86_64-slackware-linux/include -isystem
/usr/x86_64-slackware-linux/sys-include  -m32 -DHAVE_CONFIG_H -I.
-I../../../../gcc-3.4.5/libjava -I./include -I./gcj
-I../../../../gcc-3.4.5/libjava -Iinclude
-I../../../../gcc-3.4.5/libjava/include -I/root/gcc-3.4.5/boehm-gc/include 
-DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1
-DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1
-DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -DUSE_MMAP=1  
-I../../../../gcc-3.4.5/libjava/libltdl -I../../../../gcc-3.4.5/libjava/libltdl
 -I../../../../gcc-3.4.5/libjava/.././libjava/../gcc
-I../../../../gcc-3.4.5/libjava/../zlib -I../../../../gcc-!
 3.4.5/libjava/../libffi/include -I../libffi/include  -O2 -g -O2 -fno-rtti
-fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum -ffloat-store
-fno-omit-frame-pointer  -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE
-DPREFIX="\"/usr\"" -DLIBDIR="\"/usr/lib\""
-DBOOT_CLASS_PATH="\"/usr/share/java/libgcj-3.4.5.jar\"" -g -O2 -D_GNU_SOURCE 
-m32 -c ../../../../gcc-3.4.5/libjava/prims.cc
mkdir .libs
/root/gcc-build/gcc/xgcc -shared-libgcc -B/root/gcc-build/gcc/ -nostdinc++
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src
-L/root/gcc-build/x86_64-slackware-linux/32/libstdc++-v3/src/.libs
-B/usr/x86_64-slackware-linux/bin/ -B/usr/x86_64-slackware-linux/lib/ -isystem
/usr/x86_64-slackware-linux/include -isystem
/usr/x86_64-slackware-linux/sys-include -m32 -DHAVE_CONFIG_H -I.
-I../../../../gcc-3.4.5/libjava -I./include -I./gcj
-I../../../../gcc-3.4.5/libjava -Iinclude
-I../../../../gcc-3.4.5/libjava/include -I/root/gcc-3.4.5/boehm-gc/include
-DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1
-DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1
-DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -DUSE_MMAP=1
-I../../../../gcc-3.4.5/libjava/libltdl -I../../../../gcc-3.4.5/libjava/libltdl
-I../../../../gcc-3.4.5/libjava/.././libjava/../gcc
-I../../../../gcc-3.4.5/libjava/../zlib
-I../../../../gcc-3.4.5/libjava/../libffi/include -I../libffi/incl!
 ude -O2 -g -O2 -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers
-Wswitch-enum -ffloat-store -fno-omit-frame-pointer -I/usr/X11R6/include -W
-Wall -D_GNU_SOURCE -DPREFIX=\"/usr\" -DLIBDIR=\"/usr/lib\"
-DBOOT_CLASS_PATH=\"/usr/share/java/libgcj-3.4.5.jar\" -g -O2 -D_GNU_SOURCE
-m32 -Wp,-MD,.deps/jni.pp -c ../../../../gcc-3.4.5/libjava/jni.cc  -fPIC -DPIC
-o .libs/jni.o
In file included from ../../../../gcc-3.4.5/libjava/jni.cc:38:
./java/lang/Integer.h:45: warning: this decimal constant is unsigned only in
ISO C90
/root/gcc-build/gcc/xgcc -share

[Bug bootstrap/28469] New: stage2 error: toplev.c redefines floor_log2

[gcc-bugzilla at gcc dot gnu dot org]

When executing `make bootstrap', the following error occurs.

stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/   -O2 -g
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -DHAVE_CONFIG_H -I. -I.
-I../../share/src/gcc-4.0.3/gcc -I../../share/src/gcc-4.0.3/gcc/.
-I../../share/src/gcc-4.0.3/gcc/../include
-I../../share/src/gcc-4.0.3/gcc/../libcpp/include \
  -DTARGET_NAME=\"i686-pc-linux-gnu\" \
  -c ../../share/src/gcc-4.0.3/gcc/toplev.c -o toplev.o
../../share/src/gcc-4.0.3/gcc/toplev.c: In function 'toplev_main':
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1713: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1717: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1719: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1723: sorry, unimplemented: called from
here
make[2]: *** [toplev.o] Error 1

Will post full preprocessed code on request.  It actually contains the
`floor_log2' declarations in order as follows.  Describing their line
numbers in the same way as preprocessor does.

# 168 "../../share/src/gcc-4.0.3/gcc/toplev.h"
extern int floor_log2 (unsigned long);
# 183 "../../share/src/gcc-4.0.3/gcc/toplev.h"
extern __inline__ __attribute__((always_inline)) __attribute__((always_inline))
int
floor_log2 (unsigned long x)
{
/* skipping */
# 546 "../../share/src/gcc-4.0.3/gcc/toplev.c"
int
floor_log2 (unsigned long x)
{

Inline definition in `toplev.h' is not output by preprocessor with
older gcc versions, including that of old / stage 1 compiler.

Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686

Old compiler is `gcc-3.3.2-6mdk'.  On stage 1 `GCC_VERSION' numeric
value is 3003.
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c

How-To-Repeat:
make bootstrap


-- 
   Summary: stage2 error: toplev.c redefines floor_log2
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=28469

[Bug c/28470] New: does not inline constant funargs

[gcc-bugzilla at gcc dot gnu dot org]

Observing it at least on stage 1 compiler, and exactly the same way as
in 3.3.2.

If inline function, later called a functional, is passed a function
argument that is constant and inline, and said argument is called in
the functional body, and when inline expansions are on, compiler
expand inline only said functional, but not function argument calls in
said expansion.  Instead, it handles these calls just like those of
non- inline function, that is, outputs uninlined function body and
call instruction of that body, with all call overhead.

If argument is a nested function, 4.0.3 behaves a bit better than
3.3.2.  It does not output full trampoline code unnecessarily.

Priority?  How should I know?  Depends on projects using the compiler.

Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c

How-To-Repeat:
Compile with `-O99'.  `do_it_cb' code is output as a separate funtion,
and code output for `do_it_with_g_set_v0' calls `do_it_cb', not
`do_it'.

extern int g_set_v0 (void);
extern void g_restore_v (int);
extern void do_it (void);

static inline
with_g_set_v0 (void (f) (void))
{
  int v = g_set_v0 ();
  f ();
  g_restore_v (v);
}

static inline void
do_it_cb (void)
{
  do_it ();
}

void
do_it_with_g_set_v0 (void)
{
  with_g_set_v0 (do_it_cb);
}


-- 
   Summary: does not inline constant funargs
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=28470

[Bug bootstrap/28472] New: -B$(build_tooldir)/bin/

[gcc-bugzilla at gcc dot gnu dot org]

Some targets in `gcc/Makefile.in' built while `make bootstrap' specify
`-B$(build_tooldir)/bin/'.  All of this is done when nothing from gcc
being built is installed in that directory yet.  What is installed
there, if any, generally has nothing to do with gcc at all.  It may
easily be files from older compiler version.  Using them may do only
harm.

In this gcc version this is exactly the same in all build
configurations on and for all systems.  Detailed system description is
irrelevant, leaving it empty.

Environment:
System: 
Architecture: 
host:
build:
target:
configured with:

How-To-Repeat:
make bootstrap


--- Comment #1 from gin at mo dot msk dot ru  2006-07-24 18:01 ---
Fix:
If in some build configurations bootstrap compiler must use some
external software and find it though additional `-B' option, need a
cleaner way to specify list of such `-B' options for these
configurations.  And leave it empty by default.


-- 
   Summary: -B$(build_tooldir)/bin/
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru


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

[Bug other/28700] New: does not fix broken linux/compiler-gcc+.h

[gcc-bugzilla at gcc dot gnu dot org]

System include file is broken as described in  section.
fixincludes does not create any modification of it, let alone fixed as
described.  Newly built gcc includes broken file when run.  This may
break just any program built with gcc, and does break compiling
`toplev.c' with `stage1/xgcc' as described in bug 28469.

Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686

Old compiler is `gcc-3.3.2-6mdk'.  System headers are
`glibc-devel-2.3.3-12.8.100mdk'.
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c

How-To-Repeat:
make bootstrap


--- Comment #1 from gin at mo dot msk dot ru  2006-08-11 14:59 ---
Fix:
Currently not known.  Obviously any fixincludes bug (even lack of
fixincludes itself) may be worked around, by doing the necessary
include file editing manually.  (This is why severity is not
critical.)  In this case the workaround is as follows.

  Fix after `compiler-gcc3.h': reverse `#ifndef __KERNEL__'.  If user
  mode code with contains seemingly identical inline function
  definitions before and after this file, type of the 2nd one becomes
  different, which breaks compilation.

--- /usr/include/linux/compiler-gcc+.h  2006/08/10 21:55:37 1.1
+++ /usr/include/linux/compiler-gcc+.h  2006/08/10 22:02:12 1.2
@@ -6,11 +6,11 @@
  */
 #include 

-#ifndef __KERNEL__
+#if defined __KERNEL__
 #define inline __inline__ __attribute__((always_inline))
 #define __inline__ __inline__ __attribute__((always_inline))
 #define __inline   __inline__ __attribute__((always_inline))
-#endif
+#endif /* defined __KERNEL__ */

 #define __deprecated   __attribute__((deprecated))
 #define __attribute_used__ __attribute__((__used__))

Hope this is enough data to patch fixincludes.  Its maintainers
certainly do not have to ask details of includes in my system from me
or other users.  All of them are in

archive.  (Anyway, will be unable to check mail until aug 21.)


-- 
   Summary: does not fix broken linux/compiler-gcc+.h
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=28700

[Bug c/28814] New: ICE when compiling Stalin under 4.1 but not 4.0

[gcc-bugzilla at gcc dot gnu dot org]

Stalin is a Scheme compiler that generates C code. Stalin is itself written in
C and can compile itself. I am preparing a new release of Stalin for Debian
Etch. This release compiles with earlier versions of gcc, such as gcc-4.0, but
not with gcc-4.1. It gives an ICE.

The preprocessed source is huge. I submitted an earlier bug report that
included the preprocessed source but apparently the email bounced. I am
resubmitting making the preprocessed source available on the web instead.
I would appreciate if someone from GCC/GNU can let me know when you have
downloaded the preprocessed source so that I can remove it from my web site.

Environment:
System: Linux chino 2.6.15-1-k7-smp #2 SMP Mon Mar 6 15:50:26 UTC 2006 i686
GNU/Linux
Architecture: i686


I am submitting this from a different machine than that which generated the
error because the latter has no email connection. Both run Debian Etch on
identical hardware.
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu

How-To-Repeat:
[EMAIL PROTECTED]>gcc -v -save-temps -o stalin -I./include -O3 
-fomit-frame-pointer
-fno-strict-aliasing -freg-struct-return stalin.c -L./include -lm -lgc
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -E -quiet -v -I./include stalin.c
-mtune=i686 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return -O3
-fpch-preprocess -o stalin.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 ./include
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed stalin.i -quiet -dumpbase
stalin.c -mtune=i686 -auxbase stalin -O3 -version -fomit-frame-pointer
-fno-strict-aliasing -freg-struct-return -o stalin.s
GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) (i486-linux-gnu)
   compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3efbb0b5b3119ec825babd3e1cecb910
stalin.c: In function ‘f9226’:
stalin.c:369354: internal compiler error: in compare_values, at tree-vrp.c:415
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccYcxZDO.out file, please attach this to
your bugreport.
395.851u 3.338s 6:39.21 99.9%  0+0k 0+0io 0pf+0w
[EMAIL PROTECTED]>gcc-4.0 -v -save-temps -o stalin -I./include -O3
-fomit-frame-pointer -fno-strict-aliasing -freg-struct-return stalin.c
-L./include -lm -lgc
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
 /usr/lib/gcc/i486-linux-gnu/4.0.4/cc1 -E -quiet -v -I./include stalin.c
-mtune=i686 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return -O3
-fpch-preprocess -o stalin.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> searc

[Bug c/29309] New: Compiling an assembler-less file generates error from assembler

[gcc-bugzilla at gcc dot gnu dot org]

I'm trying to compile svgalib (http://www.svgalib.org/) on my
FreeBSD/amd64 system.

Although the package uses assembler in a few places, this can be
disabled with the -DNO_ASSEMBLY flag. After the pre-processor
there is no assembler code in the trouble-some C-file, except
for the (unused) definitions of bswap*, which come from system
headers ().

Both, the system compiler (gcc-3.4.6) and the optional gcc41
give the same error:

{standard input}:30: Error: Incorrect register `%rax' used with `l' suffix

The line number differs depending on the compiler and the
optimization options, but the error is the same, and talks about
the same piece of the gcc-generated assembly:

[...]
#APP
outl %rax,%dx   ## <-- here
#NO_APP
leave
ret
[...]

Environment:
System: FreeBSD aldan.algebra.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sat
Sep 30 16:33:20 EDT 2006 [EMAIL PROTECTED]:/meow/obj/var/src/sys/SILVER
amd64



host: x86_64-portbld-freebsd6.1
build: x86_64-portbld-freebsd6.1
target: x86_64-portbld-freebsd6.1
configured with: ./..//gcc-4.1-20060623/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/opt --program-suffix=41
--libdir=/opt/lib/gcc/x86_64-portbld-freebsd6.1/4.1.2
--with-gxx-include-dir=/opt/lib/gcc/x86_64-portbld-freebsd6.1/4.1.2/include/c++/
--infodir=/opt/info/gcc41 --disable-libgcj --prefix=/opt
x86_64-portbld-freebsd6.1

How-To-Repeat:

# 1 "/var/ports/graphics/svgalib/work/svgalib-1.4.3/src/vgapci.c"
# 1 ""
# 1 ""
# 1 "/var/ports/graphics/svgalib/work/svgalib-1.4.3/src/vgapci.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 43 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 44 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/include/sys/_null.h" 1 3 4
# 45 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/include/sys/_types.h" 1 3 4
# 33 "/usr/include/sys/_types.h" 3 4
# 1 "/usr/include/machine/_types.h" 1 3 4
# 51 "/usr/include/machine/_types.h" 3 4
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short __int16_t;
typedef unsigned short __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long __int64_t;
typedef unsigned long __uint64_t;




typedef __int32_t __clock_t;
typedef unsigned int __cpumask_t;
typedef __int64_t __critical_t;
typedef double __double_t;
typedef double __float_t;
typedef __int64_t __intfptr_t;
typedef __int64_t __intmax_t;
typedef __int64_t __intptr_t;
typedef __int32_t __int_fast8_t;
typedef __int32_t __int_fast16_t;
typedef __int32_t __int_fast32_t;
typedef __int64_t __int_fast64_t;
typedef __int8_t __int_least8_t;
typedef __int16_t __int_least16_t;
typedef __int32_t __int_least32_t;
typedef __int64_t __int_least64_t;
typedef __int64_t __ptrdiff_t;
typedef __int64_t __register_t;
typedef __int64_t __segsz_t;
typedef __uint64_t __size_t;
typedef __int64_t __ssize_t;
typedef __int64_t __time_t;
typedef __uint64_t __uintfptr_t;
typedef __uint64_t __uintmax_t;
typedef __uint64_t __uintptr_t;
typedef __uint32_t __uint_fast8_t;
typedef __uint32_t __uint_fast16_t;
typedef __uint32_t __uint_fast32_t;
typedef __uint64_t __uint_fast64_t;
typedef __uint8_t __uint_least8_t;
typedef __uint16_t __uint_least16_t;
typedef __uint32_t __uint_least32_t;
typedef __uint64_t __uint_least64_t;
typedef __uint64_t __u_register_t;
typedef __uint64_t __vm_offset_t;
typedef __int64_t __vm_ooffset_t;
typedef __uint64_t __vm_paddr_t;
typedef __uint64_t __vm_pindex_t;
typedef __uint64_t __vm_size_t;





typedef __builtin_va_list __va_list;






typedef __va_list __gnuc_va_list;
# 34 "/usr/include/sys/_types.h" 2 3 4




typedef __uint32_t __blksize_t;
typedef __int64_t __blkcnt_t;
typedef __int32_t __clockid_t;
typedef __uint32_t __fflags_t;
typedef __uint64_t __fsblkcnt_t;
typedef __uint64_t __fsfilcnt_t;
typedef __uint32_t __gid_t;
typedef __int64_t __id_t;
typedef __uint32_t __ino_t;
typedef long __key_t;
typedef __int32_t __lwpid_t;
typedef __uint16_t __mode_t;
typedef int __nl_item;
typedef __uint16_t __nlink_t;
typedef __int64_t __off_t;
typedef __int32_t __pid_t;
typedef __int64_t __rlim_t;


typedef __uint8_t __sa_family_t;
typedef __uint32_t __socklen_t;
typedef long __suseconds_t;
typedef __int32_t __timer_t;
typedef __uint32_t __uid_t;
typedef unsigned int __useconds_t;
# 82 "/usr/include/sys/_types.h" 3 4
typedef int __ct_rune_t;
typedef __ct_rune_t __rune_t;
typedef __ct_rune_t __wchar_t;
typedef __ct_rune_t __wint_t;

typedef __uint32_t __dev_t;

typedef __uint32_t __fixpt_t;





typedef union {
 char __mbstate8[128];
 __int64_t _mbstateL;
} __mbstate_t;
# 46 "/usr/include/stdio.h" 2 3 4

typedef __off_t fpos_t;


typedef __size_t size_t;





typedef __va_list va_list;
# 70 "/usr/include/stdio.h" 3 4
struct __sbuf {
 unsigned char *_base;
 int _size;
};


struct __sFILEX;
# 102 "/usr/include/stdio.h" 3 4
typed

[Bug fortran/29321] New: optional arguments+derived types = segmentation fault

[gcc-bugzilla at gcc dot gnu dot org]

Compilation of functions/subroutines with optional derived type arguments 
gives segmentation fault. 

a.F90: In function 'func':
a.F90:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

If I remove one of the optional arguments (C in SUB)
in the sample code below it appears to work

Environment:
System: Linux olavs 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux
Architecture: i686


host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../gcc/configure
--prefix=/cosmic/coudert/tmp/gfortran-20060906/irun
--enable-languages=c,fortran --host=i386-linux
--with-gmp=/cosmic/coudert/tmp/gfortran-20060906/gfortran_libs

How-To-Repeat:

MODULE MYINT
   TYPE NUM
  INTEGER :: R = 0
   END TYPE NUM
   CONTAINS 
  FUNCTION FUNC(A,B) RESULT(E)
  IMPLICIT NONE
  TYPE(NUM)  A,B,E
  INTENT(IN) ::  A,B
  OPTIONAL B
  E%R=A%R
  CALL SUB(A,E)
  END FUNCTION FUNC

  SUBROUTINE SUB(A,E,B,C)
  IMPLICIT NONE
  TYPE(NUM) A,E,B,C
  INTENT(IN)   A,B
  INTENT(OUT)  E,C
  OPTIONAL B,C
  E%R=A%R
  END SUBROUTINE SUB
END MODULE MYINT


-- 
   Summary: optional arguments+derived types = segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vahtras at pdc dot kth dot se
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


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

[Bug c++/31289] New: gcc412 elides code in operator delete() override method

[gcc-bugzilla at gcc dot gnu dot org]

// BUG DEMO for gcc 4.1.2 (and 4.1.1) for 32-bit x86
//
// If operator delete() is over-ridden in a base class, then
// if the implementation of delete() stores into the storage used
// by the object, the store seems to be removed by the compiler
// (maybe because the compiler thinks stores to a deleted object 
// are dead code?  Or may be the casts of void * cause trouble
// with the C99 aliasing rules??)
//
//   Only occurs with g++ -O3
//   Occurs using native gcc on 32-bit x86.  
//   Does NOT occur with 64-bit x86.
//   Does NOT occur with gcc 3.2.3
//
// The following program is a skeletal memory manager which maintains
// a separate free-list for each size object.  Deleted objects are
// kept in a singly-linked list.  operator delete() casts the void *
// pointer to be a pointer to an internal struct in order to store
// a "next" pointer in the first word of the storage block.   The
// store through this cast pointer seems to be lost.
//
// TO DEMO THE PROBLEM:
//g++ -O3 thisfile.cpp && ./a.out
//(prints "ERROR" and then segfaults if the bug is there)
//
// -Jim Avera ([EMAIL PROTECTED])
// Please copy [EMAIL PROTECTED] [EMAIL PROTECTED] on all correspondence
//
#include 
#include 

const size_t MaxSize = 100;
class MyHeap {
public:
  MyHeap();
  ~MyHeap() {}
  void * Malloc(const size_t bytes_needed);
  void   Free(void * ptr_to_free, size_t how_big_it_is);
  void   Dump(void);

  struct Node {
Node *next;
  };
private:
  Node *Heads[MaxSize];
};

MyHeap::MyHeap() {
  printf("MyHeap constructed\n");
  for (int i=0; i < MaxSize; ++i) {
Heads[i] = 0;
  }
}
void MyHeap::Dump(void)
{
  printf("Dump of free-list data:\n");
  int num_empties = 0;
  for (int i=0; i < MaxSize; ++i) {
if (Heads[i] == 0) {
  ++num_empties;
} else {
  printf("  Heads[%d] = %p\n", i, Heads[i]);
  Node * next_node = Heads[i]->next;
  if (next_node != 0) {
// For this test program, there should be exactly one item
printf("  ERROR: Expecting only one free item on list\n");
while (next_node != 0) {
  printf("next = %p\n", next_node);
  next_node = next_node->next;
}
exit(1); // usually segfaults before getting here
  }
}
  }
  printf("(%d lists are empty)\n", num_empties);
}
void * MyHeap::Malloc(const size_t bytes_needed) 
{
  if (bytes_needed < sizeof(Node) || bytes_needed > MaxSize) {
printf("MyHeap::Malloc - object too small or too large\n");
exit(1);
  }
  if (Heads[bytes_needed] == 0) {
// Pre-charge the free list with more storage
// (just one object for this test)
Node * newnode = static_cast( malloc(bytes_needed) );
newnode->next = 0;
Heads[bytes_needed] = newnode;
  }
  // Detach the first from the list
  Node * node = Heads[bytes_needed];
  Heads[bytes_needed] = node->next;
  return node;
}
void MyHeap::Free(void * ptr_to_free, size_t how_big_it_is)
{
  // Put object on the free list
  Node * node = static_cast(ptr_to_free);
  node->next = Heads[how_big_it_is];
  Heads[how_big_it_is] = node;
}


// The memory-manager object
MyHeap my_pool;

class base {
public:
  void * operator new(size_t bytes_needed)
  {
void * raw_mem = my_pool.Malloc(bytes_needed);
return(raw_mem);
  }

  void operator delete(void * ptr_to_free,  size_t how_big_it_is) 
  {
my_pool.Free(ptr_to_free, how_big_it_is);
  }
};

class middle : public base {
public:
  virtual ~middle() { }
};

class derived : public middle {
public:
  derived() {
i = ;
j = ;
k = ;
  }
  virtual ~derived() {
  }
  int i,j,k;
};

int main() {
  setbuf(stdout,NULL); setbuf(stderr,NULL); // disable buffering
  my_pool.Dump();

  printf("new...\n");
  derived *d = new derived;

  printf("Got %p, sizeof=%u, raw dump follows:\n", d, (unsigned)sizeof(*d));
  unsigned * up = reinterpret_cast(d);
  const size_t size_in_unsigneds = sizeof(*d)/sizeof(unsigned);
  for (int ix=0; ix < size_in_unsigneds; ++ix) {
printf("  0x%08x = %d\n", up[ix], up[ix]);
  }
  my_pool.Dump();

  printf("delete...\n");
  delete d;

  my_pool.Dump();

  printf("The bug was not detected\n");
  return 0;
}

Environment:
System: Linux xba24 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686
i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with:
/grid/sfi/ct_src/gcc-v4.1.2/platforms/linux86/matrix_bootstrap_000/gcc-4.1.2/configure
--prefix=/grid/common/pkgs/gcc/v4.1.2 --mandir=/grid/common/pkgs/gcc/v4.1.2/man
--infodir=/grid/common/pkgs/gcc/v4.1.2/info --enable-shared
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --with-gnu-as
--with-as=/grid/common/pkgs/binutils/v2.17/bin/as --with-gnu-ld
--with-ld=/grid/common/pkgs/binutils/v2.17/bin/ld --disable-libgcj
--with-local-prefix=/grid/common/pkgs/gcc/v4.1.2 --enable-clocale=gnu
--with-gmp=/grid/common/pkgs/gmp/v4.1.4 --enable-languages=c,c++,objc,fortran

How-T

[Bug target/31486] New: ICE with vector code when -mno-sse2 on amd64

[gcc-bugzilla at gcc dot gnu dot org]

Compilation of the attached code yields an ICE in certain cases.

Environment:
System: Linux chii 2.6.20 #3 SMP Sun Feb 11 23:52:47 EET 2007 x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu

How-To-Repeat:
Compile this code:
typedef double ss2 __attribute__((vector_size(2*sizeof(double;
ss2 b = {1,1};
extern ss2 a2(ss2 a,ss2 b);
void test2() { b = a2(b,b); }
With these commandline options:
gcc-4.1 -mno-sse2 -S -o- test3.c
The output comes as follows:
.file   "test3.c"
.globl b
.data
.align 16
.type   b, @object
.size   b, 16
b:
.long   0
.long   1072693248
.long   0
.long   1072693248
test3.c: In function 'test2':
test3.c:6: internal compiler error: in emit_move_insn, at expr.c:3162
Please submit a full bug report,
with preprocessed source if appropriate.
(rest of output omitted for brevity)
It does not occur if "double" is changed to "float", "long double", "short",
"int" or "char".
It does occur if "double", "long int" or "long long int" is used.
It does not occur if 2 is changed to 4.

Architecture:
CPU=AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
CPU features=fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
pni lahf_lm cmp_legacy

GCC is:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


-- 
   Summary: ICE with vector code when -mno-sse2 on amd64
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at bisqwit dot iki dot fi
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/31652] New: postfix increment semantics implemented incorrectly

[gcc-bugzilla at gcc dot gnu dot org]

g++ parses the code correctly and calls the correct overloaded
increment operators, but in the wrong postfix order.  The semantics of
postfix are to take the rvalue before invoking the method.  Note this
is not related to multiple reference ordering between sequence points
as the object is only referenced once.  Although I have not checked
postfix decrement, it may have the same semantic problem and it is
trivial to adapt the supplied code.

Environment:
System: Linux dbox 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu

How-To-Repeat:
cat > a.cpp
#include 

class C
{
public:
  int v;

  C( int v ) : v( v ) {}

  C & operator++( void ) { v++;  return *this; }
  C & operator++( int )  { v += 100; return *this; }
};

main()
{
  C a( 0 );
  C b( 0 );

  std::cout << "a:" << a.v << std::endl;  // 0
  std::cout << "b:" << b.v << std::endl;  // 0

  b = ++a;

  std::cout << "a:" << a.v << std::endl;  // 1
  std::cout << "b:" << b.v << std::endl;  // 1

  b = a++;

  std::cout << "a:" << a.v << std::endl;  // 101
  std::cout << "b:" << b.v << std::endl;  // should be 1, not 101!
}
^D
> g++ a.cpp ; ./a.out
a:0
b:0
a:1
b:1
a:101
b:101


--- Comment #1 from hayward at loup dot net  2007-04-21 23:39 ---
Fix:
Execute postfix methods *after* evaluating the expression they are in.


-- 
   Summary: postfix increment semantics implemented incorrectly
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hayward at loup dot net
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug libfortran/32977] New: [4.3 regression] All gfortran tests fail on Tru64 UNIX V4.0F: vsnprintf missing

[gcc-bugzilla at gcc dot gnu dot org]

As of 20070730, all gfortran tests fail on alpha-dec-osf4.0f:

25729:./PR19754_2.exe: /sbin/loader: Error: Unresolved symbol in
/amnt/sequoia/export/vol/gcc/obj/alpha/gcc-4.3.0-20070730/4.0f-gcc/alpha-dec-osf4.0f/./libgfortran/.libs/libgfortran.so.3:
vsnprintf
25729:./PR19754_2.exe: /sbin/loader: Fatal Error: this executable has
unresolvable symbols
FAIL: gfortran.dg/PR19754_2.f90  -O0  execution test

This was introduced by

2007-07-29  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/32858
PR libfortran/30814
[...]
* io/unix.c (init_error_stream):  Remove.
(tempfile):  Replace st_sprintf by sprintf.
(st_vprintf):  New function.
(st_printf):  Rewrite to call st_vprintf.

Even though HAVE_VSNPRINTF is undefined, __builtin_vsnprintf expands to
vsnprintf.

Environment:
System: OSF1 hindemith V4.0 1229 alpha
Machine: alpha

host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build
alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap and test as described above.


-- 
   Summary: [4.3 regression] All gfortran tests fail on Tru64 UNIX
V4.0F: vsnprintf missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug c/33024] New: gcc allows negatively-sized arrays

[gcc-bugzilla at gcc dot gnu dot org]

By using an integer variable as the size of an array to be 
initialized on the stack, you can trick gcc into accepting
and trying to create a negatively-sized array.  The assembly
it generates in such a case seems to indicate it really thinks
it has a negatively-sized array.

Environment:
System: Linux pc1 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686
GNU/Linux
Architecture: i686

host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu

How-To-Repeat:
#include 

int main(int argc, char **argv) {
int x = -2;
int y[x];

printf("%d\n", sizeof(y));
}

This will output -8.


--- Comment #1 from sdyoung at miranda dot org  2007-08-08 16:47 ---
Fix:
I don't know.


-- 
   Summary: gcc allows negatively-sized arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sdyoung at miranda dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug bootstrap/33306] New: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B: ICE in convert_move, at expr.c:369

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping current mainline as of 20070903 fails on alpha-dec-osf5.1b
building the stage 1 libgcc:

/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include -g -fkeep-inline-functions -O2  -O2 -g
-O2   -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -pthread -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I/vol/gcc/src/gcc-dist/libgcc -I/vol/gcc/src/gcc-dist/libgcc/.
-I/vol/gcc/src/gcc-dist/libgcc/../gcc -I/vol/gcc/src/gcc-dist/libgcc/../include
 -DHAVE_CC_TLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep
-DL_powitf2 -c /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c \

/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__powitf2':
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:1742: internal compiler error: in
convert_move, at expr.c:369

The same problem happens at -O, while -O0 is ok.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B:
ICE in convert_move, at expr.c:369
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug c++/33468] New: C++: Invalid interpretation of friendness with nested classes

[gcc-bugzilla at gcc dot gnu dot org]

Gcc's friend-mechanism seems to expand to nested classes as well, although
the C++ standard explicitly tells differently.

The following example is almost straight from the C++ standard (11.4/2). The
only change is that inheritance is commented out for class X (in order to
remove the first error in the example). Gcc compiles this with no error
messages, even with -Wall -pedantic

// test.cc
class A {
  class B { };
  friend class X;
};

// INHERITANCE BELOW COMMENTED OUT BY ME
class X /* : A::B */ { // ill-formed: A::B cannot be accessed
  // in the base-clause for X
  A::B mx; // OK: A::B used to declare member of X
  class Y : A::B { // OK: A::B used to declare member of X
// !!! The illegal line below compiles fine !!
A::B my; // ill-formed: A::B cannot be accessed
// to declare members of nested class of X
  };
};

Environment:
System: Linux mustikkakukko 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC
2007 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-suse-linux-gnu
build: x86_64-suse-linux-gnu
target: x86_64-suse-linux-gnu
configured with: ../gcc-4.2.1/configure --prefix=/usr/local/gcc-4.2.1
--bindir=/usr/local/gcc-4.2.1/bin64 --enable-languages=c,c++
--enable-__cxa_atexit --host=x86_64-suse-linux --with-arch=nocona
--with-tune=nocona

How-To-Repeat:
  g++ -W -Wall -pedantic -c test.cc
  (No errors result in compilation.)


-- 
   Summary: C++: Invalid interpretation of friendness with nested
classes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bitti at iki dot fi
 GCC build triplet: x86_64-suse-linux-gnu
  GCC host triplet: x86_64-suse-linux-gnu
GCC target triplet: x86_64-suse-linux-gnu


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

[Bug c/33519] New: Invalid code generated with a combination of thumb, AAPCS and -Os.

[gcc-bugzilla at gcc dot gnu dot org]

GCC generates odd code sequence..

Part of the source (full source in attachment):

usbd_status
usbd_do_request_flags_pipe(usbd_device_handle dev, usbd_pipe_handle pipe,
usb_device_request_t *req, void *data, u_int16_t flags, int *actlen,
u_int32_t timeout)
{
usbd_xfer_handle xfer;
usbd_status err;

xfer = usbd_alloc_xfer(dev);
...


objdump output:

 :
   0:   b5f0push{r4, r5, r6, r7, lr}
   2:   b089sub sp, #36
   4:   1c14addsr4, r2, #0
   6:   9a0fldr r2, [sp, #60]
   8:   1c1eaddsr6, r3, #0
   a:   605astr r2, [r3, #4]<-- writes using r3 (data)
   c:   9b10ldr r3, [sp, #64]
   e:   9007str r0, [sp, #28]
  10:   609bstr r3, [r3, #8]
  12:   ab0eadd r3, sp, #56
  14:   9106str r1, [sp, #24]
  16:   881fldrhr7, [r3, #0]
  18:   f7ff fffe   bl  0 


And here's objdump output when compiled with the same options but gcc 4.2.1:

 :
   0:   b5f0push{r4, r5, r6, r7, lr}
   2:   b089sub sp, #36
   4:   1c1eaddsr6, r3, #0
   6:   ab0eadd r3, sp, #56
   8:   9007str r0, [sp, #28]
   a:   9106str r1, [sp, #24]
   c:   1c14addsr4, r2, #0
   e:   881fldrhr7, [r3, #0]
  10:   f7ff fffe   bl  0 

Environment:
System: Linux kivi 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: arm-unknown-elf
configured with: /s/devel/gcc-4.1.1/configure --target=arm-elf --with-gnu-as
--with-gcc --with-gnu-ld --enable-languages=c --disable-libstdc
--disable-hosted-libstdcxx --disable-libstdcxx --disable-libstdcxx-v3
--disable-libstdcxx_v3 --disable-nls --disable-shared --disable-threads
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch
--prefix=/emb/arm-elf-gcc-4.1.1 --program-prefix=arm-elf- --program-suffix=
--with-newlib -v --without-headers -v

How-To-Repeat:
Compile the test case like:
# arm-elf-gcc -Os -Wall -Werror -mcpu=arm920t -mlittle-endian -mthumb
-mabi=aapcs -c usbdi.c -o usbdi.o


--- Comment #1 from sami dot kantoluoto at embedtronics dot fi  2007-09-21 
16:29 ---
Fix:
Work arounds: gcc 4.2.1, optimize for speed instead of size.


-- 
   Summary: Invalid code generated with a combination of thumb,
AAPCS and -Os.
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sami dot kantoluoto at embedtronics dot fi
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf


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

[Bug c/19988] New: [4.0 Regression] pessimizes fp multiply-add/subtract combo

[gcc-bugzilla at gcc dot gnu dot org]

When I compile the following code with 'gcc -O3 --save-temps -c':

double foo(double x, double y)
{
 return ((x + 0.1234 * y) * (x - 0.1234 * y));
}

gcc 3.x gives one load of the constant 0.1234, one multiplication
0.1234 * y, one addition, one subtraction, and the final
multiplication: total = one constant (load) and four fp operations.

gcc 4.0 (20050213 snapshot), on the other hand, compiles (x - 0.1234 *
y) as (x + (-0.1234) * y), and thus doesn't recognize that it is the
same constant as in the other expression.  Thus, it produces *two*
constants (2 loads), and *five* fp operations (3 multiplications):

foo:
pushl   %ebp
movl%esp, %ebp
fldl16(%ebp)
fld %st(0)
fldl8(%ebp)
fxch%st(1)
fmull   .LC0
fxch%st(2)
popl%ebp
fmull   .LC1
fxch%st(2)
fadd%st(1), %st
fxch%st(1)
faddp   %st, %st(2)
fmulp   %st, %st(1)
ret

As you can imagine, this leads to a major slowdown in code that has
lots of multiply-add and multiply-subtract combinations...in
particular any FFT (such as our FFTW, www.fftw.org) could
suffer a lot.

Thanks for your efforts,
Steven G Johnson

PS. When you fix this, please don't re-introduce another optimizer bug
that appears in gcc 3.x.  In particular, when compiling for a PowerPC
target, it *should* produce one constant load, one fused multiply-add,
one fused-multiply subtract, and one multiplication.  gcc 3.x, on the
other hand, pulls out the (0.1234 * y) in CSE, and thus does not
exploit the fma.  gcc 4.0 on PowerPC (MacOS 10.3) produces:

_foo:
mflr r0
bcl 20,31,"L001$pb"
"L001$pb":
stw r31,-4(r1)
fmr f13,f1
mflr r31
stw r0,8(r1)
lwz r0,8(r1)
addis r2,r31,ha16(LC0-"L001$pb")
lfd f1,lo16(LC0-"L001$pb")(r2)
addis r2,r31,ha16(LC1-"L001$pb")
lfd f0,lo16(LC1-"L001$pb")(r2)
Cordially,mtlr r0
fmadd f1,f2,f1,f13
lwz r31,-4(r1)
fmadd f2,f2,f0,f13
fmul f1,f1,f2
blr

which utilizes the fma, but loads the constant twice (as 0.1234 and
-0.1234) instead of using fmadd and fmsub.

PPS. In general, turning negative constants into positive constants by
changing additions into subtractions can lead to substantial speedups
by reducing the number of fp constants in certain kinds of code.
e.g. "manually" doing this in FFTW gained us 10-15% in speed; YMMV.
Something to think about.

Environment:
System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686 
GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/home/stevenj/gcc4

How-To-Repeat:
Compile above foo() subroutine with gcc -O3 -c --save-temps and look
at assembler output.

-- 
   Summary: [4.0 Regression] pessimizes fp multiply-add/subtract
combo
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenj at fftw dot org
CC: gcc-bugs at gcc dot gnu dot org
 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=19988

[Bug other/20055] New: Many source files are unnecessarily executable

[gcc-bugzilla at gcc dot gnu dot org]

I just noticed that many source files are unnecessarily marked executable.
This needs to be fixed by someone with direct access to the CVS repository.

The list below is pruned of anything which obviously needs to be executable,,
like configure scripts etc.

boehm-gc/AmigaOS.c
boehm-gc/cord/de_win.ICO
boehm-gc/digimars.mak
boehm-gc/doc/README.arm.cross
gcc/ada/a-chzla1.ads
gcc/ada/a-chzla9.ads
gcc/ada/a-elchha.ads
gcc/ada/a-lfztio.ads
gcc/ada/a-liztio.ads
gcc/ada/a-llfzti.ads
gcc/ada/a-llizti.ads
gcc/ada/a-sfztio.ads
gcc/ada/a-siztio.ads
gcc/ada/a-ssizti.ads
gcc/ada/a-stzbou.adb
gcc/ada/a-stzbou.ads
gcc/ada/a-stzfix.adb
gcc/ada/a-stzfix.ads
gcc/ada/a-stzhas.adb
gcc/ada/a-stzhas.ads
gcc/ada/a-stzmap.adb
gcc/ada/a-stzmap.ads
gcc/ada/a-stzsea.adb
gcc/ada/a-stzsea.ads
gcc/ada/a-stzsup.adb
gcc/ada/a-stzsup.ads
gcc/ada/a-stzunb.adb
gcc/ada/a-stzunb.ads
gcc/ada/a-swunau.adb
gcc/ada/a-swunau.ads
gcc/ada/a-szmzco.ads
gcc/ada/a-szunau.adb
gcc/ada/a-szunau.ads
gcc/ada/a-szunha.adb
gcc/ada/a-szunha.ads
gcc/ada/a-szuzti.adb
gcc/ada/a-szuzti.ads
gcc/ada/a-tiunio.ads
gcc/ada/a-wwunio.ads
gcc/ada/a-ztcoau.adb
gcc/ada/a-ztcoau.ads
gcc/ada/a-ztcoio.adb
gcc/ada/a-ztcoio.ads
gcc/ada/a-ztcstr.adb
gcc/ada/a-ztcstr.ads
gcc/ada/a-ztdeau.adb
gcc/ada/a-ztdeau.ads
gcc/ada/a-ztdeio.adb
gcc/ada/a-ztdeio.ads
gcc/ada/a-ztedit.adb
gcc/ada/a-ztedit.ads
gcc/ada/a-ztenau.adb
gcc/ada/a-ztenau.ads
gcc/ada/a-ztenio.adb
gcc/ada/a-ztenio.ads
gcc/ada/a-ztexio.adb
gcc/ada/a-ztexio.ads
gcc/ada/a-ztfiio.adb
gcc/ada/a-ztfiio.ads
gcc/ada/a-ztflau.adb
gcc/ada/a-ztflau.ads
gcc/ada/a-ztflio.adb
gcc/ada/a-ztflio.ads
gcc/ada/a-ztgeau.adb
gcc/ada/a-ztgeau.ads
gcc/ada/a-ztinau.adb
gcc/ada/a-ztinau.ads
gcc/ada/a-ztinio.adb
gcc/ada/a-ztinio.ads
gcc/ada/a-ztmoau.adb
gcc/ada/a-ztmoau.ads
gcc/ada/a-ztmoio.adb
gcc/ada/a-ztmoio.ads
gcc/ada/a-zttest.adb
gcc/ada/a-zttest.ads
gcc/ada/a-zzunio.ads
gcc/ada/g-memdum.adb
gcc/ada/g-memdum.ads
gcc/ada/g-sestin.ads
gcc/ada/g-utf_32.adb
gcc/ada/g-utf_32.ads
gcc/ada/g-zstspl.ads
gcc/ada/i-vxwork-x86.ads
gcc/ada/s-addope.adb
gcc/ada/s-addope.ads
gcc/ada/s-exnint.adb
gcc/ada/s-exnllf.adb
gcc/ada/s-exnlli.adb
gcc/ada/s-expint.adb
gcc/ada/s-explli.adb
gcc/ada/s-restri.adb
gcc/ada/s-restri.ads
gcc/ada/seh_init.c
gcc/config/i386/host-mingw32.c
gcc/testsuite/g++.dg/ext/dll-MI1.h
gcc/testsuite/g++.dg/ext/dllexport-MI1.C
gcc/testsuite/g++.dg/ext/dllexport1.C
gcc/testsuite/g++.dg/ext/dllimport-MI1.C
gcc/testsuite/g++.dg/ext/dllimport10.C
gcc/testsuite/g++.dg/ext/dllimport3.C
gcc/testsuite/g++.dg/ext/dllimport4.C
gcc/testsuite/g++.dg/ext/dllimport5.C
gcc/testsuite/g++.dg/ext/dllimport6.C
gcc/testsuite/g++.dg/ext/dllimport7.C
gcc/testsuite/g++.dg/ext/dllimport9.C
gcc/testsuite/g++.dg/template/array11.C
gcc/testsuite/g++.dg/template/array3.C
gcc/testsuite/g++.dg/template/friend33.C
gcc/testsuite/g++.dg/template/partial3.C
gcc/testsuite/g++.dg/template/spec15.C
gcc/testsuite/g++.dg/template/spec16.C
gcc/testsuite/g++.dg/template/ttp7.C
gcc/testsuite/gcc.c-torture/execute/20031012-1.c
gcc/testsuite/gcc.c-torture/execute/970923-1.c
gcc/testsuite/gcc.dg/dll-5.c
gcc/testsuite/gcc.dg/vect/pr16105.c
gcc/testsuite/gcc.dg/vect/pr18400.c
gcc/testsuite/gcc.dg/vect/tree-vect.h
gcc/testsuite/gcc.dg/vect/vect-1.c
gcc/testsuite/gcc.dg/vect/vect-10.c
gcc/testsuite/gcc.dg/vect/vect-11.c
gcc/testsuite/gcc.dg/vect/vect-12.c
gcc/testsuite/gcc.dg/vect/vect-13.c
gcc/testsuite/gcc.dg/vect/vect-14.c
gcc/testsuite/gcc.dg/vect/vect-15.c
gcc/testsuite/gcc.dg/vect/vect-16.c
gcc/testsuite/gcc.dg/vect/vect-17.c
gcc/testsuite/gcc.dg/vect/vect-18.c
gcc/testsuite/gcc.dg/vect/vect-19.c
gcc/testsuite/gcc.dg/vect/vect-2.c
gcc/testsuite/gcc.dg/vect/vect-20.c
gcc/testsuite/gcc.dg/vect/vect-21.c
gcc/testsuite/gcc.dg/vect/vect-22.c
gcc/testsuite/gcc.dg/vect/vect-23.c
gcc/testsuite/gcc.dg/vect/vect-24.c
gcc/testsuite/gcc.dg/vect/vect-25.c
gcc/testsuite/gcc.dg/vect/vect-26.c
gcc/testsuite/gcc.dg/vect/vect-27.c
gcc/testsuite/gcc.dg/vect/vect-28.c
gcc/testsuite/gcc.dg/vect/vect-29.c
gcc/testsuite/gcc.dg/vect/vect-3.c
gcc/testsuite/gcc.dg/vect/vect-30.c
gcc/testsuite/gcc.dg/vect/vect-31.c
gcc/testsuite/gcc.dg/vect/vect-32.c
gcc/testsuite/gcc.dg/vect/vect-33.c
gcc/testsuite/gcc.dg/vect/vect-34.c
gcc/testsuite/gcc.dg/vect/vect-36.c
gcc/testsuite/gcc.dg/vect/vect-4.c
gcc/testsuite/gcc.dg/vect/vect-40.c
gcc/testsuite/gcc.dg/vect/vect-41.c
gcc/testsuite/gcc.dg/vect/vect-42.c
gcc/testsuite/gcc.dg/vect/vect-43.c
gcc/testsuite/gcc.dg/vect/vect-44.c
gcc/testsuite/gcc.dg/vect/vect-45.c
gcc/testsuite/gcc.dg/vect/vect-46.c
gcc/testsuite/gcc.dg/vect/vect-47.c
gcc/testsuite/gcc.dg/vect/vect-48.c
gcc/testsuite/gcc.dg/vect/vect-49.c
gcc/testsuite/gcc.dg/vect/vect-5.c
gcc/testsuite/gcc.dg/vect/vect-50.c
gcc/testsuite/gcc.dg/vect/vect-51.c
gcc/testsuite/gcc.dg/vect/vect-52.c
gcc/testsuite/gcc.dg/vect/vect-53.c
gcc/testsuite/gcc.dg/vect/vect-54.c
gcc/testsuite/gcc.dg/vect/vect-55.c
gcc/testsuite/gcc.dg/vect/vect-56.c
gcc/testsuite/gcc.dg/vect/vect-57.c
gcc/testsuite/gcc.dg/vect/vect-58.c
gcc/testsuite

[Bug c++/20062] New: hash_map leak memory

[gcc-bugzilla at gcc dot gnu dot org]

hash_map implementation of g++ extensions of STL leaks memory

Environment:
System: Linux rose 2.6.8-2004 #2 SMP Wed Nov 24 11:15:13 CET 2004 i686 
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib 
--enable-nls --without-included-gettext --enable-__cxa_atexit 
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm 
--enable-java-awt=xlib --enable-objc-gc i486-linux

How-To-Repeat:
Compile the code, rerun command, I included in the description
--- Additional Comments From arturas at inf dot unibz dot it  2005-02-18 
18:10 ---
Fix:
I have no idea.

-- 
   Summary: hash_map leak memory
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arturas at inf dot unibz dot it
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug fortran/20178] New: COMPLEX function returns incompatible with g77

[gcc-bugzilla at gcc dot gnu dot org]

A function returning a COMPLEX value cannot be compiled in g77 and
called from gfortran (or vice versa) - doing so results in a segfault
or incorrect results.  (See test case below.)

This is a problem, since for the near future g77 and gfortran are
likely to coexist on many systems, and incompatible calling
conventions for F77 code means that libraries like the BLAS will have
to be provided in two flavors (g77 and gfortran) on the same system, a
major headache for users (not to mention distributors).

Note that COMPLEX argument passing seems to be okay (the below test
case works fine if it is switched from a function into a subroutine).

Environment:
System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686 
GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/home/stevenj/gcc4 
--enable-languages=c,f95

How-To-Repeat:
Create two files, arg1.f and arg1tst.f, consisting of:

arg1.f:
  complex function arg1(x, y)
  complex x, y
  arg1 = x + y
  return
  end

arg1tst.f:
  program arg1tst
  complex x,y,z, arg1
  x = cmplx(1.,2.)
  y = cmplx(3.,4.)
  z = arg1(x,y)
  write(*,*) z
  end

Compile arg1.f with g77 (I'm using version 3.3.5):

g77 -c arg1.f

Compile arg1tst.f with gfortran, and link with arg1.o from above:

gfortran arg1tst.f arg1.o -o arg1tst

Run ./arg1tst, and the result on my system is:

Segmentation fault

Expected output is: (  4.00,  6.00)

-- 
   Summary: COMPLEX function returns incompatible with g77
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenj at fftw dot org
CC: gcc-bugs at gcc dot gnu dot org
 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=20178

[Bug fortran/20179] New: cannot mix C and Fortran I/O

[gcc-bugzilla at gcc dot gnu dot org]

When calling a C library from a gfortran-compiled program, C stdio is only
partially written.

Ability to mix languages as needed is really important in many practical
applications these days, so this would be nice to fix.  I suspect that
there is simply a missing fflush (or similar) somewhere, since the
problem appears when you have a printf with a missing newline (as in the
test case below) or when doing character-based (putc) I/O.

Environment:
System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686 
GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/home/stevenj/gcc4 
--enable-languages=c,f95

How-To-Repeat:
Create two files, cio.c and ciotst.f, to be compiled in gcc and gfortran:

cio.c:
   #include 
   void cio_(void){
 printf("foo\n");
 printf("bar\n");
 printf("baz");
   }

ciotst.f:
  program ciotst
  call cio
  end

Compile:
gcc -c cio.c
gfortran ciotst.f cio.o -o ciotst

Run:
./ciotst

Output:
foo
bar

Expected output (e.g. what I get with g77):
foo
bar
baz

(Note that last line is missing a newline.)

-- 
   Summary: cannot mix C and Fortran I/O
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenj at fftw dot org
CC: gcc-bugs at gcc dot gnu dot org
 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=20179

[Bug target/20263] New: Incorrect asm for global register vars on sparc64

[gcc-bugzilla at gcc dot gnu dot org]

Using a global variable tied to register g7 generates invalid assembly
code on sparc64.

Consider:

register void *tp __asm__("%g7");

void set_tp() {
tp = 0;
}

Compiling this file produces an error and a warning from the assembler:

/usr/ccs/bin/as: "/var/tmp//ccLsIpQg.s", line 2: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccLsIpQg.s", line 10: warning: detect global 
register use not covered .register pseudo-op

Environment:
System: SunOS plg2.math 5.8 Generic_117350-18 sun4u sparc SUNW,Sun-Fire-880
Architecture: sun4
host: sparc64-sun-solaris2.8
build: sparc64-sun-solaris2.8
target: sparc64-sun-solaris2.8
configured with: ../gcc/configure --prefix=/u/rcbilson/software/gcc 
--enable-languages=c,c++ sparc64-sun-solaris2.8

How-To-Repeat:
Attempt to compile the above program fragment.
--- Additional Comments From rcbilson at plg dot uwaterloo dot ca  
2005-03-01 16:45 ---
Fix:
Examining the -S output shows that the .register op generated by the
compiler is

.register   %g7, %g7

The second operand seems to be incorrect -- it ought to be a plain
name, not a register name.  Replacing this op with

.register   %g7, g7

allows the code to assemble, eliminating both the error and the
warning.

I don't know enough about .register to be confident in suggesting an
appropriate identifier to use for the second operand.

-- 
   Summary: Incorrect asm for global register vars on sparc64
   Product: gcc
   Version: 1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rcbilson at plg dot uwaterloo dot ca
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc64-sun-solaris2.8
  GCC host triplet: sparc64-sun-solaris2.8
GCC target triplet: sparc64-sun-solaris2.8


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

[Bug debug/20268] New: g++ generates incomplete debug information for given testcase

[gcc-bugzilla at gcc dot gnu dot org]

It appears that g++ is generating incorrect scope debug information
for inlined functions.  One symptom of this is that addr2line will
generate inconsistent results for the affected address ranges, showing
the correct line information for the inlined function, but showing the
function name as the most outer scope that contains the inlined
function.

For example, it may show a line number in a C++ header file and give
the function name as "main".

Environment:
System: Linux toadfish.ninemoons.com 2.6.9-1.681_FC3.stk16 #1 Mon Nov 22 
16:44:32 EST 2004 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /src/sourceware/gcc/gcc/configure -v 
--prefix=/opt/local/sourceware --enable-languages=c,c++

How-To-Repeat:

Compile and link this code:

  #include 

  using namespace std;

  int main ()
  {
vector V(10);
V[10] = 1;
  }

using a command like:

  g++ -ggdb -O2 --save-temps -o t t.cc

Below is an annotated copy of the disassembly of main().

First I removed all the instruction pattern fields since they just
clutter stuff up for our purposes.  Having the instruction name and
args is sufficient to see what the code is doing.

Next I ran addr2line on every address, collected the output function
name and line number info, and inserted that as columns 2 and 3 (after
the instruction address and before the instruction name).

Next I examined the dwarf output and looked for the most outer scopes
of the inlined functions.  I.E. if DW_TAG_subprogram is scope '<1>'
then I looked for the inlined subroutines at scope '<2>' and inserted
lines in the disassembly at the beginning (beg) and ending (end) of
each scope.  This shows the coverage of the function code for inlined
functions.  Code outside these scopes SHOULD belong only to code in
main() itself.

If you look at the function names emitted by addr2line (the second
column) you will note that it associates any code outside the scope of
the beg...end regions as belonging to main.  All of these SHOULD have
filenames from the line number info of "t.cc".  However some of these
ranges identified as code belonging to main are actually code from
inlined functions in the C++ headers, thus there must be some missing
DW_TAG_inlined_subroutine DIES for these sections.  For example:

  0x804896b  main  mt_allocator.h:450  call  80486c4 <[EMAIL PROTECTED]>

where the code at line 450 in mt_allocator.h is:

  static pool_type&
  _S_get_pool()
  {
450->static pool_type _S_pool;
 return _S_pool;
  }



08048880 :

beg <1><39c1>: Abbrev Number: 111 (DW_TAG_subprogram)

0x8048880   maint.cc:5  push   %ebp
0x8048881   maint.cc:5  mov%esp,%ebp
0x8048883   maint.cc:5  push   %ebx
0x8048884   maint.cc:5  sub$0x34,%esp
0x8048887   maint.cc:5  and$0xfff0,%esp
0x804888a   maint.cc:5  sub$0x10,%esp

beg <2><39e7>: Abbrev Number: 92 (DW_TAG_inlined_subroutine): vector

0x804888d   _S_get_pool mt_allocator.h:450  cmpb   $0x0,0x804a768
0x8048894   _S_get_pool mt_allocator.h:450  je 8048964 

0x804889a   _M_allocate stl_vector.h:117xor%eax,%eax
0x804889c   _M_allocate stl_vector.h:117lea
0xffe8(%ebp),%ebx
0x804889f   _M_allocate stl_vector.h:117mov%eax,0x8(%esp)
0x80488a3   _M_allocate stl_vector.h:117mov$0xa,%eax
0x80488a8   _Vector_implstl_vector.h:85 movl   
$0x0,0xffe8(%ebp)
0x80488af   _Vector_implstl_vector.h:85 movl   
$0x0,0xffec(%ebp)
0x80488b6   _Vector_implstl_vector.h:85 movl   
$0x0,0xfff0(%ebp)
0x80488bd   _Vector_basestl_vector.h:117mov%eax,0x4(%esp)
0x80488c1   _Vector_basestl_vector.h:117mov%ebx,(%esp)
0x80488c4   _Vector_basestl_vector.h:117call   8049140 
<__gnu_cxx::__mt_alloc >::allocate(unsigned int, void const*)>
0x80488c9   _S_get_pool mt_allocator.h:450  cmpb   $0x0,0x804a768
0x80488d0   vector  stl_vector.h:103mov
%eax,0xffe8(%ebp)
0x80488d3   vector  stl_vector.h:104mov
%eax,0xffec(%ebp)
0x80488d6   vector  stl_vector.h:105lea0x28(%eax),%eax
0x80488d9   vector  stl_vector.h:105mov
%eax,0xfff0(%ebp)
0x80488dc   vector  mt_allocator.h:450  je 8048a50 

0x80488e2   vector  stl_vector.h:219lea
0xfffa(%ebp),%eax
0x80488e5   vector  stl_vector.h:219mov$0xa,%edx
0x80488ea   vector  stl_vector.h:219mov%eax,0

[Bug c/20272] New: AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

[gcc-bugzilla at gcc dot gnu dot org]

On MacOS 10.3, when I compile Altivec programs that use certain
builtins, in particular the vec_ste() function, specifying -faltivec
and/or -mcpu=7400, gcc-4.1-20050227 gives me the following error:

/var/tmp//ccpZcozX.s:16:lvx vector instruction is optional for the PowerPC (not 
allowed without -force_cpusubtype_ALL option)
/var/tmp//ccpZcozX.s:19:stvewx vector instruction is optional for the PowerPC 
(not allowed without -force_cpusubtype_ALL option)

This doesn't seem correct to me - I have already specified -faltivec
to specifically enable AltiVec instructions, and moreover have
specified -mcpu=7400 (my G4 processor).  According to the
documentation, -force_cpusubtype_ALL overrides -mcpu to cause the
output to have the ALL subtype, which is precisely the opposite of
what you want here (you only want to emit instructions for G4 or
higher).

Note that the error only appears when I use certain Altivec
instructions and not others, reinforcing my notion that there is a
bug.  Apple's gcc 3.3 works fine.

Environment:
System: Darwin 172.16.0.242 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 
14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power Macintosh 
powerpc



host: powerpc-apple-darwin7.8.0
build: powerpc-apple-darwin7.8.0
target: powerpc-apple-darwin7.8.0
configured with: ../configure --enable-languages=c 
--prefix=/Users/stevenj/t/gcc-4.1-20050227/obj/../i

How-To-Repeat:
Compile the following code with gcc -faltivec -mcpu=7400 -c:

#include 

void bug(const float *x)
{
 vector float T;
 vec_ste(T, 4, x);
}

The preprocessed source (with --save-temps) is:

void bug(const float *x)
{
 __attribute__((altivec(vector__))) float T;
 __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) unsigned char, __typeof__ ((T))) && 
__builtin_types_compatible_p (unsigned char, __typeof__ (*(x, 
__builtin_altivec_stvebx ((__attribute__((altivec(vector__))) signed char) (T), 
(4), (void *) (x)), __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) signed char, __typeof__ ((T))) && 
__builtin_types_compatible_p (signed char, __typeof__ (*(x, 
__builtin_altivec_stvebx ((__attribute__((altivec(vector__))) signed char) (T), 
(4), (void *) (x)), __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) __attribute__((altivec(bool__))) unsigned 
char, __typeof__ ((T))) && __builtin_types_compatible_p (unsigned char, 
__typeof__ (*(x, __builtin_altivec_stvebx 
((__attribute__((altivec(vector__))) signed char) (T), (4), (void *) (x)), 
__builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) __attribute__((altivec(bool__))) unsigned 
char, __typeof__ ((T))) && __builtin_types_compatible_p (signed char, 
__typeof__ (*(x, __builtin_altivec_stvebx 
((__attribute__((altivec(vector__))) signed char) (T), (4), (void *) (x)), 
__builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) unsigned short, __typeof__ ((T))) && 
__builtin_types_compatible_p (unsigned short, __typeof__ (*(x, 
__builtin_altivec_stvehx ((__attribute__((altivec(vector__))) signed short) 
(T), (4), (void *) (x)), __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) signed short, __typeof__ ((T))) && 
__builtin_types_compatible_p (short, __typeof__ (*(x, 
__builtin_altivec_stvehx ((__attribute__((altivec(vector__))) signed short) 
(T), (4), (void *) (x)), __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) __attribute__((altivec(bool__))) unsigned 
short, __typeof__ ((T))) && __builtin_types_compatible_p (unsigned short, 
__typeof__ (*(x, __builtin_altivec_stvehx 
((__attribute__((altivec(vector__))) signed short) (T), (4), (void *) (x)), 
__builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) __attribute__((altivec(bool__))) unsigned 
short, __typeof__ ((T))) && __builtin_types_compatible_p (short, __typeof__ 
(*(x, __builtin_altivec_stvehx ((__attribute__((altivec(vector__))) signed 
short) (T), (4), (void *) (x)), __builtin_choose_expr 
((__builtin_types_compatible_p (__attribute__((altivec(vector__))) 
__attribute__((altivec(pixel__))) unsigned short, __typeof__ ((T))) && 
__builtin_types_compatible_p (unsigned short, __typeof__ (*(x, 
__builtin_altivec_stvehx ((__attribute__((altivec(vector__))) signed short) 
(T), (4), (void *) (x)), __builtin_choose_expr ((__builtin_types_compatible_p 
(__attribute__((altivec(vector__))) __attribute__((altivec(pixel__))) unsigned 
short, __typeof__ ((T))) && __builtin_types_compatible_p (short, __typeof__ 
(*(x, __builtin_altivec_stvehx ((__attribute__((altivec(vector__))) signed 
short) (T), (4), (void *) (x)), __builtin_choose_expr 
((__builtin_types_compatible_p (__attribute__((altivec(vector__))) unsigned 
int, __typeof__ ((T))) && __builtin_types_compatible_p (unsigne

[Bug c++/20324] New: Tru64 assembler cores for 3.4.3 g++ -gcoff of #include

[gcc-bugzilla at gcc dot gnu dot org]

On a Tru64 alpha system, when I compile a file containing:

#include 

using g++ 3.4.3 as follows:

g++ -c -gcoff

I get the following output:

mips-tfile, /tmp//ccnFchPc.s:1071 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIbE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1072 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIbE; .scl13; 
.tag13__type_traitsIbE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1074 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIcE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1075 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIcE; .scl13; 
.tag13__type_traitsIcE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1077 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIaE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1078 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIaE; .scl13; 
.tag13__type_traitsIaE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1080 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIhE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1081 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIhE; .scl13; 
.tag13__type_traitsIhE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1083 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIwE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1084 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIwE; .scl13; 
.tag13__type_traitsIwE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1086 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIsE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1087 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIsE; .scl13; 
.tag13__type_traitsIsE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1089 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsItE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1090 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsItE; .scl13; 
.tag13__type_traitsItE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1092 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIiE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1093 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIiE; .scl13; 
.tag13__type_traitsIiE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1095 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   .eos;   .val1;  .scl102;
.tag13__type_traitsIjE; .size   1;  .endef

mips-tfile, /tmp//ccnFchPc.s:1096 compiler error, badly formed 
#.def (internal line # = 2812)
line:   #.def   13__type_traitsIjE; .scl13; 
.tag13__type_traitsIjE; .size   1;  .type   0x8;.endef

mips-tfile, /tmp//ccnFchPc.s:1098 compiler

[Bug c++/20366] New: AIX g++ -D_LARGE_FILES fails to compile #include

[gcc-bugzilla at gcc dot gnu dot org]

The compiler's C++ headers do not appear to work properly on AIX when
the compiler is run with -D_LARGE_FILES.  This macro causes the
system headers to #define symbols like fopen, while the C++ headers
unconditionally #undef these symbols.

Environment:
System: AIX bigblue 2 5 000F699D4C00



host: powerpc-ibm-aix5.2.0.0
build: powerpc-ibm-aix5.2.0.0
target: powerpc-ibm-aix5.2.0.0
configured with: /usr0/slammert/gcc-3.4.3/configure --with-as=/usr/bin/as 
--with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++ --enable-threads 
--enable-version-specific-runtime-libs

How-To-Repeat:
On AIX 5.2, compile the following program with
3.4.3 g++ -D_LARGE_FILES:

#include 
int main(void) { return 0; }

You will get output similar to the following:

In file included from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/powerpc-ibm-aix5.2.0.0/bits/c++locale.h:43,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iosfwd:46,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ios:44,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ostream:45,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iostream:45,
 from bug0.C:1:

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:108: error: 
`::fgetpos' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:110: error: 
`::fopen' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:115: error: 
`::freopen' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:118: error: 
`::fsetpos' has not been declared
--- Additional Comments From dsanderson at panasas dot com  2005-03-07 
19:12 ---
Fix:
I can work around this problem and still compile a program with a
64-bit off_t by compiling with -maix64 instead of -D_LARGE_FILES.

-- 
   Summary: AIX g++ -D_LARGE_FILES fails to compile #include

   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dsanderson at panasas dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.2.0.0
  GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0


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

[Bug target/20415] New: Vector init builtin produces invalid instruction pshufw

[gcc-bugzilla at gcc dot gnu dot org]

__builtin_ia32_vec_init_v4hi and __builtin_ia32_vec_init_v8qi
produce the pshufw instruction when compiled with -O2 and any of the
switches -mmmx, -m3dnow, -march=pentium-mmx, -march=pentium2,
-march=k6, -march=k6-2, i.e. targeting CPUs which do not support SSE.

Environment:
System: Linux localhost 2.4.20 #2 Tue Mar 8 16:32:57 CET 2005 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../../cvs/gcc/configure --prefix=/opt/gcc-4.1 
--enable-languages=c,c++

How-To-Repeat:

typedef short __v4hi __attribute__ ((__vector_size__ (8)));
extern int i;
extern __v4hi v1;
extern __v4hi v2;
void foo (void)
{
  v1 = __builtin_ia32_vec_init_v4hi (i,i,i,i);
  v2 = __builtin_ia32_vec_init_v8qi (i,i,i,i,i,i,i,i);
}

gcc -O2 -mmmx -S example.c 

  .file   "example.c"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
pushl   %eax
movli, %edx
movl%edx, -4(%ebp)
andl$255, %edx
movl%edx, %eax
movd-4(%ebp), %mm1
sall$8, %eax
orl %edx, %eax
pshufw  $0, %mm1, %mm1
movl%eax, -4(%ebp)
movq%mm1, v1
movd-4(%ebp), %mm1
pshufw  $0, %mm1, %mm1
movq%mm1, v2   
leave
ret
.size   foo, .-foo
.ident  "GCC: (GNU) 4.1.0 20050307 (experimental)"
.section.note.GNU-stack,"",@progbits

-- 
   Summary: Vector init builtin produces invalid instruction pshufw
   Product: gcc
   Version: 1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mschimek at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
 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=20415

[Bug c/20573] New: unable to use cast to suppress "warning: comparison is always false due to limited range of data type"

[gcc-bugzilla at gcc dot gnu dot org]

There doesn't seem to be an easy way to suppress this warning in a macro like
#define MILL(in) ((in) > 100)
where the macro may be passed different sizes of ints including shorts.
I would have expected the warning to be suppressed when a cast is present
like:
#define MILL(in) ((int)(in) > 100)
but it isn't.

Environment:
System: CYGWIN_NT-5.1 DHX98431 1.5.14s(0.124/4/2) 20050319 16:46:09 i686 
unknown unknown Cygwin



host: i686-pc-cygwin
build: i686-pc-cygwin
target: i686-pc-cygwin
configured with: /gcc/3.4/gcc-3.4.1-1/configure --verbose --prefix=/usr 
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib 
--mandir=/usr/share/man --infodir=/usr/share/info 
--enable-languages=c,ada,c++,f77,java,objc --enable-nls 
--without-included-gettext --enable-libgcj --with-system-zlib 
--enable-interpreter --enable-threads=posix --enable-java-gc=boehm 
--enable-sjlj-exceptions --disable-version-specific-runtime-libs 
--disable-win32-registry

How-To-Repeat:
Given warnme.c:
#define MILL(in) ((in) > 100)
int foo(short s) { return MILL(s); }
int bar(short s) { return MILL((int)s); }
int baz(short s) { int i=s; return MILL(i); }

with preprocessor output warnme.i:
# 1 "warnme.c"
# 1 ""
# 1 ""
# 1 "warnme.c"

int foo(short s) { return ((s) > 100); }
int bar(short s) { return (((int)s) > 100); }
int baz(short s) { int i=s; return ((i) > 100); }

$ gcc -Wall -save-temps -c warnme.c
warnme.c: In function `foo':
warnme.c:2: warning: comparison is always false due to limited range of data 
type
warnme.c: In function `bar':
warnme.c:3: warning: comparison is always false due to limited range of data 
type

The warning in foo is expected; the warning in bar is not.  baz is an ugly
workaround.
--- Additional Comments From sthoenna at efn dot org  2005-03-21 00:16 
---
Fix:
An ugly workaround is to assign to a temporary variable of large enough data
type where the macro is called, and pass the temporary variable instead.

-- 
   Summary: unable to use cast to suppress "warning: comparison is
always false due to limited range of data type"
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sthoenna at efn dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/37087] New: Segfault on compiling template defined in wrong namespace.

[gcc-bugzilla at gcc dot gnu dot org]

G++ reports a segmentation fault when compiling the code below.

Environment:
System: Linux temporal.corp.google.com 2.6.18.5-gg34workstation-mixed64-32 #1
SMP Thu May 8 01:31:23 UTC 2008 x86_64 GNU/Linux
Architecture: x86_64

host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu

How-To-Repeat:
Invoke g++ on the following (invalid) code with no other arguments.
There are no #includes; this is the entire source file.

==
namespace a {
  template  class Foo;
}

namespace b {
  template <> class ::a::Foo {};
}
==

(The gccbug script claims it will remove "comments" delimited by angle
brackets.
Hopefully that isn't actually true because it will mess up the above code
sample as well as the following error log.)

Result:
testtemplate.cc:6: error: global qualification of class name is invalid before
'{' token
testtemplate.cc:6: error: specialization of 'template struct a::Foo'
in different namespace
testtemplate.cc:2: error:   from definition of 'template struct
a::Foo'
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.


--- Comment #1 from kenton at google dot com  2008-08-11 22:23 ---
Fix:
Unknown.


-- 
   Summary: Segfault on compiling template defined in wrong
namespace.
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kenton at google dot com
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug preprocessor/37215] New: ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[gcc-bugzilla at gcc dot gnu dot org]

Executing 'gcc -E -dM -fpreprocessed - < /dev/null' gives:

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

Environment:
System: Linux alpha2 2.6.26 #1 Sun Jul 20 12:35:52 CEST 2008 x86_64 AMD
Athlon(tm) 64 Processor 2800+ AuthenticAMD GNU/Linux
Architecture: x86_64


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib
--libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic

How-To-Repeat:
Just run 'gcc -E -dM -fpreprocessed - < /dev/null'.


-- 
   Summary: ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'
   Product: gcc
   Version: 3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan dot stankovic at fer dot hr
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug pending/37879] New: g++: internal compiler error: Segmentation fault

[gcc-bugzilla at gcc dot gnu dot org]

NOTE: Defaulting component because reported component no longer exists
ICE: Segmentation fault when compiling with an incorrect used
__attribute__((noreturn));

Environment:
System: Linux molybdaen 2.6.26-1-686 #1 SMP Wed Sep 10 16:46:13 UTC 2008 i686
GN
U/Linux

host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--with-b
ugurl=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-i
nclude-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu
--ena
ble-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all
--enable
-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--ta
rget=i486-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)

How-To-Repeat:
source code (preprocessed file looks the same):

inline unsigned f( unsigned i ) { return i; }
unsigned i = 23;
static inline void g( unsigned ) __attribute__((noreturn));
static inline void g( unsigned j ) { if( j ) asm ("hlt"); }
void main_func() asm("main_func") __attribute__((noreturn));
void main_func()
{
unsigned j;
g( f( j = i++ ) );
asm("hlt");
}

compile with:
g++ -save-temps -m32 -MD -Os -ffunction-sections -fstrict-aliasing
-fno-rtti
 -fno-exceptions -fcheck-new -fshort-enums --param max-inline-insns-single=100
-
mregparm=3 -fomit-frame-pointer -minline-all-stringops -nostdinc -ggdb 
-Wconver
sion -Wctor-dtor-privacy -Wdeprecated -Winvalid-offsetof -Wnon-template-friend
-
Wold-style-cast -Woverloaded-virtual -Wpmf-conversions -Wreorder -Wsign-promo
-W
strict-null-sentinel -Wsynth -Waggregate-return -Wattributes -Wcast-align
-Wdepr
ecated-declarations -Wextra -Winline -Wmissing-noreturn -Wpacked -Wshadow
-Wstac
k-protector -Wstrict-aliasing -Wswitch -Wswitch-default -Wswitch-enum
-Wsystem-h
eaders -Wunsafe-loop-optimizations -Wvolatile-register-var
-Wdisabled-optimizati
on -Wformat -Wreturn-type -Wno-non-virtual-dtor -Wuninitialized -c -o
segfault.o
 segfault.cc


--- Comment #1 from benjamin at os dot inf dot tu-dresden dot de  
2008-10-21 07:09 ---
Fix:
use __attribute__((noreturn)) correctly


-- 
   Summary: g++: internal compiler error: Segmentation fault
   Product: gcc
   Version: 3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benjamin at os dot inf dot tu-dresden dot de
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug java/38075] New: Scanner(System.in) causes next*() to behave incorrectly

[gcc-bugzilla at gcc dot gnu dot org]

When the below code (see How-To-Repeat) is compiled and run, the
program waits for input after initializing the Scanner. That input is
then returned to the first input.next() call, and each input.next()
call returns the user input given during the previous call.

Environment:
System: Linux hybrid 2.6.27-zen3-4.2.0 #2 SMP Sat Oct 25 12:29:11 EDT
2008 x86_64 GNU/Linux 
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../trunk/configure --program-suffix=-svn 
--enable-languages=c,c++,java --with-x --enable-java-awt=xlib

How-To-Repeat:
Compile and run a file containing the following code:

import java.util.Scanner;

public class Test {
public static void main(String argv[]) {
Scanner input = new Scanner(System.in);

System.out.print("Enter a string: ");
String foo = input.next();
System.out.println(foo);

System.out.print("Enter a string: ");
foo = input.next();
System.out.println(foo);

input.close();
}
}


-- 
   Summary: Scanner(System.in) causes next*() to behave incorrectly
   Product: gcc
   Version: 4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jre21 at case dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/34977] New: GCC 3.4.6 link fails with undefined reference to .hidden symbol __floatdidf (libgcc.a)

[gcc-bugzilla at gcc dot gnu dot org]

Building Regina-REXX-3.4 from source distribution.  The linker fails
with the following error:

/usr/local/bin/gcc  -O2 -I/usr/local/include  -pthreads -L/usr/local/lib -o
execiser32 execiser.o -L. -lregina -lfl  -lm -lnsl -lsocket -lcrypt -ldl  
-lpthread
/usr/local/bin/ld: execiser32: hidden symbol `__floatdidf' in
/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/libgcc.a(_floatdidf.oS) is
referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

I've verified that the compiled code has undefined references to the
__floatdidf function.

Environment:
System: SunOS arcade 5.9 Generic_122300-13 sun4u sparc SUNW,Sun-Fire-V490
Architecture: sun4


host: sparc-sun-solaris2.9
build: sparc-sun-solaris2.9
target: sparc-sun-solaris2.9
configured with: ../src/gcc-3.4.6/configure
--prefix=/sea/compilers/native/gcc-3.4.6 --with-local-prefix=/sea/local
--enable-threads --enable-languages=c,c++ --disable-multilib --with-gnu-as
--with-gnu-ld --with-as=/sea/compilers/native/gcc-3.4.6/bin/as
--with-ld=/sea/compilers/native/gcc-3.4.6/bin/ld

How-To-Repeat:
Untar REXX
configure --enable-32bit
make


--- Comment #1 from Reid dot Madsen at tek dot com  2008-01-26 01:10 ---
Fix:
I know of no workaround.


-- 
   Summary: GCC 3.4.6 link fails with undefined reference to .hidden
symbol __floatdidf (libgcc.a)
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Reid dot Madsen at tek dot com
 GCC build triplet: sparc-sun-solaris2.9
  GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9


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

[Bug c++/35021] New: g++ fails to compile legal template code involving templatized methods

[gcc-bugzilla at gcc dot gnu dot org]

g++ is unable to compile a call to a templatized method from a template
function that takes the class that contains the templatized methods as
a template parameter.

Environment:
System: Linux bnell-deb4-64 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007
x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../../../sources/gcc/configure
--prefix=/hub/Linux/glibc-2.3.6/x86_64/apps/gcc-4.1.1
--with-gmp=/mathworks/devel/sandbox/greg/Amake/3p/derived/glnxa64/gcc/gmp
--with-mpfr=/mathworks/devel/sandbox/greg/Amake/3p/derived/glnxa64/gcc/mpfr
--enable-languages=c,c++,fortran
--with-as=/hub/Linux/glibc-2.3.6/x86_64/apps/gcc-4.1.1/bin/as
--with-ld=/hub/Linux/glibc-2.3.6/x86_64/apps/gcc-4.1.1/bin/ld
--disable-multilib

How-To-Repeat:
1) save the following code into bug.cpp

  struct foo {
template 
const void* bar(char* p) const
{
  return p;
}

template 
const void* moo(char* p) const
{
  return p;
}
  };

  template 
  void test_template(const F& f)
  {
f.bar<3>(0);// doesn't work here
f.moo(0);  // doesn't work here
  }

  int main(int argc, char* argv[])
  {
foo f;

f.bar<3>(0);// works here
f.moo(0);  // works here

test_template(f);

return 0;
  }

2) attempt to compile: g++ -o bug bug.cpp


-- 
   Summary: g++ fails to compile legal template code involving
templatized methods
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bnell at mathworks dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug libobjc/39465] New: libobjc does not find classes of DLLs

[gcc-bugzilla at gcc dot gnu dot org]

When building a program that uses an objc library as a DLL, libobjc
can't find its classes. When the program and the library are statically
linked, it works.
My libobjc itself is linked as a static library.

Environment:
System: Linux asgard.webkeks.org 2.6.28.5 #1 SMP Sat Feb 14 14:16:10 CET 2009
i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux



host: mingw32
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-4.3.0-20080502/configure -v --prefix=/usr
--libexecdir=/usr/lib --program-prefix=mingw32- --target=mingw32
--with-headers=/usr/mingw32/include --without-x --disable-nls
--disable-win32-registry --disable-shared --disable-java-awt
--disable-libgcj-debug --with-gcc --with-gnu-ld --with-gnu-as --enable-threads
--enable-languages=c,c++,objc --enable-libgcj --enable-java-gc=boehm
--enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug

How-To-Repeat:
asgard:/tmp$ cat foo.h
#import 

@interface MyObj: Object
- (void)foo;
@end
asgard:/tmp$ cat foo.m
#import 

#import "foo.h"

@implementation MyObj
- (void)foo
{
puts("foo!");
}
@end
asgard:/tmp$ cat test.m
#import "foo.h"

int main()
{
MyObj *x = [MyObj new];
[x foo];
return 0;
}
asgard:/tmp$ mingw32-gcc -shared -Wl,--out-implib,libfoo.dll.a foo.m -o
libfoo.dll -lobjc
asgard:/tmp$ mingw32-gcc -L. test.m -lfoo -lobjc
Info: resolving ___objc_class_name_MyObj by linking to
__impobjc_class_name_MyObj (auto-import)
/usr/lib/gcc/mingw32/4.3.0/../../../../mingw32/bin/ld: warning:
auto-importing has been activated without --enable-auto-import specified on the
command line.
This should work unless it involves constant data structures
referencing symbols from auto-imported DLLs.
asgard:/tmp$ wine a.exe
objc runtime: cannot find class MyObj


--- Comment #1 from js-gcc at webkeks dot org  2009-03-15 15:34 ---
Fix:
I guess some change to libobjc is needed so it can find classes inside
DLLs.


-- 
   Summary: libobjc does not find classes of DLLs
   Product: gcc
   Version: 3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: js-gcc at webkeks dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: mingw32
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/41551] New: ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[gcc-bugzilla at gcc dot gnu dot org]

ICE on ia64 at -O1 and higher, seen with gcc 4.3 and 4.4 but not 4.2.
% gcc -O -c t.c
t.c: In function 'main':
t.c:5:1: error: unrecognizable insn:
(insn 5 4 6 3 t.c:3 (set (reg:DF 344)
(unsigned_float:DF (reg/f:DI 328 sfp))) -1 (nil))
t.c:5:1: internal compiler error: in instantiate_virtual_regs_in_insn, at
function.c:1630

Environment:
System: Linux merulo 2.6.30.4-dsa-mckinley #1 SMP Sat Aug 15 18:22:08 UTC 2009
ia64 GNU/Linux
host: ia64-unknown-linux-gnu
build: ia64-unknown-linux-gnu
target: ia64-unknown-linux-gnu
configured with: ../src/configure -v --with-pkgversion='Debian 20090821-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --disable-libssp --enable-mpfr --enable-java-awt=gtk
--enable-gtk-cairo --disable-plugin
--with-java-home=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.5/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.5
--with-arch-directory=ia64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-system-libunwind --disable-werror
--build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu

How-To-Repeat:
% cat t.c
int main(void)
{
 int var, *p = &var;
 return (double)(unsigned long)(p);
}


--- Comment #1 from ntyni at debian dot org  2009-10-02 19:22 ---
Fix:
downgrade to -O0


-- 
   Summary: ia64: ICE: in instantiate_virtual_regs_in_insn, at
function.c:1630
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ntyni at debian dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug c++/31816] New: If a function foo is defined before declaring a template class A, overloaded version of foo defined after the class declaration will not be available within class A.

[gcc-bugzilla at gcc dot gnu dot org]

Let us consider the following code:
-
void qHash(double) {}

template 
struct QSet
{
  void foo()
  {
qHash(T());
  }
};

// void qHash(double) {} // ok if placed here
void qHash(int*) {}

int main()
{
  QSet s;
  s.foo(); // ok

  QSet sp;
  sp.foo(); // do not compile, qHash(int*) is not considered.
}
-

It does not compile, because the overloaded version of qHash() for
int* is not available in QSet, even if QSet is instantiated after the
declaration of qHash(int*). If no qHash function is defined before the
declaration of QSet, it works fine. Although I'm not absolutely
certain that this code is valid, my intuition tells me this behavior
is strongly suspect ..

It works fine with g++ 4.0.4, 3.3 and 2.95.

Environment:
System: Linux stageuei9 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu

How-To-Repeat:

Compile the given code.


--- Comment #1 from nicolas dot burrus at ensta dot fr  2007-05-04 14:31 
---
Fix:

Do not overload a function before and after a template class
using it.


-- 
   Summary: If a function foo is defined before declaring a template
class A, overloaded version of foo defined after the
class declaration will not be available within class
A.
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolas dot burrus at ensta dot fr
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug target/32264] New: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3

[gcc-bugzilla at gcc dot gnu dot org]

When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
.config: CONFIG_MCYRIXIII=y

Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu VIA C3 -march=c3
configured with: /home/axel/p/rpm/BUILD/gcc-4.2.0/configure --prefix=/opt/gcc4
--exec-prefix=/opt/gcc4 --srcdir=/home/axel/p/rpm/BUILD/gcc-4.2.0
--enable-shared --enable-languages=c,c++,objc

How-To-Repeat:
compile vanilla linux kernel 2.4.34.5 with CONFIG_MCYRIXIII=y and boot
the kernel on a VIA C3 -> crash


--- Comment #1 from axel at freakout dot de  2007-06-08 20:17 ---
Fix:
Compile kernel with gcc 4.1.2 Ok and working with -march=c3


-- 
   Summary: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when
VIA C3 optimized -march=c3
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: axel at freakout dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu VIA C3 -march=c3


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

[Bug c++/32325] New: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info

[gcc-bugzilla at gcc dot gnu dot org]

During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:

checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1

config.log reveals:

configure:13794: checking for exception model to use
configure:13838:  /vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.3.0-20070612/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include -c -S  conftest.cc >&5
configure: In function 'void foo()':
configure:13836: error: end insn 27 for block 7 not found in the insn stream
configure:13836: error: head insn 24 for block 7 not found in the insn stream
configure:13836: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
configure:13841: $? = 1
configure:13870: error: unable to detect exception model

This happens with the following conftest.cc:

struct S { ~S(); };
void bar();
void foo()
{
  S s;
  bar();
}

 % ./cc1plus conftest.cc
 void foo()
Analyzing compilation unit
Performing interprocedural optimizations
   Assembling functions:
 void foo()
conftest.cc: In function 'void foo()':
conftest.cc:7: error: end insn 27 for block 7 not found in the insn stream
conftest.cc:7: error: head insn 24 for block 7 not found in the insn stream
conftest.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Running gdb reveals

Program received signal SIGSEGV, Segmentation fault.
rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
(gdb) where
#0  rtl_verify_flow_info () at /vol/gcc/src/gcc-dist/gcc/cfgrtl.c:2005
#1  0x000120516638 in verify_flow_info () at
/vol/gcc/src/gcc-dist/gcc/cfghooks.c:245
#2  0x000120618934 in commit_edge_insertions () at
/vol/gcc/src/gcc-dist/gcc/cfgrtl.c:1467
#3  0x000120415bcc in alpha_gp_save_rtx () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.c:4784
#4  0x0001206406fc in gen_exception_receiver () at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.md:7019
#5  0x000120314dc8 in finish_eh_generation () at
/vol/gcc/src/gcc-dist/gcc/except.c:1633
#6  0x000120314f98 in rest_of_handle_eh () at
/vol/gcc/src/gcc-dist/gcc/except.c:3985
#7  0x000120421978 in execute_one_pass (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1124
#8  0x000120421c48 in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1177
#9  0x000120421c5c in execute_pass_list (pass=0x0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1178
#10 0x0001204fef44 in tree_rest_of_compilation (fndecl=0x0) at
/vol/gcc/src/gcc-dist/gcc/tree-optimize.c:406
#11 0x0001202535c8 in c_expand_body (fndecl=0x140137d80) at
/vol/gcc/src/gcc-dist/gcc/c-common.c:4331
#12 0x0001201ea958 in expand_body (fn=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cp/semantics.c:3136
#13 0x000120423f60 in cgraph_expand_function (node=0x18de60) at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1073
#14 0x000120427400 in cgraph_optimize () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1142
#15 0x00012015e054 in cp_write_global_declarations () at
/vol/gcc/src/gcc-dist/gcc/cp/decl2.c:3305
#16 0x0001204432e0 in toplev_main (argc=1, argv=0x0) at
/vol/gcc/src/gcc-dist/gcc/toplev.c:1064
#17 0x00012029fe98 in main (argc=1075019136, argv=0x11fffbb30) at
/vol/gcc/src/gcc-dist/gcc/main.c:35
(gdb) p x
$1 = 0x0

I.e. rtl_verify_flow_info dereferences a NULL pointer.  This happens only
on alpha-dec-osf5.1b, alpha-dec-osf4.0f is unaffected.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap as described above.


-- 
   Summary: cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B:
SEGV in rtl_verify_flow_info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


http://gcc.gnu.org/bugzil

[Bug libfortran/32345] New: Unconditional snprintf use breaks all gfortran exec tests on Tru64 UNIX V4.0F

[gcc-bugzilla at gcc dot gnu dot org]

All gfortran execute tests fail on alpha-dec-osf4.0f since snprintf is
missing in libc, but used in libgfortran.

Environment:
System: OSF1 hindemith V4.0 1229 alpha
Machine: alpha

host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build
alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap and test on alpha-dec-osf4.0f.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-14 
16:40 ---
Fix:
The reference is from runtime/backtrace.c (show_backtrace) and can easily
be changed to use sprintf() is snprintf() is unavailable.


-- 
   Summary: Unconditional snprintf use breaks all gfortran exec
tests on Tru64 UNIX V4.0F
   Product: gcc
   Version: 3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug pending/32403] New:

[gcc-bugzilla at gcc dot gnu dot org]

NOTE: Defaulting component because reported component no longer exists


Environment:
System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007
i686 GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: m68hc11-unknown-none
configured with: ../src/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --with-gnu-as --with-gnu-ld --enable-nls
--without-included-gettext --disable-checking --enable-languages=c
--build=i486-linux-gnu --host=i486-linux-gnu --target=m68hc11 --without-headers

How-To-Repeat:



-- 
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marko at localhost dot localhost
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: m68hc11-unknown-none


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

[Bug libgcj/32462] New: Linking libgcj.so fails on Solaris 10/x86

[gcc-bugzilla at gcc dot gnu dot org]

A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 fails to link libgcj.so:

ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: relocation must bind locally
collect2: ld returned 1 exit status
make[3]: *** [libgcj.la] Error 1

Performing the same link on Solaris 11 gives

ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: a GOT relative relocation must
reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::processManager: a GOT relative relocation must
reference a local symbol
collect2: ld returned 1 exit status

I'm currently investigating if using the native /usr/ccs/bin/as, gas 2.17
or gld 2.17 makes a difference.

Environment:
System: SunOS erebus 5.11 snv_60 i86pc i386 i86pc
Architecture: i86pc


host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/usr/sfw/bin/gas --disable-multilib --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: Linking libgcj.so fails on Solaris 10/x86
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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

[Bug libgcj/32465] New: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC

[gcc-bugzilla at gcc dot gnu dot org]

A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 and my patch to support boehm-gc for x86-64

 http://gcc.gnu.org/ml/java-patches/2007-q2/msg00330.html

fails when linking the 64-bit libgcj:

[ca. 6800 lines omitted]
gnu::gcj::runtime::FinalizerThread::finalizer_ready0x602   
gnu/gcj/.libs/runtime.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

I've checked for some of the affected object files that they have been
built with -fPIC, nonetheless text relocations remain, thus breaking the
link.

Environment:
System: SunOS erebus 5.11 snv_60 i86pc i386 i86pc
Architecture: i86pc


host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/usr/sfw/bin/gas --with-gmp=/vol/gcc --with-mpfr=/vol/gcc
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-22 
17:42 ---
Fix:
It is possible to link with -mimpure-text as a workaround.


-- 
   Summary: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-
PIC code despite -fPIC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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

[Bug libstdc++/32499] New: libstdc++ testsuite fails on platforms without ranlib

[gcc-bugzilla at gcc dot gnu dot org]

I noticed that the libstdc++ testsuite fails to run on mips-sgi-irix6.5 and
mips-sgi-irix5.3::

ERROR: tcl error sourcing
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not link libtestc++.a
while executing
"error "could not link libtestc++.a""
(procedure "v3-build_support" line 82)
invoked from within
"v3-build_support"
(file "/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
line 22)
invoked from within
"source /vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""

It turns out that this happens since the platform lacks ranlib, but
testsuite/lib/libstdc++.exp (v3-build_support) uses either
$RANLIB_FOR_TARGET or ranlib.  Of course, trying to execute a non-existant
command fails.

The toplevel Makefile only passes in RANLIB=:, not RANLIB_FOR_TARGET.

This was most likely introduced by this patch:

2007-03-15  Hans-Peter Nilsson  <[EMAIL PROTECTED]>

* testsuite/lib/libstdc++.exp (v3-build_support) : If it
exists, use env(AR_FOR_TARGET).  Log the command.
: Similar.

Environment:
System: IRIX64 columba 6.5 07010238 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.17 --enable-libgcj --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --disable-libmudflap
--enable-languages=c,ada,c++,fortran,objc --no-create --no-recursion

How-To-Repeat:
Bootstrap and test mainline or the 4.2 branch as above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-25 
15:23 ---
Fix:
This can be worked around by setting RANLIB_FOR_TARGET=: in the
environment, but this shouldn't be necessary.


-- 
   Summary: libstdc++ testsuite fails on platforms without ranlib
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug c/32536] New: wrong generated code on complex statement;

[gcc-bugzilla at gcc dot gnu dot org]

sample code:

#include 

int main()
{
  char cp[2];
  cp[0] = 'A';
  cp[1] = 'B';
  printf("%x %x\n",cp[0],cp[1]);
  cp[0] ^= (cp[1]^=(cp[0]^=cp[1]));
  printf("%x %x\n",cp[0],cp[1]);
  return 0;
}

The complex byte swapping instruction is far fetched but seems legal.
It actually swaps bytes if compiled with "gcc -O3". Without optimization, 
one of the bytes receives a '\0'. 
   This instruction seemed to work properly with versions 3.

Environment:
System: Linux lpnp204 2.4.21-47.0.1.EL.cernsmp #1 SMP Thu Oct 19 16:35:52 CEST
2006 i686 i686 i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure

How-To-Repeat:
Compile the code above with various degrees of optimization.


-- 
   Summary: wrong generated code on complex statement;
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astier at lpnp204 dot in2p3 dot fr
 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=32536

[Bug libgomp/32538] New: All libgomp tests fail to link on IRIX 6: copysignl undefined

[gcc-bugzilla at gcc dot gnu dot org]

All libgomp tests fail to link on IRIX 6:

Executing on host: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/xgcc
-B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/
/vol/gcc/src/gcc-dist/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 
-B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/
-I/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp
-I/vol/gcc/src/gcc-dist/libgomp/testsuite/.. -fmessage-length=0 -fopenmp  -O0  
  -L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs
-lgomp
-L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs
-lgfortranbegin -lgfortran -lm   -o ./a.16.1.exe(timeout = 300)
ld32: ERROR   33 : Unresolved data symbol "copysignl" -- 1st referenced by
/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/libgcc.a(_divtc3.o).
Use linker option -v to see when and which objects, archives and dsos
are loaded.  
ld32: INFO152: Output file removed because of error.
collect2: ld returned 2 exit status
compiler exited with status 1

This happens because libgcc contains an undefined reference to copysignl.
This function is present in libm, but libm is before libgcc on the linker
command line, as can be seen with -v:

 /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/collect2 -call_shared
-no_unresolved -init __gcc_init -fini __gcc_fini -_SYSTYPE_SVR4 -woff 131 -n32
-o ./a.16.1.exe /usr/lib32/mips3/crt1.o
/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crti.o
/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtbegin.o
-L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/.libs
-L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp/../libgfortran/.libs
-L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc
-L/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/mips-sgi-irix6.5/./libgomp
-L/lib/../lib32 -L/usr/lib/../lib32 /var/tmp//ccCchLrr.o -lgomp -lgfortranbegin
-lgfortran -lm -lgomp -dont_warn_unused -lgcc -lgcc_eh -warn_unused
-L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lpthread -lc -warn_unused
-dont_warn_unused -lgcc -lgcc_eh -warn_unused
/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/crtend.o
/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/irix-crtn.o /usr/lib32/mips3/crtn.o

The 4.2 branch is affected as well.

Environment:
System: IRIX64 columba 6.5 07010238 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.17 --enable-libgcj --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --disable-libmudflap
--enable-languages=c,ada,c++,fortran,objc --no-create --no-recursion

How-To-Repeat:
Bootstrap and test as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-28 
17:35 ---
Fix:
There are two possible solutions: 

* add -lgcc -lm to the link_gomp spec (this is obviously a hack)

* add -lm to the libgcc spec (this seems to be the proper solution)

Comments?


-- 
   Summary: All libgomp tests fail to link on IRIX 6: copysignl
undefined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug ada/32547] New: gnat.dg tasking tests fail on IRIX 5.3

[gcc-bugzilla at gcc dot gnu dot org]

All gnat.dg tasking tests FAIL on IRIX 5.3 since the platform lacks thread
support:

failed run-time assertion : Tasking not implemented on this configuration
FAIL: gnat.dg/curr_task.adb execution test

Instead of failing, the tests should be marked UNSUPPORTED as is done for
ACATS.

Environment:
System: IRIX lyra 5.3 11091812 IP22 mips



host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.17 --with-gmp=/vol/gcc --with-mpfr=/vol/gcc
--enable-languages=c,c++,fortran,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap and test mainline as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-29 
15:11 ---
Fix:
It should be possible to handle this in gcc/testsuite/lib/gnat.exp via
${tool}_check_unsupported_p.


-- 
   Summary: gnat.dg tasking tests fail on IRIX 5.3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix5.3
  GCC host triplet: mips-sgi-irix5.3
GCC target triplet: mips-sgi-irix5.3


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

[Bug ada/32548] New: gnat.dg tests for non-default multilib fail

[gcc-bugzilla at gcc dot gnu dot org]

When running the gnat.dg tests on multilib-targets (like
sparc-sun-solaris2*, i386-pc-solaris2*, or mips-sgi-irix6*), most tests for
a non-default multilib fail with confusing error messages:

Running /vol/gcc/src/gcc/gcc/testsuite/gnat.dg/dg.exp ...
Executing on host: /vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/gnatmake
-I/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/ada/rts
--GCC=/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/xgcc
--GNATBIND=/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/gnatbind
--GNATLINK=/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/gnatlink -cargs
-B/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc -largs
--GCC=/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc -margs -q -f
/vol/gcc/src/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb   
-I/vol/gccsrc/obj/gcc-4.3.0-20070614/10-gcc/gcc/ada/rts  -lm   -m64 -o
./abstract_with_anonymous_result.exe(timeout = 300)
abstract_with_anonymous_result.adb:6:12: alignment for "I" must be at least 8
abstract_with_anonymous_result.adb:10:12: alignment for "New_I" must be at
least 8
gnatmake:
"/vol/gcc/src/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb"
compilation error
compiler exited with status 1
output is:
abstract_with_anonymous_result.adb:6:12: alignment for "I" must be at least 8
abstract_with_anonymous_result.adb:10:12: alignment for "New_I" must be at
least 8
gnatmake:
"/vol/gcc/src/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb"
compilation error

FAIL: gnat.dg/abstract_with_anonymous_result.adb (test for excess errors)

Per PR ada/5911, multilibs are not supported in Ada yet.

Environment:
System: SunOS thor 5.10 Generic_125100-08 sun4u sparc SUNW,Sun-Fire-V240
Architecture: sun4


host: sparc-sun-solaris2.10
build: sparc-sun-solaris2.10
target: sparc-sun-solaris2.10
configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap and test mainline (or the 4.2 branch) as described above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-06-29 
15:23 ---
Fix:
When gcc is invoked for a non-default multilib, it should print a message
indicating missing multilib support and the tests could be marked
UNSUPPORTED.


-- 
   Summary: gnat.dg tests for non-default multilib fail
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug libgcj/32651] New: [4.2/4.3 regression] libjava fails to build on IRIX 6.5

[gcc-bugzilla at gcc dot gnu dot org]

On both the 4.2 branch and mainline, libjava fails to build on
mips-sgi-irix6.5:

* sysdeps_dir isn't set in configure.host, so the generic locks.h is used
  which just errors out

* libgcj_interpreter is set to yes in the general mips-* clause in
  configure.host, but this cannot work for IRIX 6 since libffi supports
  closures only for the O32 ABI, N32 and N64 support is still missing

Environment:
System: IRIX64 columba 6.5 07010238 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --enable-libgcj --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,java --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.17

How-To-Repeat:
Bootstrap either branch as reported above.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-07-06 
17:24 ---
Fix:
Initial patch posted here:

http://gcc.gnu.org/ml/java-patches/2007-q3/msg00025.html


-- 
   Summary: [4.2/4.3 regression] libjava fails to build on IRIX 6.5
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug libgcj/32652] New: [4.3 regression] libgcj fails to build with --disable-interpreter

[gcc-bugzilla at gcc dot gnu dot org]

Even with the fix for PR libgcj/32651 (which sets libgcj_interpreter=no),
libgcj doesn't build on IRIX 6.5 (or any other platform) because several
types and classes from java-interp.h are used even with INTERPRETER
undefined.  This is a regression from 4.1 and 4.2 and can easily be
reproduced with --disable-interpreter.

Environment:
System: IRIX64 columba 6.5 07010238 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --enable-libgcj --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,java --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.17

How-To-Repeat:
Bootstrap mainline with the patch from

http://gcc.gnu.org/ml/java-patches/2007-q3/msg00025.html

or just pass --disable-interpreter on any platform.


--- Comment #1 from ro at techfak dot uni-bielefeld dot de  2007-07-06 
17:32 ---
Fix:
The mail above contains a hacky patch to allow the compilation to complete,
but all libjava programs fail to link due to many unresolved symbols (no
surprise given the nature of the patch).


-- 
   Summary: [4.3 regression] libgcj fails to build with --disable-
interpreter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug ada/32654] New: [4.2 regression] Ada comparison failure in exp_aggr.o on Tru64 UNIX V5.1B

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping the current 4.2 branch on alpha-dec-osf5.1b with GCC 3.4 as
the bootstrap compiler, I get a comparison failure in exp_aggr.o:

Comparing stages 2 and 3
Bootstrap comparison failure!
./ada/exp_aggr.o differs
make[2]: *** [compare] Error 1

There's only a minimal difference in the debugging info:

--- prev-gcc/exp_aggr.s Fri Jun 15 21:55:38 2007
+++ gcc/exp_aggr.s  Fri Jun 15 21:56:39 2007
@@ -13799,7 +13799,7 @@
beq $0,$L1053
 $L974:
 $LBB210:
- #.stabn   68,0,3263,$LM2081
+ #.stabn   68,0,3155,$LM2081
 $LM2081:
bis $31,$31,$1
 $L973:

This happens since at least 20070506 and only on alpha-dec-osf5.1b,
alpha-dec-osf4.0f is unaffected (as is mainline unless I'm mistaken).

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha

host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gcc/src/gcc-4.2-branch-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build
alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada

How-To-Repeat:
Bootstrap the 4.2 branch as described above.


-- 
   Summary: [4.2 regression] Ada comparison failure in exp_aggr.o on
Tru64 UNIX V5.1B
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf5.1b
  GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b


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

[Bug bootstrap/32744] New: [4.3 regression] ICE in build2_stat, at tree.c:3077 bootstrapping on Tru64 UNIX

[gcc-bugzilla at gcc dot gnu dot org]

On both alpha-dec-osf4.0f and alpha-dec-osf5.1b, current mainline (as of
r126588) fails to bootstrap: 
/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./gcc/
-B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem
/vol/gcc/alpha-dec-osf4.0f/include -isystem
/vol/gcc/alpha-dec-osf4.0f/sys-include -g -fkeep-inline-functions -O2  -O2 -g
-O2  -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -pthread -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I/vol/gcc/src/gcc-dist/libgcc -I/vol/gcc/src/gcc-dist/libgcc/.
-I/vol/gcc/src/gcc-dist/libgcc/../gcc -I/vol/gcc/src/gcc-dist/libgcc/../include
 -DHAVE_CC_TLS -o _gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep
-DL_gcov_execl -c /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcov.c
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcov.c: In function '__gcov_execl':
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcov.c:838: internal compiler error: in
build2_stat, at tree.c:3077

This happens at -O and -O0 as well.

I've last bootstrapped successfully on 20070612.

Environment:
System: OSF1 hindemith V4.0 1229 alpha
Machine: alpha

host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build
alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: [4.3 regression] ICE in build2_stat, at tree.c:3077
bootstrapping on Tru64 UNIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug bootstrap/32745] New: [4.3 regression] ICE in set_expression_vuses at tree-ssa-pre.c:265 on Solaris 10/SPARC

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping mainline on sparc-sun-solaris2.10 as of r126588 fails
building the sparcv9 stage2 libgcc:

/vol/gccsrc/obj/gcc-4.3.0-20070712/10-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070712/10-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.10/bin/ -B/vol/gcc/sparc-sun-solaris2.10/lib/
-isystem /vol/gcc/sparc-sun-solaris2.10/include -isystem
/vol/gcc/sparc-sun-solaris2.10/sys-include -g -O2 -m64 -O2  -O2 -g -O2 
-DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc
-I/vol/gcc/src/gcc-dist/libgcc -I/vol/gcc/src/gcc-dist/libgcc/.
-I/vol/gcc/src/gcc-dist/libgcc/../gcc -I/vol/gcc/src/gcc-dist/libgcc/../include
  -o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c \
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__lshrti3':
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:413: internal compiler error:
vector VEC(vuse_vec,base) replace domain error, in set_expression_vuses at
tree-ssa-pre.c:265

The file compiles at -O.

Environment:
System: SunOS thor 5.10 Generic_125100-10 sun4u sparc SUNW,Sun-Fire-V240
Architecture: sun4


host: sparc-sun-solaris2.10
build: sparc-sun-solaris2.10
target: sparc-sun-solaris2.10
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada
--disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.


-- 
   Summary: [4.3 regression] ICE in set_expression_vuses at tree-
ssa-pre.c:265 on Solaris 10/SPARC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug c++/23730] New: ICE instead of reporting a call to a non existant member function

[gcc-bugzilla at gcc dot gnu dot org]

G++ dies instead of reporting a clear error message.  This is a
regression as compared to 3.3

I'm afraid I can't currently upgrade to 4.1, so I can't tell if this
is still a problem...

Environment:
System: Linux nostromo 2.4.27-1-686 #1 Wed Dec 1 19:57:47 JST 2004 i686 
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls 
--without-included-gettext --enable-threads=posix --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --enable-checking=release i486-linux-gnu

How-To-Repeat:

/tmp % eof foo.ccnostromo 14:57
:  foo.cc --
cat > foo.cc << \EOF
struct Visitor;

struct Ast
{
  virtual void accept (Visitor& v);
};

void
Ast::accept (Visitor& v)
{
  v (*this);
}
EOF
: 
/tmp % gcc-4.0 foo.ccnostromo 14:57
foo.cc: In member function 'virtual void Ast::accept(Visitor&)':
foo.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

/tmp % gcc-3.3 foo.ccnostromo Err 1
foo.cc: In member function `virtual void Ast::accept(Visitor&)':
foo.cc:11: error: no match for call to `(Visitor) (Ast&)'

-- 
   Summary: ICE instead of reporting a call to a non existant member
function
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akim at lrde dot epita dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug middle-end/23775] New: 4.1: wrong code in argument passing

[gcc-bugzilla at gcc dot gnu dot org]

On a i686 platform, the example below is miscompiled with -O1.
I expect this program to print -0.96.  Here's what it actually does:

$ g++ -O1 -o y y.cc
$ ./y
-1.288766
$ g++  -o y y.cc
$ ./y
-0.96
$

The value that the optimized version prints is actually different
on each run of the program.

Here's the generated code for main(), 

.globl main
.type   main, @function
main:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movl%ebx, -8(%ebp)
movl%esi, -4(%ebp)
andl$-16, %esp
subl$16, %esp
movl$0, 12(%esp)
movl8(%esp), %ebx; this seems to load ebx with garbage???
movl12(%esp), %esi
fldz
fstl8(%esp)
fstpl   (%esp)
call_Z8x_from_zdd
fstpl   4(%esp)
movl%ebx, 8(%esp); this clobbers half of the arg with
 ; the garbage
movl%esi, 12(%esp)
movl$0, (%esp)
call_Z17local_to_trflocalidi
movl$0, %eax
movl-8(%ebp), %ebx
movl-4(%ebp), %esi
movl%ebp, %esp
popl%ebp
ret

It looks to me like the error occurs during RTL generation.
Here's the tree dump from the t87.final_cleanup file (slightly trimmed):

void local_to_trflocal(int, double, int) (D.1741, x_loc, D.1743)
{
:
  printf (&"%f\n"[0], x_loc);
  return;
}

double x_from_z(double, double) (pitch, stereo)
{
:
  return -9.59964472863211994990706443786621094e-1 / cos (stereo);
}

int main() ()
{
:
  local_to_trflocal (0, x_from_z (0.0, 0.0), 0);
  return 0;
}


But in the 00.expand file, here's the sequence leading
to the local_to_trflocal() call:

(insn 27 26 28 1 (set (mem/i:DF (plus:SI (reg/f:SI 56 virtual-outgoing-args)
(const_int 4 [0x4])) [0 S8 A32])
(reg:DF 71)) -1 (nil)
(nil))

(insn 28 27 29 1 (set (mem:DI (plus:SI (reg/f:SI 56 virtual-outgoing-args)
(const_int 8 [0x8])) [0 S8 A8])
(reg:DI 68)) -1 (nil)
(nil))

(insn 29 28 30 1 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32])
(const_int 0 [0x0])) -1 (nil)
(nil))

(call_insn 30 29 31 1 (call (mem:QI (symbol_ref:SI ("_Z17local_to_trflocalidi") 
[flags 0x3] ) [0 S1 A8])
(const_int 16 [0x10])) -1 (nil)
(nil)
(nil))


Reg 71 here is the return value from x_from_z.
I don't know where the DI store to v-o-a+8 is coming from...

Environment:
System: Linux karma 2.6.12.1sss #2 Thu Jul 7 00:28:21 EDT 2005 i686 i686 i386 
GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc 
--enable-threads=posix --enable-long-long --enable-languages=c,c++,f95

How-To-Repeat:

Compile with -O1

-
//g++ -O1 -g -o y y.cc 

extern "C" double cos(double);
extern "C" int printf (...);


double x_from_z(double pitch=0, double stereo=0)
{
  return -0.96/cos(stereo);
}

void local_to_trflocal(int, double x_loc, int=0)
{
  printf ("%f\n", x_loc);
}


int main()
{
  local_to_trflocal(0, x_from_z());
  return 0;
}

-
--- Additional Comments From snyder at fnal dot gov  2005-09-08 02:31 
---
Fix:


-- 
   Summary: 4.1: wrong code in argument passing
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snyder at fnal dot gov
CC: gcc-bugs at gcc dot gnu dot org
 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=23775

[Bug rtl-optimization/23810] New: missed 64-bit shift+mask optimizations on 32-bit arch

[gcc-bugzilla at gcc dot gnu dot org]

(Sources are from CVS as of about 6AM US/Eastern time today.)

I'm testing out how well gcc optimizes some code for reversing bit
strings.  It appears that on x86 at least, double-word shifts followed
by masks that zero out all the bits that crossed the word boundary are
not optimized as well as they could be.

In the included file, compiled with "-O9 -fomit-frame-pointer",
functions rt and rt2 both result in assembly code including a
double-word shift, bringing two bits from the upper half of the
argument into the top of the lower half of the double-word value, then
masks that word with 0x, which zeros out those bits:

rt:
movl8(%esp), %edx
movl4(%esp), %eax
shrdl   $2, %edx, %eax
shrl$2, %edx
andl$858993459, %eax
andl$858993459, %edx
ret

Okay, in this case, the only optimization would be to make the shift
not reference both %edx and %eax, and drop the reference to the upper
half flom the RTL during optimization.  To highlight the issue a
little more, rt4 is like rt but only returns the lower half.  Still,
the upper half is read in from memory (and shifted!) needlessly:

rt4:
movl8(%esp), %edx
movl4(%esp), %eax
shrdl   $2, %edx, %eax
andl$858993459, %eax
shrl$2, %edx
ret

Function left shows the same problem, shifting in the opposite
direction:

left:
movl4(%esp), %eax
movl8(%esp), %edx
shldl   $2, %eax, %edx
sall$2, %eax
andl$-858993460, %edx
andl$-858993460, %eax
ret

The "andl" of %edx with 0x will clobber the bits brought in
from %eax.

I haven't got the hang of reading ppc assembly yet, but I think the
Mac OS X compiler (10.4.2 = "gcc version 4.0.0 (Apple Computer,
Inc. build 5026)") is missing similar optimizations.  I haven't tried
the cvs code on ppc.

Environment:
System: Linux kal-el 2.4.17 #4 SMP Sun Apr 6 16:25:37 EDT 2003 i686 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../src/configure --enable-maintainer-mode 
--prefix=/u3/raeburn/gcc/linux/Install --enable-languages=c,c++,java,objc 
--no-create --no-recursion : (reconfigured) ../src/configure 
--prefix=/u3/raeburn/gcc/linux/Install

How-To-Repeat:

typedef unsigned long long uint64_t;
typedef unsigned long uint32_t;

uint64_t rt (uint64_t n) { return (n >> 2) & 0xULL; }
uint64_t rt2 (uint64_t n) { return (n & (0xULL << 2)) >> 2; }
uint32_t rt4 (uint64_t n) { return (n >> 2) & 0x; }
uint64_t left(uint64_t n) {
  return (n << 2) & (0xULL & ~0xULL);
}

-- 
   Summary: missed 64-bit shift+mask optimizations on 32-bit arch
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
CC: gcc-bugs at gcc dot gnu dot org
 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=23810

[Bug c++/24014] New: casting int to double with got wrong result

[gcc-bugzilla at gcc dot gnu dot org]

I've written an macro for log2 calculation to calculate the exponent of 
one value.
Than I cast this value to from double to int.
The 2 values double and int differs. 
example:
log2(8) should be 3 but after casting to int its 2.
This bug could be reproduced on 2 different linux distributions (Debian 
GNU/Linux and Fedora Core 2) with different compiler versions.

Environment:
System: Linux lux 2.6.9 #2 Tue Dec 28 22:27:56 CET 2004 i686 GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--enable-__cxa_atexit --with-system-zlib --enable-nls 
--without-included-gettext --enable-clocale=gnu --enable-debug 
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux

How-To-Repeat:
use this code to reproduce it
--- code ---
#include 
#include 
#define log2(val) (log((val))/log(2.0))
int main()
{   
  int n1=log2(8);
double d1=log2(8);
printf("%d %f\n",n1,d1);
return 0;
 }
--- end ---
--- Additional Comments From u dot strempel at gmx dot de  2005-09-22 15:44 
---
Fix:
For workaround I implemented a function for log2.

-- 
   Summary: casting int to double with got wrong result
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: u dot strempel at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug fortran/24144] New: segmentation fault in gfortran with character functions.

[gcc-bugzilla at gcc dot gnu dot org]

When compiling the given peace of fortran code I will get a segmentation fault.
With g77 there have been no problems on it.

The problem is independent of the used optimization level.

[EMAIL PROTECTED]:~/maint_gcc4/tools> /usr/local/bin/gfortran-4.0 -g -v 
-save-temps -c  test.f
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/root/gcc-4.0.2/configure --prefix=/usr/local 
--program-suffix=-4.0
Thread model: posix
gcc version 4.0.2
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.0.2/f951 test.f -ffixed-form -quiet 
-dumpbase test.f -mtune=pentiumpro -auxbase test -g -version -o test.s
GNU F95 version 4.0.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test.f: In function 'qfiopn':
test.f:20: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Environment:
System: Linux fs1 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 
athlon i386 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /scratch/root/gcc-4.0.2/configure --prefix=/usr/local 
--program-suffix=-4.0

How-To-Repeat:
  SUBROUTINE QFIOPN (TYPE,IDF, I R C)
  IMPLICIT NONE 
  INTEGER, INTENT(IN)   :: IDF
  INTEGER, INTENT(OUT)  :: IRC
  CHARACTER*(4), INTENT(IN)   :: TYPE
C---
C (C) Copyright INTES GmbH, Stuttgart, Germany   SEApr-19911
C!modHM-20-Jun-2005-11:03:46
  INTEGER   IUNIT,ISTAT
  CHARACTER*8   FIGOST,STAT
  CHARACTER*12  FIGACC,FIGFOR
  CHARACTER*96  FIGNAM
C---
  IRC= 0
  IF( FIGACC(TYPE,IDF) .NE. 'SEQUENTIAL' )THEN
  IRC = 5
CPER  FORTRAN open failed
  GOTO 999
  ENDIF
  STAT = FIGOST(TYPE,IDF)
C
C Open the sequential file for work
C
  OPEN( UNIT   = IUNIT  ,
 *  FILE   = FIGNAM(TYPE,IDF)   ,
 *  ACCESS = FIGACC(TYPE,IDF)   ,
 *  STATUS = STAT   ,
 *  FORM   = FIGFOR(TYPE,IDF)   ,
 *  ERR= 777,
 *  IOSTAT = ISTAT  )
  GOTO 999
  777 CONTINUE
  IRC = 6
  999 END
--- Additional Comments From manz at intes dot de  2005-09-30 13:02 ---
Fix:

If I add a temproara variable to store the result of the function call
FIGACC(TYPE,IDF) at the beginning and than use this variable on the 2 locations
wehere its realy used, it works, Also only using the OPEN statement also works.

-- 
   Summary: segmentation fault in gfortran with character functions.
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manz at intes dot de
CC: gcc-bugs at gcc dot gnu dot org
 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=24144

[Bug c++/24164] New: Explicit instantiation of template has no effect.

[gcc-bugzilla at gcc dot gnu dot org]

Here are three files that illustrate the problem.  
Header file "t.hpp":
namespace arrpp {

template 
class A {
public:
A();
};
}

File implementing class A, called t.cc:

#include "t.hpp"
template class arrpp::A;// instatiate class
template  arrpp::A:: A(){} // define ctor

File containing main, called xt.cc:
#include "t.hpp"
int main(int argc, char **argv) { arrpp::A x; }

Produce t.o and xt.o:
gcc -c t.cc xt.cc

Examine symbols in t.o:
nm t.o
(Produces no output, indicating that no symbols are defined.)

Try to link object files:
 gcc -o xt xt.o t.o -lstdc++
 xt.o: In function `main':
 xt.cc:(.text+0x24): undefined reference to `arrpp::A::A()'
 collect2: ld returned 1 exit status

On a machine with g++-3.3, this code works fine (links and runs, producing no
output).

Environment:
System: Linux dogwood 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls 
--without-included-gettext --enable-threads=posix --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --enable-checking=release i486-linux-gnu

How-To-Repeat:
See above.  Here is the preprocessor output for t.cc:

# 1 "t.cc"
# 1 ""
# 1 ""
# 1 "t.cc"
# 1 "t.hpp" 1
namespace arrpp {

template 
class A {
public:
 A();
};
}
# 2 "t.cc" 2

template class arrpp::A;

template 
arrpp::A::
A(){}

Here is the preprocessor output for xt.cc:

# 1 "xt.cc"
# 1 ""
# 1 ""
# 1 "xt.cc"
# 1 "t.hpp" 1
namespace arrpp {

template 
class A {
public:
 A();
};
}
# 2 "xt.cc" 2

int main(int argc, char **argv) {
arrpp::A x;
}
--- Additional Comments From rogers at anthro dot utah dot edu  2005-10-01 
17:04 ---
Fix:
Here is a patch for t.cc that provides a work-around.  It instantiates
the class by declaring a variable:

--- t.cc2005-10-01 10:53:33.038810604 -0600
+++ t2.cc   2005-10-01 10:53:47.335552612 -0600
@@ -1,6 +1,6 @@
 #include "t.hpp"
 
-template class arrpp::A;
+arrpp::A foo;
 
 template 
 arrpp::A::

-- 
   Summary: Explicit instantiation of template has no effect.
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogers at anthro dot utah dot edu
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug target/24334] New: [4.0/4.1 regression] IRIX 6.5 bootstrap failure with SGI 7.4.3m ld: GOT overflow

[gcc-bugzilla at gcc dot gnu dot org]

Bootstrapping both the 4.0 branch as of 20050928 and mainline as of
20051004 fails on IRIX 6.5.26f with SGI ld from MIPSpro 7.4.3m:

gcc   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
   -DHAVE_CONFIG_H  -o cc1 \
c-parse.o c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o
c-objc-common.o c-dump.o c-pch.o  c-gimplify.o tree-mudflap.o c-pretty-print.o
main.o  libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a  
../libiberty/libiberty.a
ld32: WARNING 84 : ../libcpp/libcpp.a is not used for resolving any symbol.
ld32: WARNING 47 : This module (libbackend.a(fold-const.o) .text) contains
branch instruction(s)
   that might degrade performance on an older version (rev.
2.2) R4000 processor.
ld32: INFO171: Multigot invoked. Gp relative region broken up into 2
separate regions.
ld32: ERROR   97 : GOT overflow in
/amnt/figaro/volumes/obj-gcc/gcc/obj.irix5/gnat/3.4.5/6.5/bin/../lib/gcc/mips-sgi-irix6.5/3.4.5/crtbegin.o.
 
See the dso(5) manpage.
ld32: ERROR   97 : GOT overflow in c-parse.o. 
See the dso(5) manpage.
[... many more omitted]
ld32: INFO152: Output file removed because of error.
collect2: ld returned 2 exit status
make[2]: *** [cc1] Error 1

This is a regression both from the 3.4 branch (which currently bootstraps
with the same toolset successfully) and both branches (where I could
bootstrap the 4.0 branch on 20050414 and mainline on 20050527) with the
same toolset.

Environment:
System: IRIX sculptor 6.5 10060437 IP32



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gnu/src/gcc/gcc-4.0-branch-dist/configure
--prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.15 --enable-libgcj --disable-multilib
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,f95,java,objc,ada

How-To-Repeat:
Bootstrap as described above.


-- 
   Summary: [4.0/4.1 regression] IRIX 6.5 bootstrap failure with SGI
7.4.3m ld: GOT overflow
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug c++/24386] New: 4.1: wrong virtual function called in template member

[gcc-bugzilla at gcc dot gnu dot org]

The cvs head of g++ 4.1 miscompiles the following program:


extern "C" int printf(...);
struct A
{
  virtual void foo () { printf ("A::foo\n"); }
};
struct B : public A
{
  virtual void foo () { printf ("B::foo\n"); }
};

template 
void f(T a)
{
  ((A*)a)->A::foo();
}

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


I expect this program to print `A::foo'.  But instead, it prints:

$ g++ -o x x.cc
$ ./x
B::foo
$

This worked correctly as of the cvs version from a couple weeks ago.
It also works correctly if f() is made into a non-template function.

Here is the dump of f() from the 02.original tree dump, just to verify
that the problem is upstream of here:

;; Function void f(T) [with T = B*] (_Z1fIP1BEvT_)
;; enabled by -tree-original

_vptr.A>;&a->D.1746->0)
(&a->D.1746) >>>
>>;

It's doing a virtual function call, rather than calling A::foo directly.


The problem seems to have been introduced by this change:

2005-10-12  Nathan Sidwell  <[EMAIL PROTECTED]>

PR c++/21592
* pt.c (build_non_dependent_expr): Don't wrap a COMPONENT_REF
with already looked up member functions.  Assert we're not
returning a NON_DEPENDENT_EXPR with unknown type.
* typeck.c (finish_class_member_access_expr):  We can get
non-template-id-expr baselinks.  If the lookup finds a baselink,
remember it even inside templates.

If i revert this change, then the test case is compiled correctly.

Environment:
System: Linux karma 2.6.12.1sss #2 Thu Jul 7 00:28:21 EDT 2005 i686 i686 i386
GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc
--enable-threads=posix --enable-long-long --enable-languages=c,c++,f95

How-To-Repeat:

See above.


-- 
   Summary: 4.1: wrong virtual function called in template member
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snyder at fnal dot gov
 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=24386

[Bug c++/2350] No warning for referencing a temporary

[gcc-bugzilla at gcc dot gnu dot org]

--- Comment #6 from neroden at gcc dot gnu dot org  2003-05-23 06:02 ---
confirmed dupe.


-- 

neroden at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED


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

[Bug c++/4409] Internal Compiler Error

[gcc-bugzilla at gcc dot gnu dot org]

--- Comment #2 from from-classpath at savannah dot gnu dot org  2003-07-22 
17:16 ---
I've checked in a fix for this.


-- 


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

[Bug c++/8701] Internal compiler error in expand_call, at calls.c:3049

[gcc-bugzilla at gcc dot gnu dot org]

--- Comment #6 from bangerth at dealii dot org  2003-06-11 22:18 ---
*** Bug 8240 has been marked as a duplicate of this bug. ***


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||philipp dot berndt at gmx
   ||dot net


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