[Bug fortran/16898] Aliasing problem with array descriptors
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-12-10 13:21 --- This is not fixed. It still fails for me at -O2 in i686-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898
[Bug c++/18922] [3.3/3.4 Regression] ICE in tree_low_cst, at tree.c:3315
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:27 --- *** This bug has been marked as a duplicate of 18384 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18922
[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:27 --- *** Bug 18922 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||a dot kral at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug target/16932] Compilation error for sh-coff-gcc little endian target
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:39 --- So lets close it as fixed for 4.0.0 then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16932
[Bug target/18919] print_address_operand produces segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:44 --- Fixed in 4.0.0 by changing the definition of HOST_LONG_LONG_FORMAT to be correct for mingw32. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18919
[Bug libfortran/18924] New: segfault in dot_product with missing interface information
This one is a bit tricky. It passes two arrays to a subroutine, where they are passed on to the intrinsic function dot_product. However, they are passed old-style, without interface information. dot_product expects to receive only new-style arrays, and generates a segfault in the executed program. This one can't be caught at compile time (at least not without inter-procedural analysis) because it's the caller who determines wether to pass an old-style or a new-style array. $ cat dot_product.f90 program main implicit none real, dimension(2) :: a, b real :: c a = 1. b = -2.3 call foo(a,b,c) print *,c end program main subroutine foo(a,b,c) real, dimension(:), intent(in) :: a, b real, intent(out) :: c c = dot_product(a,b) end subroutine foo $ gfortran dot_product.f90 ./a.out Segmentation fault $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 --disable-shared Thread model: posix gcc version 4.0.0 20041205 (experimental) -- Summary: segfault in dot_product with missing interface information Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18924
[Bug c++/18920] internal compiler error: Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:47 --- Fixed in 3.4.0 and later: pr18920.cc:16: error: template argument required for 'struct print_matrix' pr18920.cc:16: error: types may not be defined in parameter types pr18920.cc:20: error: two or more data types in declaration of 'parameter' pr18920.cc:20: error: 'class std::vectorstd::vectordouble, std::allocatordouble , std:: allocatorstd::vectordouble, std::allocatordouble ' is not a valid type for a template constant parameter pr18920.cc:20: error: expected `' before ';' token pr18920.cc:26: error: expected unqualified-id at end of input -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18920
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-10 13:48 --- Subject: Re: set_exponent breaks with integer*8 exponent paulthomas2 at wanadoo dot fr wrote: --- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 13:35 --- You have fixed this one, haven't you? cvs 20041205 runs it fine. I don't think so, maybe it's got hidden by another change. However, in testing, I found another nasty: y = 1/2 + 1/8 !y= 0.125 + 0.5 !!works OK 1/2 .EQ. 0 in Fortran, same for 1/8, this is integer division :-) - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00742.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18731
[Bug target/18925] New: Invalid gprel relocation in PIC
$ cat gprel.cc
class __attribute__ ((visibility(default))) Type
{
private:
static long _staticTypeCount;
public:
Type() { _staticTypeCount++; }
~Type();
};
long Type::_staticTypeCount = 0;
Type::~Type()
{
_staticTypeCount--;
}
$ gcc -fPIC -fvisibility=hidden -S gprel.cc
$ grep _staticTypeCount gprel.s
.global _ZN4Type16_staticTypeCountE#
.type _ZN4Type16_staticTypeCountE#, @object
.size _ZN4Type16_staticTypeCountE#, 8
_ZN4Type16_staticTypeCountE:
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp
--
Summary: Invalid gprel relocation in PIC
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18925
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 14:14 --- Note the date for C++ is different: : Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug target/18896] addressing split complex parm
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-10 14:14 --- http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00682.html -- What|Removed |Added Keywords||ABI, ice-on-valid-code, ||patch, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18896
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 14:18 --- (In reply to comment #9) The fail dates from comment #3 probably refer to this change 2004-10-17 Andrew Pinski [EMAIL PROTECTED] * c-typeck.c (default_function_array_conversion): Always create a[0] for array types. (build_unary_op): Do not fold a[x] into a + x. which was reverted again on the same day. Can someone try with the reghunter to see if it failed before October 17 also? What this tells me it is a latent bug in x86/x86_64 back-end as my change should not change what RTL is produced as it is the back-end's job to reject addressing modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug libfortran/17597] list directed read has error
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 14:24 --- This runs correctly when read(10,*)I,X,P,Z,G is broken up into read(10,*)I,X read(10,*)P,Z,G (In reply to comment #0) here is the list directed read example from the F2003 draft standard: $ cat a.f ! taken from F2003 standard integer I real X(8) data X / 8*0.0/ character*20 P complex z logical g open(UNIT=10) write(10,'(A)') '12345,12345,,2*1.5,4*' write(10,'(A)') ISN'T_BOB'S,(123,0),.TEXAS$ rewind(10) read(10,*)I,X,P,Z,G print*,I,X,P,Z,G end $ gfc a.f $ ./a.out At line 12 of file a.f Fortran runtime error: Bad complex value in item 11 of list input $ g77 a.f $ ./a.out 12345 12345. 0. 1.5 1.5 0. 0. 0. 0.ISN'T_BOB'S (123.,0.) T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17597
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-10 14:53 --- BTW Paul, this depends on the endianess of your target, the error won't show up on i686. I'm currently testing a patch which should really fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC
-- What|Removed |Added Summary|Invalid gprel relocation in |[4.0 regression] Invalid |PIC |gprel relocation in PIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18925
[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error
--- Additional Comments From uros at kss-loka dot si 2004-12-10 15:34 --- This patch will fix the mainline, but more investigation is needed. Index: cse.c === RCS file: /cvs/gcc/gcc/gcc/cse.c,v retrieving revision 1.327 diff -u -r1.327 cse.c --- cse.c 26 Nov 2004 15:42:36 - 1.327 +++ cse.c 10 Dec 2004 15:30:34 - @@ -3860,6 +3860,9 @@ case RTX_COMPARE: case RTX_COMM_COMPARE: + if (VECTOR_MODE_P (mode)) + break; + /* See what items are actually being compared and set FOLDED_ARG[01] to those values and CODE to the actual comparison code. If any are constant, set CONST_ARG0 and CONST_ARG1 appropriately. We needn't Uros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17767
[Bug c++/18926] New: internal compiler error: in tree_low_cst, at tree.c:3255
[EMAIL PROTECTED]:/tmp/s$ g++ -c foo.c
foo.c:16: internal compiler error: in tree_low_cst, at tree.c:3255
when compiling following code:
8 [cut here] ---
typedef struct {
char *str;
int n;
char *(f[]);
char *(l[]);
int *a;
} t_moja;
t_moja x={
foobar,
4,
{imie,nazwisko,telefon,email},
{Imiê,Nazwisko,Telefon,E-mail},
{0,1,2,3},
};
t_moja y={
baz,
2,
{dupa,blada},
{Pan,Kowalski},
{8,9}
};
8 [cut here] ---
Environment:
System: Linux blabluga.hell.pl 2.6.7bl #1 Sun Jul 4 17:47:48 CEST 2004 i686
GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
How-To-Repeat:
Save above snippet into file and run:
g++ -c filename
--
Summary: internal compiler error: in tree_low_cst, at tree.c:3255
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arturcz at blabluga dot hell dot pl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18926
[Bug target/18927] New: O(n^2) compile time with -O0 (n= number of basic blocks) in global alloc
Some C-Code is (with Option -O0) processed by an algorithm with O(n^2) time.
This simple code scheme shows that the compile time grows fast with
the number of basic blocks in a function. If the number of
basic blocks is doubled the compile time is almost quadrupled.
The output of -ftime-report shows that global alloc uses most of the time.
But C-Code with a small difference has roughly O(n) compile time.
expensive code:
if(*i0){int a; a=(*i1);*i2=(a/3+a/7);} : roughly O(n*n) compile time
if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);} : roughly O(n*n) compile time
cheap code:
if(*i0){int a; a=(*i1);*i2=(a*3+a*7);} : roughly O(n) compile time
if(*i0){int a; a=(*i1);*i2=(a*3+(*i2)*7);} : roughly O(n) compile time
Used Code Scheme:
void test(int *i0,int *i1,int *i2){
if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
... copies of the last statement
return;}
The body of the test function consists of a number of copies of
the following Statement:
if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
Each statement produces 2 basic blocks.
Content of the following table:
BBs : number of basic blocks in if-statements
user: user time from /usr/bin/time gcc
global_alloc : from output of -ftime-report
lines of assembler code : lines of gcc output
(Intel Pentium 700Mhz or an old SPARC-Computer)
Table relating number of basic block to compile time for gcc 3.4.3 intel
BBs user global_alloclines of assembler code
---
100 0.22 0.12(55%) 1468
200 0.54 0.30(56%) 2918
400 1.36 0.91(67%) 5818
800 4.09 3.15(77%) 11618
1600 15.52 13.67 (88%) 23218
3200 76.63 72.87 (95%) 46418
6400 277.25 269.49 (97%) 92818
128001072.581057.20 (99%) 185618
Table relating number of basic block to compile time for gcc 3.2 intel
==
BBs user global_alloclines of assembler code
---
100 0.170.07(41%) 1369
200 0.370.15(42%) 2719
400 0.760.36(48%) 5419
800 1.530.76(50%) 10819
1600 3.501.80(52%) 21619
3200 8.134.59(56%) 43219
6400 21.59 14.33 (66%) 86419
1280062.03 45.75 (74%) 172819
Table relating number of basic block to compile time for gcc 3.4.3 sparc
=
BBs user global_alloclines of assembler code
---
100 0.320.05(16%) 1218
200 0.490.07(15%) 2418
400 0.870.16(19%) 4818
800 1.490.30(20%) 9618
1600 3.100.67(22%) 19218
3200 6.721.51(23%) 38418
6400 14.95 4.45(30%) 76818
1280054.73 32.43 (59%) 153618
Table relating number of basic block to compile time for gcc 2.95.2 sparc
=
BBs user global_alloclines of assembler code
---
100 0.111173
200 0.172323
400 0.304623
800 0.629223
1600 1.3518423
3200 2.9036823
6400 6.1973623
1280014.97 147223
Table relating number of basic block to compile time for gcc 3.4.3 intel
for this Code: if(*i0){int a; a=(*i1);*i2=(a*3+a*7);}
=
BBs user global_alloclines of assembler code
---
100 0.110.01(10%) 713
200 0.160.03(20%) 1413
400 0.350.07(21%) 2813
800 0.650.14(22%) 5613
1600 1.330.28(21%) 11213
3200 2.930.58(20%) 22413
6400 5.801.15(20%) 44813
1280012.09 2.68(22%) 89613
Shellscripts:
---
for x in 50 100 200 400 800 1600 3200 6400
do
echo $x
run $x
done
---
[[ -z $1 ]] exit 1
N=$1
echo 'void test(int *i0,int *i1,int *i2){' z.c
IF=if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);}
((i=$N))
while((i0))
do
echo $IF z.c
((i=i-1))
done
echo 'return;}' z.c
wc z.c
echo $IF
/usr/bin/time -p gcc -S -O0 -ftime-report z.c
((BB=N+N))
echo ### BB $BB
wc z.s
-
gawk '
$1==global $2 == alloc
[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-10 15:48 --- Gaby, is this trivial patch OK for the 3.3 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17868
[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-10 16:04 --- Subject: Bug 18731 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-10 16:04:22 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: struct-1.C struct-2.C struct-3.C Log message: PR c++/18731 * parser.c (cp_parser_class_head): Reject typedef-name in class head. * g++.dg/parser/struct-1.C: New test. * g++.dg/parser/struct-2.C: New test. * g++.dg/parser/struct-3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4527r2=1.4528 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.292r2=1.293 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4734r2=1.4735 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-2.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-3.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18731
[Bug c++/18926] internal compiler error: in tree_low_cst, at tree.c:3255
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 16:08 --- *** This bug has been marked as a duplicate of 18327 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Version|3.3 |3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18926
[Bug c++/18327] [3.3/3.4/4.0 Regression] ICE while compiling valid c code with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 16:08 --- *** Bug 18926 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||arturcz at hell dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18327
[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC
--- Additional Comments From schwab at suse dot de 2004-12-10 16:23 --- Broken by 2004-08-03 Mark Mitchell [EMAIL PROTECTED] * class.c (build_vtable): Do not set DECL_VISIBILITY here. (check_field_decls): Or here. (check_methods): Or here. (initialize_array): Don't mess with DECL_CONTEXT. * cp-tree.h (start_decl): Adjust prototype. (determine_visibility): New function. * decl.c (duplicate_decls): Remove checks for hidden operator new. (build_library_fn_1): Give all library functions default visibility. (start_decl): Add pop_scope_p parameter. Tidy. (cp_finish_decl): Do not pop scopes here. Call determine_visibility for variable definitions. (start_preparsed_function): Call determine_visibility. * decl2.c (determine_visibility): New function. * method.c (use_thunk): Fix formatting. * parser.c (cp_parser_condition): Adjust calls to start_decl. (cp_parser_init_declarator): Likewise. * pt.c (instantiate_decl): Always call pop_nested_class. * rtti.c (get_tinfo_decl): Do not set DECL_VISIBILITY. (tinfo_base_init): Likewise. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18925
[Bug target/18459] [4.0 Regression] gcj no longer works on win32
--- Additional Comments From ovidr at users dot sourceforge dot net 2004-12-10 16:35 --- It was a completely fresh checkout to an empty dir (both times). I build a linux-win32 cross. (building on win32 takes way too long due to fork()). For the dwarf2 patch, I had used the one line patch from: http://sources.redhat.com/ml/binutils/2004-11/msg00249.html; on the binutils-2.15.91-20040904-1-src.tar.gz from mingw.org. If I don't need any further patches(?), I will try to use binutils directly from cvs and build it again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459
[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr
--- Additional Comments From gdr at integrable-solutions dot net 2004-12-10 16:53 --- Subject: Re: [3.3 regression] RDIV_EXPR not supported by dump_expr reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Gaby, is this trivial patch OK for the 3.3 branch? Yes, thanks. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17868
[Bug middle-end/18928] ice on valid code with -O2 -fPIC
-- What|Removed |Added Component|other |middle-end Keywords||ice-on-valid-code Summary|ice on valid code. |ice on valid code with -O2 - ||fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3
-- What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2004-04-29 21:27:43 |2004-12-10 16:59:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-10 17:09 --- Oh, cool. :-) Did you get the patch linked up? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7
--- Additional Comments From hjl at lucon dot org 2004-12-10 17:11 --- An updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00757.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18153
[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-10 17:26 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16536
[Bug libfortran/18891] write with no open causes core dump
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 17:44 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00764.html. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2004-12-10 17:44:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug middle-end/18928] ice on valid code with -O2 -fPIC
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:01 --- This used to work with my somewhat outdated version 20041015; it must be a regression since then. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug libfortran/17597] list directed read has error
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-12-10 18:03 --- The patch included here http://gcc.gnu.org/ml/fortran/2004-12/msg00088.html fixes this problem. -- steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17597
[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:04 --- I can, however, confirm the segfault on top-of-mainline. No reduced testcase, however. W. -- What|Removed |Added Known to fail||4.0.0 Summary|ice on valid code with -O2 -|[4.0 regression] ice on |fPIC|valid code with -O2 -fPIC Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 18:11 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 05:24 +, kazu at cs dot umass dot edu wrote:
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09
05:24 ---
Updated the testcase like so:
/* PR tree-optimization/18694
The dominator optimization didn't take the PHI evaluation order
into account when threading an edge. */
extern void abort (void) __attribute__((noreturn));
extern void exit (int) __attribute__((noreturn));
void __attribute__((noinline))
foo (int i)
{
int next_n = 1;
int j = 0;
for (; i != 0; i--)
{
int n;
for (n = next_n; j n; j++)
next_n++;
if (j != n)
abort ();
}
}
int
main (void)
{
foo (2);
exit (0);
}
Can you go ahead and install this into the testsuite? No need to xfail
since we ought to have a patch installed for the problem soon.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:13
---
Here's a small testcase:
--
const char *toHex( unsigned short u )
{
static char hexVal[5];
int i = 3;
while ( i = 0 ) {
unsigned short hex = (u 0x000f);
if ( hex 0x0a )
hexVal[i] = '0'+hex;
else
hexVal[i] = 'A'+(hex-0x0a);
i--;
}
hexVal[4] = '\0';
return hexVal;
}
---
sandbox/tt ../../build-gcc/gcc-install/bin/c++ -O2 -fPIC -c x.cc
c++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
W.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-10 18:13:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 18:14 --- : Search converges between 2004-11-03-014001-trunk (#612) and 2004-11-03-161001-trunk (#613). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug c/18929] New: Profiling optimized code causes segfaults on ARM due to missing frames
When compiling with the arm-linux compiler with optimization enabled, the compiler removes frame pointers from functions even when they are profiled. This leads to a segmentation fault with the glibc version of mcount when it attempts to determine the caller of a function from the current stack because mcount assumes the frame pointer is there. It seems that optimized functions, on this platform, should not drop their frame pointers when profiling is enabled. -- Summary: Profiling optimized code causes segfaults on ARM due to missing frames Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: opensource at artnaseef dot com CC: gcc-bugs at gcc dot gnu dot org,opensource at artnaseef dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929
[Bug c/18929] Profiling optimized code causes segfaults on ARM due to missing frames
--- Additional Comments From opensource at artnaseef dot com 2004-12-10 18:19 --- Created an attachment (id=7720) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7720action=view) recommended fix This patch fixes the problem by forcing functions to keep their frame pointers when compiled with profiling. It maintains portability by using a macro, and only defining it for the ARM architecture, that indicates when mcount requires the frame pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929
[Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 18:20 --- Does this work in 3.4.? -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 18:24 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 00:28 +, kazu at cs dot umass dot edu wrote: --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 00:28 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Jeff, I believe your fast-path check is effectively equivalent to if ((e-flags EDGE_DFS_BACK) == 0) I see that we call mark_dfs_back_edges at the beginning of tree_ssa_dominator_optimize. Now, after we call cleanup_tree_cfg, can we trust EDGE_DFS_BACK? No pass in cleanup_tree_cfg really adds an edge. All we do is either remove or redirect edges, so the real question is Do we ever get a new back edge without a EDGE_DFS_BACK mark as a result of edge redirection? If we have a forwarder block BB flowing into the loop header, BB's sole successor edge may be marked with a EDGE_DFS_BACK, but its incoming edges may not be. When we call cleanup_forwarder_blocks, the edges that will survive are BB's incoming edges, not the edge going out of BB, so we may end up with a back edge without a EDGE_DFS_BACK mark. Hmm, I think you're right. I think we should call mark_dfs_back_edges at the beginning of every iteration That might be advisable -- we use EDGE_DFS_BACK to avoid creating irreducible loops as a result of jump threading IIRC. or simply use dominated_by_p, which is not too expensive - only a couple of if statements, assuming the dominator infomatino is available. EDGE_DFS_BACK would have been more efficient. But I don't think it's 100% safe right now. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug c/18930] New: name clash in C?
On several different version of gcc (2.95, 3.3 and 3.4)
(gcc-3.4 --version reports: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2))
When I compile a.c I get errors:
a.c:6: error: parse error before c
etc
but b.c compiles without errors. As I understand the ANSI-C standard,
type names and variable names should be separate namespaces - and both
programs should compile (borland turbo C 2.01 compiles both programs).
== a.c ==
#include stdio.h
typedef int i;
typedef char c;
i main (i c, c ** v)
{
i i=1;
printf(%d\n,c+i);
return 0;
}
== b.c ==
#include stdio.h
typedef int i;
typedef char c;
i main (i C, c ** v)
{
i i=1;
printf(%d\n C+i);
return 0;
}
--
Summary: name clash in C?
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at engelbrecht dot dk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18930
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-12-10 18:38 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) or simply use dominated_by_p, which is not too expensive - only a couple of if statements, assuming the dominator infomatino is available. EDGE_DFS_BACK would have been more efficient. But I don't think it's 100% safe right now. not that much. Since you do not change cfg in the progress of dominator optimizations, you should have fast query structure for dominators up-to-date; i.e. testing whether a basic block dominates other takes only two comparisons of integers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames
--- Additional Comments From opensource at artnaseef dot com 2004-12-10 18:40 --- Subject: Re: Profiling optimized code causes segfaults on ARM due to missing frames I have not tested it, but I don't see why not. The patch is fairly short and straight-forward, I believe. -- Original Message - Subject: [Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames Date: 10 Dec 2004 18:20:04 - From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 18:20 --- Does this work in 3.4.? -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929
[Bug rtl-optimization/18928] [4.0 regression] ice on valid code with -O2 -fPIC
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 18:40 --- simplify_plus_minus is where the problem is. -- What|Removed |Added Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 18:53 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Zdenek, or simply use dominated_by_p, which is not too expensive - only a couple of if statements, assuming the dominator infomatino is available. EDGE_DFS_BACK would have been more efficient. But I don't think it's 100% safe right now. not that much. Since you do not change cfg in the progress of dominator optimizations, you should have fast query structure for dominators up-to-date; i.e. testing whether a basic block dominates other takes only two comparisons of integers. Right. If we have dominator information available, mark_dfs_back_edges does nothing but duplicates a part of what the dominator information has to offer. (It's not that mark_dfs_back_edges is very flow, but ) Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-10 18:58 --- I'm not sure redirecting __addvsi3 to __addvdi3 is correct. If we provide that symbol at all, I think it should do what it advertises. Just so I'm clear, are we invoking __addvsi3 right now, or is it just that __addvdi3 has the wrong implementation? -- What|Removed |Added GCC build triplet|*-*-* | GCC host triplet|*-*-* | GCC target triplet|*-*-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 19:18 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: I think so. :-) I don't. :( I think it'll record tmp_1 = next_2, which is actually wrong, even though it doesn't actually cause problems with this testcase. What thread_across_edge is really trying to do is What would these statements in E-dest look like if they appeared at the end of E-src? Then the question is reduced to whether each statement in E-dest is translated correctly. To do the translation, we use SSA_NAME_VALUE, but note that we don't use it iteratively. In other words, given a SSA_NAME variable VAR, we don't do this while (TREE_CODE (var) == SSA_NAME SSA_NAME_VALUE (var) != NULL_TREE) var = SSA_NAME_VALUE (var); And the reason we don't do that is we can actually get into a loop due to equivalences created by equality tests. p.s. By the way, I am now wondering how many times we succeed in threading a back edge. It does happen, but I don't know how often. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug c/18282] PR c/17384 patch causes regression from 3.4.2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-10 19:23 --- Subject: Bug 18282 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-10 19:23:25 Modified files: gcc: ChangeLog attribs.c c-common.c Added files: gcc/testsuite/gcc.dg: attr-mode-2.c Log message: PR c/18282 * attribs.c (decl_attributes): Clear DECL_ALIGN when relaying out decl. * c-common.c (handle_mode_attribute): Handle enumeral types. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.726r2=2.2326.2.727 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/attribs.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.28r2=1.28.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.476.4.10r2=1.476.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-mode-2.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18282
[Bug c/18282] PR c/17384 patch causes regression from 3.4.2
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-10 19:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18282
[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-10 19:24 --- I'm not sure redirecting __addvsi3 to __addvdi3 is correct. If we provide that symbol at all, I think it should do what it advertises. But what we export now as __addvsi3 will be exported as __addvdi3 after the fix. Just so I'm clear, are we invoking __addvsi3 right now, or is it just that __addvdi3 has the wrong implementation? The latter. __addvdi3 uses double words everywhere, so is actually __addvti3 on 64-bit targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug middle-end/18903] [4.0 Regression] ice in bsi_after_labels
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-10 19:32 --- Subject: Bug 18903 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-10 19:32:14 Modified files: gcc: ChangeLog tree-cfg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr18903.c Log message: 2004-12-10 Andrew Pinski [EMAIL PROTECTED] PR middle-end/18903 * gcc.c-torture/compile/pr18903.c: New test. 2004-12-10 Andrew Pinski [EMAIL PROTECTED] PR middle-end/18903 * tree-cfg.c (remove_bb): Put the moved label at the beginning of the basic block. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6773r2=2.6774 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gccr1=2.133r2=2.134 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4736r2=1.4737 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr18903.c.diff?cvsroot=gccr1=NONEr2=1.1 --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 19:32 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18903
[Bug middle-end/18931] jar - .so optimization problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 19:41 --- What target is this on? i686-pc-linux? I cannot reproduce this on 20041204 on powerpc-darwin. -- What|Removed |Added Component|java|middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug middle-end/18931] jar - .so optimization problem
--- Additional Comments From overholt at redhat dot com 2004-12-10 19:43 --- Yes, this is i686-linux. I'll update to a more recent snapshot and see if I can reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 19:44 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: By the way, I am now wondering how many times we succeed in threading a back edge. I just put in some instrumentation. It happens relatively often. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 20:00 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote: --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:08 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Jeff, Note that recording tmp_1 = next_2 isn't particularly good either since tmp_1 really isn't equivalent to next_2. It's equivalent to the previous valueof n next_2, which was next_3. ugh. Anyway, I'll verify that Kazu's patch handles this correctly. I think so. :-) What thread_across_edge is really trying to do is What would these statements in E-dest look like if they appeared at the end of E-src? Then the question is reduced to whether each statement in E-dest is translated correctly. To do the translation, we use SSA_NAME_VALUE, but note that we don't use it iteratively. In other words, given a SSA_NAME variable VAR, we don't do this while (TREE_CODE (var) == SSA_NAME SSA_NAME_VALUE (var) != NULL_TREE) var = SSA_NAME_VALUE (var); because SSA_NAME_VALUE is supposed to be closed so that you won't need to iterate. So when we follow copy-of relation from tmp_1 to next_2 using SSA_NAME_VALUE, we don't follow next_2 to something else. Note also that lookup_avail_expr does not translate the expression in hash table using SSA_NAME_VALUE. What we translate is the expression that we look up. BTW, I may have a nice clean way to deal with this problem which doesn't depend on us not walking the SSA_NAME_VALUE chain. I'm looking into it now... jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-10 20:04 --- If addvsi3 actually performs addvdi3, that will be most surprising to everyone. I think that's a very bad idea. Since we are not invoking addvsi3, and I suspect it's impossible to convince the compiler to do so, After your patch, that's indeed the case. I think there's no reason to provide the backward compatibility function at all; the symbol was unused and unusable. Except that, before your patch, the 64-bit compiler was emitting addvsi3 (see comment #6 by Steven). So I think we need to provide the symbol. The question would then be: should we provide real SImode addition or word_mode addition as currently? Strict backwards compatibility would imply the latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 20:12 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 19:57 +, kazu at cs dot umass dot edu wrote: --- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:57 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Jeff, I think so. :-) I don't. :( I think it'll record tmp_1 = next_2, which is actually wrong, even though it doesn't actually cause problems with this testcase. IMHO, you should really think of it as tmp_1 - next_2 or tmp_1 is a copy-of next_2. It is a one-way relation, not an equivalence because it is not symmetric. Err, no. You're totally warping how the the equivalency code is meant to work. It's a symmetric relationship and it's your patch that is making it asymmetric. Let me also think hard to see if I can prove my patch is correct or come up with a counterexample. I certainly don't intend to push my patch blindly. Don't bother. The patch is wrong.There's a couple of very simple ways to fix this problem that I'm evaluating. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-10 20:17 --- Since the symbol exists in 3.3 (which I'd forgotten), we have to keep it. But I don't see any reason we can't fix the bug in its implementation. So let's do proper simode arithmetic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug target/18932] New: [3.4 regression] -march=pentium4 -O2 causes ICE
This patch http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00701.html causes a regression on i386. -- Summary: [3.4 regression] -march=pentium4 -O2 causes ICE Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: target AssignedTo: rth at redhat dot com ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18932
[Bug target/18932] [3.4 regression] -march=pentium4 -O2 causes ICE
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-10 20:25 --- Do not assign prs to people unless they request it. Assignment implies actively working on the problem. Use cc for advisory. -- What|Removed |Added AssignedTo|rth at redhat dot com |rth at gcc dot gnu dot org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18932
[Bug c++/18933] New: pointer-to-member called on incomplete type generates bad code
When presented with the attached code, gcc (taken from CVS on Dec. 6 2004)
generates bad code for the function callpmf(). The code it generates never
calls the member function, so the exit status of this program is garbage (I get
39). No diagnostic is issued when compiling.
If you replace the declaration of A with a trivial definition (class A{};), it
generates the correct code.
gcc-3.4.2 and earlier generated the correct code regardless of whether A was an
incomplete type.
class A;
class B {
public:
int memfn() { return 1; }
};
int callpmf(A* a_ptr, int (A::*memfn_ptr)()) {
return (a_ptr-*memfn_ptr)();
}
int main() {
B b;
return callpmf((A*)b, (int (A::*)())B::memfn);
}
This bug looks related to 15684, which seems to be debating whether this is a
legal thing to do or not. If it is decided that this is illegal, a diagnostic
would be helpful.
--
Summary: pointer-to-member called on incomplete type generates
bad code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: efrias at syncad dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18933
[Bug c++/18933] pointer-to-member called on incomplete type generates bad code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 21:09 --- Yes this invalid code and here is the werid part we have a error_mark_node. So this is a dup of bug 15684. *** This bug has been marked as a duplicate of 15684 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18933
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 21:31 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Jeff, Err, no. You're totally warping how the the equivalency code is meant to work. It's a symmetric relationship and it's your patch that is making it asymmetric. I thought SSA_NAME_VALUE gets me a gimple min invariant or the earliest SSA_NAME that has the same value. Don't bother. The patch is wrong. Can you come up with a hypothetical scenario? Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From law at redhat dot com 2004-12-10 21:42 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) On Fri, 2004-12-10 at 21:31 +, kazu at cs dot umass dot edu wrote: Can you come up with a hypothetical scenario? No need. It's fundamentally broken in that it's recording an invalid equivalence. It's recording that tmp_1 = next_2 which is totally bogus. The only reason it works is because we don't walk through all the SSA_NAME_VALUEs back to the oldest. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug c++/18933] pointer-to-member called on incomplete type generates bad code
--- Additional Comments From bangerth at dealii dot org 2004-12-10 21:53 --- The fact that we don't issue any errors is a duplicate of PR 15684. However, the code is fundamentally broken in that you cast a pointer to B into a pointer to A and use it to do something with it. This violates aliasing constraints, and you shouldn't be surprised that your code does weird things. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18933
[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage
Once more i couldn't upload an attachment with the bugzilla upload form, so i send it here. I'll refer to it later. Regards Andre compiletimetest2.cc.gz Description: GNU Zip compressed data
[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 22:25 --- Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch) Hi Jeff, Can you come up with a hypothetical scenario? No need. It's fundamentally broken in that it's recording an invalid equivalence. It's recording that tmp_1 = next_2 which is totally bogus. The only reason it works is because we don't walk through all the SSA_NAME_VALUEs back to the oldest. Yes, I was relying on that fact. Ah, now I see that we have two different definitions of SSA_NAME_VALUE. Rather than pushing what I think is the right definition, let's get a correct definition from the author of tree-ssa-dom.c. :-) Is the following more or less correct? SSA_NAME_VALUE(X) gives you a gimple min invariant or an SSA_NAME that has the same value as X. If we do not find a gimple min invariant for X, we make every effort to make SSA_NAME_VALUE(X) evaluate to the oldest SSA_NAME that has the same value as X (via record_const_or_copy, etc), but that is not guaranteed. For the best result, you may have to walk SSA_NAME_VALUE, but it's questionable how profitable that is. The only comment I can find for SSA_NAME_VALUE is this: /* Get the value of this SSA_NAME, if available. */ #define SSA_NAME_VALUE(N) \ SSA_NAME_CHECK (N)-ssa_name.value_handle I think it would be helpful to expand the comment for a future reference. To be honest, given that tree-ssa-dom.c never walks SSA_NAME_VALUE and that record_const_or_copy makes a transitive closure of copy-of relations, I was under the impression that SSA_NAME_VALUE gives you the oldest value. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage
--- Additional Comments From andre dot maute at gmx dot de 2004-12-10 22:36 --- I don't think the compile time regression is solved in the actual g++-4.0. I made some run time measurements with the attached file compiletimetest2.cc on a PIII 550. The __DEBUG__ tests only enable iostream and some cerr lines. g++ -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs Configured with: ../gcc-3.2.1/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib --enable-__cxa_atexit--enable-clocale=gnu Thread model: posix gcc version 3.2.1 g++-3.3.5 -v Reading specs from /opt/gcc-3.3.5/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs Configured with: ../gcc-3.3.5/configure --prefix=/opt/gcc-3.3.5 --enable-shared--enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.3.5 --with-cpu=pentium3 Thread model: posix gcc version 3.3.5 g++-3.4.3 -v Reading specs from /opt/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc-3.4.3 --enable-shared--enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.4.3 --with-arch=pentium3 Thread model: posix gcc version 3.4.3 g++-4.0-20041205 -v Reading specs from /opt/gcc-4.0-20041205/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041205/configure --prefix=/opt/gcc-4.0-20041205 --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-nls --program-suffix=-4.0-20041205 --with-arch=pentium3 Thread model: posix gcc version 4.0.0 20041205 (experimental) time g++ -c -O3 -D __NDEBUG__ compiletimetest2.cc real 0m9.957suser 0m9.910ssys 0m0.090s time g++ -c -O3 -D __DEBUG__ compiletimetest2.cc real0m13.544suser0m13.270ssys 0m0.170s time g++-3.3.5 -c -O3 -D __NDEBUG__ compiletimetest2.cc real 0m9.881suser 0m9.740ssys 0m0.130s time g++-3.3.5 -c -O3 -D __NDEBUG__ compiletimetest2.cc real 0m9.881suser 0m9.740ssys 0m0.130s time g++-3.4.3 -c -O3 -D __NDEBUG__ compiletimetest2.cc real0m18.614suser0m18.240ssys 0m0.310s time g++-3.4.3 -c -O3 -D __DEBUG__ compiletimetest2.cc real0m21.563suser0m21.050ssys 0m0.510s time g++-4.0-20041205 -c -O3 -D __NDEBUG__ compiletimetest2.cc real0m24.983suser0m24.740ssys 0m0.160s time g++-4.0-20041205 -c -O3 -D __DEBUG__ compiletimetest2.cc real0m31.269suser0m30.230ssys 0m0.240s Regards Andre -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613
[Bug target/18459] [4.0 Regression] gcj no longer works on win32
--- Additional Comments From dannysmith at users dot sourceforge dot net 2004-12-10 23:11 --- Ugh, I see what is wrong with the patch I posted at: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html * config/i386/cygming.h (TARGET_USE_JCR_SECTION): Overide default. Index: gcc/gcc/config/i386/cygming.h === RCS file: /cvs/gcc/gcc/gcc/config/i386/cygming.h,v retrieving revision 1.23 diff -c -3 -p -r1.23 cygming.h *** gcc/gcc/config/i386/cygming.h 6 Nov 2004 04:28:06 - 1.23 --- gcc/gcc/config/i386/cygming.h 25 Nov 2004 21:25:17 - *** extern int i386_pe_dllimport_name_p (con *** 408,413 --- 410,420 while (0) #endif /* HAVE_GAS_WEAK */ + /* FIXME: SUPPORTS_WEAK TARGET_HAVE_NAMED_SECTIONS is true, +but for .jcr section to work we also need crtbegin and crtend +objects as well as linker supoort. */ + #define USE_JCR_SECTION 0 + /* Decide whether it is safe to use a local alias for a virtual function when constructing thunks. */ #undef TARGET_USE_LOCAL_THUNK_ALIAS_P That should be #define TARGET_USE_JCR_SECTION 0 Sorry, I'll retest with clean CVS co and resubmit patch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459
[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-10 23:12 --- (In reply to comment #9) g++-4.0-20041205 -v Reading specs from /opt/gcc-4.0-20041205/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041205/configure --prefix=/opt/gcc-4.0-20041205 --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-nls --program-suffix=-4.0-20041205 --with-arch=pentium3 Thread model: posix gcc version 4.0.0 20041205 (experimental) You need to add --disable-checking to your configure flags in order to compare against a development branch. When release branches are made, checking gets turned off by default by configure, but it's on in non-release branches. The compiler is a *lot* slower with checking -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613
[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage
--- Additional Comments From andre dot maute at gmx dot de 2004-12-10 22:42 --- sorry missed the following two lines time g++-3.3.5 -c -O3 -D __DEBUG__ compiletimetest2.cc real0m12.454suser0m12.210ssys 0m0.230s so g++-3.3.5 is really good, and I don't hope that we will see 40 s for g++-4.1 ;-) Regards Andre -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613
[Bug c++/18934] Spurious Uninitialized Variable Warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 23:20 --- Fixed in 4.0.0 by moving the uninitializing warning to the tree level where the exceptions have not been lowered to setjmp/longjmp which is what is causing the warning. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC target triplet||i686-pc-cygwin Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18934
Re: [Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage
On Fri, 10 Dec 2004, andre maute wrote: Once more i couldn't upload an attachment with the bugzilla upload form, so i send it here. You can email it to [EMAIL PROTECTED] with a subject of Bug 16613 (or whatever the bug number is), and it'll auto-add it to the bug for you.
[Bug driver/18732] Compiler will not compile two source files if first has error or is unreadable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-11 00:02 --- Subject: Bug 18732 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-11 00:02:00 Modified files: gcc: ChangeLog gcc.c Log message: PR 18732 * gcc.c (main): Do not break out of loop when error is reported while processing one source file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6777r2=2.6778 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gccr1=1.440r2=1.441 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18732
[Bug c/18935] New: Error on reference of 'extern' variable in block scope.
This problem occurs in both mode c89 and c99.
I will try to describe it with a simple example.
- code.c --
#include stdio.h
int main(void)
{
extern int a;
printf(a: %d\n, a);
int a = 20; /* internal compiler error */
return 0;
}
-
If you compile this code, you'll get follwing error message.
$ gcc -Wall -std=c89 code.c
code.c: In function `main':
code.c:7: internal compiler error: in make_decl_rtl, at varasm.c:752
Inside a block scope, the codes are executed sequently.
So I think, when there is a variable declaration with 'extern', that the
compiler should either let occur an error of double variable-declaration or show
warning only and just give the local variable priority.
Thank you for reading.
--
Summary: Error on reference of 'extern' variable in block scope.
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sorie at sorie dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18935
[Bug c/18935] [3.4 Regression] Error on reference of 'extern' variable in block scope.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-11 01:21 --- Fixed at least on the mainline: Search converges between 2004-07-31-trunk (#500) and 2004-08-01- trunk (#501). But it is a regression from 2.95.3: : Search converges between 2001-03-11-trunk (#10) and 2001-03-18-trunk (#11). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Known to work||2.95.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-12-11 01:21:44 date|| Summary|Error on reference of |[3.4 Regression] Error on |'extern' variable in block |reference of 'extern' |scope. |variable in block scope. Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18935
[Bug fortran/18913] [g77 only] seg. fault with -finit-local-zero option on complex array of dimension 1
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-11 01:35 --- same results on 3.4.2 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-11 01:35:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug target/18002] [3.4/4.0 Regression] 'while' loop performace regression on avr target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-11 01:49 --- Subject: Bug 18002 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-11 01:49:06 Modified files: gcc: ChangeLog dojump.c Log message: PR target/18002 PR middle-end/18424 * dojump.c (do_jump): When attempting to reverse the effects of fold_single_bit_test, we need to STRIP_NOPS and narrowing type conversions, and handle BIT_XOR_EXPR that's used to invert the sense of the single bit test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6778r2=2.6779 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dojump.c.diff?cvsroot=gccr1=1.32r2=1.33 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18002
[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-11 01:49 --- Subject: Bug 18424 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-11 01:49:06 Modified files: gcc: ChangeLog dojump.c Log message: PR target/18002 PR middle-end/18424 * dojump.c (do_jump): When attempting to reverse the effects of fold_single_bit_test, we need to STRIP_NOPS and narrowing type conversions, and handle BIT_XOR_EXPR that's used to invert the sense of the single bit test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6778r2=2.6779 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dojump.c.diff?cvsroot=gccr1=1.32r2=1.33 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite
--- Additional Comments From jvdelisle at verizon dot net 2004-12-11 05:59 --- ICE on NIST FM252.f reduced case similar to pr#18827 PROGRAM FM252 C ASSIGN 0012 TO I 0012 FORMAT ( ASSIGN FORMAT NUMBER TO INTEGER VARIABLE ) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423
[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite
--- Additional Comments From jvdelisle at verizon dot net 2004-12-11 06:34 --- Some regressions showing up: FM111 and FM252 FM111.f:241: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:154 FM252.f:115: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:154 gcc version 4.0.0 20041210 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423
[Bug tree-optimization/18892] missed optimization with and ==
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-11
07:19 ---
(In reply to comment #5)
(In reply to comment #4)
when I compile this program with mainline. Isnt this what you claimed it
should
be compiled to? or are you claiming it should be optimized to 'return 0'?
I am claiming it should be compiled to return 0. The full testcase which
is closer to
what shows up in GCC is:
void f(int a)
{
int i = a -129;
if (i == 144)
link_error ();
}
The testcase works but for the wrong reason (we call fold for COND_EXPR after
out of ssa because
of tree_cleanup_cfg).
Here is a testcase which fails though:
void g(int) __attribute__((noinline);
void g(int a) { a+=2; }
void f(int a)
{
int i = a -129;
g(i);
if (i == 144)
link_error ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18892
[Bug driver/15690] [4.0 Regression] compilation stops after the first file with errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-11 07:45 --- Fixed by: PR 18732 * gcc.c (main): Do not break out of loop when error is reported while processing one source file. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15690
[Bug c++/18920] New: internal compiler error: Segmentation fault
Here's the output:
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v -
D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE new.cpp new
.ii
ignoring nonexistent directory /usr/i486-slackware-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/qt/include
/usr/include/c++/3.3.4
/usr/include/c++/3.3.4/i486-slackware-linux
/usr/include/c++/3.3.4/backward
/usr/local/include
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -fpreprocessed new.ii -quie
t -dumpbase new.cpp -auxbase new -version -o new.s
GNU C++ version 3.3.4 (i486-slackware-linux)
compiled by GNU C version 3.3.4.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64393
new.cpp:16: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
And here the source:
#include iostream
#include vector
using namespace std;
template class T
struct print_matrix : public unary_functionT, void{
ostream os;
print_matrix( ostream out ) : os( out ){
}
};
templatevectorvectordouble
struct print_matrix : public unary_functionvectorvectordouble , void{
void operator()( T x ){
}
};
int main( int argc, char **argv ){
return 0;
}
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kornel at gazeta dot pl
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18920
[Bug fortran/15966] ICE and segmentation fault on internal write
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 10:50 --- Note that this compiles and runs OK subroutine a() implicit none integer :: i character(100) :: r !! eliminate dimension = works write(r,*) I end subroutine a -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15966
[Bug middle-end/18596] [4.0 regression] ICE in make_decl_rtl
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-10 11:09 --- Ehm, maybe this is a stupid question - but why are we generating a DECL_RTL to begin with, given that we have errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18596
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-10 11:52 --- The fail dates from comment #3 probably refer to this change 2004-10-17 Andrew Pinski [EMAIL PROTECTED] * c-typeck.c (default_function_array_conversion): Always create a[0] for array types. (build_unary_op): Do not fold a[x] into a + x. which was reverted again on the same day. Can someone try with the reghunter to see if it failed before October 17 also? -- What|Removed |Added Known to fail||4.0.0 Known to work||3.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug tree-optimization/18921] [4.0 Regression] wrong code with operator ?
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-10 11:55:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18921
[Bug fortran/16898] Aliasing problem with array descriptors
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 13:02 --- Andrew, This one is fixed now, isn't it? It runs fine with the CVS of 20041205 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898
[Bug middle-end/18921] [4.0 Regression] wrong code with operator ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:35 --- We are getting rid of (k ? 0 : j++) == -1; for some reason even though it has side effects. -- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18921
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 13:35 --- You have fixed this one, haven't you? cvs 20041205 runs it fine. However, in testing, I found another nasty: y = 1/2 + 1/8 !y= 0.125 + 0.5 !!works OK x = set_exponent (y, 5_4) print *,x x = set_exponent (y, 5_8) print *,x end gives $ ./a 0.00 0.00 instead of 20.0 20.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug c++/17395] Incorrect lookup for parameters
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10 13:37 --- (In reply to comment #5) Subject: Re: Incorrect lookup for parameters pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Additional Comments From bangerth at dealii dot org 2004-09-10 14:40 --- | No, GCC is wrong :-) | We had a thread on this issue on the Core reflector, no later than two | days ago. | | Ah, I should have guessed :-) | | In that case, I think I should confirm the bug. | W. Is it normal that I get a mail from pinskia and signed W.? What most likely happened is that bugzilla did not sent message before, so when I reconfirmed the bug, bugzilla sent out all of the pending messages for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17395
[Bug target/18925] Invalid gprel relocation in PIC
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18925
[Bug target/18925] Invalid gprel relocation in PIC
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18925
[Bug middle-end/18596] [4.0 regression] ICE in make_decl_rtl
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-10 14:23 --- The problem occurs in no-unit-at-a-time mode, so the nested functions are expanded, and that is where the problems start. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18596
[Bug fortran/18827] ICE on assign to common variable
--- Additional Comments From wf_cs at yahoo dot com 2004-12-10 14:58 --- I've fixed the first and am looking into the second. I think the second (variable with equivalence)is an invalid code. ifort also gives an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-10 15:32 --- Patch here: http://gcc.gnu.org/ml/fortran/2004-12/msg00099.html -- What|Removed |Added Keywords||patch, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16536
