[Bug ada/19918] New: [4.0 Regression] ICE: Segementation fault compiling ada/ada.ads
stage1/xgcc -Bstage1/ -B/opt/gnu/gcc/gcc-4.0.0/hppa2.0w-hp-hpux11.11/bin/ -c -g -O2 -mdisable-indexing -gnatpg -gnata -I- -I. -Iada -I../../gcc/gcc/ada ../. ./gcc/gcc/ada/ada.ads -o ada/ada.o built-in:0: internal compiler error: Segmentation fault I believe that this was introduced this afternoon. -- Summary: [4.0 Regression] ICE: Segementation fault compiling ada/ada.ads Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs 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=19918
[Bug ada/19918] [4.0 Regression] ICE: Segementation fault compiling ada/ada.ads
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-12 03:34 --- GNU gdb 6.3.50.20050210-cvs 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 hppa2.0w-hp-hpux11.11... Breakpoint 1 at 0x517c80: file ../../gcc/gcc/diagnostic.c, line 556. Breakpoint 2 at 0x517afc: file ../../gcc/gcc/diagnostic.c, line 500. Breakpoint 3 at 0xa70430: file ../../gcc/libiberty/obstack.c, line 450. Breakpoint 4 at 0xa5755c: file ../../gcc/libcpp/lex.c, line 178. (gdb) r `cat xx.sh` Starting program: /mnt/gnu/gcc-3.3/objdir/gcc/stage1/gnat1 `cat xx.sh` Breakpoint 3 at 0x7af87744 Breakpoint 4 at 0x7afeb230 Program received signal SIGSEGV, Segmentation fault. 0x00688be4 in type_hash_list (list=0x7ade29c0, hashcode=1325671104) at ../../gcc/gcc/tree.c:3427 3427 hashcode = iterative_hash_object (TYPE_HASH (TREE_VALUE (tail)), (gdb) disass 0x00688bc4 0x00688bf4 Dump of assembler code from 0x688bc4 to 0x688bf4: 0x00688bc4 type_hash_list+196:b,l 0x698a20 tree_check_failed,rp 0x00688bc8 type_hash_list+200:nop 0x00688bcc type_hash_list+204:ldw 10(,r3),r19 0x00688bd0 type_hash_list+208:ldw 14(,r19),r19 0x00688bd4 type_hash_list+212:stw r19,c(,r3) 0x00688bd8 type_hash_list+216:ldil a73800,r19 0x00688bdc type_hash_list+220:ldo 560(r19),r20 0x00688be0 type_hash_list+224:ldw c(,r3),r19 0x00688be4 type_hash_list+228:ldw c(,r19),r19 0x00688be8 type_hash_list+232:extrw,u r19,7,8,r19 0x00688bec type_hash_list+236:ldw,s r19(,r20),r19 0x00688bf0 type_hash_list+240:cmpib,=,n 2,r19,0x688c1c type_hash_list+ 284 End of assembler dump. (gdb) p/x $r19 $1 = 0x0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug middle-end/19697] [4.0 Regression] gcc.c-torture/execute/ieee/mzero6.c:24: error: unrecognizable insn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-11 23:51 --- Subject: Bug 19697 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-02-11 23:50:51 Modified files: gcc: ChangeLog gcc/config/pa : pa.md Log message: PR middle-end/19697 2005-01-30 Roger Sayle [EMAIL PROTECTED] * config/pa/pa.md (anddi3, iordi3): On HPPA64, disallow an integer constant as the second operand and a register as the third. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1059r2=1.16114.2.1060 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.116.2.13r2=1.116.2.14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19697
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-12 08:09 --- Broken by: 2005-02-11 Richard Henderson [EMAIL PROTECTED] * tree-complex.c (expand_complex_libcall): New. (expand_complex_multiplication): Use it for c99 compliance. (expand_complex_division): Likewise. * fold-const.c (fold_complex_add, fold_complex_mult): New. (fold): Call them. * builtins.c (built_in_names): Remove const. * tree.c (build_common_builtin_nodes): Build complex arithmetic builtins. * tree.h (BUILT_IN_COMPLEX_MUL_MIN, BUILT_IN_COMPLEX_MUL_MAX): New. (BUILT_IN_COMPLEX_DIV_MIN, BUILT_IN_COMPLEX_DIV_MAX): New. (built_in_names): Remove const. * c-common.c (c_common_type_for_mode): Handle complex modes. * flags.h, toplev.c (flag_complex_method): Rename from flag_complex_divide_method. * libgcc2.c (__divsc3, __divdc3, __divxc3, __divtc3, __mulsc3, __muldc3, __mulxc3, __multc3): New. * libgcc2.h: Declare them. * libgcc-std.ver: Export them. * mklibgcc.in (lib2funcs): Build them. It appears that Ada front-end's type_for_mode is not prepared to handle complex floating-point modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2
--- Additional Comments From schlie at comcast dot net 2005-02-12 07:59 --- Subject: Re: avr target build broken by recent 'DC' type update to libgcc2 This is a complex mode of DFmode. Is DFmode supported at all on avr? - no, but doubles are defined as being the same size as floats so that shouldn't represent a problem. libgcc2 should be basing it's built-in function definitions on the type sizes the target defines, not assume them to be of certain modes. More specifically, libgcc2 should be defining built-in's based on the target's type sizes which may be larger than it's MAX_FIXED_MODE_SIZE, (and presumably MAX_FLOAT_MODE_SIZE if it were defined), and properly specify their modes based on these specified type sizes, not some presumptions based on the size of the target's machine word size, as it's largely irrelevant. For example if a target defines: #define CHAR_TYPE_SIZE 8 #define SHORT_TYPE_SIZE 8 #define INT_TYPE_SIZE 16 #define LONG_TYPE_SIZE 32 #define LONG_LONG_TYPE_SIZE 64 #define MAX_FIXED_MODE_SIZE 32 #define FLOAT_TYPE_SIZE 32 #define DOUBLE_TYPE_SIZE 32 #define LONG_DOUBLE_TYPE_SIZE 32 #define MAX_FLOAT_MODE_SIZE 0 It should be presumed that the target will have defined implementations for standard integer modes char/short(QI),int(HI),long(HI) instructions, but any built-in's required for types larger than the maximum-mode-size would need to be defined (with their corresponding correct type modes). Implying libgcc2 would need to either use the above defined type-modes, and/or define long-long(DI), float(SF), double(SF), complex-float(CF), and complex-double(CF); as required to satisfy any built-in requirements. If not, why not? - most simply because DF mode register demands exceed avr's available resources; and secondarily it exceeds the demands for typical avr class applications in terms of the value of it's precision vs demand for machine resources, vs. performance, (as C typically implies double precision for transcendental operations by default, for example), etc. [actually even long-long(DI) support is likely overkill, but gcc can't build without DI mode support as exception headers are defined as requiring 64 bits, which it likely shouldn't as it's an unnecessary requirement apparently derived from ia64 code; likely benefiting all 32 bit or less machines, and should likely be relaxed.] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug java/15543] jv-scan --complexity segfaults
--- Additional Comments From bothner at gcc dot gnu dot org 2005-02-12 06:25 --- Checked in --enable-mapped-location fix, -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15543
[Bug c++/19919] [regression 3.3/3.4/4.0]
--- Additional Comments From kent at sas dot com 2005-02-12 03:50 --- sorry, next time i'll add a.cpp as an attachment. still getting the hang of this. -- What|Removed |Added Keywords||diagnostic Known to fail||3.3 Known to work||3.2 Summary|[regression 3.3/3.4.4.0]|[regression 3.3/3.4/4.0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19919
[Bug java/15543] jv-scan --complexity segfaults
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 06:13 --- Subject: Bug 15543 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-12 06:12:48 Modified files: gcc/java : parse-scan.y lex.c jv-scan.c ChangeLog Log message: PR java/15543 * parse-scan.y (input_location): Remove variable. (main_input_filename): New - replaces input_filename, which isn't settable if USE_MAPPED_LOCATION. * lex.c (java_init_lex): Wrap some more places in #ifndef JC1-LITE, so we don't reference input_location or wfl_operator in that case. * jv-scan.c (expand_location): Remove - no longer used. (main): Set main_input_filename rather than input_filename. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse-scan.y.diff?cvsroot=gccr1=1.38r2=1.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/lex.c.diff?cvsroot=gccr1=1.118r2=1.119 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jv-scan.c.diff?cvsroot=gccr1=1.45r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1548r2=1.1549 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15543
[Bug ada/19918] [4.0 Regression] ICE: Segementation fault compiling ada/ada.ads
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-12 03:59 --- hppa-unknown-linux-gnu is also broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug java/19921] wrong argument count for invokeInterface with new multidimensional array
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19921
[Bug target/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-12 04:00 --- I have taken an initial look. This is an ivopts problem. Compiling with -O -fno-ivopts works. There is clearly something wrong with ivopts if I look at the t54.ivopts dump file. For the J loop iterator, I get before the loop # ivtmp.41_57 = PHI ivtmp.41_58(9), 4294967296(0); and inside the loop ivtmp.41_58 = ivtmp.41_57 - 4294967295; Translating that into hex, we have an initial value of 0x1 . And an increment of 0x 0001. The first addition produces a value of 0x1, so a loop that iterates once works correctly. If the loop needs to execute more than once, we are screwed, as now the iterator ends up with useless values. I haven't tried looking at ivopts yet, but I wonder if perhaps this is a 64-bit hosting issue, and ivopts is getting some mixed 32-bit/64-bit arithmetic wrong. Trying this theory, I compiled the testcase on an x86_64 system, and got the same failure, with the same bogus iterator values. I updated my source trees, rebuilt, and now it works on both IA-64 and x86-64. This bug must have been fixed sometime within the last week or two by a patch for another ivopts PR. It would be nice to know which one fixed it though. I will check to see if I can figure this out easily. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-12 04:00:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug c/19920] New: avr target build broken by recent 'DC' type update to libgcc2
As of a few hours ago, avr target build broken by recent 'DC' type update to libgcc2. In file included from /Applications/avr/avr-src/gcc/libgcc2.c:56: /Applications/avr/avr-src/gcc/libgcc2.h:96: error: unable to emulate 'DC' make[2]: *** [libgcc/./_muldi3.o] Error 1 -- Summary: avr target build broken by recent 'DC' type update to libgcc2 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schlie at comcast dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.8.0 GCC host triplet: powerpc-apple-darwin7.8.0 GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
aren't specialized templates templates?
hi all.
the code snippet below is extracted from a much more
complicated piece of code. basically the problem is that
g++ (3.3 and 3.4) demand different typedef syntax inside
template bodies, depending on whether full or partial
specialization is used.
is this really the correct behaviour and standard conform?
(to me it seems, line20 should still be considered part of
a template and thus accept the typename)
snip-
templateclass C
struct Base {
typedef C* Iterator;
};
templateclass C, class D
struct Derived : BaseD {
typedef typename BaseD::Iterator Iterator;
};
#define BASE_ITER(BASE) typename BASE :: Iterator
templateclass D
struct Derivedchar, D : BaseD {
typedef BASE_ITER (BaseD) Iterator; // line15
};
template
struct Derivedchar, int : Baseint {
typedef BASE_ITER (Baseint) Iterator; // line20
};
// test.cc:20: error: using `typename' outside of template
snip-
---
ciaoTJ
[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 05:46 --- This is a complex mode of DFmode. Is DFmode supported at all on avr? If not, why not? -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 00:53 --- This is related to PR 19828 but note constant functions are are required not to read memory. We are getting to a point where we have to defined what it means to be both const and weak which seems like a werid combination. Really const means that I can pull the function out of the loop but weak means that it might not be defined, now what is this function. Really in my mind this is undefined and glibc should be fixed in that way as __pthread_internal_tsd_address is not really const because it reads memory. Note at -O3 we get it right because we unswitch the loop. Now using pure instead of const gets us into PR 19828. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug middle-end/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-11 22:40 --- Fails on i686 and on AMD64 also. And with both gcc and g++... In c_finish_return, retval is (long long int) (a / 2). That is already wrong. In parser_build_binary_op we build TRUNC_DIV_EXPR (unsigned int) a, 2LL, which is also already wrong (lost the signed int cast). And so we dig deeper into the parser... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug c++/19914] New: The left side of the = operator must be an lvalue.
Sourc code for t.cpp:
int mymain()
{
int i = 0;
static_castlong int(i) = 1;
return i;
}
Expected Behaviour:
t.cpp, line 4.9: 1540-2410 (S) The left side of the = operator must be an
lvalue.
Actual Behaviour:
None.
t.ii generated with -save-temps option
# 1 t.cpp
# 1 built-in
# 1 command line
# 1 t.cpp
int mymain()
{
int i = 0;
static_castlong int(i) = 1;
return i;
}
Release:
GCC Version: 3.2.0
Environment:
System Type:
Reading specs from
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/specs
Configured with: /scratch/gcc-3.2/configure --prefix=/usr/local/gcc.3.2.0
--enable-threads=aix --disable-nls
Thread model: aix
gcc version 3.2
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cpp0 -lang-c++
-D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__STRICT_ANSI__ -trigraphs -$ -v
-iprefix /usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/ -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_IBMR2
-D_POWER -D_LONG_LONG -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -Asystem=unix
-Asystem=aix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE_EXTENDED=1 -D_LARGE_FILE_API -D_ALL_SOURCE
-D__WCHAR_TYPE__=short unsigned int -D_ARCH_COM t.cpp -std=iso9899:199409 -Wall
-pedantic t.ii
GNU CPP version 3.2 (cpplib)
ignoring nonexistent directory
/usr/local/lib/gcc-lib/../../powerpc-ibm-aix5.1.0.0/include
ignoring nonexistent directory
/usr/local/gcc.3.2.0/powerpc-ibm-aix5.1.0.0/include
ignoring duplicate directory
/usr/local/gcc.3.2.0/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
/usr/local/include
/usr/local/gcc.3.2.0/include
/usr/include
End of search list.
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cc1plus -fpreprocessed
t.ii -trigraphs -$ -quiet -dumpbase t.cpp -ansi -Wall -pedantic
-std=iso9899:199409 -ansi -version -o t.s
GNU CPP version 3.2 (cpplib)
GNU C++ version 3.2 (powerpc-ibm-aix5.1.0.0)
compiled by GNU C version 3.2.
as -u -mcom -o t.o t.s
How-To-Repeat:
g++ -v -save-temps -std=iso9899:199409 -ansi -Wall -pedantic -c t.cpp
--
Summary: The left side of the = operator must be an lvalue.
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msadoghi at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19914
[Bug c++/19915] The left side of the = operator must be an lvalue.
--- Additional Comments From msadoghi at ca dot ibm dot com 2005-02-11 22:51 --- *** This bug has been marked as a duplicate of 19914 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19915
[Bug c++/19919] [regression 3.3/3.4/4.0]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 05:59 --- are sure that this is valid c++? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19919
[Bug c++/19915] New: The left side of the = operator must be an lvalue.
Sourc code for t.cpp:
int mymain()
{
int i = 0;
static_castlong int(i) = 1;
return i;
}
Expected Behaviour:
t.cpp, line 4.9: 1540-2410 (S) The left side of the = operator must be an
lvalue.
Actual Behaviour:
None.
t.ii generated with -save-temps option
# 1 t.cpp
# 1 built-in
# 1 command line
# 1 t.cpp
int mymain()
{
int i = 0;
static_castlong int(i) = 1;
return i;
}
Release:
GCC Version: 3.2.0
Environment:
System Type:
Reading specs from
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/specs
Configured with: /scratch/gcc-3.2/configure --prefix=/usr/local/gcc.3.2.0
--enable-threads=aix --disable-nls
Thread model: aix
gcc version 3.2
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cpp0 -lang-c++
-D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__STRICT_ANSI__ -trigraphs -$ -v
-iprefix /usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/ -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_IBMR2
-D_POWER -D_LONG_LONG -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -Asystem=unix
-Asystem=aix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE_EXTENDED=1 -D_LARGE_FILE_API -D_ALL_SOURCE
-D__WCHAR_TYPE__=short unsigned int -D_ARCH_COM t.cpp -std=iso9899:199409 -Wall
-pedantic t.ii
GNU CPP version 3.2 (cpplib)
ignoring nonexistent directory
/usr/local/lib/gcc-lib/../../powerpc-ibm-aix5.1.0.0/include
ignoring nonexistent directory
/usr/local/gcc.3.2.0/powerpc-ibm-aix5.1.0.0/include
ignoring duplicate directory
/usr/local/gcc.3.2.0/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/include
/usr/local/include
/usr/local/gcc.3.2.0/include
/usr/include
End of search list.
/usr/local/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2/cc1plus -fpreprocessed
t.ii -trigraphs -$ -quiet -dumpbase t.cpp -ansi -Wall -pedantic
-std=iso9899:199409 -ansi -version -o t.s
GNU CPP version 3.2 (cpplib)
GNU C++ version 3.2 (powerpc-ibm-aix5.1.0.0)
compiled by GNU C version 3.2.
as -u -mcom -o t.o t.s
How-To-Repeat:
g++ -v -save-temps -std=iso9899:199409 -ansi -Wall -pedantic -c t.cpp
--
Summary: The left side of the = operator must be an lvalue.
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msadoghi at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19915
[Bug c++/19916] New: Segmentation fault in __static_initialization_and_destruction_0
The following testcase segfaults on 3.4.4 and 3.4.0, but runs to completion on
3.2.3.
Note this test won't even compile on mainline, so I don't know if the same
problem exists there. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
//test.c
struct S {
char k;
};
char const volatile S::* const p01 = S::k;
int main(void)
{
return 0;
}
/opt/gcc-nightly/3.4-20050211/bin/g++ -o test test.c
./test
Segmentation fault
$ gdb ./test
(gdb) run
Starting program: /home/jgrimm/tmp/13930/test
Program received signal SIGSEGV, Segmentation fault.
0x1474 in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535) at g.c:5
5 char const volatile S::* const p01 = S::k;
---
$ /opt/gcc-nightly/3.4-20050211/bin/g++ -v
Reading specs from
/home/gcc-nightly/3.4-20050211/bin/../lib/gcc/powerpc64-linux/3.4.4/specs
Configured with: /home/gccbuild/gcc_3.4_anoncvs/gcc/configure
--prefix=/opt/gcc-nightly/3.4-20050211 --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32
--with-as=/opt/gcc-nightly/binutils/bin/as
--with-ld=/opt/gcc-nightly/binutils/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f77,java,objc
Thread model: posix
gcc version 3.4.4 20050211 (prerelease)
--
Summary: Segmentation fault in
__static_initialization_and_destruction_0
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19916
[Bug middle-end/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-11 22:50 --- And there was great rejoicing... In c-typeck.c: 3253 ovalue = value; (gdb) p debug_generic_expr (value) (intD.0) aD.1454 // Good. (gdb) next 3254 value = convert (type, value); (gdb) p debug_generic_expr (ovalue) (intD.0) aD.1454 (gdb) next 3257 if (TREE_CODE (value) == INTEGER_CST) (gdb) p debug_generic_expr (value) (unsigned intD.3) aD.1454 (gdb) p debug_generic_expr(type) unsigned intD.3 So convert (unsigned int, (int) a) results in (unsigned int) a which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug regression/19898] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/strlen-1.c execution, -O2 and higher
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 01:09 --- Subject: Bug 19898 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-12 01:08:34 Modified files: gcc: ChangeLog gcc/config/cris: cris.c Log message: PR regression/19898. * config/cris/cris.c (cris_notice_update_cc): When testing if insn changes cc_status, use apply modified_in_p to part of cc_status and insn, not cris_reg_overlap_mentioned_p on SET_DEST of insn body. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7452r2=2.7453 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.c.diff?cvsroot=gccr1=1.64r2=1.65 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19898
[Bug c++/19914] The left side of the = operator must be an lvalue.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 22:56 --- *** This bug has been marked as a duplicate of 1920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19914
[Bug c++/1920] no warning or error with cast-as-lvalue extension
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 22:56 --- *** Bug 19914 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||msadoghi at ca dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1920
[Bug c++/19748] aggressive no-inline options still cause inlining
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-11 23:11 --- Try -fno-optimize-sibling-calls. sibling-call (tail-call) optimizations can confuse anything that tries to produce call graph info, and the end result will look similar to the result you get with function inlining. In both cases, a procedure frame gets optimized away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19748
[Bug c++/19914] The left side of the = operator must be an lvalue.
--- Additional Comments From msadoghi at ca dot ibm dot com 2005-02-11 22:51 --- *** Bug 19915 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19914
[Bug c++/19916] [3.4/4.0? Regression] Segmentation fault in __static_initialization_and_destruction_0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 23:12 --- Confirmed. -- What|Removed |Added BugsThisDependsOn||19878 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-02-11 23:12:41 date|| Summary|Segmentation fault in |[3.4/4.0? Regression] |__static_initialization_and_|Segmentation fault in |destruction_0 |__static_initialization_and_ ||destruction_0 Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19916
[Bug regression/19898] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/strlen-1.c execution, -O2 and higher
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-11 23:13 --- This is a bug in cris_notice_update_cc, which doesn't account for postincrement changing the known expression. Patch being tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19898
[Bug regression/19898] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/strlen-1.c execution, -O2 and higher
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-11 23:13:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19898
[Bug middle-end/19912] GCC does not disclose parentheses
--- Additional Comments From l_belev at yahoo dot com 2005-02-11 23:09 --- (In reply to comment #1) Note that the first expression can involve undefined behavior when the second doesn't, so transformations between these forms would be invalid with -ftrapv and until we have internal overflow flags on expressions we could only transform in one direction without -fwrapv. The compiler does know what options are passed to it, so it can disable such transformations in the rare cases when -ftrapv is specified. I dont understand what the purpose of -fwrapv is, because the compiler always knows whether the machine it's currently generating code for, wraps around the results on arithmetic overflow. Anyway surely the first consideration applies in this case too, that is, the transformations could be disabled if they are not applicable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19912
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
-- What|Removed |Added Severity|critical|normal Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug regression/19898] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/strlen-1.c execution, -O2 and higher
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-12 01:28 --- See URL:http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00561.html. Closed, though should apply to 3.3 and 3.4 too. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19898
[Bug c++/19878] [4.0 Regression] ICE in import_export_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-11 23:13 --- This has been failing since at least 20041124. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[Bug tree-optimization/19853] [4.0 Regression] ICE with address in struct assignment
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-12 01:36 --- Diego, I think it's clear that adding a new global variable is much trickier business than we've previously given it credit. For the special case of calls, we could get away with recording which to-be-renamed variables are actually new and if the variable is call-clobbered, add a vop at the call site. But that doesn't handle any pointer operation referencing global non-conflicting TMT's. And I'm definitely not certain if or how NMTs might need updating to cope with the newly exposed variable. I'm not sure how to do anything but run a brand-new alias pass here and anywhere else we expose new global variables (e.g DOM?). -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Last reconfirmed|2005-02-09 14:38:06 |2005-02-12 01:36:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug c/19771] VLA deallocation
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-12 00:09 --- The problem here is that the C front end is not creating a new BIND_EXPR for the scope starting at the declaration for X. Insert one by hand and you'll see that the tree optimizers are doing the right thing. -- What|Removed |Added Last reconfirmed|2005-02-03 02:35:43 |2005-02-12 00:09:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19771
[Bug middle-end/19912] GCC does not disclose parentheses
--- Additional Comments From joseph at codesourcery dot com 2005-02-11 23:19 --- Subject: Re: GCC does not disclose parentheses On Fri, 11 Feb 2005, l_belev at yahoo dot com wrote: I dont understand what the purpose of -fwrapv is, because the compiler always knows whether the machine it's currently generating code for, wraps around the results on arithmetic overflow. Anyway surely the first consideration applies in this case too, that is, the transformations could be disabled if they are not applicable. The internal tree structures (GIMPLE) have well-defined mostly machine-independent semantics, which on signed arithmetic overflow follow C, i.e. signed overflow is undefined behavior unless -fwrapv. This means, for example, that ((x * 2)/2) can be optimized to x for signed arithmetic, although it can't for unsigned. Because of the potential for such transformations to be applied to the results of other transformations, it isn't safe to apply any transformation introducing undefined behavior lest some other such transformation use the fact it is undefined in a way that changes the semantics where the original code did not involve undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19912
[Bug c/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-11 23:42 --- Ignore comment #4, it's wrong. An IRC debug session revealed that the call to get_narrower at c-typeck.c:7492 is incorrect; it's not being fed values properly converted to result_type. A little archaeology shows that the offending code has been there since forever (ie. it is in old-gcc). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug preprocessor/19077] [3.4/4.0 Regression] Internal compiler error compiling MPlayer
--- Additional Comments From echristo at redhat dot com 2005-02-12 01:43 --- Ran it through valgrind to track down the memory errors and then started hunting. Testing a patch currently. valgrind returns no errors after patch. -eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19077
[Bug tree-optimization/19917] New: [4.0 regression] Weak const function mishandled inside loop
$ cat weak.c
extern void *__pthread_internal_tsd_address (void) __attribute__ ((__const__));
#pragma weak __pthread_internal_tsd_address
void f (void)
{
for (;;)
if (__pthread_internal_tsd_address ? __pthread_internal_tsd_address () : 0)
return;
}
$ gcc/xgcc -Bgcc -O2 -S weak.c
$ grep __pthread weak.s
br.call.sptk.many b0 = __pthread_internal_tsd_address#
addl r14 = @ltoff(@fptr(__pthread_internal_tsd_address#)), gp
.weak __pthread_internal_tsd_address#
__pthread_internal_tsd_address is called before being checked for NULL.
Broken by this change:
2004-07-09 Zdenek Dvorak [EMAIL PROTECTED]
* tree-ssa-loop-im.c: New file.
...
--
Summary: [4.0 regression] Weak const function mishandled inside
loop
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,rakdver at atrey dot
karlin dot mff dot cuni dot cz
GCC target triplet: ia64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug tree-optimization/19899] ICE: tree check: expected real_cst, have integer_cst in const_binop, at fold-const.c:1490 with -ftree-vectorize -msse2
--- Additional Comments From dorit at il dot ibm dot com 2005-02-12 11:13 --- As far as I can see it's related to scalar evolution (nothing gets vectorized, the ICE happens during the analysis stage of the vectorizer, when the vectorizer calls analyze_scalar_evolution): (gdb) backtrace #0 tree_check_failed (node=0x414902e0, file=0x49ab2c ../../gcc/gcc/fold- const.c, line=1490, function=0x49abcc const_binop) at ../../gcc/gcc/tree.c:5450 #1 0x00205504 in const_binop (code=MULT_EXPR, arg1=0x4148de58, arg2=0x414902e0, notrunc=0) at ../../gcc/gcc/fold-const.c:1543 #2 0x0021c1ac in fold (expr=0x4140c894) at ../../gcc/gcc/fold-const.c:7222 #3 0x003bbce4 in add_to_evolution (loop_nb=252, chrec_before=0x414902e0, code=1095294552, to_add=0x0) at ../../gcc/gcc/tree-scalar-evolution.c:897 #4 0x003bc644 in follow_ssa_edge_in_rhs (loop=0x413044e0, rhs=0x4148de58, halting_phi=0x412d9780, evolution_of_loop=0xb580) at ../../gcc/gcc/tree- scalar-evolution.c:1176 #5 0x003bcff0 in follow_ssa_edge (loop=0x413044e0, def=0x4140c3f0, halting_phi=0x412d9780, evolution_of_loop=0xb580) at ../../gcc/gcc/tree- scalar-evolution.c:1446 #6 0x003bd1e0 in analyze_evolution_in_loop (loop_phi_node=0x412d9780, init_cond=0x414902e0) at ../../gcc/gcc/tree-scalar-evolution.c:1497 #7 0x003bdf24 in analyze_scalar_evolution_1 (loop=0x413044e0, var=0x4140c534, res=0x0) at ../../gcc/gcc/tree-scalar-evolution.c:1798 #8 0x003be054 in analyze_scalar_evolution (loop=0x413044e0, var=0x4140c534) at ../../gcc/gcc/tree-scalar-evolution.c:1850 #9 0x00115918 in vect_analyze_scalar_cycles (loop_vinfo=0x41304600) at ../../gcc/gcc/tree-flow-inline.h:309 #10 0x00119004 in vect_analyze_loop (loop=0x41304600) at ../../gcc/gcc/tree- vectorizer.c:5697 #11 0x00119244 in vectorize_loops (loops=0x413011a0) at ../../gcc/gcc/tree- vectorizer.c:5815 #12 0x00093900 in execute_one_pass (pass=0x595cd0) at ../../gcc/gcc/tree- optimize.c:528 #13 0x000939e0 in execute_pass_list (pass=0x595cd0) at ../../gcc/gcc/tree- optimize.c:565 #14 0x000939f8 in execute_pass_list (pass=0x595c00) at ../../gcc/gcc/tree- optimize.c:566 #15 0x000939f8 in execute_pass_list (pass=0x595520) at ../../gcc/gcc/tree- optimize.c:566 #16 0x00093cec in tree_rest_of_compilation (fndecl=0x41487d24) at ../../gcc/gcc/tree-optimize.c:664 #17 0x0001b3e0 in c_expand_body (fndecl=0x4148f0e8) at ../../gcc/gcc/c- decl.c:6437 #18 0x003b2a6c in cgraph_expand_function (node=0x4148f0e8) at ../../gcc/gcc/cgraphunit.c:822 #19 0x003b47d8 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1689 #20 0x003b4b78 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1786 #21 0x0034d234 in compile_file () at ../../gcc/gcc/toplev.c:1009 #22 0x0034f100 in do_compile () at ../../gcc/gcc/toplev.c:2101 #23 0x0034f184 in toplev_main (argc=6042020, argv=0x5c31d0) at ../../gcc/gcc/toplev.c:2133 #24 0x27a8 in _start (argc=20, argv=0xbcb0, envp=0xbd04) at /SourceCache/Csu/Csu-47/crt.c:267 #25 0x8fe1a558 in __dyld__dyld_start () (gdb) (gdb) p debug_generic_expr(node) -1 $2 = void (gdb) up #1 0x00205504 in const_binop (code=MULT_EXPR, arg1=0x4148de58, arg2=0x414902e0, notrunc=0) at ../../gcc/gcc/fold-const.c:1543 1543 tree r2 = TREE_REALPART (arg2); (gdb) p debug_generic_expr(arg1) 1.0e+0 $3 = void (gdb) p debug_generic_expr(arg2) -1 $4 = void (gdb) up #2 0x0021c1ac in fold (expr=0x4140c894) at ../../gcc/gcc/fold-const.c:7222 7222t1 = const_binop (code, arg0, arg1, 0); (gdb) p debug_generic_expr(expr) 1.0e+0 * -1 $5 = void (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19899
[Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug java/19907] Incorrect code generated for ManifestElement.java
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-12 13:29 --- The patch I submitted is inadequate. I know how to fix it, and I'll resubmit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19907
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-12 13:50 --- A sub-optimal fix is to disable movmemhi expansion. Either delete it or the less draconian: (define_expand movmemhi [(parallel [(set (match_operand:BLK 0 memory_operand ) (match_operand:BLK 1 memory_operand )) (use (match_operand:HI 2 const_int_operand )) (use (match_operand:HI 3 const_int_operand )) (clobber (match_scratch:HI 4 )) (clobber (match_scratch:HI 5 )) (clobber (match_dup 6))])] (0) etc A better solution is currently being tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug libgcj/8170] jni.cc needs stack trace handling
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 13:51 --- Subject: Bug 8170 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-12 13:51:12 Modified files: libjava: ChangeLog libjava/java/lang: ClassLoader.java libjava/gnu/java/lang: MainThread.java libjava/gnu/gcj/runtime: NameFinder.java libjava/java/net: URLClassLoader.java Log message: Fixes bug libgcj/8170 * java/lang/ClassLoader.java (loadClass): Don't rewrap ClassNotFoundException. * gnu/java/lang/MainThread.java (run): Chain NoClassDefFoundError. * gnu/gcj/runtime/NameFinder.java (remove_interpreter): Removed. (remove_internal): New field superceding remove_interpreter. (sanitizeStack): Remove all no-package classes starting with _Jv_. Remove no-class methods starting with _Jv_. And Replace null class or method names with the empty string. Stop at either the MainThread or a real Thread run() method. (newElement): Made static. * java/net/URLClassLoader.java (findClass): Throw ClassNotFoundExceptions including urls, plus parent using toString(). (thisString): New field. (toString): New method. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3317r2=1.3318 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/ClassLoader.java.diff?cvsroot=gccr1=1.36r2=1.37 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/lang/MainThread.java.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/gcj/runtime/NameFinder.java.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URLClassLoader.java.diff?cvsroot=gccr1=1.22r2=1.23 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8170
[Bug libgcj/8170] jni.cc needs stack trace handling
--- Additional Comments From mark at gcc dot gnu dot org 2005-02-12 13:53 --- Patch to fix this and other _Jv_ internal madness checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8170
[Bug tree-optimization/15785] fold misses unary transformation
--- Additional Comments From phython at gcc dot gnu dot org 2005-02-12 14:03 --- Created an attachment (id=8183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8183action=view) testcase -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15785
[Bug c++/19922] New: xor is enclosed in loop, and exectuted on each iteration of for statement
#include stdlib.h
void dupa()
{
double* wagi;
unsigned int i,synapsy=100;
wagi = (double*)malloc(100*synapsy);
for( i=0;isynapsy;i++ ) {
wagi[i] = 0;
}
}
Simple test case, if compiled with 4.0
gcc-4.0 (GCC) 4.0.0 20050212 (experimental)
g++-4.0 -pedantic --save-temps -ftree-vectorize -O3 -Wall -mtune=pentium3 -c
test.c
essencialy I get:
.LFB15:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
movl$1, (%esp)
callmalloc
movl$1, %edx
.p2align 4,,15
.L2:
xorl%ecx, %ecx
movl%ecx, -8(%eax,%edx,8)
xorl%ecx, %ecx
movl%ecx, -4(%eax,%edx,8)
incl%edx
cmpl$101, %edx
jne .L2
leave
ret
so xor on ecx is executed twice! inside the loop.
Looks simmilar with 3.4
L5:
movl$0, (%eax,%edx,8)
xorl%ecx, %ecx
movl%ecx, 4(%eax,%edx,8)
incl%edx
cmpl$100, %edx
jb .L5
on ultrasparc:
.LLFB18:
save%sp, -104, %sp
.LLCFI0:
sethi %hi(9216), %o0
callmalloc, 0
or %o0, 784, %o0
mov 0, %g1
.LL2:
add %g1, %o0, %g2
add %g1, 8, %g1
st %g0, [%g2]
cmp %g1, 800
bne .LL2
st %g0, [%g2+4]
jmp %i7+8
restore
It's odd because I do specify -O3 just to make sure code will be as fast as
possible :)
-O0 uses float point instructions to zero it, that's extremly slow than.
and -O1 uses float point too, but code is 3x smaller and neater:
fldz
.L2:
fstl-8(%eax,%edx,8)
incl%edx
cmpl$101, %edx
jne .L2
fstp%st(0)
--
Summary: xor is enclosed in loop, and exectuted on each iteration
of for statement
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gj at pointblue dot com dot pl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686
GCC host triplet: i686
GCC target triplet: i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug libgcj/8170] jni.cc needs stack trace handling
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8170
[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement
-- What|Removed |Added Component|c++ |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-12 14:52 --- Zdenek, a tree-ssa-loop-im problem, apparently... -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org, steven at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 15:06 --- Removing target milestone based on Mark's 4.0 status email. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2
-- What|Removed |Added Summary|avr target build broken by |[4.0 Regression] avr target |recent 'DC' type update to |build broken by recent 'DC' |libgcc2 |type update to libgcc2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-12 15:19 --- Removing target milestone based on Mark's 4.0 status email. I think this one doesn't qualify: it's a bootstrap failure on all platforms. -- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 15:22 --- (In reply to comment #6) Removing target milestone based on Mark's 4.0 status email. I think this one doesn't qualify: it's a bootstrap failure on all platforms. Does not matter as it only effects only Ada so it qualifies and Mark wrote: which affect only languages other than C and C++? See http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug c/19923] New: openssl is slower when compiled with gcc 4.0 than 3.3
here's openssl speed resoult when it's compiled with 3.3 (orginal debian unstable package): options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2510.80k 1064.79k 1486.96k 1641.83k 1702.87k mdc2 0.00 0.00 0.00 0.00 0.00 md4 4999.47k17746.97k51392.88k97451.59k 131711.89k md5 4405.95k15208.16k43027.34k77946.11k 101040.96k hmac(md5) 4951.58k16851.67k46126.90k81002.65k 101700.77k sha1 3892.54k12223.89k29586.19k45767.99k54082.03k rmd1603715.14k10397.52k23079.49k33148.87k37651.83k rc4 58941.98k66899.63k71733.39k72572.54k72476.92k des cbc 13353.92k13897.80k14067.26k14088.53k14107.61k des ede3 4887.63k 5039.28k 5083.63k 5116.70k 5086.58k idea cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 5257.37k 5534.13k 5560.97k 5610.12k 5582.42k rc5-32/12 cbc0.00 0.00 0.00 0.00 0.00 blowfish cbc 21054.83k22340.34k22704.49k22895.90k22860.91k cast cbc 14478.39k15882.31k16400.99k16570.03k16585.01k aes-128 cbc 13612.33k14364.39k14382.68k14404.12k14440.26k aes-192 cbc 12075.70k12370.43k12530.49k12518.63k12559.92k aes-256 cbc 10806.91k11093.65k11179.27k11185.67k11205.97k signverifysign/s verify/s rsa 512 bits 0.0023s 0.0002s438.5 4928.2 rsa 1024 bits 0.0109s 0.0006s 91.6 1746.1 rsa 2048 bits 0.0646s 0.0019s 15.5527.6 rsa 4096 bits 0.4317s 0.0066s 2.3152.0 signverifysign/s verify/s dsa 512 bits 0.0018s 0.0022s546.0460.7 dsa 1024 bits 0.0054s 0.0065s186.6154.8 dsa 2048 bits 0.0179s 0.0220s 55.7 45.5 and here's the same package compiled with gcc 4.0, gcc-4.0 (GCC) 4.0.0 20050212 (experimental) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DO PENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2361.81k 781.01k 1103.19k 1231.36k 1278.84k mdc2 0.00 0.00 0.00 0.00 0.00 md4 3103.64k11338.88k36135.04k79292.67k 123123.36k md5 2758.32k10084.74k31863.54k66522.25k98860.02k hmac(md5) 4581.08k15784.49k43771.66k78227.60k 101959.42k sha1 2638.72k 8889.12k24063.88k41890.99k53462.15k rmd1602477.15k 7918.19k19696.52k31106.04k37317.88k rc4 60284.27k67543.46k71379.34k72455.38k72581.12k des cbc 13547.77k13876.64k14049.67k14102.25k14020.78k des ede3 4950.20k 5050.99k 5068.80k 5111.00k 5088.06k idea cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 5814.75k 6060.45k 6150.37k 6169.60k 6196.13k rc5-32/12 cbc0.00 0.00 0.00 0.00 0.00 blowfish cbc 20941.23k22373.68k22868.43k22822.28k23014.29k cast cbc 12790.60k14102.95k14514.24k14494.77k14622.21k aes-128 cbc 13030.43k13549.49k13653.51k13694.85k13696.33k aes-192 cbc 11257.66k11517.92k11545.25k11604.32k11568.43k aes-256 cbc 10065.01k10296.48k10403.82k10332.02k10382.25k signverifysign/s verify/s rsa 512 bits 0.0024s 0.0002s418.5 4201.7 rsa 1024 bits 0.0112s 0.0006s 89.5 1550.7 rsa 2048 bits 0.0650s 0.0020s 15.4504.9 rsa 4096 bits 0.4311s 0.0068s 2.3147.9 signverifysign/s verify/s dsa 512 bits 0.0019s 0.0023s521.4441.9 dsa 1024
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
-- What|Removed |Added Component|c |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
--- Additional Comments From schwab at suse dot de 2005-02-12 15:32 --- I don't see any contradiction between const and weak. Neither does __pthread_internal_tsd_address read memory (it returns a pointer to some, but the address is an invariant). Once you know that the function is non-null you can freely hoist the call out of the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug middle-end/19698] [3.4/4.0 Regression] Infinite loop in update_life_info
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-12 15:33 --- More context on this bug: http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01946.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19698
[Bug c/19924] New: [AVR] MODES_TIEABLE incorrect
MODES_TIEABLE in avr is set such that access to subreg is prevented. This result is significantly sub-optimal code. Attached patch changes this. No regressions have been found with test suite - indeed things got better! Note this is related to PR/19815 documentation error. -- Summary: [AVR] MODES_TIEABLE incorrect Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andrewhutchinson at cox dot net CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19924
[Bug c/19924] [AVR] MODES_TIEABLE incorrect
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-12 15:35 --- Created an attachment (id=8186) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8186action=view) Patch to chnage MODES_TIEABLE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19924
[Bug c++/19919] [regression 3.3/3.4/4.0]
--- Additional Comments From kent at sas dot com 2005-02-12 15:37 --- i'm personally not sure; there is a test harness in the vulcan tree that i'll extract and submit as an attachment. the code in question has compiled and run on at least MSVC7, sun forte as well as GCC 3.2.x; so in that sense i'm sure it works on other compilers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19919
[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement
--- Additional Comments From phython at gcc dot gnu dot org 2005-02-12
15:39 ---
-ftree-vectorize doesn't do anything here as -msse{,2} hasn't been specified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug c++/14479] enum definition in template class with template methods causes error.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 15:40 --- Subject: Bug 14479 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-12 15:40:29 Modified files: gcc/cp : ChangeLog cp-tree.h name-lookup.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: enum5.C Log message: PR c++/14479 PR c++/19487 * pt.c (maybe_check_template_type): Remove. * cp-tree.h (maybe_check_template_type): Remove prototype. * name-lookup.c (maybe_process_template_type_declaration): Don't use maybe_check_template_type. * g++.dg/template/enum5.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4624r2=1.4625 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1103r2=1.1104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.108r2=1.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.975r2=1.976 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5025r2=1.5026 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/enum5.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
[Bug c++/19487] [3.3/3.4/4.0 Regression] map with a class template + method template fails to compile.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 15:40 --- Subject: Bug 19487 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-12 15:40:29 Modified files: gcc/cp : ChangeLog cp-tree.h name-lookup.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: enum5.C Log message: PR c++/14479 PR c++/19487 * pt.c (maybe_check_template_type): Remove. * cp-tree.h (maybe_check_template_type): Remove prototype. * name-lookup.c (maybe_process_template_type_declaration): Don't use maybe_check_template_type. * g++.dg/template/enum5.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4624r2=1.4625 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1103r2=1.1104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.108r2=1.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.975r2=1.976 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5025r2=1.5026 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/enum5.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement
--- Additional Comments From gj at pointblue dot com dot pl 2005-02-12 15:46 --- I thought that -mtune=pentium3 should get him enough hints to use sse. Some warning would be great than if what you say is true about -ftree-vectorize! Besides, -msse doesn't turn on vectorization here either. But it should probably. That would do 2 doubles cleared at one shot, rather than using integer twice it could be cleared using mmx or sse registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
--- Additional Comments From roger at eyesopen dot com 2005-02-12 16:01 --- I'm unable to reproduce this problem on either ia64-unknown-linux-gnu (an SGI altix box), with 4.0.0 20050212 (experimental), nor 20050208 on the same box, nor on powerpc-apple-darwin7.8, nor on i686-pc-cygwin. Could someone double check this wasn't a temporary failure? Strange that I can't reproduce Andreas' reordering on IA-64, nor Andrew's ICE in DOM on Darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug fortran/19925] New: Implied do-loop in an initialization expression is broken
From Richard Maine, editor of the F2003 standard program stuff integer :: i_do integer :: i(101) = (/ (i_do, i_do=1,101) /) write (*,*) i end program stuff bug1.f90: In function 'MAIN__': bug1.f90:4: internal compiler error: Possible frontend bug: array constructor not expanded Note that it works up to size 100; fails at size 101. If we look in array.c, we find the magic number 100. /* This parameter is the size of the largest array constructor that we will expand to an array constructor without iterators. Constructors larger than this will remain in the iterator form. */ #define GFC_MAX_AC_EXPAND 100 -- Summary: Implied do-loop in an initialization expression is broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgk at troutmask dot apl dot washington dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/19926] New: Incorrect rank with PARAMETER and array element.
From Richard Maine, editor of the F2003 standard subroutine string_comp integer, parameter :: map(0:50) = 0 integer :: i i = map(42) end subroutine string_comp In file bug2.f90:4 i = map(42) 1 Error: Incompatible ranks 0 and 1 in assignment at (1) Note that it works without the parameter attribute. -- Summary: Incorrect rank with PARAMETER and array element. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgk at troutmask dot apl dot washington dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19926
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
--- Additional Comments From schwab at suse dot de 2005-02-12 16:27 --- Created an attachment (id=8187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8187action=view) Orignal testcase This is the original test case from which the other one is simplified, apparently too much so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug fortran/19927] New: Function call with character*(*) arg is broken
From Richard Maine, editor of the F2003 standard module fdas_command contains function lower_case (string) result(result) character*(*), intent(in) :: string character*(len(string)) :: result result = string return end function lower_case subroutine ask_help (topic) character*(*), intent(in) :: topic character :: topic_tmp*16 topic_tmp = lower_case(topic) return end subroutine ask_help end module fdas_command bug3.f90: In function 'ask_help': bug3.f90:3: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1104 This may be related to one of the other CHARACTER*(*) bugs, but I haven't found it. -- Summary: Function call with character*(*) arg is broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgk at troutmask dot apl dot washington dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19927
[Bug c++/14479] enum definition in template class with template methods causes error.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 16:29 --- Subject: Bug 14479 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-12 16:29:21 Modified files: gcc/cp : ChangeLog cp-tree.h name-lookup.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: enum5.C Log message: PR c++/14479 PR c++/19487 * pt.c (maybe_check_template_type): Remove. * cp-tree.h (maybe_check_template_type): Remove prototype. * name-lookup.c (maybe_process_template_type_declaration): Don't use maybe_check_template_type. * g++.dg/template/enum5.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.198r2=1.3892.2.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.946.4.17r2=1.946.4.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.34.2.20r2=1.34.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.816.2.50r2=1.816.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.361r2=1.3389.2.362 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/enum5.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
[Bug c++/19487] [3.3/3.4/4.0 Regression] map with a class template + method template fails to compile.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-12 16:29 --- Subject: Bug 19487 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-12 16:29:21 Modified files: gcc/cp : ChangeLog cp-tree.h name-lookup.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: enum5.C Log message: PR c++/14479 PR c++/19487 * pt.c (maybe_check_template_type): Remove. * cp-tree.h (maybe_check_template_type): Remove prototype. * name-lookup.c (maybe_process_template_type_declaration): Don't use maybe_check_template_type. * g++.dg/template/enum5.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.198r2=1.3892.2.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.946.4.17r2=1.946.4.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.34.2.20r2=1.34.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.816.2.50r2=1.816.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.361r2=1.3389.2.362 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/enum5.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug fortran/19928] New: Reference of constant derived type component causes failure
From Richard Maine, editor of the F2003 standard subroutine open_th_read_unc2 type my_type character :: signal_names(10)*16 end type type(my_type) :: gen gen%signal_names = '' write (*,*) gen%signal_names(:)(1:4) end subroutine open_th_read_unc2 bug4.f90: In function 'open_th_read_unc2': bug4.f90:7: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:344 -- Summary: Reference of constant derived type component causes failure Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgk at troutmask dot apl dot washington dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
[Bug c++/19487] [3.3 Regression] map with a class template + method template fails to compile.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-02-12 16:32 --- Fixed in 3.4/4.0. -- What|Removed |Added Keywords|patch | Summary|[3.3/3.4/4.0 Regression] map|[3.3 Regression] map with a |with a class template + |class template + method |method template fails to|template fails to compile. |compile.| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug c++/14479] enum definition in template class with template methods causes error.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-02-12 16:33 --- Fixed in 3.4/4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
[Bug fortran/19929] New: Deallocation of an allocated derived type component causes failure
From Richard Maine, editor of the F2003 standard subroutine close_th_read_unc3 type :: unc3_ptr_type integer, pointer :: unc3 end type type(unc3_ptr_type) :: unc3_ptrs(10) allocate(unc3_ptrs(2)%unc3) deallocate(unc3_ptrs(2)%unc3) end subroutine close_th_read_unc3 bug5.f90: In function 'close_th_read_unc3': bug5.f90:6: internal compiler error: in gfc_conv_descriptor_data, at fortran/trans-array.c:181 Interestingly, the allocate is fine; only the deallocate crumps. -- Summary: Deallocation of an allocated derived type component causes failure Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgk at troutmask dot apl dot washington dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19929
[Bug c++/19487] [3.3 Regression] map with a class template + method template fails to compile.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-02-12 16:34 --- Probably won't fixed in 3.3. -- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement
--- Additional Comments From dorit at il dot ibm dot com 2005-02-12 16:35 --- We fail to vectorize with: wagi.cc:43: note: not vectorized: unhandled data ref: D.31081_39 = this_3-wagi wagi.cc:43: note: bad data references. The loop in question looks like this: # i_1 = PHI i_43(8), 0(7); L3:; D.31081_39 = this_3-wagi; D.31082_40 = i_1 * 8; D.31083_41 = (double *) D.31082_40; D.31084_42 = D.31081_39 + D.31083_41; *D.31084_42 = 0.0; i_43 = i_1 + 1; if (synapsy_2 i_43) goto L16; else goto L5; L16:; goto bb 3 (L3); If the invariant expr 'D.31081_39 = this_3-wagi;' was taken out of loop, I think we would have vectorized it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug c++/14479] enum definition in template class with template methods causes error.
-- What|Removed |Added Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
[Bug c++/19487] [3.3 Regression] map with a class template + method template fails to compile.
-- What|Removed |Added Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug target/19922] xor is enclosed in loop, and exectuted on each iteration of for statement
--- Additional Comments From gj at pointblue dot com dot pl 2005-02-12 16:39 --- that would be great if it will happend for 4.0. My bug here acctualy has two sides than. First gcc fails to trace register value that doesn't change and thus does not require to be cleared on every loop. Secondly also loop vectorizer fails to produce vector code, but that wasn't my initial problem anyway, just a second thought. thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-12 16:40:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-12 16:43 --- Does not matter as it only effects only Ada so it qualifies and Mark wrote: which affect only languages other than C and C++? That's wrong, it ruins bootstrap on all platforms, including C and C++. -- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:46 --- (In reply to comment #8) Does not matter as it only effects only Ada so it qualifies and Mark wrote: which affect only languages other than C and C++? That's wrong, it ruins bootstrap on all platforms, including C and C++. Huh, it compiles just fine on powerpc-darwin with the default enable-languages. in fact Ada is not enabled by default in 4.0? -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug fortran/19926] Incorrect rank with PARAMETER and array element.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:51 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-02-12 16:51:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19926
[Bug fortran/19927] Function call with character*(*) arg is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:56 --- *** This bug has been marked as a duplicate of 15326 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19927
[Bug fortran/15326] ICE with assumed length character strings
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:56 --- *** Bug 19927 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326
[Bug fortran/19928] Reference of constant derived type component causes failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 16:59 --- Confirmed, related to PR 17123. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-12 16:59:28 date|| Summary|Reference of constant |Reference of constant |derived type component |derived type component |causes failure |causes failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
[Bug fortran/19929] Deallocation of an allocated derived type component causes failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 17:08 --- Confirmed, related to PR 17202. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-12 17:08:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19929
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-12 17:10 --- Huh, it compiles just fine on powerpc-darwin with the default enable-languages. in fact Ada is not enabled by default in 4.0? I don't know, I personally always build all languages... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-02-12 18:55 --- Subject: Re: [4.0 Regression] ICE: Segmentation fault compilin Does not matter as it only effects only Ada so it qualifies and Mark wrote: which affect only languages other than C and C++? That's wrong, it ruins bootstrap on all platforms, including C and C++. Huh, it compiles just fine on powerpc-darwin with the default enable-languages. in fact Ada is not enabled by default in 4.0? -- What|Removed |Added Target Milestone|4.0.0 |--- Although the lack of a milestone only indicates that fixing this bug isn't a target for any release of GCC, I personally find this change disappointing. The Ada folks have worked hard to try to get ready for 4.0.0, and I don't believe the status of Ada on the PA is any worse than in previous releases. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-02-12 19:05 --- Subject: Re: [4.0 Regression] ICE: Segmentation fault compilin Although the lack of a milestone only indicates that fixing this bug isn't a target for any release of GCC, I personally find this change disappointing. Also note that it was a new feature introduced for C99 compliance that caused the problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 19:16 --- (In reply to comment #12) Also note that it was a new feature introduced for C99 compliance that caused the problem. Not being complainant to a standard is still considered a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug fortran/19302] intrinsic_nearest.f90 fails
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-12 19:20 --- It's a bug in intrinsics/c99_functions.c:nextafterf. Fixing. -- What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19302
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-02-12 19:28 --- Subject: Re: [4.0 Regression] ICE: Segmentation fault compilin (In reply to comment #12) Also note that it was a new feature introduced for C99 compliance that caused the problem. Not being complainant to a standard is still considered a bug. Well, the fix required new functionality. This was installed in stage3 when new functionality isn't supposed to be added. This functionality is not enabled yet. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop
--- Additional Comments From roger at eyesopen dot com 2005-02-12 19:31 --- Andreas, thanks for the bigger example, I can now reproduce this failure! I was wondering whether you could try the following patch to see if helps for you. Index: tree-eh.c === RCS file: /cvs/gcc/gcc/gcc/tree-eh.c,v retrieving revision 2.24 diff -c -3 -p -r2.24 tree-eh.c *** tree-eh.c 18 Jan 2005 11:36:24 - 2.24 --- tree-eh.c 12 Feb 2005 19:20:44 - *** tree_could_trap_p (tree expr) *** 1840,1845 --- 1840,1852 return true; return false; + case CALL_EXPR: + t = get_callee_fndecl (expr); + /* Assume that calls to weak functions may trap. */ + if (!t || !DECL_P (t) || DECL_WEAK (t)) + return true; + return false; + default: /* Any floating arithmetic may trap. */ if (fp_operation flag_trapping_math) Basically, this teaches tree_could_trap_p that calls to weak functions may potentially trap. This is sufficient to prevent tree-ssa-loop-im.c from moving the call before the test. It feels like the right fix. I'm currently bootstrapping and regression testing on i686-pc-linux-gnu and ia64-linux. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-12 19:31:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
[Bug ada/19918] [4.0 Regression] ICE: Segmentation fault compiling ada/ada.ads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12 20:05 --- Fixed by: * utils.c (gnat_type_for_mode): Return NULL for COMPLEX modes; validate SCALAR_INT_MODE_P before calling gnat_type_for_size. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19918
[Bug target/19623] ICE: compiling SPECfp2000 benchmark fails in 191.fma3d with -ftree-vectorizer
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-12 20:07 --- I do not replicate this as of today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19623
[Bug target/19623] ICE: compiling SPECfp2000 benchmark fails in 191.fma3d with -ftree-vectorizer
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-12 20:11 --- Well, we don't vectorize any loops as of today either... Sigh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19623
