[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #3 from pluto at agmk dot net 2006-09-04 06:01 --- (In reply to comment #2) t.cc: In function #8216;void test(base*, void (base::*)())#8217;: t.cc:19: error: converting from #8216;void (base::)()#8217; to #8216;void (*)()#8217; Why do you think this is valid thing to do? There is no way to get a normal function pointer from a pointer to member function. this is gnu c++ extension: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Bound-member-functions.html#Bound-member-functions -- pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 06:06 --- (In reply to comment #3) this is gnu c++ extension: Yes but you are using the extension incorrectly anyways as you don't pass this to the function. Did you read that page? extern A a; extern int (A::*fp)(); typedef int (*fptr)(A *); fptr p = (fptr)(a.*fp); While you do: pf f1 = (pf)( o-*pmf ); f1(); Really it should have been: f1(o); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-04 06:13 --- Ok, I have a more correct patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #5 from pluto at agmk dot net 2006-09-04 06:33 --- (In reply to comment #4) (In reply to comment #3) this is gnu c++ extension: Yes but you are using the extension incorrectly anyways as you don't pass this to the function. Did you read that page? extern A a; extern int (A::*fp)(); typedef int (*fptr)(A *); fptr p = (fptr)(a.*fp); While you do: pf f1 = (pf)( o-*pmf ); f1(); Really it should have been: f1(o); compiler reports an error now. test.cpp:18: error: too many arguments to function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #6 from pluto at agmk dot net 2006-09-04 06:33 --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) this is gnu c++ extension: Yes but you are using the extension incorrectly anyways as you don't pass this to the function. Did you read that page? extern A a; extern int (A::*fp)(); typedef int (*fptr)(A *); fptr p = (fptr)(a.*fp); While you do: pf f1 = (pf)( o-*pmf ); f1(); Really it should have been: f1(o); compiler reports an error now. test.cpp:18: error: too many arguments to function aaa, sorry. please ignore this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug c++/22597] [4.0 Regression] pure attribute produces incorrect results
--- Comment #6 from jason at gcc dot gnu dot org 2006-09-04 07:51 --- Fixed in 4.1. The patch is too dangerous to backport to 4.0. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22597
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #4 from tbm at cyrius dot com 2006-09-04 10:10 --- And what if you don't specify --with-sysroot? Everything else compiles fines without this option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #29 from paul dot richard dot thomas at cea dot fr 2006-09-04 10:31 --- Created an attachment (id=12183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12183action=view) Fix for HJ's problems HJ, Could you try this one, please? I am pretty certain it will do the job. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #6 from jakub at gcc dot gnu dot org 2006-09-04 11:28 --- Can you readelf -Ws libstdc++.so.6 | egrep '[EMAIL PROTECTED]' | grep -v ' _Z' on both libraries (the 4.0 built one and 4.1.x --with-long-double-128 one)? The 4.0.x built one should contain the (DFmode) long double *l functions as *l@@GLIBCXX_3.4* symbols while 4.1.x --with-long-double-128 (note, this is something that to my knowledge is only as a patch for 4.1 or on redhat/gcc-4_1-branch, not in stock 4.1, but in stock 4.2) those should be [EMAIL PROTECTED] If that's the same on your system as on mine, then the only reason why you'd get such errors would be a buggy linker. I have tested several linkers (several years old as well as the most recent ones) and they all behave properly. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug c/28946] New: assembler shifts set the flag ZF, no need to re-test to zero
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --
enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
[EMAIL PROTECTED]:~$ cat tmp1.c
int fct1(void);
int fct2(void);
int fct (unsigned nb)
{
if ((nb 5) != 0)
return fct1();
else
return fct2();
}
[EMAIL PROTECTED]:~$ gcc -O3 -fomit-frame-pointer -S tmp1.c -o tmp1.s
[EMAIL PROTECTED]:~$ cat tmp1.s
.file tmp1.c
.text
.p2align 4,,15
.globl fct
.type fct, @function
fct:
movl4(%esp), %eax
shrl$5, %eax
testl %eax, %eax
je .L2
jmp fct1
.p2align 4,,7
.L2:
jmp fct2
.size fct, .-fct
.ident GCC: (GNU) 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED]:~$
The assembly instruction testl %eax, %eax is not needed considering the
Intel documentation of SAL/SAR/SHL/SHR, Flags Affected:
The SF, ZF, and PF flags are set according to the result.
--
Summary: assembler shifts set the flag ZF, no need to re-test to
zero
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #8 from paul dot richard dot thomas at cea dot fr 2006-09-04 12:08 --- Even simpler is: trans-array.c(gfc_trans_array_constructor_value) replace loopvar = se.expr; byloopvar = gfc_evaluate_now (se.expr, pblock); gfc_expand_constructor is called from resolve_expr and from three places in expr.c. As far as I can tell, non-initialization expressions only try the expansion from resolve_expr. If I flag the calls to distinguish them and limit the maximum number of expanded elements to 10, say, in gfc_expand_constructor, the code reflects this but the compilation time does not. Something, somewhere is doing a temporary expansion of the constructor, which is taking all the time. I have to leave this again but I will get to the bottom of it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #7 from jakub at gcc dot gnu dot org 2006-09-04 12:14 --- I have downloaded your tarball and it seems you are not building gcc to default to 128-bit long double on a glibc 2.4+ system. That's very bad idea, you either shouldn't have upgraded to glibc 2.4+, or should have switched everything to 128-bit long double. While --with-long-double-128 libstdc++.so.6 is ABI compatible with older one, --without-long-double-128 exact ABI of the math stubs depends on whatever configure tests find out. With older glibc's, log10l etc. is not in system libm (long double was just 64-bit there and so log10 did the same), but with glibc 2.4+ it is present in libm (and implements the 128bit long double logarithm etc.). Guess something like: --- libstdc++-v3/src/compatibility.cc 2006-02-23 09:55:01.0 +0100 +++ libstdc++-v3/src/compatibility.cc 2006-09-04 14:12:07.0 +0200 @@ -398,7 +398,11 @@ GLIBCXX_3.4) #undef _List_node_base // gcc-4.1.0 -#ifdef _GLIBCXX_LONG_DOUBLE_COMPAT +#if defined _GLIBCXX_LONG_DOUBLE_COMPAT \ +|| (defined (__GLIBC__) \ +(__GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ = 4)) \ +defined __LONG_DOUBLE_MATH_OPTIONAL \ +defined __NO_LONG_DOUBLE_MATH) #define _GLIBCXX_MATHL_WRAPPER(name, argdecl, args, ver) \ extern C double \ __ ## name ## l_wrapper argdecl\ in GCC 4.2 and similar thing, but with also the whole _GLIBCXX_MATHL_WRAPPER and its uses hunks added in GCC 4.1 could cure this (but that doesn't make it a good idea to mix glibc 2.4+ with DFmode GCC). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-04 12:14:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug rtl-optimization/20728] Wrong evaluation order of expressions in combine_reloads() in reload.c
--- Comment #3 from kumura at r2 dot dion dot ne dot jp 2006-09-04 12:48 --- When I ported gcc to our processor architecture a year ago, I found this might be a problem. But, now things have changed. Old version of the function reg_overlap_mentioned_for_reload_p() had abort() in it and the function abort() was activated when reg_overlap_mentioned_for_reload_p() was invoked with a pseudo register. Now reg_overlap_mentioned_for_reload_p() has been modified and the function abort() has been removed from reg_overlap_mentioned_for_reload_p(). So, the problem I got would not happen any more in the latest gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20728
[Bug fortran/28947] New: Double MATMUL() uses wrong array elements
Hi *, the attached code exhibits bad code generation for a double invocation of MATMUL (). Running the code with any recent gfortran gives: h(3,:) = -3.4028235E+38 -3.4028235E+38 -3.4028235E+38 Bummer! The result should be: h(3,:) = 2.00 2.00 3.00 Cheers, -ha -- Summary: Double MATMUL() uses wrong array elements Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug fortran/28947] Double MATMUL() uses wrong array elements
--- Comment #1 from anlauf at gmx dot de 2006-09-04 12:51 --- Created an attachment (id=12184) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12184action=view) Demo code for MATMUL bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug fortran/25620] Missed optimization with power
--- Comment #9 from jv244 at cam dot ac dot uk 2006-09-04 14:10 --- (In reply to comment #7) Looking at how we deal with all this, we seem to like pow() very much during folding, even doing the reverse transformations you suggest. The transformation back to sqrt ( x**N ) with N being an integer could be done by expand_builtin_pow in case that computation of sqrt is cheap. Other than that, exposing integer powers is only a win if theres some CSE possibility. Despite this PR being a bit old, I'd like to add another (similar example, also from real code) where other compilers generate much better code: subroutine t(x) x=x**1.5 end subroutine t pgf90: # lineno: 0 sqrtss (%rdi), %xmm0 mulss (%rdi), %xmm0 movss %xmm0, (%rdi) gfortran -S -O3 -ffast-math: movss (%rdi), %xmm0 movq%rdi, %rbx movss .LC0(%rip), %xmm1 callpowf movss %xmm0, (%rbx) popq%rbx ret trying to time this with the following fragment: y=0. DO i=1,1000 x=i y=y+x**1.5 ENDDO write(6,*) y END pgf90 is about 10 times faster than gfortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
BUG Reports
The exact version of GCC: 3.4.2
The system type; WINDOWS XP, DEV C++ IDE
The options given when GCC was configured/built; --
The complete command line that triggers the bug; NA
The compiler output (error messages, warnings, etc.); NONE
The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a
bug report for the GNAT front end, a complete set of source files (see
below). ATTACHED
Code: ATTACHED
Problem: Input values and output values different! Tried the same on a
Fedora Core 5/GCC 4.1 System. Similar Error
# 1 untest1.c
# 1 built-in
# 1 command line
# 1 untest1.c
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h
1 3
# 19 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h
3
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/_mingw.h
1 3
# 20 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h
2 3
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stddef.h
1 3
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stddef.h 1 3 4
# 213 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stddef.h 3 4
typedef unsigned int size_t;
# 325 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stddef.h 3 4
typedef short unsigned int wchar_t;
# 354 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stddef.h 3 4
typedef short unsigned int wint_t;
# 7 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stddef.h
2 3
# 27 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h
2 3
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdarg.h
1 3
# 1 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stdarg.h 1 3 4
# 44 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 7 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdarg.h
2 3
# 29 C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h
2 3
# 138
C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h 3
typedef struct _iobuf
{
char* _ptr;
int _cnt;
char* _base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char* _tmpfname;
} FILE;
# 163
C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h 3
extern __attribute__ ((dllimport)) FILE _iob[];
# 178
C:/apps/Dev-Cpp/bin/../lib/gcc/mingw32/3.4.2/../../../../include/stdio.h 3
FILE* __attribute__((__cdecl__)) fopen (const char*, const char*);
FILE* __attribute__((__cdecl__)) freopen (const char*, const char*, FILE*);
int __attribute__((__cdecl__)) fflush (FILE*);
int __attribute__((__cdecl__)) fclose (FILE*);
int __attribute__((__cdecl__)) remove (const char*);
int __attribute__((__cdecl__)) rename (const char*, const char*);
FILE* __attribute__((__cdecl__)) tmpfile (void);
char* __attribute__((__cdecl__)) tmpnam (char*);
char* __attribute__((__cdecl__)) _tempnam (const char*, const char*);
int __attribute__((__cdecl__)) _rmtmp(void);
char* __attribute__((__cdecl__)) tempnam (const char*, const char*);
int __attribute__((__cdecl__)) rmtmp(void);
int __attribute__((__cdecl__)) setvbuf (FILE*, char*, int, size_t);
void __attribute__((__cdecl__)) setbuf (FILE*, char*);
int __attribute__((__cdecl__)) fprintf (FILE*, const char*, ...);
int __attribute__((__cdecl__)) printf (const char*, ...);
int __attribute__((__cdecl__)) sprintf (char*, const char*, ...);
int __attribute__((__cdecl__)) _snprintf (char*, size_t, const char*, ...);
int __attribute__((__cdecl__)) vfprintf (FILE*, const char*, __gnuc_va_list);
int __attribute__((__cdecl__)) vprintf (const char*, __gnuc_va_list);
int __attribute__((__cdecl__)) vsprintf (char*, const char*, __gnuc_va_list);
int __attribute__((__cdecl__)) _vsnprintf (char*, size_t, const char*,
__gnuc_va_list);
int __attribute__((__cdecl__)) snprintf(char* s, size_t n, const char* format,
...);
extern __inline__ int __attribute__((__cdecl__))
vsnprintf (char* s, size_t n, const char* format, __gnuc_va_list arg)
{ return _vsnprintf ( s, n, format, arg); }
int __attribute__((__cdecl__)) vscanf (const char * __restrict__,
__gnuc_va_list);
int __attribute__((__cdecl__)) vfscanf (FILE * __restrict__, const char *
__restrict__,
__gnuc_va_list);
int __attribute__((__cdecl__)) vsscanf (const char * __restrict__,
const char * __restrict__, __gnuc_va_list);
int __attribute__((__cdecl__)) fscanf (FILE*, const char*, ...);
int __attribute__((__cdecl__)) scanf (const char*, ...);
int __attribute__((__cdecl__)) sscanf (const char*, const char*, ...);
int __attribute__((__cdecl__)) fgetc (FILE*);
char* __attribute__((__cdecl__)) fgets (char*, int, FILE*);
int __attribute__((__cdecl__)) fputc (int, FILE*);
int __attribute__((__cdecl__)) fputs (const char*, FILE*);
char* __attribute__((__cdecl__)) gets (char*);
int
[Bug fortran/25620] Missed optimization with power
--- Comment #10 from rguenther at suse dot de 2006-09-04 14:17 --- Subject: Re: Missed optimization with power On Mon, 4 Sep 2006, jv244 at cam dot ac dot uk wrote: --- Comment #9 from jv244 at cam dot ac dot uk 2006-09-04 14:10 --- (In reply to comment #7) Looking at how we deal with all this, we seem to like pow() very much during folding, even doing the reverse transformations you suggest. The transformation back to sqrt ( x**N ) with N being an integer could be done by expand_builtin_pow in case that computation of sqrt is cheap. Other than that, exposing integer powers is only a win if theres some CSE possibility. Despite this PR being a bit old, I'd like to add another (similar example, also from real code) where other compilers generate much better code: subroutine t(x) x=x**1.5 end subroutine t pgf90: # lineno: 0 sqrtss (%rdi), %xmm0 mulss (%rdi), %xmm0 movss %xmm0, (%rdi) gfortran -S -O3 -ffast-math: movss (%rdi), %xmm0 movq%rdi, %rbx movss .LC0(%rip), %xmm1 callpowf movss %xmm0, (%rbx) popq%rbx ret This should be doable from expand_builtin_pow if we have an optab for the sqrt computation. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #13 from nathan at gcc dot gnu dot org 2006-09-04 15:22 --- Subject: Bug 23287 Author: nathan Date: Mon Sep 4 15:21:50 2006 New Revision: 116679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116679 Log: cp/ PR 23287 Revert my 2006-09-01 patch. * parser.c: Reverted. * pt.c: Reverted. testsuite/ PR c++/23287 Revert my 2006-09-01 patch * g++.dg/parse/dtor12.C: Remove. Removed: trunk/gcc/testsuite/g++.dg/parse/dtor12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-09-04 15:22 --- Furthermore, defining _Tag in an anonymous namespace will cause the compiler to give all functions with _Tag in their signature internal linkage. I don't understand why you would want this. This is precisely one reason why anonymous namespaces are useful. It provides a very viceral way to sanity check an API. Make sure that the private parts really are private, say. Please, let's leave rope out of it. I think that there are good reasons to use anonymous namespaces in headers, even if you disagree with these designs personally. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #14 from nathan at gcc dot gnu dot org 2006-09-04 15:22 --- I have reverted this patch. -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/28871] massive C++ compile time slowdown
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-09-04 15:25 --- ...this is a PCH vs. anonymous namespace issue. Crack smoking! If PCH is incommpatible with anonymous namespaces, then -Winvalid-pch needs to warn about it at the time of pch creation. I'm going to check in a fix to this, in that I'm going to revert to using stdc++.h and remove the one use of anonymous namespaces. I'll also make an enhancement request about -Winvalid-pch vs. anonymous namespaces. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
[Bug c++/28871] massive C++ compile time slowdown
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-04 15:26 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
[Bug tree-optimization/28948] New: -fprofile-generate/use and C++ anonymous namespaces don't mix
As the subject says. Take this:
-
namespace {
void f() {}
}
int main () {
f();
}
-
and then do this:
g/x c++ -fprofile-generate x.cc ; ./a.out
g/x c++ -fprofile-use x.cc
x.cc: In function 'voidunnamed::f()':
x.cc:6: error: coverage mismatch for function
'_ZN33_GLOBAL__N_x.cc__3836C1911fEv' while reading counter 'arcs'
x.cc:6: error: checksum is 87e5f01 instead of fec92a63
This is due to the fact that gcc mangles anonymous namespace members with
different names every time it compiles the file. -fprofile-use should take
that into account.
Note that some libstdc++ has some anonymous namespaces. Consequently, some
programs that use libstdc++ will not be able to use -fprofile-generate/use
and there is nothing a program author can do about it.
Best
W.
--
Summary: -fprofile-generate/use and C++ anonymous namespaces
don't mix
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
[Bug bootstrap/28949] New: [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
I did: ../configure --target=arm-linux --prefix=/usr/local/DIR/gcc-arm- svn20060904 --enable-languages=c --with-as=/usr/local/bin/arm-linux-as --with-ld=/usr/local/bin/arm-linux-ld --without-headers --disable-shared --disable-multilib --enable-threads=single --disable-nls --disable-libmudflap --disable-libssp make error message: -- snip -- ... checking for pid_t... no checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libiberty] Error 1 make[1]: Leaving directory `/TMP/svn/gcc/build-arm' make: *** [all] Error 2 -- snip -- The error is not specific for the arm target, I'm also getting it for several other targets. -- Summary: [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-linux-gnu (and several others) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
--- Comment #1 from bunk at stusta dot de 2006-09-04 15:34 --- Created an attachment (id=12185) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12185action=view) configure log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
--- Comment #2 from bunk at stusta dot de 2006-09-04 15:34 --- Created an attachment (id=12186) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12186action=view) make log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug c++/28871] massive C++ compile time slowdown
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-09-04 15:41 --- Subject: Bug 28871 Author: bkoz Date: Mon Sep 4 15:41:18 2006 New Revision: 116680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116680 Log: 2006-09-04 Benjamin Kosnik [EMAIL PROTECTED] PR c++/28871 * include/ext/bitmap_allocator.h: Add comment for end of anonymous namespace. * include/ext/rope: Same. * include/bits/cpp_type_traits.h: Same. * include/tr1/tuple: Same. * include/tr1/functional_iterate.h: Same. * include/bits/cpp_type_traits.h: Revert anonymous namespace change, use nested detail instead. * testsuite/lib/libstdc++.exp (libstdc++_init): PCHFLAGS revert to stdc++.h. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/ext/bitmap_allocator.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/tr1/functional_iterate.h trunk/libstdc++-v3/include/tr1/tuple trunk/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
[Bug tree-optimization/28948] -fprofile-generate/use and C++ anonymous namespaces don't mix
--- Comment #1 from bangerth at dealii dot org 2006-09-04 16:04 --- I forgot to say that this comes from trying to use -fprofile-use on 447.dealII from SPEC 2006... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
[Bug fortran/28947] Double MATMUL() uses wrong array elements
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug testsuite/28950] New: regex wrong for gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
I am able to verify that the regex for
gcc/testsuite/gcc.target/powerpc/ppc-and-1.c is
incorrect as previously diagnosed on the gcc mailing list...
http://gcc.gnu.org/ml/gcc/2006-09/msg00030.html
...and that the following change fixes the problem...
--- gcc-4.2-20060901/gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
2006-08-13 14:10:07.0 -0400
+++ gcc-4.2-20060901.allocate/gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
2006-09-01 20:10:44.0 -0400
@@ -1,8 +1,8 @@
/* { dg-do compile { target { powerpc*-*-* lp64 } } } */
/* { dg-options -O2 } */
-/* { dg-final { scan-assembler rlwinm \[0-9\]+,\[0-9\]+,0,0,30 } } */
-/* { dg-final { scan-assembler rlwinm \[0-9\]+,\[0-9\]+,0,29,30 } } */
+/* { dg-final { scan-assembler rlwinm r\[0-9\]+,r\[0-9\]+,0,0,30 } } */
+/* { dg-final { scan-assembler rlwinm r\[0-9\]+,r\[0-9\]+,0,29,30 } } */
/* { dg-final { scan-assembler-not rldicr } } */
/* Origin:Pete Steinmetz [EMAIL PROTECTED] */
...with this change this test properly passes at -m64 on Darwin...
Executing on host:
/sw/src/fink.build/gcc4-4.1.999-20060902/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060902/darwin_objdir/gcc/
/sw/src/fink.build/
gcc4-4.1.999-20060902/gcc-4.2-20060902/gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
-O2 -fno-show-column -S -m64 -o ppc-and-1.s(timeout = 300)
PASS: gcc.target/powerpc/ppc-and-1.c (test for excess errors)
PASS: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm
r[0-9]+,r[0-9]+,0,0,30
PASS: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm
r[0-9]+,r[0-9]+,0,29,30
PASS: gcc.target/powerpc/ppc-and-1.c scan-assembler-not rldicr
--
Summary: regex wrong for gcc/testsuite/gcc.target/powerpc/ppc-
and-1.c
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug tree-optimization/28948] -fprofile-generate/use and C++ anonymous namespaces don't mix
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-04 16:16 --- This is a dup of bug 26399 which was fixed for 4.2.0. *** This bug has been marked as a duplicate of 26399 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28948
[Bug gcov-profile/26399] -fprofile-use fails with unnamed namespaces
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-04 16:16 --- *** Bug 28948 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 16:21 --- What does config.log show? This works for me for a cross to powerpc64-linux, though I am using a sysroot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug rtl-optimization/20728] Wrong evaluation order of expressions in combine_reloads() in reload.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 16:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20728
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #4 from bunk at stusta dot de 2006-09-04 16:27 --- Created an attachment (id=12187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12187action=view) arm-linux/libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug c++/28942] [4.2 Regression] Dependent deconstrcutors
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 16:42 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28942
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #5 from bunk at stusta dot de 2006-09-04 16:46 --- I can reproduce it trying to build a cross compiler for a powerpc64-linux- target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-04 16:50 --- Confirmed, a regression from 2.95.3 which almost means the new ia32 back-end caused this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-linux-gnu | GCC host triplet|i486-linux-gnu | Known to fail||4.0.0 4.1.0 4.2.0 3.0.4 ||3.2.3 3.3.3 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2006-09-04 16:50:06 date|| Summary|assembler shifts set the|[4.0/4.1/4.2 Regression] |flag ZF, no need to re-test |assembler shifts set the |to zero |flag ZF, no need to re-test ||to zero Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-04 17:07 --- Once my current builds are finished, I will look into fixing this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #30 from hjl at lucon dot org 2006-09-04 17:39 --- Gcc 4.2.0 revision 116560 plus the patch in comment #29 fixes this regression and passes SPEC CPU 2006. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #31 from paulthomas2 at wanadoo dot fr 2006-09-04 17:48 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: --- Comment #30 from hjl at lucon dot org 2006-09-04 17:39 --- Gcc 4.2.0 revision 116560 plus the patch in comment #29 fixes this regression and passes SPEC CPU 2006. Thanks. HJ, You are in danger - in this neck of the woods, men kiss each other; by way of greetings and to show gratitude... hah! Thanks I will commit first thing tomorrow. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #2 from hjl at lucon dot org 2006-09-04 17:49 --- It is entirely coincident. For some processors, it is an optimization to avoid partial flag register stall. When it is fixed, it should be reenabled with a new flag, something like TARGET_PARTIAL_FLAG_REG_STALL. -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-09-04 17:56 --- This specific case can probably be solved at the tree level by changing the test: (nb 5) != 0 to nb 32 -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added CC||dann at godzilla dot ics dot ||uci dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug c++/28951] New: [4.1.1 regression]runtime segfault with array assignment on i386-redhat-linux
When compiling with g++ 4.1.1 (shipping build on Fedora 5 i386), the following
line cause runtime segmentation fault.
voidAddElement (const T val) { _array[Newidx()] = val; }
A complete test case is attached below.
The error also occurs on gcc 4.2.0 (built from snapshot, gcc version 4.2.0,
Revision: 116178)
Not occured on gcc 3.3.5 .
--
Summary: [4.1.1 regression]runtime segfault with array assignment
on i386-redhat-linux
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sourceinsight001 at gmail dot com
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
[Bug c++/28951] [4.1.1 regression]runtime segfault with array assignment on i386-redhat-linux
--- Comment #1 from sourceinsight001 at gmail dot com 2006-09-04 18:46 --- Created an attachment (id=12188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12188action=view) [4.1.1 regression] runtime segfault with AddElement(): assignment of array element A complete test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
[Bug c++/28951] [4.1.1 regression]runtime segfault with array assignment on i386-redhat-linux
--- Comment #2 from sourceinsight001 at gmail dot com 2006-09-04 18:49 --- No special compilation option is used. It looks like this: g++ -c test_addelem.cxx -o test_addelem.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
[Bug tree-optimization/28952] New: [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
tree check error with -ftree-vectorize: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122 (sid)142:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -c -ftree-vectorize -O1 freeciv-spacerace.c freeciv-spacerace.c: In function 'send_spaceship_info': freeciv-spacerace.c:21: internal compiler error: tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)143:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -c -O3 freeciv-spacerace.c (sid)144:[EMAIL PROTECTED]: ~] -- Summary: [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #1 from tbm at cyrius dot com 2006-09-04 18:56 --- Created an attachment (id=12189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12189action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2006-09-04 18:58 --- Paul, FYI, between the changes in the proposed patch here and others in gcc trunk to gfortran.h, resolve.c and trans-types.c, the proposed patch for PR 20541 needs to be readjusted again. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #2 from tbm at cyrius dot com 2006-09-04 19:00 ---
Reduced some more:
struct player_spaceship
{
_Bool structure[32];
};
struct player
{
struct player_spaceship spaceship;
};
struct packet_spaceship_info
{
char structure[32 + 1];
};
send_spaceship_info (void)
{
int j;
struct player *pplayer;
struct packet_spaceship_info info;
struct player_spaceship *ship = pplayer-spaceship;
for (j = 0; j 32; j++)
{
info.structure[j] = ship-structure[j] ? '1' : '0';
}
lsend_packet_spaceship_info (info);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug c++/28951] [4.1.1 regression]runtime segfault with array assignment on i386-redhat-linux
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 19:09 ---
voidAddElement (const T val) { _array[Newidx()] = val; }
I think this code contains unspecified behavior.
There are no sequence points between the this-_array and the function call
Newidx() so we load this-_array before the function call which is valid
according to the C++ standard.
Can you try changing AddElement to:
voidAddElement (const T val) { int newidx = Newidx(); _array[newidx] =
val; }
And try again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 19:15 --- Confirmed, we have: D.1539_10 = pplayer_4-spaceship.structure[j_11]; iftmp.1_2 = D.1539_10 ? 49 : 48; Which is valid. It is caued by: /* We do not handle two different vector types for the condition and the values. */ if (TREE_TYPE (TREE_OPERAND (cond_expr, 0)) != TREE_TYPE (vectype)) return false; Which was added by: 2006-05-06 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27151 * tree-vect-transform.c (vectorizable_condition): Punt on values that have a different type than the condition. I also bet this is a latent (or even ICE only when checking) bug on the 4.1 branch too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-09-04 19:15:48 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug c++/28951] [4.1.1 regression]runtime segfault with array assignment on i386-redhat-linux
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 19:20 --- Yep, that worked so this is not a bug but a bug in your code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28951
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #3 from gin at mo dot msk dot ru 2006-09-04 19:32 --- Subject: Re: -B$(build_tooldir)/bin/ Why do you think this wrong? -B. is suppied first so this is not a bug If during build all files are found through `-B./' (or other specification of part of build tree containing files that are already built), then `-B$(build_tooldir)/bin/' is not needed at all. Otherwise, build process uses some external software that must be installed before build. Where it is installed has nothing to do with gcc build configuration and installation tree conventions. We have to configure arbitrary directories / compiler options for this. With `Makefile.in' as it is currently one can not do that. It sets this external software option unconditionally to point to `$(exec_prefix)/$(target_noncanonical)/bin' directory - with variables from build configuration of gcc, not of that external software. It will break build if the external software to use is actually installed elsewhere, and software in `$(build_tooldir)/bin/' also exists, but behaves in a quite different way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Infinite loop at -O1 and above in RTL CSE
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-04 19:33 --- Subject: Bug 27616 Author: ebotcazou Date: Mon Sep 4 19:33:24 2006 New Revision: 116683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116683 Log: PR rtl-optimization/27616 * cse.c (table_size): New static variable. (new_basic_block): Initialize it to 0. (remove_from_table): Decrement it. (insert): Increment it. (fold_rtx_mem_1): New function, renamed from fold_rtx_mem. (fold_rtx_mem): Enforce a cap on the recursion depth. Call fold_rtx_mem_1 if under the cap. (fold_rtx) RTX_COMM_ARITH: In the associative case, delay a little the lookup of the equivalent expression and test for equality of the first operand of the equivalent expression before in turn looking up an equivalent constant for the second operand. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20060904-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-09-04 19:33 --- The proposed change in comment #8 appears to give several testsuite failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Infinite loop at -O1 and above in RTL CSE
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-04 19:35 --- Subject: Bug 27616 Author: ebotcazou Date: Mon Sep 4 19:35:09 2006 New Revision: 116684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116684 Log: PR rtl-optimization/27616 * cse.c (table_size): New static variable. (new_basic_block): Initialize it to 0. (remove_from_table): Decrement it. (insert): Increment it. (fold_rtx_mem_1): New function, renamed from fold_rtx_mem. (fold_rtx_mem): Enforce a cap on the recursion depth. Call fold_rtx_mem_1 if under the cap. (fold_rtx) RTX_COMM_ARITH: In the associative case, delay a little the lookup of the equivalent expression and test for equality of the first operand of the equivalent expression before in turn looking up an equivalent constant for the second operand. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20060904-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cse.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Infinite loop at -O1 and above in RTL CSE
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-09-04 19:38 --- Fixed everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug ada/28953] New: Documentation for gprmake is missing
Hello, the documentation for the program gprmake is missing. -- Summary: Documentation for gprmake is missing Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: berndtrog at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28953
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #4 from gin at mo dot msk dot ru 2006-09-04 20:02 --- A question was sent to original reporter: Why do you think this wrong? If it was needed at all, the actions on the bug could have depended on the answer, and whether it should be closed could be decided only after receiving the answer. Instead, it was closed *along* with sending question. The answer alone, now that it is posted, whatever it is, is sufficient new information on bug. -- gin at mo dot msk dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #33 from paulthomas2 at wanadoo dot fr 2006-09-04 20:33 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator Jack, I know *sigh* First I have to fix that which was working that I broke. Then I will fix that which was neither broken nor fixed that might need breaking or fixing. I am so fed up of the whole business; it has taken two weeks from me. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-09-04 23:11 --- Well I confirmed this is not on cygwin. Now I have to build a mingw version. Sorry this is taking so long. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #9 from patchapp at dberlin dot org 2006-09-05 01:07 --- Subject: Bug number PR tree-opt/28937 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00121.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug rtl-optimization/26069] [4.0/4.1/4.2 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #16 from patchapp at dberlin dot org 2006-09-05 01:09 --- Subject: Bug number PR 26069 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00117.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-05 02:22 --- I have a fix, just move the conditional below the next one which checks for comparisions expressions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-04 19:15:48 |2006-09-05 02:22:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-05 04:19 --- I have a fix for this, it needed a couple of different fixes. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #34 from pault at gcc dot gnu dot org 2006-09-05 04:26 --- Subject: Bug 28908 Author: pault Date: Tue Sep 5 04:26:10 2006 New Revision: 116690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116690 Log: 2006-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. Modify the restored code so that a check is made to see if the symbol is already in the list. (resolve_fntype): Make sure that the specification block version of the derived type is used for a module function that returns that type. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. Modify the restored code such that all derived types are built if their symbols are found in the parent namespace; not just non-module types. Add backend_decls to like derived types in sibling namespaces, as well as that of the derived type. 2006-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test. * gfortran.dg/used_types_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_7.f90 trunk/gcc/testsuite/gfortran.dg/used_types_8.f90 trunk/gcc/testsuite/gfortran.dg/used_types_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #35 from pault at gcc dot gnu dot org 2006-09-05 04:30 --- Subject: Bug 28908 Author: pault Date: Tue Sep 5 04:29:56 2006 New Revision: 116691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116691 Log: 2006-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. Modify the restored code so that a check is made to see if the symbol is already in the list. (resolve_fntype): Make sure that the specification block version of the derived type is used for a module function that returns that type. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. Modify the restored code such that all derived types are built if their symbols are found in the parent namespace; not just non-module types. Add backend_decls to like derived types in sibling namespaces, as well as that of the derived type. 2006-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test. * gfortran.dg/used_types_9.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_8.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_9.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #36 from pault at gcc dot gnu dot org 2006-09-05 04:32 --- Closed, at last! Thanks everybody. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-05 04:52 --- Actually it looks like an oversight of what relayout_decl does. The reason is that relayout_decl was added by the patch to fix PR c++/16115 and I think Jason forgot about user specified alignment because he was only dealing with PARM_DECLs at the time. Anyways I am going to test the obvious fix unless you (Ulrich) want to do it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
