missing spec?
I built SVN gcc and installed it in the default place: [EMAIL PROTECTED]:~$ gcc -fopenmp combined_mp.c -o comb gcc: libgomp.spec: No such file or directory [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.3.0 20071014 (experimental) Am i doing something wrong or is this a bug in the install script? -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net
Re: gomp slowness
skaller wrote: OK, attached. Hi skaller, I think I've wasted my money. They do not ship OpenMP headers and libs with Standard Edition. :( Best Regards, Biplab
Re: gomp slowness
Hi All, I did some tests with GCC-4.2.2 (MinGW build) and the source code provided by skaller. The compilation log is as follows. -- Build: Release in Test --- [ 50.0%] mingw32-gcc.exe -Wall -fexceptions -fopenmp -O2 -IC:\MinGW\include -c C:\Projects\Test\combined_mp.c -o obj\Release\combined_mp.o C:\Projects\Test\combined_mp.c: In function 'main': C:\Projects\Test\combined_mp.c:77: warning: 'sum' is used uninitialized in this function [100.0%] mingw32-g++.exe -LC:\MinGW\lib -o bin\Release\Test.exe obj\Release\combined_mp.o -s -lgomp -lpthread Output size is 16.50 KB Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings Here is the result of two sample runs. C:\Projects\Test\bin\Releaseset OMP_NUM_THREADS=1 C:\Projects\Test\bin\Releasetest e started at 0 e done at 2859 pi started at 2859 pi done at 12390 integration started at 12390 integration done at 26234 Values: e*pi = 8.539734, integral = 9.67 Total elapsed time: 26.234 seconds C:\Projects\Test\bin\Releaseset OMP_NUM_THREADS=2 C:\Projects\Test\bin\Releasetest e started at 0 pi started at 0 e done at 828 integration started at 828 integration done at 8015 pi done at 8703 integration started at 8703 Values: e*pi = 9.267763, integral = 9.67 Total elapsed time: 15.609 seconds C:\Projects\Test\bin\Release This indicates that GOMP is working well. :) My system specs: Windows XP SP2, 1GB RAM, [EMAIL PROTECTED] GHz (Core Duo) Compiler: GCC-4.2.2 (MinGW build) Best Regards, Biplab http://biplab.in
indirect memory op in SSA
Hi! i am trying to implement the SSA form, inspirated in GCC way. I have found problems in processing indirect memory operations like arrays, structures and pointers. My questions are: are nodes STRUCT_FIELD_TAG, NAME_MEMORY_TAG, SYMBOL_MEMORY_TAG used for that purpose? and, where i can find documentation about their use within the translation process to SSA? Thanks.
Re: gomp slowness
On Thu, Oct 18, 2007 at 02:47:44PM +1000, skaller wrote:
On Thu, 2007-10-18 at 12:02 +0800, Biplab Kumar Modak wrote:
skaller wrote:
On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote:
skaller wrote:
It would be interesting to try with another compiler. Do you have access
to another OpenMP-enabled compiler?
Unfortunately no, unless MSVC++ in VS2005 has openMP.
I have an Intel licence but they're too tied up with commerical
vendors and it doesn't work on Ubuntu (it's built for Fedora and Suse).
If possible, you can post the source code. I've a MSVC 2005 license (I
bought it to get OpenMP working with it).
I can then give it a try. I have a dual core PC. :)
OK, attached.
On LU_mp.c according to oprofile more than 95% of time is spent in the inner
loop, rather than any kind of waiting. On quad core with OMP_NUM_THREADS=4
all 4 threads eat 99.9% of CPU and the inner loop is identical between
OMP_NUM_THREADS=1 and OMP_NUM_THREADS=4. I believe this benchmark is highly
memory bound rather than CPU intensive, so the relative difference between
OMP_NUM_THREADS={1,2,4} is very likely not in what GCC or other OpenMP
implementation does, but in what kind of cache patterns it generates.
OMP_NUM_THREADS=1 /tmp/LU_mp; OMP_NUM_THREADS=2 GOMP_CPU_AFFINITY=0,1
/tmp/LU_mp; \
OMP_NUM_THREADS=2 GOMP_CPU_AFFINITY=0,2 /tmp/LU_mp; OMP_NUM_THREADS=4 /tmp/LU_mp
Completed decomposition in 4.830 seconds
Completed decomposition in 5.970 seconds
Completed decomposition in 9.140 seconds
Completed decomposition in 11.480 seconds
shows this quite clearly. This Intel quad core CPU shares 4MB L2 cache between
core 0 and 1 and between core 2 and 3. So, if you run the two threads on
cores sharing the same L2 cache, it is only slightly slower than one thread,
while running it on cores with different L2 caches shows a huge slowdown.
So, I very much doubt you'd get much better results with other OpenMP
implementations. I believe how the 3 arrays are layed out on the stack
is what really matters most for this case, the synchronization overhead is
in the noise.
Jakub
Re: gomp slowness
skaller wrote: On Thu, 2007-10-18 at 12:02 +0800, Biplab Kumar Modak wrote: skaller wrote: On Wed, 2007-10-17 at 18:14 +0100, Biagio Lucini wrote: skaller wrote: It would be interesting to try with another compiler. Do you have access to another OpenMP-enabled compiler? Unfortunately no, unless MSVC++ in VS2005 has openMP. I have an Intel licence but they're too tied up with commerical vendors and it doesn't work on Ubuntu (it's built for Fedora and Suse). If possible, you can post the source code. I've a MSVC 2005 license (I bought it to get OpenMP working with it). I can then give it a try. I have a dual core PC. :) OK, attached. I don't know of any OpenMP compiler which would correct the nesting of parallel loops in your LU. I have assumed that OpenMP doesn't allow such optimization; you have to get it right yourself.
Re: gomp slowness
On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote: skaller wrote: I don't know of any OpenMP compiler which would correct the nesting of parallel loops in your LU. I have assumed that OpenMP doesn't allow such optimization; you have to get it right yourself. Can you explain? This code was taken from a *tutorial* on OpenMP: http://kallipolis.com/openmp/2.html -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net
Re: gomp slowness
On Thu, 2007-10-18 at 13:04 +0200, Jakub Jelinek wrote:
On Thu, Oct 18, 2007 at 02:47:44PM +1000, skaller wrote:
On LU_mp.c according to oprofile more than 95% of time is spent in the inner
loop, rather than any kind of waiting. On quad core with OMP_NUM_THREADS=4
all 4 threads eat 99.9% of CPU and the inner loop is identical between
OMP_NUM_THREADS=1 and OMP_NUM_THREADS=4. I believe this benchmark is highly
memory bound rather than CPU intensive, so the relative difference between
OMP_NUM_THREADS={1,2,4} is very likely not in what GCC or other OpenMP
implementation does, but in what kind of cache patterns it generates.
This does seem quite plausible. However LU is a typical
numerical routine. This seems to limit the utility of
shared memory parallelism quite significantly: seems like
you're better off copying the matrix to another computer,
just to get two memory buses, since that's the bottleneck.
Has anyone got any comparative data on the libstdc++ parallel
model STL code?
--
John Skaller skaller at users dot sf dot net
Felix, successor to C++: http://felix.sf.net
Re: Problem with too many virtual operands ( tree-ssa-operands.c:484)
Pranav Bhandarkar wrote:
Hi,
In the attached testcase due to an ivopts modification, while
rewriting the uses the compiler crashes in tree-ssa-operands.c because
the number of virtual operands of the modified stmt is much greater
than the thresholds controlled by OP_SIZE_{1,2,3} in
tree-ssa-operands.c.
I went through
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01269.html
and it seemed to me that these values (OP_SIZE etc) have been quite
experimentally set. I am wondering If these values should be
increased.
They are 'experimental', but the reason is to catch cases like this to
examine. MEM-SSA was suppose to eliminate excessively large numbers of
virtual operands. I haven't had a chance to look at this yet, perhaps
Diego will get a chance before I do since I'm traveling and tied up the
rest of this week.
If it turns out there isn't something mem-ssa should be doing
differently for this case to reduce the number of operands, we can
either increase the thresholds, or add a 4th one for these excessive
cases. Im hoping there is a different solution since large numbers of
virtuals cause lots of compile time issues. I believe the previous times
we've triggered this (Its been a while), we made changes to the virtual
operand processing to resolve it and save memory/compile time.
Andrew
Re: Static stack analysis
Daniel, Michael J wrote: Hi! I'm interested in static stack analysis tools. Either using someone else's or creating. Where would I find existing tools? Where would I find existing contracter software developers? michael AdaCore has a tool called gnatstack. Check with AdaCore for details.
Re: gomp slowness
skaller wrote: On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote: skaller wrote: I don't know of any OpenMP compiler which would correct the nesting of parallel loops in your LU. I have assumed that OpenMP doesn't allow such optimization; you have to get it right yourself. Can you explain? This code was taken from a *tutorial* on OpenMP: http://kallipolis.com/openmp/2.html Did they show your version somewhere as an example of what not to do? In the page you referenced, they appear to have the correct loop nesting.
RE: gomp slowness
On 19 October 2007 02:45, tim prince wrote:
skaller wrote:
On Thu, 2007-10-18 at 06:00 -0700, Tim Prince wrote:
skaller wrote:
I don't know of any OpenMP compiler which would correct the nesting of
parallel loops in your LU. I have assumed that OpenMP doesn't allow
such optimization; you have to get it right yourself.
Can you explain? This code was taken from a *tutorial* on OpenMP:
http://kallipolis.com/openmp/2.html
Did they show your version somewhere as an example of what not to do?
In the page you referenced, they appear to have the correct loop nesting.
Huh?
http://kallipolis.com/openmp/2.html
Or, if you are really lazy, you can download LU_mp.c.
47: /* Here we update A by subtracting the appropriate values from row
48:and column. Note that these adjustments to A can be done in
49:any order */
50: #pragma omp parallel for shared(A, row, col)
51: for (i = k+1; iSIZE; i++) {
52: for (j = k+1; jSIZE; j++) {
53: A[i][j] = A[i][j] - row[i] * col[j];
54: }
55: }
Now instead of a parallel
http://gcc.gnu.org/ml/gcc/2007-10/msg00230.html
/* Here we update A by subtracting the appropriate values from row
and column. Note that these adjustments to A can be done in
any order */
#pragma omp parallel for shared(A, row, col)
for (i = k+1; iSIZE; i++) {
for (j = k+1; jSIZE; j++) {
A[i][j] = A[i][j] - row[i] * col[j];
}
}
}
cheers,
DaveK
--
Can't think of a witty .sigline today
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #2 from falk at debian dot org 2007-10-18 06:27 ---
Whoops.
void f(unsigned char *s, unsigned char *d, int n) {
int i;
for (i = 0; i n; i += 4) {
d[i + 0] += s[i + 0];
d[i + 1] += s[i + 1];
d[i + 2] += s[i + 2];
d[i + 3] += s[i + 3];
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug c++/33807] New: Incorrect ambiguous overload
The following code fails to compile with an overload ambiguity in gcc 4.2.1. It
successfully compiles in 3.4.4, 4.0.3 and 4.1.1. In the error message, note
also the bogus display of the signature for the first candidate:
note: candidates are: bool std::operator!=(const std::allocator_CharT, const
std::allocator_T2) [with _T1 = std::_List_nodefoo, _T2 =
std::_List_nodefoo]
bug.cc
--
#include list
template class T
bool operator != (const T x, const T y) { return !(x == y); }
struct foo {};
void fnx() {
std::listfoo l1, l2;
l1 = l2;
}
EOF
% g++ -c bug.cc
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/stl_list.h:
In member function 'void std::list_Tp,
_Alloc::_M_check_equal_allocators(std::list_Tp, _Alloc) [with _Tp = foo,
_Alloc = std::allocatorfoo]':
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/stl_list.h:930:
instantiated from 'void std::list_Tp,
_Alloc::splice(std::_List_iterator_Tp, std::list_Tp, _Alloc) [with _Tp =
foo, _Alloc = std::allocatorfoo]'
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/stl_list.h:833:
instantiated from 'void std::list_Tp,
_Alloc::insert(std::_List_iterator_Tp, _InputIterator, _InputIterator) [with
_InputIterator = std::_List_const_iteratorfoo, _Tp = foo, _Alloc =
std::allocatorfoo]'
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/list.tcc:135:
instantiated from 'std::list_Tp, _Alloc std::list_Tp,
_Alloc::operator=(const std::list_Tp, _Alloc) [with _Tp = foo, _Alloc =
std::allocatorfoo]'
bug.cc:9: instantiated from here
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/stl_list.h:1179:
error: ambiguous overload for 'operator!=' in '((std::listfoo,
std::allocatorfoo *)this)-std::listfoo, std::allocatorfoo
::anonymous.std::_List_base_Tp, _Alloc::_M_get_Node_allocator [with _Tp =
foo, _Alloc = std::allocatorfoo]() != ((std::listfoo, std::allocatorfoo
*)__x)-std::listfoo, std::allocatorfoo ::anonymous.std::_List_base_Tp,
_Alloc::_M_get_Node_allocator [with _Tp = foo, _Alloc =
std::allocatorfoo]()'
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/bits/allocator.h:120:
note: candidates are: bool std::operator!=(const std::allocator_CharT, const
std::allocator_T2) [with _T1 = std::_List_nodefoo, _T2 =
std::_List_nodefoo]
/usr/local/lib/gcc/ia64-hp-hpux11.31/4.2.1/../../../../include/c++/4.2.1/ext/new_allocator.h:120:
note: bool __gnu_cxx::operator!=(const
__gnu_cxx::new_allocator_Tp, const __gnu_cxx::new_allocator_Tp) [with _Tp
= std::_List_nodefoo]
bug.cc:3: note: bool operator!=(const T, const T) [with T =
std::allocatorstd::_List_nodefoo ]
Compilation exited abnormally with code 1 at Wed Oct 17 22:53:00
%
--
Summary: Incorrect ambiguous overload
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bldantes at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #9 from ubizjak at gmail dot com 2007-10-18 06:33 --- (In reply to comment #8) Icc generates: 0: 66 0f 6e cf movd %edi,%xmm1 4: 66 0f f2 c1 pslld %xmm1,%xmm0 Right, that's what icc's documentation would suggest. But that documentation seems inconsistent with the assembly reference guide. It may be that the assembly reference guide is the one that's wrong, or that icc intentionally extends it. I think we should follow icc example, because there is realy no problem to support immediates and non-immediates for these insns. Supporting only immediates looks like forced limitation to me, even if it is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug c++/33808] New: internal compiler error: in write_type, at cp/mangle.c:1651
Hello,
I'm working on Dev-cpp this is the output :
Compiler: Default compiler
Building Makefile: C:\cygwin\tmp\Makefile.win
Executing make...
make.exe -f C:\cygwin\tmp\Makefile.win all
g++.exe -c toto.cc -o toto.o -IC:/GTK/INCLUDE -IC:/GTK/INCLUDE/GTK-2.0
-IC:/GTK/INCLUDE/GLIB-2.0 -IC:/GTK/INCLUDE/PANGO-1.0
-IC:/GTK/INCLUDE/ATK-1.0 -IC:/GTK/INCLUDE/GTKGLEXT-1.0
-IC:/GTK/LIB/GTK-2.0/INCLUDE -IC:/GTK/LIB/GLIB-2.0/INCLUDE
-IC:/GTK/LIB/GTKGLEXT-1.0/INCLUDE -IC:/GTK/INCLUDE/LIBGLADE-2.0
-IC:/GTK/INCLUDE/LIBXML2 -v -save-temps
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.1.2/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=C:/MinGW --enable-threads
--disable-nls --enable-languages=c,c++ --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --disable-libstdcxx-pch
Thread model: win32
gcc version 4.1.2
c:/dev-cpp/bin/../libexec/gcc/mingw32/4.1.2/cc1plus.exe -E -quiet -v
-IC:/GTK/INCLUDE -IC:/GTK/INCLUDE/GTK-2.0 -IC:/GTK/INCLUDE/GLIB-2.0
-IC:/GTK/INCLUDE/PANGO-1.0 -IC:/GTK/INCLUDE/ATK-1.0
-IC:/GTK/INCLUDE/GTKGLEXT-1.0 -IC:/GTK/LIB/GTK-2.0/INCLUDE
-IC:/GTK/LIB/GLIB-2.0/INCLUDE -IC:/GTK/LIB/GTKGLEXT-1.0/INCLUDE
-IC:/GTK/INCLUDE/LIBGLADE-2.0 -IC:/GTK/INCLUDE/LIBXML2 -iprefix
c:\dev-cpp\bin\../lib/gcc/mingw32/4.1.2/ toto.cc -fpch-preprocess -o toto.ii
ignoring nonexistent directory
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2
ignoring nonexistent directory
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2/mingw32
ignoring nonexistent directory
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2/backward
ignoring nonexistent directory
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../mingw32/include
ignoring nonexistent directory
C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2
ignoring nonexistent directory
C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2/mingw32
ignoring nonexistent directory
C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2/backward
ignoring nonexistent directory C:/MinGW/lib/gcc/mingw32/4.1.2/include
ignoring nonexistent directory
C:/MinGW/lib/gcc/mingw32/../../../mingw32/include
#include ... search starts here:
#include ... search starts here:
C:/GTK/INCLUDE
C:/GTK/INCLUDE/GTK-2.0
C:/GTK/INCLUDE/GLIB-2.0
C:/GTK/INCLUDE/PANGO-1.0
C:/GTK/INCLUDE/ATK-1.0
C:/GTK/INCLUDE/GTKGLEXT-1.0
C:/GTK/LIB/GTK-2.0/INCLUDE
C:/GTK/LIB/GLIB-2.0/INCLUDE
C:/GTK/LIB/GTKGLEXT-1.0/INCLUDE
C:/GTK/INCLUDE/LIBGLADE-2.0
C:/GTK/INCLUDE/LIBXML2
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include
c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/include
C:/MinGW/lib/gcc/mingw32/../../../include
C:/MinGW/include
/mingw/include
End of search list.
c:/dev-cpp/bin/../libexec/gcc/mingw32/4.1.2/cc1plus.exe -fpreprocessed toto.ii
-quiet -dumpbase toto.cc -auxbase-strip toto.o -version -o toto.s
GNU C++ version 4.1.2 (mingw32)
compiled by GNU C version 4.1.2.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130982
Compiler executable checksum: 669e873dd1c794b0f5ddbea8fe211782
toto.cc:54: internal compiler error: in write_type, at cp/mangle.c:1651
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make.exe: *** [toto.o] Error 1
Execution terminated
the same error occurs on cygwin (v 3.4.4) and on latest ubuntu (v 4.2?)
this is the code:
#include complex
using namespace std;
template class T
class X
{
public:
X() {}
};
template class T
class Y
{
public:
template class U
Y(const XU) {}
template class U
Y operator *=(const U) { return *this; }
};
template class Tx, class Ty
Ytypeof(Tx()*Ty()) operator *(XTx x, const Ty y)
{
Ytypeof(Tx()*Ty()) res(x);
//res *= y;
return res;
}
template class Tx, class Ty
Ytypeof(Tx()*Ty()) operator *(const Tx x, XTy y)
{
Ytypeof(Tx()*Ty()) res(y);
//res *= x;
return res;
}
int main()
{
double a;
complexdouble b;
Xdouble i;
Xcomplexdouble j;
i*a;
a*i;
i*b;
b*i;
j*a;
a*j;
j*b;
b*j;
}
It's my first bug report, How can I give you the .ii file?
--
Summary: internal compiler error: in write_type, at
cp/mangle.c:1651
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brakiozor at caramail dot com
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-10-18 07:38 --- (In reply to comment #24) So maybe approach the question differently. Which element in an array of NaNs is the smallest one and what is its value? If I pick any one element, its value is NaN. It does not matter which one I select, its value always comes out NaN. I understand your argument, but there are other arguments that are, I think, at least equally valid and convincing. As I said, MINVAL basically ignores NaNs, so an array containing only NaNs is equivalent to an empty array: its MINVAL is +Huge. Note that having MINVAL = +Huge is, in itself, a telltale sign that something is wrong, if there is no mask present. Now, I have another question: what happens for mixed NaNs? For example, in your scheme, what would be the value of MAXVAL((/sNaN, qNaN/))? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651
--- Comment #2 from brakiozor at caramail dot com 2007-10-18 07:56 --- Created an attachment (id=14369) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14369action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651
--- Comment #3 from brakiozor at caramail dot com 2007-10-18 08:06 --- I found this bug on a more complex program and I did an epurated code. -- brakiozor at caramail dot com changed: What|Removed |Added CC||brakiozor at caramail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651
--- Comment #1 from brakiozor at caramail dot com 2007-10-18 07:55 --- Created an attachment (id=14368) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14368action=view) source code I was playing a little with template -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #3 from irar at il dot ibm dot com 2007-10-18 08:33 --- It works fine for me (and the loop gets SLPed) on powerpc-64 and x86_64. Could you please run it with -fdump-tree-vect-details and attach the dump file? Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-18 08:49 --- As far as I understand there is no way to encode currently typeof for templates. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #10 from uros at gcc dot gnu dot org 2007-10-18 09:12 --- Subject: Bug 32961 Author: uros Date: Thu Oct 18 09:12:30 2007 New Revision: 129433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129433 Log: PR target/32961 * config/i386/i386.c (ix86_expand_builtin) [IX86_BUILTIN_PSLLWI128, IX86_BUILTIN_PSLLDI128, BUILTIN_PSLLQI128, IX86_BUILTIN_PSRAWI128, IX86_BUILTIN_PSRADI128, IX86_BUILTIN_PSRLWI128, IX86_BUILTIN_PSRLDI128, IX86_BUILTIN_PSRLQI128]: Do not require immediate shift value. * config/i386/emmintrin.h (_mm_slli_epi16, _mm_slli_epi32, _mm_slli_epi64, _mm_srai_epi16, _mm_srai_epi32, _mm_srli_epi16, _mm_srli_epi32, _mm_srli_epi64): Enable disabled functions and remove equivalent macro definitions. testsuite/ChangeLog: PR target/32961 * gcc.target/i386/pr32961.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr32961.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/emmintrin.h branches/gcc-4_2-branch/gcc/config/i386/i386.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #11 from ubizjak at gmail dot com 2007-10-18 09:14 --- Fixed for 4.2.3 and 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug libstdc++/33807] Incorrect ambiguous overload
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-18 09:35:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug c++/5645] gcc warns that pure virtual class not explicitly initialized
--- Comment #5 from nathan at codesourcery dot com 2007-10-18 09:43 --- Subject: Re: gcc warns that pure virtual class not explicitly initialized manu at gcc dot gnu dot org wrote: --- Comment #4 from manu at gcc dot gnu dot org 2007-10-17 11:26 --- Does this patch makes any sense? This needs testcases (suggestions for extra testcases are welcome), Changelog, bootstrap + testing and proper submission. this patch looks reasonable. nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5645
[Bug libstdc++/33807] Incorrect ambiguous overload
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #1 from pcarlini at suse dot de 2007-10-18 09:55 --- Note, the problem - trivial, the same we had in stl_iterator.h - is latent in the older branches, dates back to the configurable allocator.h. The fix is safe and will go in 4_2-branch too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #2 from paolo at gcc dot gnu dot org 2007-10-18 10:00 --- Subject: Bug 33807 Author: paolo Date: Thu Oct 18 10:00:18 2007 New Revision: 129434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129434 Log: 2007-10-18 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33807 * include/bits/allocator.h (operator==(const allocator_Tp, const allocator_Tp), operator!=(const allocator_Tp, const allocator_Tp)): Add. * testsuite/20_util/allocator/33807.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/allocator/33807.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/allocator.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug c/33809] New: Rounding off error in GCC 4.1.2
Based on our investigation and the gcc documentation , we think there is a Bug
in GCC 4.1.2
Firstly, according to the doc and our understanding, the error caused by
rounding should be small, for instance, some systems may treat 5.000 as 4.998.
However, in our case, the difference is quit big, about 40% by compare
-0.7240616609 to -0.5413411329464. I think it can't be ignored.
Secondly, -frounding-math and -fno-rounding-math are two gcc options to control
rounding. However, using -O0, for both two options, We got the same value,
-0.7240616609. But using -O3 (or -O1), We got the same value, -0.5413411329464.
This means changing rounding option doesn't affect the result.
Thirdly, in the case, function double ahdlDoFloatDiv(double a, double) is to
return the result of a/b. If I directly use a/b, instead of function, for -O3,
the result is -0.7240616609, the same as -O0. If the issue is caused by
rounding, both two ways should have the same result. But now it is different.
Finally, we simplified the c code as below and can reproduce the problem:
#include math.h
#include stdio.h
#include stdlib.h
double ahdlDoFloatDiv (double a, double b)
{
return a/b;
}
// #define ahdlDoFloatDiv(a, b) (a/b)
int main()
{
double pow_tmp = 0;
printf(%f\n,
ahdlDoFloatDiv((2.7182818284590451)) +
(((ahdlDoFloatDiv-(((2.7182818284590451)) *
((1.e+00))) * 1.e+00))),
pow_tmp = (2.7182818284590451)) * pow_tmp)) * (2.7182818284590451))
- (((ahdlDoFloatDiv(1.e+00, (2.7182818284590451)))
- 2.7182818284590451)) - (((ahdlDoFloatDiv-(((2.7182818284590451))
* ((1.e+00))) * 1.e+00))),
pow_tmp = (2.7182818284590451)) * pow_tmp)) * (2.7182818284590451))
+ (((ahdlDoFloatDiv(1.e+00,
(2.7182818284590451, pow_tmp = 2.7182818284590451)) -
(((ahdlDoFloatDiv(1.e+00, (2.7182818284590451 *
pow_tmp
);
return 0;
}
Please use gcc4.1.2 to compile it under Linux and you can reproduce the bug.
For -O3, the printed value is -0.541341, for -O0, it is -0.724062. If comment
the function ahdlDoFloatDiv and uncomment the macro definition, both -O0 and
-O3 have the same result, -0.724062.
This issue causes our problem to producing incorrect values, even lead to
convergence issue.
--
Summary: Rounding off error in GCC 4.1.2
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
[Bug c++/33810] New: gcc 4.1.2 mangles results on x86_64 in bitfield operations
Run the test case on a x86_64 bit machine to see how gcc 4.1.2 mangles results
in under Linux
We have tested the test case using 3.2.3 Compiler on RHEL 3 on both 32 as well
as 64 bit OS it works well.
Compile the test case provided with the following steps
$gcc -g -I. -Wall -m64 -c bar.c
$g++ -g -I. -Wall -m64 -o foo foo.c bar.o
Actual results: once you run the program foo you will see the following result
foo: i is 3.
bar: i is 3221205968.
Expected results:
foo: i is 3.
bar: i is 3.
Additional info: Test Case follows
- bar.h -
typedef struct {
unsigned b1:16;
unsigned b2:16;
} foo;
#ifdef __cplusplus
extern C
{
#endif
foo bar(unsigned);
#ifdef __cplusplus
}
#endif
- bar.c -
#include stdio.h
#include bar.h
foo bar(unsigned i)
{
foo myfoo;
myfoo.b1=myfoo.b2=0;
printf(bar: i is %u.\n,i);
return(myfoo);
}
- foo.c -
#include stdio.h
#include bar.h
int main(void)
{
foo myfoo;
unsigned i = 3;
printf(foo: i is %u.\n,i);
myfoo = bar(i);
return 0;
}
--
Summary: gcc 4.1.2 mangles results on x86_64 in bitfield
operations
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33810
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-18 11:45 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-10-07 15:17:20 |2007-10-18 11:45:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug fortran/33811] New: Character assignment misses dependency
This $ cat assign_bug_3.f90 character(1) :: a(3) = ['1','2','3'] integer :: i = 1 a(2:3)(i:i) = a(1:2)(i:i) print *, a end $ /irun/bin/gfortran assign_bug_3.f90; ./a 111 is the wrong result (should be 112) The problem lies in gfc_check_dependency, where the assumption about substrings is wrong. Fixing this exposes an ICE in trans-array.c(gfc_trans_create_temp_array), which arises because the temporary is an incomplete type. These problems are related to PR31217 and arose in the course of fixing that pr. A fix for both will be posted tonight, as long as the regtesting completes OK. Cheers Paul -- Summary: Character assignment misses dependency Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org BugsThisDependsOn: 31217 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33811
[Bug fortran/31217] ICE using FORALL on character substrings
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 15:32:12 |2007-10-18 12:03:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31217
[Bug c/33809] Rounding off error in GCC 4.1.2
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 12:18 --- What about -ffloat-store? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
[Bug fortran/33811] Character assignment misses dependency
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-10-18 12:23:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33811
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #11 from pault at gcc dot gnu dot org 2007-10-18 12:44 --- Subject: Bug 33733 Author: pault Date: Thu Oct 18 12:44:03 2007 New Revision: 129435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129435 Log: 2007-10-18 Paul Thomas [EMAIL PROTECTED] Dominique d'Humieres [EMAIL PROTECTED] PR fortran/33733 * simplify.c (gfc_simplify_transfer): Return null if the source expression is EXPR_FUNCTION. 2007-10-18 Paul Thomas [EMAIL PROTECTED] PR fortran/33733 * gfortran.dg/transfer_simplify_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_6.f90 Modified: trunk/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #12 from pault at gcc dot gnu dot org 2007-10-18 12:45 --- Subject: Bug 33733 Author: pault Date: Thu Oct 18 12:44:57 2007 New Revision: 129436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129436 Log: 2007-10-18 Paul Thomas [EMAIL PROTECTED] Dominique d'Humieres [EMAIL PROTECTED] PR fortran/33733 * simplify.c (gfc_simplify_transfer): Return null if the source expression is EXPR_FUNCTION. 2007-10-18 Paul Thomas [EMAIL PROTECTED] PR fortran/33733 * gfortran.dg/transfer_simplify_6.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-18 12:48 --- Subject: Bug 33233 Author: pault Date: Thu Oct 18 12:48:37 2007 New Revision: 129437 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129437 Log: 2007-10-18 Paul Thomas [EMAIL PROTECTED] PR fortran/33233 * resolve.c (check_host_association): Check singly contained namespaces and start search for symbol in current namespace. 2007-10-18 Paul Thomas [EMAIL PROTECTED] PR fortran/33233 * gfortran.dg/host_assoc_function_1.f90: Correct references. * gfortran.dg/host_assoc_function_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_function_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/host_assoc_function_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33233
[Bug middle-end/33806] [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 12:55 --- This regression affects also gfortran.fortran-torture/execute/stack_varsize.f90. A reduced test case is: ! Program to test the stack variable size limit. program stack call sub1 contains ! Local variables larger than 32768 in byte size shall be placed in static ! storage area, while others be put on stack by default. subroutine sub1 real b(32768/4), c(32768/4+1) b = 20.0 c = 30.0 if ((b(1) .ne. 20.0).or.(c(1) .ne. 30.0)) call abort end subroutine end [karma] f90/bug% gfc -m64 -O3 stack_varsize_red.f90 stack_varsize_red.f90: In function 'sub1': stack_varsize_red.f90:12: internal compiler error: in change_address_1, at emit-rtl.c:1888 Note that array c alone is not sufficient to trigger the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33806
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-10-18 13:22
---
(In reply to comment #13)
../../../libgfortran/runtime/environ.c:312: warning: 'init_choice' defined but
not used
../../../libgfortran/runtime/environ.c:339: warning: 'show_choice' defined but
not used
These two have been removed by Ben Elliston.
../../../libgfortran/runtime/backtrace.c:66: warning: 'local_strcasestr'
defined but not used
Fixed by the following:
Index: runtime/backtrace.c
===
--- runtime/backtrace.c (revision 129403)
+++ runtime/backtrace.c (working copy)
@@ -60,7 +60,18 @@ Boston, MA 02110-1301, USA. */
#include ctype.h
+/* Macros for common sets of capabilities: can we fork and exec, can
+ we use glibc-style backtrace functions, and can we use pipes. */
+#define CAN_FORK (defined(HAVE_FORK) defined(HAVE_EXECVP) \
+ defined(HAVE_WAIT))
+#define GLIBC_BACKTRACE (defined(HAVE_BACKTRACE) \
+ defined(HAVE_BACKTRACE_SYMBOLS))
+#define CAN_PIPE (CAN_FORK defined(HAVE_PIPE) \
+ defined(HAVE_DUP2) defined(HAVE_FDOPEN) \
+ defined(HAVE_CLOSE))
+
+#if GLIBC_BACKTRACE CAN_PIPE
static char *
local_strcasestr (const char *s1, const char *s2)
{
@@ -85,14 +96,7 @@ local_strcasestr (const char *s1, const
}
#endif
}
-
-#define CAN_FORK (defined(HAVE_FORK) defined(HAVE_EXECVP) \
- defined(HAVE_WAIT))
-#define GLIBC_BACKTRACE (defined(HAVE_BACKTRACE) \
- defined(HAVE_BACKTRACE_SYMBOLS))
-#define CAN_PIPE (CAN_FORK defined(HAVE_PIPE) \
- defined(HAVE_DUP2) defined(HAVE_FDOPEN) \
- defined(HAVE_CLOSE))
+#endif
#if GLIBC_BACKTRACE
../../../libgfortran/runtime/main.c:179: warning: passing argument 1 of 'free'
discards qualifiers from pointer target type
Fixed by:
Index: runtime/main.c
===
--- runtime/main.c (revision 129403)
+++ runtime/main.c (working copy)
@@ -176,5 +176,5 @@ cleanup (void)
close_units ();
if (please_free_exe_path_when_done)
-free (exe_path);
+free ((char *) exe_path);
}
../../../../libgfortran/intrinsics/signal.c:201: warning: cast to pointer from
integer of different size
../../../../libgfortran/intrinsics/signal.c:208: warning: cast to pointer from
integer of different size
../../../../libgfortran/intrinsics/signal.c:229: warning: cast to pointer from
integer of different size
../../../../libgfortran/intrinsics/signal.c:236: warning: cast to pointer from
integer of different size
This should be silenced by:
Index: intrinsics/signal.c
===
--- intrinsics/signal.c (revision 129403)
+++ intrinsics/signal.c (working copy)
@@ -198,14 +198,14 @@ alarm_sub_int_i4 (int *seconds, int *han
#if defined (SIGALRM) defined (HAVE_ALARM) defined (HAVE_SIGNAL)
if (status != NULL)
{
- if (signal (SIGALRM, (void (*)(int)) *handler) == SIG_ERR)
+ if (signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler) == SIG_ERR)
*status = -1;
else
*status = alarm (*seconds);
}
else
{
- signal (SIGALRM, (void (*)(int)) *handler);
+ signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler);
alarm (*seconds);
}
#else
@@ -226,14 +226,14 @@ alarm_sub_int_i8 (int *seconds, int *han
#if defined (SIGALRM) defined (HAVE_ALARM) defined (HAVE_SIGNAL)
if (status != NULL)
{
- if (signal (SIGALRM, (void (*)(int)) *handler) == SIG_ERR)
+ if (signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler) == SIG_ERR)
*status = -1;
else
*status = alarm (*seconds);
}
else
{
- signal (SIGALRM, (void (*)(int)) *handler);
+ signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler);
alarm (*seconds);
}
#else
../../../libgfortran/intrinsics/spread_generic.c:136: warning: format '%d'
expects type 'int', but argument 2 has type 'long int'
../../../libgfortran/intrinsics/spread_generic.c:147: warning: format '%d'
expects type 'int', but argument 2 has type 'long int'
Fixed by:
Index: intrinsics/spread_generic.c
===
--- intrinsics/spread_generic.c (revision 129403)
+++ intrinsics/spread_generic.c (working copy)
@@ -131,9 +131,9 @@ spread_internal (gfc_array_char *ret, co
if (ret_extent != ncopies)
runtime_error(Incorrect extent in return value of SPREAD
- intrinsic in dimension %d: is %ld,
- should be %ld, n+1, (long int) ret_extent,
- (long int) ncopies);
+ intrinsic in dimension %ld: is %ld,
+ should be %ld, (long int) n+1,
+
[Bug tree-optimization/33812] New: Vectorizer testcases fail
With current trunk (r129433) vectorizer testcases fail on powerpc64: FAIL: gcc.dg/vect/vect-64.c (internal compiler error) FAIL: gcc.dg/vect/vect-64.c (test for excess errors) WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-68.c (internal compiler error) FAIL: gcc.dg/vect/vect-68.c (test for excess errors) WARNING: gcc.dg/vect/vect-68.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-70.c (internal compiler error) FAIL: gcc.dg/vect/vect-70.c (test for excess errors) WARNING: gcc.dg/vect/vect-70.c compilation failed to produce executable FAIL: gcc.dg/vect/no-scevccp-slp-31.c (internal compiler error) FAIL: gcc.dg/vect/no-scevccp-slp-31.c (test for excess errors) WARNING: gcc.dg/vect/no-scevccp-slp-31.c compilation failed to produce executable The tests ICE: vect-64.c: In function #1490;main1#1490;: vect-64.c:75: internal compiler error: in change_address_1, at emit-rtl.c:1888 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. #0 change_address_1 (memref=0xf7e44f40, mode=SImode, addr=0xf7e44f30, validate=1) at ../../gcc/gcc/emit-rtl.c:1888 #1 0x10179fd4 in validize_mem (ref=0xf7e44f40) at ../../gcc/gcc/explow.c:546 #2 0x101a88e8 in emit_move_insn (x=0xf7e38e00, y=0xf7e44f40) at ../../gcc/gcc/expr.c:3403 #3 0x105543e4 in rs6000_emit_epilogue (sibcall=0) at ../../gcc/gcc/config/rs6000/rs6000.c:16095 #4 0x28000488 in ?? () #5 0x105ec5ec in gen_epilogue () at ../../gcc/gcc/config/rs6000/rs6000.md:14476 #6 0x102242b4 in rest_of_handle_thread_prologue_and_epilogue () at ../../gcc/gcc/function.c:5298 #7 0x102a7af4 in execute_one_pass (pass=0x108f6a78) at ../../gcc/gcc/passes.c:1117 #8 0x102a7d68 in execute_pass_list (pass=0x108f6a78) at ../../gcc/gcc/passes.c:1170 #9 0x102a7d80 in execute_pass_list (pass=0x108f6ee8) at ../../gcc/gcc/passes.c:1171 #10 0x102a7d80 in execute_pass_list (pass=0x108f6eb4) at ../../gcc/gcc/passes.c:1171 #11 0x103ae68c in tree_rest_of_compilation (fndecl=0xf7dbc100) at ../../gcc/gcc/tree-optimize.c:404 #12 0x105705fc in cgraph_expand_function (node=0xf7dbc300) at ../../gcc/gcc/cgraphunit.c:1060 #13 0x105728c4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1123 #14 0x10017914 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8077 #15 0x1033fff0 in toplev_main (argc=value optimized out, argv=value optimized out) at ../../gcc/gcc/toplev.c:1055 #16 0x1009e370 in main (argc=0, argv=0x0) at ../../gcc/gcc/main.c:35 This doesn't happen with r129290. Ira -- Summary: Vectorizer testcases fail Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: irar at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug fortran/29452] Keyword check for specifiers in WRITE and READ
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-18 13:39 --- I think it's best to close this one. I only wanted to keep it open because I thought I'd add the rest of the F2003 specifiers quickly, which didn't happen. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug tree-optimization/33812] Vectorizer testcases fail
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 13:40 --- This seems to be a duplicate of PR33806, at least the ICE occurs at the same point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #12 from hjl at lucon dot org 2007-10-18 13:44 --- (In reply to comment #8) (In reply to comment #7) Icc generates: 0: 66 0f 6e cf movd %edi,%xmm1 4: 66 0f f2 c1 pslld %xmm1,%xmm0 Right, that's what icc's documentation would suggest. But that documentation seems inconsistent with the assembly reference guide. It may be that the assembly reference guide is the one that's wrong, or that icc intentionally extends it. There is nothing wrong with IA32 SDM. One intrinsic does map to one assembly instruction, but not necessarily the same instruction every time. Another example is _mm_cmpistrm and its friends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures
--- Comment #6 from pault at gcc dot gnu dot org 2007-10-18 13:54 --- Fixed on trunk. 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=33233
[Bug c/33809] Rounding off error in GCC 4.1.2
--- Comment #2 from satyaakam at yahoo dot co dot in 2007-10-18 14:00 --- $gcc -ffloat-store round.c $ ./a.out -0.724062 $gcc -O3 -ffloat-store round.c $ ./a.out -0.541341 $gcc -O0 -ffloat-store round.c ./a.out -0.724062 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #13 from pault at gcc dot gnu dot org 2007-10-18 13:53 --- Fixed on trunk 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=33733
[Bug tree-optimization/33812] Vectorizer testcases fail
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-18 14:32 --- The same occurs in 32 bit mode, see for instance http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00804.html [karma] dominiq/Desktop% gfc -O2 -ftree-vectorize -maltivec /opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c /opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c: In function 'main1': /opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c:39: internal compiler error: in change_address_1, at emit-rtl.c:1888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug tree-optimization/33812] Vectorizer testcases fail
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-18 14:37 --- The PR started between revisions 129388 (works) and 129401 (does not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug c/33809] Rounding off error in GCC 4.1.2
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-18 14:46 --- Your code is undefined. You have multiple assignments to pow_tmp without intervening sequence points. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
[Bug fortran/33811] Character assignment misses dependency
--- Comment #1 from pault at gcc dot gnu dot org 2007-10-18 14:50 --- (In reply to comment #0) A fix for both will be posted tonight, as long as the regtesting completes OK. Cheers Paul This fix has been posted: http://gcc.gnu.org/ml/fortran/2007-10/msg00264.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33811
[Bug middle-end/33780] different results between O3 and O0
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 15:23 --- while we expand a constant integral power to an optimal (as of the count of multiplications / additions) series of multiplications and additions. It seems the difference is coming from something else. I'll bet that with -O3 the powers are computed at compile time with some extra precision. At least it is what I conclude from the following code: integer :: ia(16) = (/ 1, 1, 2, 2, 3, 3, 4, 4, 6, 5, 6, 6, 10, 7, 9, 8 /) real(8) :: a(16), b(16), c(16), d(16) real(16) :: e(16) real(8), parameter :: r=4.51556282882533D0 a(1) = r a(2) = a(1)*a(1) a(3:4) = a(2)*a(1:2) a(5:8) = a(4)*a(1:4) a(9:16) = a(8)*a(1:8) b(1) = r do i = 2, 16 b(i) = b(ia(i))*b(i-ia(i)) end do e(1) = r e(2) = e(1)*e(1) e(3:4) = e(2)*e(1:2) e(5:8) = e(4)*e(1:4) e(9:16) = e(8)*e(1:8) d = real(e,8) do i=1, 16 c(i) = r**i end do do i=1, 16 print *, a(i)/d(i)-1.0d0, b(i)/d(i)-1.0d0, c(i)/d(i)-1.0d0 end do print * print *, sum(abs(a/d-1.0d0)), sum(abs(b/d-1.0d0)), sum(abs(c/d-1.0d0)), epsilon(r) end a stores the powers computed from the usual shift, b those computed from the optimal tree (from gcc/builtins.c, c those computed from the power, and d the values rounded from values with higher precision. At -O2 the output is: 0.0.0. 0.0.0. 0.0.0. 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 0. 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 2.22044604925031308E-016 4.44089209850062616E-016 4.44089209850062616E-016 4.44089209850062616E-016 2.22044604925031308E-016 0. 2.22044604925031308E-016 4.44089209850062616E-016 2.22044604925031308E-016 4.44089209850062616E-016 4.44089209850062616E-016 2.22044604925031308E-016 4.44089209850062616E-016 4.44089209850062616E-016 0. 4.44089209850062616E-016 4.44089209850062616E-016 4.44089209850062616E-016 4.44089209850062616E-016 4.44089209850062616E-016 2.22044604925031308E-016 4.44089209850062616E-016 6.66133814775093924E-016 0. 6.66133814775093924E-016 6.66133814775093924E-016 6.66133814775093924E-016 6.66133814775093924E-016 5.10702591327572009E-015 2.88657986402540701E-015 5.10702591327572009E-015 2.22044604925031308E-016 a and c are equal, while at -O3 the output is 0.0.0. 0.0.0. 0.0.0. 2.22044604925031308E-016 2.22044604925031308E-016 0. 2.22044604925031308E-016 2.22044604925031308E-016 0. 2.22044604925031308E-016 0.0. 2.22044604925031308E-016 2.22044604925031308E-016 0. 4.44089209850062616E-016 4.44089209850062616E-016 0. 2.22044604925031308E-016 0.0. 4.44089209850062616E-016 2.22044604925031308E-016 0. 4.44089209850062616E-016 2.22044604925031308E-016 0. 4.44089209850062616E-016 0.0. 4.44089209850062616E-016 4.44089209850062616E-016 0. 4.44089209850062616E-016 2.22044604925031308E-016 0. 6.66133814775093924E-016 0.0. 6.66133814775093924E-016 6.66133814775093924E-016 0. 5.10702591327572009E-015 2.88657986402540701E-015 0. 2.22044604925031308E-016 c and d are equal. If the difference were coming only from the optimal tree, c should be equal to b. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33780
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-10-18 15:23 --- Subject: Bug 30085 Author: bkoz Date: Thu Oct 18 15:22:58 2007 New Revision: 129442 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129442 Log: 2007-10-18 Benjamin Kosnik [EMAIL PROTECTED] * include/ext/hash_map: To... * include/backward/hash_map: ...here. Remove debug mode. * include/ext/hash_set: To... * include/backward/hash_set: ...here. Remove debug mode. * include/ext/hash_fun.h: To... * include/backward/hash_fun.h: ...here. * include/ext/hashtable.h: To... * include/backward/hashtable.h: ...here. * include/bits/c++config: Remove __gnu_cxx namespace from debug mode. * include/debug/debug.h: Same. * include/debug/hash_map: Remove. * include/debug/hash_multimap.h: Remove. * include/debug/hash_set.h: Remove. * include/debug/hash_set: Remove. * include/debug/hash_multiset.h: Remove. * include/debug/hash_map.h: Remove. * include/Makefile.am (ext_headers): Move hash_set, hash_map to backward. (debug_headers): Remove hash_map, hash_set, hash_map.h, hash_map.h, hash_multiset.h, hash_multimap.h. * include/Makefile.in: Regenerate. * docs/html/debug.html: Update. * docs/html/ext/howto.html: Same. * docs/html/faq/index.html: Same. * docs/doxygen/Intro.3: Same. * docs/doxygen/user.cfg.in: Adjust includes. * testsuite/ext/hash_map: Move to... * testsuite/backward/hash_map: ...here. * testsuite/ext/hash_set: Move to... * testsuite/backward/hash_set: ...here. 2007-10-18 Benjamin Kosnik [EMAIL PROTECTED] Removal of pre-ISO C++ items from include/backwards. * include/Makefile.am (backward_headers): Remove all but strstream, backward_warning.h. * include/Makefile.in: Regenerate. * include/backward/new.h: Remove. * include/backward/iterator.h: Same. * include/backward/alloc.h: Same. * include/backward/set.h: Same. * include/backward/hashtable.h: Same. * include/backward/hash_set.h: Same. * include/backward/fstream.h: Same. * include/backward/tempbuf.h: Same. * include/backward/istream.h: Same. * include/backward/bvector.h: Same. * include/backward/stack.h: Same. * include/backward/rope.h: Same. * include/backward/complex.h: Same. * include/backward/ostream.h: Same. * include/backward/heap.h: Same. * include/backward/iostream.h: Same. * include/backward/function.h: Same. * include/backward/multimap.h: Same. * include/backward/pair.h: Same. * include/backward/stream.h: Same. * include/backward/iomanip.h: Same. * include/backward/slist.h: Same. * include/backward/tree.h: Same. * include/backward/vector.h: Same. * include/backward/deque.h: Same. * include/backward/multiset.h: Same. * include/backward/defalloc.h: Same. * include/backward/list.h: Same. * include/backward/map.h: Same. * include/backward/algobase.h: Same. * include/backward/hash_map.h: Same. * include/backward/algo.h: Same. * include/backward/queue.h: Same. * include/backward/streambuf.h: Same. * testsuite/backward/header_hash_set_h.cc: Same. * testsuite/backward/header_slist_h.cc: Same. * testsuite/backward/header_hash_map_h.cc: Same. * testsuite/backward/header_tempbuf_h.cc: Same. * testsuite/backward/header_deque_h.cc: Same. * testsuite/backward/header_rope_h.cc: Same. * testsuite/backward/header_iterator_h.cc: Same. * testsuite/backward/header_hashtable_h.cc: Same. 2007-10-18 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/30085 * include/debug/unordered_map: New. * include/debug/unordered_set: New. * include/debug/safe_association.h: New. * include/std/unordered_map: Include debug header if _GLIBCXX_DEBUG. * include/std/unordered_set: Same. * include/Makefile.am (debug_headers): Add unordered_map, unordered_set, safe_association.h. * include/Makefile.in: Regenerate. * testsuite/23_containers/unordered_map/requirements/debug.cc: New. * testsuite/23_containers/unordered_multimap/requirements/ debug.cc: New. * testsuite/23_containers/unordered_set/requirements/debug.cc: New. * testsuite/23_containers/unordered_multiset/requirements/ debug.cc: New. 2007-10-18 Benjamin Kosnik [EMAIL PROTECTED] * testsuite/util/native_type/assoc/native_hash_multimap.hpp: Remove hash_map include. Added: trunk/libstdc++-v3/include/backward/hash_fun.h - copied, changed from r129351, trunk/libstdc++-v3/include/ext/hash_fun.h
[Bug middle-end/21718] real.c rounding not perfect
--- Comment #6 from neil at gcc dot gnu dot org 2007-10-18 15:24 ---
(In reply to comment #5)
I believe more than 160 bits are required to get even single-precision numbers
right with DECIMAL_DIG digits precision and an exponent. I'm going to try and
prove this by finding an example. It could be hard as I believe 160 is only
just below the required number.
Here's an example to prove this assertion. When compiled with GCC 4.1.2 or
4.1.3 with -std=c99, assuming a correctly-rounding libc (e.g. NetBSD's; glibc
also seems to get this correct) you get the following output:
0x1.8p-147 0x1.4p-147 8.40779078594890243e-45
So not only is it rounded incorrectly, but the number it is rounded to, when
converted back to decimal, does not even match the input number in the first
digit.
#include stdio.h
#include stdlib.h
int main (void)
{
float f1 = 7.7071415537864938e-45;
float f2 = strtof (7.7071415537864938e-45, NULL);
printf( %a %a %0.18g\n, f1, f2, f1);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-10-18 16:04 --- Done. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug libstdc++/33489] parallel v3: not default constructible issues
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-10-18 16:06 --- Wolfgang, I'm going to close this as fixed, ok? We are now checking systematically for this issue as part of the 25_algo conformance testing. If you find any more of these, please re-open. best, benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
[Bug driver/33577] Compile failing for xpdf 3.02
--- Comment #7 from cabanasg at metro dot net 2007-10-18 16:13 --- Subject: RE: Compile failing for xpdf 3.02 My problem occurs during the 'make' step, after the './configure' step. How can I use 'g++' for linking during the 'make' step? Thanks. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 5:56 PM To: Cabanas, Gilberto Subject: [Bug driver/33577] Compile failing for xpdf 3.02 --- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-18 00:56 --- with the following error message: (Any help will be greatly appreciated) ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info Yes you are not linking with the correct libstdc++ or not linking with it at all. Link with g++ and not gcc directly. -- 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=33577 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33577
[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-10-18 16:18 ---
Current mainline in parallel mode still has this fail, for the record.
Looking at the concepts code
From:
http://www.generic-programming.org/software/ConceptGCC/
include/bits/stl_numeric.h:
template_GLIBCXX_REQ_PARM(InputIterator, _Iter),
_GLIBCXX_REQ_PARM(CopyConstructible, _Tp)
_GLIBCXX_WHERE(Addable_Tp, _Iter::value_type,
Assignable_Tp,
Addable_Tp, _Iter::value_type::result_type)
_Tp
accumulate(_Iter __first, _Iter __last, _Tp __init)
{
__glibcxx_requires_valid_range(__first, __last);
for (; __first != __last; ++__first)
__init = __init + *__first;
return __init;
}
which is also assuming iterator_traits::value_type
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33490
[Bug c/33809] Rounding off error in GCC 4.1.2
--- Comment #4 from manu at gcc dot gnu dot org 2007-10-18 16:27 --- (In reply to comment #3) Your code is undefined. You have multiple assignments to pow_tmp without intervening sequence points. Do you think it could be interesting to collect these kind of reports as potential testcases for an improved Wsequence-point (PR16202)? The only thing to be done is (apart from closing it as invalid) add it as blocking bug 16202. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-10-18 16:29 --- Thanks for fixing this Paolo. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libstdc++/33603] configuration failure during native build
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-10-18 16:31 --- Yo Gaby. Has this been worked out? Can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #4 from bldantes at comcast dot net 2007-10-18 16:40 --- Why does adding the new libstdc++ template function: templatetypename _Tp inline bool operator!=(const allocator_Tp, const allocator_Tp); fix the conflict between my template function: template class T bool operator != (const T x, const T y); and the existing libstdc++ template function: templatetypename _T1, typename _T2 inline bool operator!=(const allocator_T1, const allocator_T2); ??? Before the addition of the new template function, it seems like the conflict in the first place is just wrong. The compiler should pick the existing one in libstdc++ over mine because it more closely matches the type, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug tree-optimization/33812] Vectorizer testcases fail
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 16:40 --- May I guess revision 129400? --- trunk/gcc/ChangeLog 2007/10/17 00:46:27 129399 +++ trunk/gcc/ChangeLog 2007/10/17 01:05:50 129400 @@ -1,3 +1,10 @@ +2007-10-17 Alan Modra [EMAIL PROTECTED] + + * config/rs6000/rs6000.c (rs6000_emit_epilogue): Correct + altivec sp_offset. Rearrange sp_offset assignments to + correspond to stack adjustments. Use frame_reg_rtx for + SPE register restores. Correct SPE stack adjustment. + 2007-10-17 Manuel Lopez-Ibanez [EMAIL PROTECTED] * builtins.c (gimplify_va_arg_expr): Use inform for help message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/33812] [4.3 Regression] Vectorizer testcases fail
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-18 16:56 --- Looks like they also appear on ppc-darwin too: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00818.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Status|UNCONFIRMED |NEW Component|tree-optimization |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-18 16:56:18 date|| Summary|Vectorizer testcases fail |[4.3 Regression] Vectorizer ||testcases fail Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #6 from dcb314 at hotmail dot com 2007-10-18 17:33 --- (In reply to comment #2) Although valgrind is correct that we are doing an uninitialized read, the code is actually working as designed and is correct. I wish I had a pound for every time I've heard that ;- So yes we do some uninitialized accesses to the sparse array, but that's ok. Sure ? So absolutely *any* value is fine ? Aren't there some machines where unaligned accesses to words fail ? It's also a benefit of sparseset, given that we don't have to memset/clear the whole sparseset data structure before using it, so it's fast. I'd appreciate seeing some performance measurement numbers which tell us just how fast, so we can make a comparison of just how much speed this tricky code is buying us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #5 from pcarlini at suse dot de 2007-10-18 17:48 --- No, this is ADL at work. Browse the comments in stl_iterator.h for some additional hints, or delve into the nuisances of ADL ;) Anyway, for mainline, I will also add another fix, which avoid completely the comparison for stateless allocators. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #6 from paolo at gcc dot gnu dot org 2007-10-18 17:58 --- Subject: Bug 33807 Author: paolo Date: Thu Oct 18 17:58:13 2007 New Revision: 129454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129454 Log: 2007-10-18 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33807 * include/bits/allocator.h (operator==(const allocator_Tp, const allocator_Tp), operator!=(const allocator_Tp, const allocator_Tp)): Add. * testsuite/20_util/memory/allocator/33807.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/20_util/memory/allocator/33807.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/bits/allocator.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libstdc++/33807] Incorrect ambiguous overload
--- Comment #7 from pcarlini at suse dot de 2007-10-18 17:58 --- Fixed for 4.2.3. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #26 from burnus at gcc dot gnu dot org 2007-10-18 18:22 --- If I understand it correctly, there is a difference between IEEE 754-1989 and the current draft of IEEE 754 (duped IEEE 754r), see also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/33055faef528c075 IEEE 754r says that all operations with NaN yield NaN except of min and max which give only NaN if all (i.e. both) arguments are NaN. IEEE 754-1989 had no min/max functions and thus always NaN have to be produced for maxval( huge(x), NAN ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug libstdc++/33603] configuration failure during native build
--- Comment #7 from gdr at cs dot tamu dot edu 2007-10-18 18:46 --- Subject: Re: configuration failure during native build bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Yo Gaby. Has this been worked out? Can we close this? As long as we document that that build on MinGW requires explicit specification of the paths to `as' and `ld'. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug libstdc++/33489] parallel v3: not default constructible issues
--- Comment #12 from bangerth at dealii dot org 2007-10-18 18:46 --- Yes, sorry. I meant to report of course that I believe that it works now. Thanks for your work! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #4 from falk at debian dot org 2007-10-18 19:26 --- Created an attachment (id=14370) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370action=view) Vectorization dump file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #17 from hjl at lucon dot org 2007-10-18 20:55 --- This patch: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01047.html makes 437.leslie3d 10% faster on Intel Core 2 Duo 64bit. But it is still 23% slower than gcc 4.1 Red Hat. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-18 21:04 --- The native compiler MSVC++ does not limit field alignment to 64 bits, but as documented here Windows Data Alignment on IPF, x86, and x64 http://msdn2.microsoft.com/en-us/library/Aa290049(VS.71).aspx supports at least up to 256-bit field alignment (see Listing 5 in above article). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33774
[Bug fortran/32021] Fix,document,remove GFORTRAN_* environment variables
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-18 21:25 --- Subject: Bug 32021 Author: fxcoudert Date: Thu Oct 18 21:25:21 2007 New Revision: 129463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129463 Log: PR libfortran/32021 * runtime/backtrace.c (local_strcasestr): Protect by appropriate macros. * runtime/main.c (cleanup): Cast argument to free. * intrinsics/spread_generic.c (spread_internal): Match runtime_error arguments and format. * intrinsics/signal.c (alarm_sub_int_i4, alarm_sub_int_i8): Cast pointers to avoid warnings. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/signal.c trunk/libgfortran/intrinsics/spread_generic.c trunk/libgfortran/runtime/backtrace.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
[Bug libstdc++/33815] New: tr1::uniform_int isn't uniform
Consider:
#include ctime
#include iostream
#include vector
#include tr1/random
void test ( unsigned int num_buckets, unsigned int seed = 3141592 ) {
std::cout using num_buckets buckets:\n;
std::tr1::mt19937 eng(seed);
const unsigned long range = eng.max() / 5.5;
std::tr1::uniform_intunsigned long rnd( 0, range );
std::vectorunsigned long bucket ( num_buckets, 0 );
for ( unsigned int i = 0; i 100; ++i ) {
++bucket[ rnd(eng) / (range / num_buckets) ];
}
for ( unsigned int i = 0; i num_buckets; ++i ) {
std::cout i : bucket[i] '\n';
}
std::cout '\n';
}
int main ( void ) {
test( 2 );
test( 3 );
test( 4 );
test( 6 );
test( 10 );
test( 20 );
test( 30 );
test( 40 );
}
It yields:
using 2 buckets.
0: 545389
1: 454611
using 3 buckets.
0: 363350
1: 333829
2: 302821
using 4 buckets.
0: 272507
1: 272882
2: 227489
3: 227122
using 6 buckets.
0: 181743
1: 181607
2: 182039
3: 151790
4: 151182
5: 151639
...
This doesn't look uniform. It looks more like the buckets in the
lower half get hit significantly more often.
Credit: This strange behavior had been reported by David Benbennick
to Boost long ago and was apparently never fixed.
--
Summary: tr1::uniform_int isn't uniform
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33815
[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_number not working
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:16 --- Subject: Bug 33795 Author: jvdelisle Date: Fri Oct 19 04:16:14 2007 New Revision: 129471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129471 Log: 2007-10-18 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33795 * gfortran.texi: Document GFORTRAN_UNBUFFERED_PRECONNECTED environment variable. Delete mention of environment variable GFORTRAN_UNBUFFERED_n. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33795
[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_number not working
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:11 --- Subject: Bug 33795 Author: jvdelisle Date: Fri Oct 19 04:10:58 2007 New Revision: 129470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129470 Log: 2007-10-18 Francois-Xavier Coudert [EMAIL PROTECTED] Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33795 * libgfortran.h: Add unbuffered_preconnected. * io/unix.c (output_stream): Set stream unbuffered flag if options.unbuffered_preconnected has been set. (error_stream): Ditto. * runtime/environ.c (variable_table): Add to environment variable table the entry: GFORTRAN_UNBUFFERED_PRECONNECTED. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/environ.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33795
[Bug fortran/33814] New: Failure of gfortran n Mac Mini
I am using gfortran on a Mac Mini, and have got the compiler by untaring the gfortran-intel-bin.tar package. The compilers are located in /usr/local/bin. I am running Mac OS X Version 10.4.10 Whenever I invoke this compiler without specifying a cource file I get the expected error message: gfortran: no input files From this I deduce that the compiler is in the correct place and is able to detect this simplest of errors Whenever I invoke the compiler with a valid fortran source file I get the error message: gfortran: error trying to exec 'f951': execvp: No such file or directive. I detected this error while trying to compile the sources for OpenGl, and I could not make sense of the message. I then discovered that the error message was the same for all the input files that I tried. Eventually I tried compiling a program that compiled successfully with g77 using the command line: /usr/local/bin/g77 -ffixed-form -ffixed-line-length-132 -fbounds-check-ffortran-bounds-check -w -ff90 -0 strauss strauss.f with the command line: /usr/local/bin/gfortran -ffixed-form -ffixed-line-length-132 -fbounds-check -fmax-errors-0 -o strauss strauss.f This caused the response (as before) gfortran: error trying to exec 'f951' : execvp I have searched the known bugs file for f951 without any response. I admit that I am new to Mac systems but have experience of Linux and SGI systems from which the above source files are derived. I have tried out trivially simple source programs for testing and got the same error message in response -- Summary: Failure of gfortran n Mac Mini Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cbas25 at strath dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33814
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #22 from bkoz at gcc dot gnu dot org 2007-10-19 02:00 --- I believe there are other functions in libstdc++ that depend on initialization order. I do not have specifics. Perhaps: FAIL: 27_io/objects/char/6.cc execution test FAIL: 27_io/objects/wchar_t/6.cc execution test FAIL: ext/mt_allocator/check_new.cc execution test FAIL: ext/pool_allocator/check_new.cc execution test from: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00820.html These are the ones I would suspect might change. FWIW, I agree 100% with Wolfgang's venting in #8, #10. Correct __cxa_atexit behavior is essential. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #21 from ajd at gentrack dot com 2007-10-19 01:44 --- Created an attachment (id=14372) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14372action=view) support -blazy, add option to disable I suggest exportinitfini_flag is enabled by default or atleast for the build of libstdc++.a and libgcc_s.a. It should have minimal impact/risk. initdependents_flag has risk/impact attached. You may want to reverse the default. My case for having it on by default: To use exceptions within global constructors a module needs to be linked with initdependents_flag enabled. I believe there are other functions in libstdc++ that depend on initialization order. I do not have specifics. Assuming AIX was the only OS that works this way, it allows removal of these types of workarounds: http://gcc.gnu.org/ml/libstdc++/2001-01/msg00369.html -- ajd at gentrack dot com changed: What|Removed |Added Attachment #14327|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug fortran/33544] [4.3 only] Warning in TRANSFER intrinsic should be made optional
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:58 --- This does the trick. I am checking the testsuite for any side effects. Index: simplify.c === --- simplify.c (revision 129465) +++ simplify.c (working copy) @@ -4065,7 +4065,7 @@ gfc_simplify_transfer (gfc_expr *source, result_size = result_elt_size; } - if (source_size result_size) + if (gfc_option.warn_surprising source_size result_size) gfc_warning(Intrinsic TRANSFER at %L has partly undefined result: source size %ld result size %ld, source-where, (long) source_size, (long) result_size); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33544
[Bug driver/33772] collect2 doesn't strip .sl version
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18 23:55 --- Subject: Re: New: collect2 doesn't strip .sl version On Sun, 14 Oct 2007, danglin at gcc dot gnu dot org wrote: After recently updating libgmp, I find that shared libraries that were linked against the old version are broken. For example, libtool links libguile.sl against libgmp.sl.7, /usr/local/lib/libltdl.sl.4, /usr/lib/libc.1 and /users/gcc/gcc-4.2.0/lib/libgcc_s.sl. The reason previously installed libraries break is the dependent libraries have hardcoded dependencies on the `*GLOBAL*' symbols used for constructors, destructors and EH exception support (hppa2.0w-hp-hpux* currently has its EH data in the data section). The attached patch fixes the versioning problem. However, we still have a random portion in every `*GLOBAL_F*' symbol. This can easily change from one build to the next. So, I'm thinking we need to bury them in special sections similar to .init_array and .fini_array. However, the dynamic loader doesn't provide direct support for this, so this it's going to take some thinking as to the best way to do this. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18 23:55 --- Created an attachment (id=14371) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14371action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33772
[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_number not working
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:22 --- Fixed, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33795
