[Bug c++/26116] New: Optimizer regression from v3 to v4
Prior to the 4.* series compilers, the following code :
char tell_endian()
{
unsigned x = 1;
return *(char*)&x;
}
... used to produce a simple contant load to a register and return. The 4.x
compilers seem like they can no longer make this optimization. It used to be
very convenient because code written using this construct would automatically
eliminate code since it was correctly able to identify that the return value
from "tell_endian" is a constant, i.e.
if ( tell_endian() ) little_stuff() else big_stuff()
would generate code consistant with simply writing "little_stuff()" on little
endian systems (and visa versa).
--
Summary: Optimizer regression from v3 to v4
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gianni at mariani dot ws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26116
[Bug c++/26117] New: #EXE#2_1.cpp#Error of executing
gcc -o test.bin 2_1.cpp -w
test.bin
echo 127
127
Function main() must return 383, but return 127
cat 2_1.cpp
int main(){
unsigned x = 255, smallest, ripple, ones;
smallest = x & -x;
ripple = x + smallest;
ones = x ^ ripple;
ones = (ones >> 2) / smallest;
return ripple | ones;
}
--
Summary: #EXE#2_1.cpp#Error of executing
Product: gcc
Version: 2.95.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aplatovsky at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26117
[Bug c/26118] New: avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
there is a bug in avr-gcc (GCC) 3.4.5, that comes with the latest WinAVR distribution (20060125). The avr-gcc (GCC) 3.4.3, that comes with WinAVR 20050214 does NOT contain this bug. The bug exists with and without optimization (I tried -O0 and -Os) If you try to copy a structure with *struct_pointer = struct; the struct_pointer gets destroyed. The assembler code generated seems to add one structure length foreach copied byte to the pointer. The complete code is attached. (there I use *struct_pointer++, but it is the same problem there). -- Summary: avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cajus dot hahn at de dot abb dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug c/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #1 from cajus dot hahn at de dot abb dot com 2006-02-06 09:18 --- Created an attachment (id=10783) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10783&action=view) Complete project. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug fortran/26107] ICE after error message on invalid code
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-06 09:34 --- Confirmed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||monitored Last reconfirmed|-00-00 00:00:00 |2006-02-06 09:34:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26107
[Bug c++/26084] [gomp-branch] ICE (segfault) on C++ OpenMP code
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-06 09:40 --- I don't get a segfault, but the error message: bug.cc:11: internal compiler error: vector VEC(eh_region,base) index domain error, in can_throw_internal_1 at except.c:2580 Looks like a duplicate of PR 26076 to me. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26117] #EXE#2_1.cpp#Error of executing
--- Comment #1 from falk at debian dot org 2006-02-06 10:04 --- The return value of main() is interpreted in an implementation-defined way by the OS. Your OS (which you failed to mention) probably crops it to 7 bit. So this is not a gcc bug. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26117
[Bug fortran/26119] New: ICE on transpose with specific compiler option
In Mac OSX ver. 10.3, I got following internal compiler error. $ gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060129 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ cat ice.f90 subroutine foo(wk0,g1,g2,ia0,ia1,n2) implicit none integer :: n2 double precision :: a3(3,3) double precision :: a4(3,3) character*72 :: g1(n2) character*72 :: g2(n2) integer :: ia0 integer :: ia1 double precision :: wk0(3) integer :: g,ia2,ia3,ia4,ia5,ia6,ia7,ia8,ia9,j,k,k1,k2,n integer :: wk2(3),wk3(n2),wk6(1) double precision :: a1(3,3),a2(3,3),wk1(n2),wk4(3),wk5(3) double precision :: a5(n2,3) , b wk1(1:3) = 0.0 do k=1,n call f(.true., a3(:,:), g1(ia9), a1, wk4 ,0, 0) call f(.true., a3(:,:), g2(ia9), a2, wk5, 0, 0) if (g(a1,wk4) == 0) return a1 = MATMUL(TRANSPOSE(a4) , a5) enddo if (b < 1.0) then k1 = 0 k2 = 0 b = 1.0 ia2 = 1 ia3 = 1 ia5 = 1 ia6 = 1 ia7 = 1 ia8 = 1 j = 1 wk1(1:4) = wk1(wk3(1:4)) wk2(1) = 1 wk6 = maxloc(wk1(1:3)) endif end subroutine $ gfortran -c -ggdb ice.f90 ice.f90: In function 'foo': ice.f90:21: internal compiler error: in gfc_conv_array_transpose, at fortran/trans-array.c:718 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE on transpose with specific compiler option Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26119
[Bug c++/26120] New: mudlap behavior changes with trivial changes to build command
The following two build commands yield executables with different mudflap
behavior, which seems like a bug to me:
g++ -c -fmudflap -o hello.o hello.cpp ; g++f4 -o hello hello.o -lmudflap
g++ -fmudflap -o hello hello.cpp -lmudflap
Here's the source for hello.cpp:
#include
#include
int main(int argc, char *argv[])
{
errno = 1;
printf("%d %s\n", errno, argv[0]);
printf("Hello, world!\n");
return 0;
}
Using gcc from svn from 2006-02-03:
{65} g++ -c -fmudflap -o hello.o hello.cpp ; g++f4 -o hello hello.o -lmudflap
{66} ./hello
***
mudflap violation 1 (check/write): time=1139021256.756465 ptr=0xb7e926a0 size=4
pc=0xb7ebc322 location=`hello.cpp:6 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7ebc322]
./hello(main+0x92) [0x8048776]
/lib/tls/libc.so.6(__libc_start_main+0xd3) [0xbdae23]
number of nearby objects: 0
***
mudflap violation 2 (check/read): time=1139021256.757309 ptr=0xbf898d64 size=4
pc=0xb7ebc322 location=`hello.cpp:7 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7ebc322]
./hello(main+0x117) [0x80487fb]
/lib/tls/libc.so.6(__libc_start_main+0xd3) [0xbdae23]
number of nearby objects: 0
***
mudflap violation 3 (check/read): time=1139021256.757390 ptr=0xb7e926a0 size=4
pc=0xb7ebc322 location=`hello.cpp:7 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0xb7ebc322]
./hello(main+0x1a0) [0x8048884]
/lib/tls/libc.so.6(__libc_start_main+0xd3) [0xbdae23]
number of nearby objects: 0
1 ./hello
Hello, world!
{67} g++ -fmudflap -o hello hello.cpp -lmudflap
{68} ./hello
1 ./hello
Hello, world!
I built on a P4 running Fedora Core 3 with the svn version of gcc.
--
Summary: mudlap behavior changes with trivial changes to build
command
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: idht4n at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug c++/26120] mudlap behavior changes with trivial changes to build command
--- Comment #1 from idht4n at hotmail dot com 2006-02-06 10:22 --- In my original report, g++f4 is the same as g++ and are both svn 2006-02-03 versions. Sorry for any confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug rtl-optimization/26069] [4.0/4.1/4.2 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-06 10:34 --- *** Bug 26116 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gianni at mariani dot ws http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug c++/26116] Optimizer regression from v3 to v4
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-06 10:34 --- *** This bug has been marked as a duplicate of 26069 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26116
[Bug c++/26084] [gomp-branch] ICE (segfault) on C++ OpenMP code
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-02-06 11:15 --- (In reply to comment #3) > I don't get a segfault, but the error message: > > bug.cc:11: internal compiler error: vector VEC(eh_region,base) index domain > error, in can_throw_internal_1 at except.c:2580 I still get the segmentation fault. Probably because I configured with --enable-checking=release... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26114] [4.2 Regression] g++.dg/init/ctor4.C and g++.old-deja/g++.jason/overload34.C and g++.old-deja/g++.mike/p11110.C fails
--- Comment #3 from hp at gcc dot gnu dot org 2006-02-06 11:50 --- Confirmed for mmix-knuth-mmixware, cris-axis-elf and cris-axis-linux-gnu, passes with 110520, fails with 110613. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 11:50:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26114
[Bug c++/26115] [4.2 Regression] bogus warning for g++.dg/parse/register1.C
--- Comment #2 from hp at gcc dot gnu dot org 2006-02-06 11:51 --- Confirmed for mmix-knuth-mmixware, cris-axis-elf and cris-axis-linux-gnu, passes with 110520, fails with 110613. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 11:51:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26115
[Bug c++/26122] New: [4.0/4.1/4.2 regression] Pure specifiers for templates causing trouble
The following invalid code snippet is accepted by GCC since at least
GCC 2.95.3:
struct A
{
template void foo() = 0;
};
A similar code snippet causes an ICE since GCC 4.0.0:
struct A
{
template void foo() = 1;
};
bug.cc:3: internal compiler error: in grokfield, at cp/decl2.c:899
Please submit a full bug report, [etc.]
It was rejected before, but only because the pure specifier was malformed,
and not because it was present at all:
bug.cc:3: error: invalid initializer for virtual method `void A::foo()'
--
Summary: [4.0/4.1/4.2 regression] Pure specifiers for templates
causing trouble
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26122
[Bug libstdc++/26123] New: Segmentation fault in constructor of std::ostream::sentry::sentry
When compiled with:
g++-4.0 -g -Wall -c -o try.o try.cc
g++-4.0 -g -Wall -c -o foo.o foo.cc
g++-4.0 -g -Wall -o try try.o foo.o
the program below creates a segmentation fault.
UNIX> gdb ./try
(gdb) r
Starting program: /data/home/osb/temp/clcpp/try
Program received signal SIGSEGV, Segmentation fault.
0xb7f83de5 in std::ostream::sentry::sentry () from /usr/lib/libstdc++.so.6
try.h
=
#ifndef TRY_H
#define TRY_H
int mkCint();
const int cInt = mkCint();
#endif
try.cc
==
#include "try.h"
#include
int main()
{
std::cout << cInt << std::endl;
}
int mkCint()
{
std::cout << "mkCint()" << std::endl;
return 2;
}
foo.cc
==
#include "try.h"
Notes
If stdout instead of std::cout is used OR
if compiled with g++-3.3 the program runs as expected:
UNIX> ./try
mkCint()
mkCint()
2
UNIX>
--
Summary: Segmentation fault in constructor of
std::ostream::sentry::sentry
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: broeni at osb-systems 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=26123
[Bug c++/26122] [4.0/4.1/4.2 regression] Pure specifiers for templates causing trouble
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:46 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 12:46:29 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26122
[Bug libstdc++/26124] New: Segmentation fault in constructor of std::ostream::sentry::sentry
When compiled with:
g++-4.0 -g -Wall -c -o try.o try.cc
g++-4.0 -g -Wall -c -o foo.o foo.cc
g++-4.0 -g -Wall -o try try.o foo.o
the program below creates a segmentation fault.
UNIX> gdb ./try
(gdb) r
Starting program: /data/home/osb/temp/clcpp/try
Program received signal SIGSEGV, Segmentation fault.
0xb7f83de5 in std::ostream::sentry::sentry () from /usr/lib/libstdc++.so.6
try.h
=
#ifndef TRY_H
#define TRY_H
int mkCint();
const int cInt = mkCint();
#endif
try.cc
==
#include "try.h"
#include
int main()
{
std::cout << cInt << std::endl;
}
int mkCint()
{
std::cout << "mkCint()" << std::endl;
return 2;
}
foo.cc
==
#include "try.h"
Notes
If stdout instead of std::cout is used OR
if compiled with g++-3.3 the program runs as expected:
UNIX> ./try
mkCint()
mkCint()
2
UNIX>
--
Summary: Segmentation fault in constructor of
std::ostream::sentry::sentry
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: broeni at osb-systems 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=26124
[Bug libstdc++/26124] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:51 --- *** This bug has been marked as a duplicate of 26123 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26124
[Bug libstdc++/26123] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:51 --- *** Bug 26124 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug libstdc++/26123] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 12:54 ---
foo.cc has nothing to do with the problem here. It all has to do with the
order of the execution of the initializers.
The following code is enough to reproduce the issue:
int mkCint();
const int cInt = mkCint();
#include
int main()
{
std::cout << cInt << std::endl;
}
int mkCint()
{
std::cout << "mkCint()" << std::endl;
return 2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug tree-optimization/26125] New: g++.dg/opt/complex5.C:11: ICE: Segmentation fault
Executing on host: /test/gnu/gcc-4.1/objdir/gcc/testsuite/../g++
-B/test/gnu/gcc
-4.1/objdir/gcc/testsuite/../
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/com
plex5.C -nostdinc++
-I/test/gnu/gcc-4.1/objdir/hppa2.0w-hp-hpux11.11/libstdc++-
v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc-4.1/objdir/hppa2.0w-hp-hpux11.1
1/libstdc++-v3/include -I/test/gnu/gcc-4.1/gcc/libstdc++-v3/libsupc++
-I/test/gn
u/gcc-4.1/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc-4.1/gcc/libstdc++-v3
/testsuite -fmessage-length=0 -O2 -S -o complex5.s(timeout = 300)
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/complex5.C: In function 'double
_
_complex__ elt_zero()':
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/complex5.C: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.
compiler exited with status 1
output is:
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/complex5.C: In function 'double
_
_complex__ elt_zero()':
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/complex5.C:11: internal compiler
error: Segmentation fault
(gdb) r `cat xx.sh`
Starting program: /test/gnu/gcc-4.1/objdir/gcc/cc1plus `cat xx.sh`
Detaching after fork from child process 19856.
GNU C++ version 4.1.0 20060205 (prerelease) (hppa2.0w-hp-hpux11.11)
compiled by GNU C version 4.1.0 20060205 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed: -nostdinc++
-I/test/gnu/gcc-4.1/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc-4.1/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc-4.1/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc-4.1/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc-4.1/gcc/libstdc++-v3/testsuite -iprefix -isystem
-auxbase-strip -O2 -fmessage-length=0
options enabled: -falign-loops -fargument-alias -fbranch-count-reg
-fcaller-saves -fcommon -fcprop-registers -fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks -fdefer-pop -fdelayed-branch
-fdelete-null-pointer-checks -fearly-inlining
-feliminate-unused-debug-types -fexceptions -fexpensive-optimizations
-ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident
-fif-conversion -fif-conversion2 -finline-functions-called-once
-fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
-fkeep-static-consts -fleading-underscore -floop-optimize -floop-optimize2
-fmath-errno -fmerge-constants -fomit-frame-pointer
-foptimize-register-move -foptimize-sibling-calls -fpeephole -fpeephole2
-freg-struct-return -fregmove -freorder-blocks -freorder-functions
-frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
-fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2 -fshow-column
-fsplit-ivs-in-unroller -fstrength-reduce -fstrict-aliasing -fthread-jumps
-ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
-ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-pre
-ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
-ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp
-funit-at-a-time -fvar-tracking -fzero-initialized-in-bss -mbig-switch
-mgas -mspace-regs
Compiler executable checksum: c122a4c335979b8f0ae5e70db9004734
double __complex__ to_complex(double) double __complex__ elt_zero()
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
double __complex__ elt_zero()
Program received signal SIGSEGV, Segmentation fault.
0x0026d820 in simple_iv_increment_p (stmt=0x0)
at ../../gcc/gcc/tree-ssa-dom.c:1739
1739 if (TREE_CODE (phi) != PHI_NODE)
(gdb) bt
#0 0x0026d820 in simple_iv_increment_p (stmt=0x0)
at ../../gcc/gcc/tree-ssa-dom.c:1739
#1 0x00271784 in optimize_stmt (walk_data=0x0, bb=0x400246a0, si=
{tsi = {ptr = 0x7ae89e80, container = 0x7ae8f450}, bb = 0x7adf0960})
at ../../gcc/gcc/tree-ssa-dom.c:2558
#2 0x003be2e8 in walk_dominator_tree (walk_data=0x7eff0dc8, bb=0x7adf0960)
at ../../gcc/gcc/domwalk.c:196
#3 0x003be0e8 in walk_dominator_tree (walk_data=0x7eff0dc8, bb=0x7adf08c0)
at ../../gcc/gcc/domwalk.c:212
#4 0x0026dce8 in tree_ssa_dominator_optimize ()
at ../../gcc/gcc/tree-ssa-dom.c:446
#5 0x002216d0 in execute_one_pass (pass=0x400657e8)
at ../../gcc/gcc/passes.c:827
#6 0x00221824 in execute_pass_list (pass=0x400657e8)
at ../../gcc/gcc/passes.c:859
#7 0x00221838 in execute_pass_list (pass=0x40007338)
at ../../gcc/gcc/passes.c:860
#8 0x0010e7ec in tree_rest_of_compilation (fndecl=0x7ae8c700)
at ../../gcc/gcc/tree-optimize.c:419
#9 0x000a8db8 in expand_body (fn=0x7ae8c700)
at ../../gcc/gcc/cp/semantics.c:3014
#10 0x0023db9c in cgraph_expand_function (node=0x7ae8c780)
at ../../gcc/gcc/cgraphunit.c:1055
---Type to continue, or q to quit---
#11 0x0023e444 in cgraph_optimize () at ../../gcc/gcc/cgraph
[Bug libstdc++/26123] [3.4/4.0/4.1/4.2 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 12:56 --- Confirmed, though I don't know if this is just undefined code or not. Also the global initializer between 3.3 and 3.4 (and 4.0/4.1/4.2) did not change so I don't think this is a front-end bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-02-06 12:56:45 date|| Summary|Segmentation fault in |[3.4/4.0/4.1/4.2 Regression] |constructor of |Segmentation fault in |std::ostream::sentry::sentry|constructor of ||std::ostream::sentry::sentry Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|g++.dg/opt/complex5.C:11: |[4.1 Regression] |ICE: Segmentation fault |g++.dg/opt/complex5.C:11: ||ICE: Segmentation fault Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug c++/26120] mudlap behavior changes with trivial changes to build command
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 13:01 --- It worked in "4.1.0 20051026". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-06 13:02 --- Subject: Re: New: g++.dg/opt/complex5.C:11: ICE: Segmentation fault The test was ok on 20060203: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00222.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug libstdc++/26123] [3.4/4.0/4.1/4.2 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #4 from pcarlini at suse dot de 2006-02-06 13:10 --- For some reason, on x86-linux, I can reproduce only with 3.4 and 4.0, not with mainline and 4.1... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-06 13:13 --- Oh, I was using 4.0.2's shared library still when testing, woops. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i486-pc-linux-gnu | GCC host triplet|i486-pc-linux-gnu | GCC target triplet|i486-pc-linux-gnu | Known to fail|3.4.0 4.0.0 4.1.0 4.2.0 |3.4.0 4.0.0 4.0.2 Known to work|3.3.3 |3.3.3 4.1.0 4.2.0 Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4/4.0 Regression] |Segmentation fault in |Segmentation fault in |constructor of |constructor of |std::ostream::sentry::sentry|std::ostream::sentry::sentry http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug fortran/26119] ICE on transpose with specific compiler option
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 13:14 --- Confirmed, I only get the failures on powerpc-darwin and not on x86_64-linux-gnu for some reason. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||powerpc-darwin Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-02-06 13:14:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26119
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #6 from pcarlini at suse dot de 2006-02-06 13:16 --- Ok. mainline is also confirmed fine on ia64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug other/13906] genmodes.c:964: internal compiler error: Bus error in md5_process_block
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-06 13:49 --- Subject: Bug 13906 Author: ghazi Date: Mon Feb 6 13:49:41 2006 New Revision: 110642 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110642 Log: include: Backport: 2006-01-18 DJ Delorie <[EMAIL PROTECTED]> * md5.h: Include ansidecl.h 2005-07-03 Steve Ellcey <[EMAIL PROTECTED]> PR other/13906 * ansidecl.h (ATTRIBUTE_ALIGNED_ALIGNOF): New. * md5.h (md5_uintptr): New. (md5_ctx): Align buffer field. libiberty: Backport: 2005-07-03 Steve Ellcey <[EMAIL PROTECTED]> PR other/13906 * md5.c (md5_process_bytes): Check alignment. Modified: branches/gcc-4_0-branch/include/ChangeLog branches/gcc-4_0-branch/include/ansidecl.h branches/gcc-4_0-branch/include/md5.h branches/gcc-4_0-branch/libiberty/ChangeLog branches/gcc-4_0-branch/libiberty/md5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13906
[Bug fortran/24557] ICE: PRINTing function result of size depending on assumed length CHARACTER dummy
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 13:51 --- Assigning to Paul based on a request made in a private email. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24557
[Bug libstdc++/26127] New: tr1/hashtable compile errors
There are a couple of minor errors in tr1/hashtable that cause some of the rarely-instantiated members defined in TR1 (http://open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf) not to compile, eg: std::tr1::unordered_set< int > s; s.key_eq();// Not declared: // error: 'class std::tr1::unordered_set, // std::equal_to, std::allocator, false>' has no member // named 'key_eq' // (The function simply isn't there.) s.bucket(42); // Implementation fails to compile: // /opt/gcc-svn/trunk/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/tr1/hashtable:1099: // error: no matching function for call to 'std::tr1::hashtable, Internal::identity, std::equal_to, // std::tr1::hash, Internal::mod_range_hashing, // Internal::default_ranged_hash, Internal::prime_rehash_policy, false, false, // true>::bucket_index(const int&, , const size_t&) const // (Missing parentheses on function call.) s.max_load_factor(); // /opt/gcc-svn/trunk/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/tr1/hashtable:656: error: base operand of '->' has non-pointer type 'const Internal::prime_rehash_policy' // (member access using -> instead of .) The above applies to the 4.0 branch and current trunk. (Line numbers above are from trunk.) Patches to follow. -- Summary: tr1/hashtable compile errors Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug target/16798] PowerPC - Opportunity to use recording form instruction.
--- Comment #4 from bonzini at gnu dot org 2006-02-06 14:06 ---
More precisely, combine is attempting to do instruction selection, and in the
case of this bug it cannot.
A similar ARM test case is
int f (int a, int b)
{
int s = a - b;
int t = a < b ? a : s;
x = s;
y = t;
}
which should be something like (pseudo-assembly)
rsbs s, b, a
str [x], s
movlt s, a
str [y], t
it is possible to teach the combiner about this reduced testcase, but it won't
match in the full testcase from which this was extracted, because s is used
between its definition and the definition of t.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16798
[Bug other/13906] genmodes.c:964: internal compiler error: Bus error in md5_process_block
--- Comment #9 from ghazi at gcc dot gnu dot org 2006-02-06 14:06 --- Subject: Bug 13906 Author: ghazi Date: Mon Feb 6 14:06:55 2006 New Revision: 110643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110643 Log: include: Backport: 2006-01-18 DJ Delorie <[EMAIL PROTECTED]> * md5.h: Include ansidecl.h 2005-07-03 Steve Ellcey <[EMAIL PROTECTED]> PR other/13906 * ansidecl.h (ATTRIBUTE_ALIGNED_ALIGNOF): New. * md5.h (md5_uintptr): New. (md5_ctx): Align buffer field. libiberty: Backport: 2005-07-03 Steve Ellcey <[EMAIL PROTECTED]> PR other/13906 * md5.c (md5_process_bytes): Check alignment. Modified: branches/gcc-3_4-branch/include/ChangeLog branches/gcc-3_4-branch/include/ansidecl.h branches/gcc-3_4-branch/include/md5.h branches/gcc-3_4-branch/libiberty/ChangeLog branches/gcc-3_4-branch/libiberty/md5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13906
[Bug other/13906] genmodes.c:964: internal compiler error: Bus error in md5_process_block
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-06 14:07 --- Fix backported to 3.4 and 4.0. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Target Milestone|4.1.0 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13906
[Bug libstdc++/26127] tr1/hashtable compile errors
--- Comment #1 from chris at bubblescope dot net 2006-02-06 14:19 --- Yep, these both look like fairly obvious errors to me. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug other/25567] 4 * set but never used
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:33 --- Most of them will be fixed by: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html (I Had forgot the tree-outof-ssa.c variable when I submitted the patch). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25567
[Bug libstdc++/26127] tr1/hashtable compile errors
-- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 14:33:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug middle-end/25547] 3 * dead data in compiler source code
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:33 --- Most of them will be fixed by: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html I still have to decide if we want to remove ggc_stats or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25547
[Bug c++/26117] #EXE#2_1.cpp#Error of executing
--- Comment #2 from aplatovsky at mail dot ru 2006-02-06 14:41 --- . -- aplatovsky at mail dot ru changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26117
[Bug target/25917] [4.0/4.2 Regression] gcc.c-torture/compile/20051228-1.c fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:51 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00139.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00139.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-02-06 14:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug regression/26128] New: Regression vs 4.1.0cvs20051015 - Trivial operation not vectorized
char a[16] __attribute__((aligned)) = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16};
char b[16] __attribute__((aligned)) = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16};
char c[16] __attribute__((aligned));
int i;
for(i = 0; i<16; i++)
{
c[i] = a[i] + b[i];
}
for(i = 0; i<16; i++)
{
printf("%i ", c[i]);
}
This code is not vectorized anymore in GCC 4.2.0 (svn checkout on Feb, 06
2006). The vectorizer tells that :
paddb4bugreport.c:14: note: vect_is_simple_use: operand (unsigned char)
D.1872_47
paddb4bugreport.c:14: note: not ssa-name.
paddb4bugreport.c:14: note: use not simple.
paddb4bugreport.c:14: note: not vectorized: relevant stmt not supported:
D.1873_48 = (unsigned char) D.1872_47
paddb4bugreport.c:14: note: bad operation or unsupported loop
bound.(get_loop_exit_condition
if (ivtmp.52_2 != 0) goto ; else goto ;)
Seems to be a problem before the autovectorizer as the (unsigned char) cast
should not happen IMHO.
--
Summary: Regression vs 4.1.0cvs20051015 - Trivial operation not
vectorized
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hurbain at cri dot ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26128
[Bug tree-optimization/26128] Trivial operation not vectorized on char
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:00 --- Actually this is a known regression and a missed optimization regression caused by fixing up wrong code. The work around is to use -fwrapv. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|regression |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-02-06 15:00:36 date|| Summary|Regression vs |Trivial operation not |4.1.0cvs20051015 - Trivial |vectorized on char |operation not vectorized| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26128
[Bug c++/26129] New: g++.dg/init/ctor4.C:11: warning: non-static reference 'int& bar::a' in class without a constructor
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++/../../g++ -B/mnt/gn u/gcc-3.3/objdir/gcc/testsuite/g++/../../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++ .dg/init/ctor4.C -nostdinc++ -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/li bstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-h pux11.11/libstdc++-v3/include -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/libsupc++ -I/m nt/gnu/gcc-3.3/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc-3.3/gcc/libstdc+ +-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S - o ctor4.s(timeout = 300) /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:11: warning: non-static r eference 'int& bar::a' in class without a constructor /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C: In constructor 'bar::bar ()': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:9: error: uninitialized r eference member 'bar::a' /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C: In function 'int main(in t, char**)': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:19: note: synthesized met hod 'bar::bar()' first required here compiler exited with status 1 output is: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:11: warning: non-static r eference 'int& bar::a' in class without a constructor /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C: In constructor 'bar::bar ()': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:9: error: uninitialized r eference member 'bar::a' /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C: In function 'int main(in t, char**)': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:19: note: synthesized met hod 'bar::bar()' first required here PASS: g++.dg/init/ctor4.C (test for errors, line 9) PASS: g++.dg/init/ctor4.C (test for errors, line 19) FAIL: g++.dg/init/ctor4.C (test for excess errors) Excess errors: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/init/ctor4.C:11: warning: non-static r eference 'int& bar::a' in class without a constructor This is as new fail in the last couple of days. The same fail also occurs in these tests: FAIL: g++.old-deja/g++.jason/overload34.C (test for excess errors) Excess errors: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++.jason/overload34.C:5: warnin g: non-static reference 'int& X::flag' in class without a constructor FAIL: g++.old-deja/g++.mike/p0.C (test for excess errors) Excess errors: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++.mike/p0.C:16: warning: n on-static reference 'conatiner& user::_c' in class without a constructor -- Summary: g++.dg/init/ctor4.C:11: warning: non-static reference 'int& bar::a' in class without a constructor Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26129
[Bug c++/26129] g++.dg/init/ctor4.C:11: warning: non-static reference 'int& bar::a' in class without a constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:02 --- This is a dup of bug 26114. *** This bug has been marked as a duplicate of 26114 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26129
[Bug c++/26114] [4.2 Regression] g++.dg/init/ctor4.C and g++.old-deja/g++.jason/overload34.C and g++.old-deja/g++.mike/p11110.C fails
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-06 15:02 --- *** Bug 26129 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26114
[Bug c++/26130] New: FAIL: g++.dg/parse/register1.C (test for excess errors)
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++/../../g++ -B/mnt/gn u/gcc-3.3/objdir/gcc/testsuite/g++/../../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++ .dg/parse/register1.C -nostdinc++ -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11. 11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w -hp-hpux11.11/libstdc++-v3/include -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/libsupc++ -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc-3.3/gcc/lib stdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o register1.s(timeout = 300) /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/parse/register1.C: In function 'C f(C) ': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/parse/register1.C:13: warning: address requested for 'x', which is declared 'register' output is: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/parse/register1.C: In function 'C f(C) ': /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/parse/register1.C:13: warning: address requested for 'x', which is declared 'register' FAIL: g++.dg/parse/register1.C (test for excess errors) Excess errors: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.dg/parse/register1.C:13: warning: address requested for 'x', which is declared 'register' The same error also occurs in this test: FAIL: g++.old-deja/g++.brendan/warnings4.C (test for excess errors) Excess errors: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++.brendan/warnings4.C:7: warni ng: address requested for 'x', which is declared 'register' This is a new fail in the last couple of days. -- Summary: FAIL: g++.dg/parse/register1.C (test for excess errors) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26130
[Bug libstdc++/26131] New: TR1 unordered associative containers: insert with hint returns wrong type
The TR1 specification of insert(iterator, value_type) on unordered associative containers states that it returns an iterator (as for ordered associative containers). However the current implementation returns std::pair instead in the case of unique keys. Patch to follow. -- Summary: TR1 unordered associative containers: insert with hint returns wrong type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
[Bug c++/26130] FAIL: g++.dg/parse/register1.C (test for excess errors)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:05 --- *** This bug has been marked as a duplicate of 26115 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26130
[Bug c++/26115] [4.2 Regression] bogus warning for g++.dg/parse/register1.C
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 15:05 --- *** Bug 26130 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26115
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-02-06 15:07 ---
I think this is undefined. Reduced testcase:
extern "C" void *malloc(__SIZE_TYPE__ n);
int mkCint();
const int cInt = mkCint();
struct Ptr {
Ptr() { ptr = (int *)malloc(sizeof(int)); }
int *ptr;
};
Ptr p;
int main()
{
*p.ptr = mkCint();
}
int mkCint()
{
return *p.ptr;
}
how should we know to initialize std::cout first?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug libstdc++/26132] New: tr1/hashtable: rehash not implemented
Attempting to call rehash produces a link error: std::tr1::unordered_set< int > s; s.rehash(42); // undefined reference to `std::tr1::hashtable, // Internal::identity, std::equal_to, std::tr1::hash, // Internal::mod_range_hashing, Internal::default_ranged_hash, // Internal::prime_rehash_policy, false, true, true>::rehash(unsigned int)' -- Summary: tr1/hashtable: rehash not implemented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-06 15:13 --- Dom -> Jeff. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug c++/26122] [4.0/4.1/4.2 regression] Pure specifiers for templates causing trouble
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-06 15:14
---
Btw, we also fail to diagnose the following invalid code snippet:
=
template struct A
{
void foo() = 0;
};
=
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26122
[Bug libstdc++/26131] TR1 unordered associative containers: insert with hint returns wrong type
--- Comment #1 from pcarlini at suse dot de 2006-02-06 15:16 --- This is already fixed for mainline and 4.1.0, will not fix in 4_0-branch. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
[Bug libstdc++/26131] TR1 unordered associative containers: insert with hint returns wrong type
--- Comment #2 from zak at transversal dot com 2006-02-06 15:18 --- Sorry, my mistake -- I thought I had checked this on both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
[Bug libstdc++/26132] tr1/hashtable: rehash not implemented
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 15:19:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
[Bug libstdc++/26133] New: unique_copy requires assignability when using output iterators
unique_copy is overloaded on forward- and output_iterators for the result iterator; the output_iterator version requires Assignability on the input's value_type, which isn't required by the resolution to DR #241: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241 I'll attach a demonstration, which compiles on at least one other implementation. When using only input AND only output iterators, implementations must keep a temporary copy somewhere; is the standard implying that implementations use placement new for that? -- Summary: unique_copy requires assignability when using output iterators Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: squell at alumina dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26133
[Bug libstdc++/26133] unique_copy requires assignability when using output iterators
--- Comment #1 from squell at alumina dot nl 2006-02-06 15:36 --- Created an attachment (id=10784) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10784&action=view) Test case Test case; the output should be "23". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26133
[Bug fortran/26119] ICE on transpose with specific compiler option
--- Comment #2 from kargl at gcc dot gnu dot org 2006-02-06 15:54 --- I've see this on amd64-*-freebsd. A brief debug session is described here. http://gcc.gnu.org/ml/fortran/2006-01/msg00413.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26119
[Bug tree-optimization/21417] Missed jump threading opportunity on trees
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 16:17 --- the load PRE issue has been fixed but DOM does not thread the jump for some reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417
[Bug tree-optimization/25553] Missed removal of load
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 16:19 --- (In reply to comment #2) > We should be able to create a PHI for this case. > > Hmm, maybe I don't understand load PRE but for some reason I thought it would > be able to do this case: This load PRE issue has been fixed. But the orginal testcase is not been fixed because it is a seperate optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25553
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-06 16:22 --- Subject: Re: [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault > Dom -> Jeff. I haven't checked this but it appears from the timing that Jason's change on 2006-02-03 introduced the failure. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug target/21169] [4.0 regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2
--- Comment #6 from dtemirbulatov at gmail dot com 2006-02-06 16:51 --- Created an attachment (id=10787) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10787&action=view) proposed patch >Can anybody do a regression hunt on mainline? I found original fix on the mainline. it is 2005-04-12 Richard Henderson <[EMAIL PROTECTED]> * config/i386/i386.c (ix86_prepare_sse_fp_compare_args): Split ... (ix86_expand_sse_fp_minmax): ... from ... (ix86_expand_fp_movcc): ... here. (ix86_expand_sse_movcc): Rewrite from ix86_split_sse_movcc. * config/i386/i386-protos.h: Update. * config/i386/i386.md (UNSPEC_IEEE_MIN, UNSPEC_IEEE_MAX): New. (sse_setccsf, sse_setccdf): Allow before reload. (movsfcc_1_sse_min, movsfcc_1_sse_max, movsfcc_1_sse): Remove. (movdfcc_1_sse_min, movdfcc_1_sse_max, movdfcc_1_sse): Remove. (ieee_sminsf3, ieee_smaxsf3, ieee_smindf3, ieee_smaxdf3): New. * config/i386/sse.md (andsf3, nandsf3, iorsf3, xorsf3): New. (anddf3, nanddf3, iordf3, xordf3): New. Attached patch was tested for i686-pc-linux-gnu and x86_64-unknown-linux-gnu including make check-gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
[Bug rtl-optimization/26069] [4.0/4.1/4.2 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #6 from gianni at mariani dot ws 2006-02-06 16:52 --- Just another data point. I tried both the original tell_endian() and the tell_endian_good() functions on the MS Visual Studio 2003 compiler and both generated: : 0: b0 01 mov$0x1,%al 2: c3 ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug middle-end/26134] New: fold *(float*)(&complex_float_var) into REALPART_EXPR
I was looking at some code which is mentioned to be in SPEC 2006 (I forgot
where I found the mentioning)
but anyways it has the following in it:
typedef _Complex float COMPLEX_FLOAT;
float real_part(COMPLEX_FLOAT a)
{
return *(float*)(&a);
}
This should be converted to:
float real_part(COMPLEX_FLOAT a)
{
return __real__ a;
}
So that the tree optimizers can work on it easier.
--
Summary: fold *(float*)(&complex_float_var) into
REALPART_EXPR
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug middle-end/26134] fold *(float*)(&complex_float_var) into REALPART_EXPR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 16:58 --- I am taking care of this one and the __imag__ part too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 16:58:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-02-06 17:05 --- The testcase also crashes on x86_64-unknown-linux-gnu with "-O -m32": complex5.C: In function 'double __complex__ elt_zero()': complex5.C:11: error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS REALPART_EXPR = r_1; complex5.C:11: internal compiler error: verify_ssa failed Please submit a full bug report, [etc.] Confirmed thusly. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||monitored Last reconfirmed|-00-00 00:00:00 |2006-02-06 17:05:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-06 17:07 --- (In reply to comment #4) > The testcase also crashes on x86_64-unknown-linux-gnu with "-O -m32": That exactly the same ICE at which the testcase was ICE before I fixed it the first time. I wonder why my fix no longer works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26125
[Bug rtl-optimization/15792] missed subreg optimization
--- Comment #7 from tony dot linthicum at amd dot com 2006-02-06 17:13 --- So do I, at least for the original code (i.e. test and test1). I'm curious, though, if you've tried the example that I listed above (foo). I still get subregs with that one, though I honestly don't recall at the moment whether or not it makes the register allocator screw up or not (I *think* it does, but I'd have to check). Either way, though, the presence of the subregs provides the needed fodder for RA badness so I'm curious if it's present in what you're working on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
[Bug tree-optimization/26135] New: store copyprop not effective
For (-O2 -fno-tree-dominator-opts -fno-tree-salias -fno-tree-sra)
int foo(int i)
{
struct { int i; int j; } a;
a.i = i;
return a.i;
}
store copyprop does not propagate i to the return stmt.
--
Summary: store copyprop not effective
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26135
[Bug tree-optimization/26135] store copyprop not effective
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-06 17:36 --- And I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at redhat dot com AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-06 17:36:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26135
[Bug middle-end/26134] fold *(float*)(&complex_float_var) into REALPART_EXPR
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 17:45 ---
This actually does not help the benchmark right away because we have:
static inline float
quantum_real(float _Complex a)
{
float *p = (float *) &a;
return p[0];
}
static inline float
quantum_imag(float _Complex a)
{
float *p = (float *) &a;
return p[1];
}
in the benchmark (this is GPL sofware by the way):
http://www.enyo.de/libquantum/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #14 from r dot emrich at de dot tecosim dot com 2006-02-06 17:58 --- Subject: Re: libgfortran build failure on mips-sgi-irix6.5 Okay, I will try! Is there a preprocessor macro defined, which identifies IRIX? As I see, there are two macros which are candidates IMHO: _SGI_SOURCE sgi, __sgi, __sgi__ any hints? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #15 from Ralf dot Wildenhues at gmx dot de 2006-02-06 18:24 --- (In reply to comment #8 by H. J. Lu) > See > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html > > I don't know how to do --disable-fast-install for gcc. > --enable-fast-install is totally wrong for ELF. It should > never be used for any ELF targets. I don't understand this comment. You seem to imply that libtool should not add DT_RPATH entries pointing to installed paths to libraries/executables in the build tree. But given --enable-fast-install, and given that there are no indirect library dependencies, this is the correct thing: both libraries and programs can be copied to their final location without relink and will work correctly. libtool creates a shell wrapper for uninstalled programs that does relink-upon-execution and adds DT_RPATH entries for all direct dependencies. Of course, given --enable-fast-install but *indirect* library dependencies inside the build tree, adding DT_RPATH entries with the installed paths would not work: the wrong indirect libs would be picked up. However, libtool could still solve this: all systems which support indirect library dependencies well (i.e.: GNU/Linux) have measures make both the link editing step work (-rpath-link) as well as relink-upon-execution (just put all paths for uninstalled indirect dependencies in the run path of the relinked executable). What am I missing? Cheers, Ralf -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-02-06 18:30 --- Here is the backtrace for this bug: Program received signal SIGSEGV, Segmentation fault. 0x080a4583 in gfc_conv_scalarized_array_ref (se=0xbfaf2924, ar=0x86f5d0c) at ../../../trunk/gcc/fortran/trans-array.c:1885 1885n = se->loop->order[0]; (gdb) where #0 0x080a4583 in gfc_conv_scalarized_array_ref (se=0xbfaf2924, ar=0x86f5d0c) at ../../../trunk/gcc/fortran/trans-array.c:1885 #1 0x080a4dfd in gfc_conv_array_ref (se=0xbfaf2924, ar=0x86f5d0c) at ../../../trunk/gcc/fortran/trans-array.c:1929 #2 0x080b2d87 in gfc_conv_expr (se=0xbfaf2924, expr=0x86f5cb0) at ../../../trunk/gcc/fortran/trans-expr.c:429 #3 0x080ba1df in gfc_conv_intrinsic_len (se=0xbfaf302c, expr=Variable "expr" is not available. ) at ../../../trunk/gcc/fortran/trans-intrinsic.c:2113 #4 0x080b61bf in gfc_conv_function_expr (se=0xbfaf302c, expr=Variable "expr" is not available. ) at ../../../trunk/gcc/fortran/trans-expr.c:2251 #5 0x080b26b9 in gfc_conv_expr (se=0xbfaf302c, expr=0x86f5bd8) at ../../../trunk/gcc/fortran/trans-expr.c:2614 #6 0x080b6a6a in gfc_trans_assignment (expr1=0x86f5968, expr2=0x86f5bd8) at ../../../trunk/gcc/fortran/trans-expr.c:3053 #7 0x080b6d09 in gfc_trans_assign (code=0x86f5ea8) at ../../../trunk/gcc/fortran/trans-expr.c:3115 #8 0x0809ffd8 in gfc_trans_code (code=0x86f5ea8) at ../../../trunk/gcc/fortran/trans.c:455 #9 0x080b0732 in gfc_generate_function_code (ns=0x86f4ef8) at ../../../trunk/gcc/fortran/trans-decl.c:2639 #10 0x08082ead in gfc_parse_file () at ../../../trunk/gcc/fortran/parse.c:2686 #11 0x0809f15d in gfc_be_parse_file (set_yydebug=0) at ../../../trunk/gcc/fortran/f95-lang.c:287 A more reduced testcase is: TYPE T CHARACTER(LEN=80) :: S(1) END TYPE T TYPE(T), POINTER :: TT PRINT *, LEN(TT % S) END -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-27 20:48:30 |2006-02-06 18:30:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug libgcj/16902] GIJ: Garbage collection related failure with interpreter
--- Comment #4 from mckinlay at redhat dot com 2006-02-06 18:38 --- You might need a multiprocessor or hyper-threaded machine to reproduce it. I was able to reproduce it with HEAD just now: $ while (true) do gij GCTest; done [20]: Success java.lang.LinkageError: field type mismatch with different loaders at GCTest$GCTest_Object. (GCTest.java:18) at GCTest.testObjChain (GCTest.java:245) at GCTest.run (GCTest.java:126) at java.lang.Thread.run (Thread.java:653) Caused by: java.lang.NoClassDefFoundError: this$0 at GCTest$GCTest_Object. (GCTest.java:18) ...3 more [41]: Failure: testObjChain: Caught exception: field type mismatch with different loaders -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902
[Bug target/23359] [4.1/4.2 regression] Many Solaris 10/x86 testsuite failures with native as: use of .word
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-06 18:39 --- Subject: Bug 23359 Author: pinskia Date: Mon Feb 6 18:39:30 2006 New Revision: 110657 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110657 Log: 2006-02-06 Andrew Pinski <[EMAIL PROTECTED]> PR target/23359 * config/i386/i386.md (trap): Use ASM_SHORT instead of .word. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23359
[Bug libgcj/16902] GIJ: Garbage collection related failure with interpreter
--- Comment #5 from mckinlay at redhat dot com 2006-02-06 18:41 --- Another example of failure: [5]: Success java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) [44]: Failure: testObjArray: Caught exception: null [44]: Success java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) [33]: Failure: testObjArray: Caught exception: null java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902
[Bug target/23359] [4.1/4.2 regression] Many Solaris 10/x86 testsuite failures with native as: use of .word
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-02-06 18:49 --- Subject: Bug 23359 Author: pinskia Date: Mon Feb 6 18:49:05 2006 New Revision: 110660 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110660 Log: 2006-02-06 Andrew Pinski <[EMAIL PROTECTED]> PR target/23359 * config/i386/i386.md (trap): Use ASM_SHORT instead of .word. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23359
[Bug target/23359] [4.1/4.2 regression] Many Solaris 10/x86 testsuite failures with native as: use of .word
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-02-06 18:49 --- Fixed, sorry for causing this in the first place. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23359
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #16 from hjl at lucon dot org 2006-02-06 19:03 --- Please read the summary line: "Wrong libgcc_s.so.1 is used by lt-gij". Ld.so will search DT_RPATH first for any shared libraries. If you have DT_RPATH entries pointing to installed paths to libraries/executables in the build tree, when you run such an executable in the build tree, the shared libraries in installed paths will be used, if they exist. That is the newly built shared libraries in the build tree may never be used. Sometimes it is fatal if the shared library in the installed path isn't 100% compatible with the newly built one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #8 from broeni at osb-systems dot com 2006-02-06 19:28 --- Posted code as from comment #2 to c.l.c++.m to verify if the initalization of std::cout is well defined (comment #3): "Initialization order of std::cout". Stephan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug fortran/26136] New: namelist doesn't work correctly
namelist doesn't work correctly -- Summary: namelist doesn't work correctly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug fortran/26136] namelist doesn't work correctly
--- Comment #1 from hjl at lucon dot org 2006-02-06 19:36 --- Created an attachment (id=10790) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10790&action=view) A testcase I got /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -o foo foo.f90 ./foo make: *** [all] Aborted [EMAIL PROTECTED] namelist]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #2 from lmorrison at nautel dot com 2006-02-06 19:46 --- Created an attachment (id=10791) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10791&action=view) preprocessed source demonstrating bug produced with commandline: avr-gcc -E -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #3 from lmorrison at nautel dot com 2006-02-06 19:49 --- Created an attachment (id=10792) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10792&action=view) assembly output from previous preprocessed source Generated with commandline: avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o Using gcc 3.4.5 on Win32 host, avr target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #4 from lmorrison at nautel dot com 2006-02-06 19:54 --- (From update of attachment 10792) assembly output from previous preprocessed source Generated with commandline: avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o Using gcc 3.4.5 on Win32 host, avr target. In the first two examples ( *ptr++ = struct; and memcpy(ptr++, &struct, sizeof(struct)); ) the source pointer is being incremented by sizeof(struct) for each byte being copied. In the third example, the pointer increment is set aside as a distinct statement. Here, things behave as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug target/26137] New: Cannot connect to target board h8 using GDB
I am trying to use GDB 5.2 on cygwin host and target hms-h8300. I did the make and built the executables for the above host and target. I used mode to set the baud rate on the system to 19200. Then ran gdb h8300-hms-gdb target remote /dev/tty0 Remote debugging using /dev/tty0 Conltn't establish connection to remote target. Please let me know how I can connect to the board using GDb. Thanks -- Summary: Cannot connect to target board h8 using GDB Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dharinih at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26137
[Bug target/26137] Cannot connect to target board h8 using GDB
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 20:03 --- GCC has nothing to do with GDB. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26137
[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #5 from cajus dot hahn at de dot abb dot com 2006-02-06 20:05 --- You are right, *ptr = struct; ptr++; works.I must have mixed up some of my testing results. Cajus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug c++/26110] using directive breaks ADL
--- Comment #6 from dg001 at t-online dot de 2006-02-06 20:06 ---
Note, I didn't change the status of the bug yet.
And you are absolutely right about the behavior of fundamental types. But I
still encounter a problem with classes.
Can you explain the behavior of gcc in the following example?
--- BEGIN CODE ---
namespace test {
template double f(T1 f)
{
return 2.;
}
}
class Type1 {
public:
Type1()
{}
~Type1()
{}
};
double f(Type1 f)
{
return 1.;
}
int main(int argc, char *argv[])
{
using test::f;
Type1 d;
double result1 = f(d);
double result2 = test::f(d);
return 0;
}
--- END CODE ---
class Type1 and the function f are in the global namespace. Nevertheless
"double result1 = f(d);" calls "template double f(T1 f)", which I
think is wrong. The function "double f(Type1 f)" should be called instead.
I tested this with another compiler (MS VC++ 8) and the code of this compiler
calls the global function f in this case.
Which behavior is the right one acording to the standard?
If you now put "class Type1" and and "double f(Type1 f)" in their own namespace
and change the code so it builds again, then gcc produces code, that calls the
function "double f(Type1 f)" when executing the line "double result1 = f(d);".
Is there anything wrong with the global namespace?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26110
[Bug fortran/23815] Add -byteswapio flag
--- Comment #30 from tkoenig at gcc dot gnu dot org 2006-02-06 20:12 --- Subject: Bug 23815 Author: tkoenig Date: Mon Feb 6 20:12:44 2006 New Revision: 110664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110664 Log: 2005-02-06 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/23815 * gfortran.texi: Document the GFORTRAN_CONVERT_UNIT environment variable. * invoke.texi: Mention the "Runtime" chapter. Document the -fconvert= option. * gfortran.h: Add options_convert. * lang.opt: Add fconvert=little-endian, fconvert=big-endian, fconvert=native and fconvert=swap. * trans-decl.c (top level): Add gfor_fndecl_set_convert. (gfc_build_builtin_function_decls): Set gfor_fndecl_set_convert. (gfc_generate_function_code): If -fconvert was specified, and this is the main program, add a call to set_convert(). * options.c: Handle the -fconvert options. 2005-02-06 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/23815 * runtime/environ.c (init_unformatted): Add GFORTRAN_CONVERT_UNIT environment variable. (top level): Add defines, type and static variables for GFORTRAN_CONVERT_UNIT handling. (search_unit): New function. (match_word): New function. (match_integer): New function. (next_token): New function. (push_token): New function. (mark_single): New function. (mark_range): New funciton. (do_parse): New function. (init_unformatted): New function. (get_unformatted_convert): New function. * runtime/compile_options.c: Add set_convert(). * libgfortran.h: Add convert to compile_options_t. * io/open.c (st_open): Call get_unformatted_convert to get unit default; if CONVERT_NONE is returned, check for the presence of a CONVERT specifier and use it. As default, use compile_options.convert. * io/io.h (top level): Add CONVERT_NONE to unit_convert, to signal "nothing has been set". (top level): Add prototype for get_unformatted_convert. 2005-02-06 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/23815 * unf_io_convert_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unf_io_convert_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/environ.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug c++/26120] mudlap behavior changes with trivial changes to build command
--- Comment #3 from idht4n at hotmail dot com 2006-02-06 20:18 --- (In reply to comment #2) > It worked in "4.1.0 20051026". > Is 4.1.0 20051026 a snapshot? It doesn't appear on the ftp mirror I checked... the snapshots went from 20051022 to 20051029. How do I get the version of which you speak? Directory: 4.1-20051022 10/22/2005 11:08:00 PM Directory: 4.1-20051029 10/29/2005 11:09:00 PM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
[Bug c++/26110] using directive breaks ADL
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-06 20:24 --- (In reply to comment #6) > Note, I didn't change the status of the bug yet. > And you are absolutely right about the behavior of fundamental types. But I > still encounter a problem with classes. > Can you explain the behavior of gcc in the following example? That was a bug in GCC before 4.1.0 and has been fixed in 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26110
[Bug libfortran/26136] arrays in namelist with not finished input does not work correctly
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 20:27 ---
Confirmed.
Simple example:
!{ dg-do run }
! Tests filling variables from a namelist read when object list is
! not complete.
program pr
implicit none
integer, parameter :: max_domains = 4
integer ier
logical, dimension(max_domains) :: non_hydrostatic
integer, dimension(max_domains) :: time_step_sound
namelist /dynamics/ non_hydrostatic
namelist /dynamics/ time_step_sound
non_hydrostatic = .true.
read (5, nml=dynamics, iostat=ier, err = 1000)
print *, non_hydrostatic
print *, time_step_sound
stop
1000 call abort()
end program pr
cat a
&dynamics
non_hydrostatic = .true., .true., .true
time_step_sound = 4, 4, 4,
/
./a.out < a
namelist read: missplaced = sign
Cannot match namelist object name 4,
Cannot match namelist object name 4,
Cannot match namelist object name 4,
T T T T
19036 -1881089148 -1073742864 1140850722
So what is happening is that we don't recognize the start of the differrent
namelist object.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-02-06 20:27:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug fortran/24406] EQUIVALENCE broken in 32-bit code with optimization -O2
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-02-06 20:33 --- Note that http://www.netlib.org/blas/d1mach.f has code INTEGER SMALL(2) INTEGER LARGE(2) INTEGER RIGHT(2) INTEGER DIVER(2) INTEGER LOG10(2) INTEGER SC, CRAY1(38), J COMMON /D9MACH/ CRAY1 SAVE SMALL, LARGE, RIGHT, DIVER, LOG10, SC DOUBLE PRECISION DMACH(5) EQUIVALENCE (DMACH(1),SMALL(1)) EQUIVALENCE (DMACH(2),LARGE(1)) EQUIVALENCE (DMACH(3),RIGHT(1)) EQUIVALENCE (DMACH(4),DIVER(1)) EQUIVALENCE (DMACH(5),LOG10(1)) ... IF (SC .NE. 987) THEN DMACH(1) = 1.D13 IF ( SMALL(1) .EQ. 1117925532 * .AND. SMALL(2) .EQ. -448790528) THEN * *** IEEE BIG ENDIAN *** SMALL(1) = 1048576 SMALL(2) = 0 LARGE(1) = 2146435071 LARGE(2) = -1 RIGHT(1) = 1017118720 RIGHT(2) = 0 DIVER(1) = 1018167296 DIVER(2) = 0 LOG10(1) = 1070810131 LOG10(2) = 1352628735 So, if we don't support this extension, we will potentially break BLAS (at least the vanilla version distributed with netlib). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24406
[Bug java/26138] New: Lots of warnings with gcj .jar -> .so
When natively-compiling the Eclipse jars, I get lots of warnings similar to this: org/eclipse/swt/internal/SWTEventObject.java:0: warning: '_otable_syms_org_eclipse_swt_internal_SWTEventObject' defined but not used org/eclipse/swt/internal/SWTEventObject.java:0: warning: '_itable_syms_org_eclipse_swt_internal_SWTEventObject' defined but not used I am compiling this jar like this: /usr/bin/gcj -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -fPIC -findirect-dispatch -fjni /var/tmp/eclipse-3.1.2-1jpp_4fc-buildroot/usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.1.1.jar.1.jar -o /var/tmp/eclipse-3.1.2-1jpp_4fc-buildroot/usr/lib/gcj/eclipse/org.eclipse.swt.gtk.linux.x86_3.1.1.jar.1.jar.o $ gcj --version gcj (GCC) 4.1.0 20060131 (Red Hat 4.1.0-0.20) i386 -- Summary: Lots of warnings with gcj .jar -> .so Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: overholt at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26138
