--- Comment #4 from ubizjak at gmail dot com 2007-10-17 07:08 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-17 06:57 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-17 06:57 ---
Subject: Bug 33760
Author: burnus
Date: Wed Oct 17 06:57:06 2007
New Revision: 129402
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129402
Log:
2007-10-17 Christopher D. Rickett [EMAIL PROTECTED]
PR
--- Comment #5 from uros at gcc dot gnu dot org 2007-10-17 08:25 ---
Subject: Bug 32961
Author: uros
Date: Wed Oct 17 08:25:15 2007
New Revision: 129403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129403
Log:
PR target/32961
* config/i386/i386.c
--- Comment #2 from ubizjak at gmail dot com 2007-10-17 09:10 ---
(In reply to comment #1)
Since this is using -ffast-math, i suspect this is not a bug.
By adding a print before the condition (line 6372), it looks that something
goes seriously wrong:
gfortran -O2:
cpu time to define
--- Comment #3 from ubizjak at gmail dot com 2007-10-17 09:11 ---
Confirmed with plain -O2 -ffast-math on i686-pc-linux-gnu.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-17 09:14 ---
*** This bug has been marked as a duplicate of 32965 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-17 09:14 ---
*** Bug 33798 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from asl at math dot spbu dot ru 2007-10-17 10:17 ---
(In reply to comment #3)
Confirmed. The same thing is true for external procedures, like:
program test
real x
external x
print *, x(2)
end program test
real function x(i)
integer i
x = i + 1
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 10:23 ---
Bisection points to r129350:
http://gcc.gnu.org/viewcvs?view=revrevision=129350
PR tree-optimization/33619
* tree-ssa-ter.c (is_replaceable_p): Return false for all
calls.
*
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-17 10:39 ---
And really that patch should not change anything really since it just means TER
does not cross function call boundaries now (and not just accross over non
pure/const function calls).
Can you at least give the
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-10-17
10:49 ---
Created an attachment (id=14362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14362action=view)
Reduced Testcase. Small Code, huge datastructure.
In the attached testcase due to an ivopts
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-10-17
10:50 ---
Adding Andrew here.
--
pranav dot bhandarkar at gmail dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-17 11:02 ---
Also what happens if you use -ffloat-store ?
Even though it might be 3 orders of magnitude, this could be still the same
issue as PR 323 (errors multiply in some cases). Also note -ffloat-store
disables TER for
--- Comment #3 from zadeck at naturalbridge dot com 2007-10-17 11:25
---
Subject: Re: valgrind error with -O2 for linux
kernel code
bergner at gcc dot gnu dot org wrote:
--- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46
---
Although valgrind is correct
--- 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.
--- init.c 2007-09-20 15:13:00.0 +0100
+++
In C++, if a local variable's destructor throws after the return value object
has been created, the return value object is never destroyed!
G++ uses the allowed C++ return value optimisation and creates a return value
object directly without copying it. This is probably one source of the bug.
--- Comment #8 from ubizjak at gmail dot com 2007-10-17 11:40 ---
(In reply to comment #6)
Also what happens if you use -ffloat-store ?
-O2 -ffast-math -ffloat-store works OK...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
--- Comment #7 from ubizjak at gmail dot com 2007-10-17 11:38 ---
(In reply to comment #5)
There are (many!) changes of type:
- D.6241 = __builtin_sqrt (receive_coil_1.self_ind * transmit_coil.self_ind);
- coil_coil_mutuals[0] = coil_coil_mutuals[0] / D.6241;
+ coil_coil_mutuals[0]
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-10-17 11:46 ---
I think what is happening is that coil_coil_mutuals[0] / D.6241 is being
expanded as coil_coil_mutuals[0] * (1/D.6241) which is not bad, just
inconstaint. I think we need to look into this more but I doubt there is
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-17 12:03 ---
As a data point, EDG based icpc behaves the same.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bitti at iki dot fi 2007-10-17 12:21 ---
I also tried on other compilers. Sun's compiler (CC: Sun C++ 5.9 SunOS_sparc
Patch 124863-01 2007/07/25) shows the same bug as Gcc. Microsoft Visual Studio
2005 works ok and destroys both objects.
--
--- Comment #10 from ubizjak at gmail dot com 2007-10-17 12:28 ---
(In reply to comment #9)
I don't want to claim excess precision problems here. I was trying to debug
self_ind_cir_coil procedure, as it looks that the problem is in calculation of
self_r output.
The input to this
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-17 12:36
---
(In reply to comment #3)
You're right. The assignment even produces the temporary for the lhs index
that it should. Now why on earth does this happen in 64bit mode an not in
32bit??
Sometimes, the
--- Comment #11 from ubizjak at gmail dot com 2007-10-17 12:39 ---
The problem is somewhere around line 212 in induct.f90. Adding some debug code
at the end of the function:
...
!evaluate self-inductance
!
self_l = (mu * turns**2 * l**2 * 2.0_longreal * r)/3.0_longreal *
--- Comment #12 from ubizjak at gmail dot com 2007-10-17 13:57 ---
Well, the problem here is that swap insn is not emitted before x87 fptan.
It is actually my fault (UNSPEC_TAN handling is a bit wrong), the problem is
only exposed by Jakub's patch.
So, mine.
--
ubizjak at gmail dot
--- Comment #4 from bergner at gcc dot gnu dot org 2007-10-17 14:21 ---
People using valgrind already have to deal with false positives and actual
uninitialized uses (like this one) that are harmless. If you look at your
valgrind install, you'll see that there are several error
--- Comment #13 from ubizjak at gmail dot com 2007-10-17 14:31 ---
Proposed patch in testing:
Index: reg-stack.c
===
--- reg-stack.c (revision 129402)
+++ reg-stack.c (working copy)
@@ -1085,11 +1085,13 @@
special
--- Comment #14 from uros at gcc dot gnu dot org 2007-10-17 15:22 ---
Subject: Bug 33794
Author: uros
Date: Wed Oct 17 15:22:23 2007
New Revision: 129406
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129406
Log:
PR middle-end/33794
* reg-stack.c
--- Comment #5 from tbm at cyrius dot com 2007-10-17 15:39 ---
(In reply to comment #3)
Adding Honza to cc: in the hope he can help since he fixed PR30509.
Honza: do you think you could take a look at this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-17 15:47 ---
Adding Zdenek, also familiar with the dominance code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from lloyd at randombit dot net 2007-10-17 16:06 ---
Created an attachment (id=14363)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14363action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
--- Comment #7 from rakdver at gcc dot gnu dot org 2007-10-17 16:07 ---
(In reply to comment #0)
I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine
with gcc 4.1 and 4.3 20070515.
(sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
--- Comment #11 from pthaugen at gcc dot gnu dot org 2007-10-17 16:14
---
Created an attachment (id=14364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14364action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #12 from pthaugen at gcc dot gnu dot org 2007-10-17 16:18
---
And now some comments to go with the prior attatchment...
This checkin is causing a 75% degradation on leslie3d for PowerPC. As HJ
observed earlier, it depends on a second function accessing some of the global
$ g++-4.3-20070907 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907
--enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt
Thread model: posix
gcc version 4.3.0 20070907 (experimental) (GCC)
--- Comment #9 from asl at math dot spbu dot ru 2007-10-17 16:45 ---
(In reply to comment #3)
Two decls are generated for function x, the first one (inside MAIN__) doesn't
have a proper argument list while the second one is OK. When I try to make
gfortran emit only one decl per
--- Comment #10 from asl at math dot spbu dot ru 2007-10-17 16:46 ---
Created an attachment (id=14365)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14365action=view)
Patch to mark external decls to be varargs
--
asl at math dot spbu dot ru changed:
What|Removed
--- Comment #2 from lloyd at randombit dot net 2007-10-17 16:48 ---
Backtrace (command line args for cc1plus chosen by stracing g++)
$ gdb /home/jack/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
Using host libthread_db library /lib64/libthread_db.so.1.
(gdb) run
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-10-17 16:59
---
Can someone explain this may_alias behavior:
so we have in the IR:
# VUSE SFT.30_53
D.892_19 = qav.data;
D.893_20 = (real8[0:] *) D.892_19;
in may_alias we get a constraint of:
D.892_19 = qav
D.893_20 =
--- Comment #11 from asl at math dot spbu dot ru 2007-10-17 17:00 ---
Also, some chunk of code in function type creation (gfc_get_function_type() is
in question) looks suspicious to me. Let me explain on terms of C (I don't know
Fortran at all :) )
Consider we have two function decls:
--- Comment #3 from jason at gcc dot gnu dot org 2007-10-17 17:07 ---
Similar to Bug 15764.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from uros at gcc dot gnu dot org 2007-10-17 17:10 ---
Subject: Bug 33794
Author: uros
Date: Wed Oct 17 17:09:58 2007
New Revision: 129410
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129410
Log:
PR middle-end/33794
* gfortran.dg/pr33794.f90: New
--- Comment #16 from ubizjak at gmail dot com 2007-10-17 17:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-10-17 17:14
---
(In reply to comment #11)
void foo2(some_fat_struct *ptr); but:
int foo(...);
This looks pretty unlogical to me. Was it intentional?
Yes, I think that's intentional. Why is it unlogical?
Also, have you
--- Comment #13 from asl at math dot spbu dot ru 2007-10-17 17:27 ---
(In reply to comment #12)
(In reply to comment #11)
void foo2(some_fat_struct *ptr); but:
int foo(...);
This looks pretty unlogical to me. Was it intentional?
Yes, I think that's intentional. Why is it
For this kind of code:
struct cont
{
typedef const int const_reference;
};
templatetypename C
struct iter
{
void
f(const typename C::const_reference value)
{ }
};
int main()
{
itercont it;
it.f(5);
}
we do not emit any warning for the 'const' in the signature of f. We simply
ignore
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-10-17 17:41
---
Subject: Re: [4.3 Regression] Revision 126326 causes 12% slowdown
On 17 Oct 2007 16:59:25 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #13 from pinskia at gcc dot gnu dot org
For the attached testcase, g++ gives a warning saying `z' is used
uninitialized in this function (_is_ used uninitialized, not _may be_ used
uninitialized)
in the statement marked with (***) below. However, `z' is indeed
initialized by the mul() function template, which takes the first
argument
--- Comment #1 from bagnara at cs dot unipr dot it 2007-10-17 18:40 ---
Created an attachment (id=14366)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14366action=view)
(Big) testcase that allows to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-17 18:46 ---
I doubt this is not an incorrect warning.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from wilson at specifix dot com 2007-10-17 20:53 ---
Subject: Re: valgrind error with -O2 for linux
kernel code
bergner at gcc dot gnu dot org wrote:
--- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46
---
Although valgrind is correct that
Multiple versions of gcc give an ICE when compiling the attached preprocessed
version of the FreeBSD des.c. The following is produced by gcc 4.2.2
$ h8300-rtems4.9-gcc -O2 -c des1.c
des1.c: In function 'des_init':
des1.c:4246: internal compiler error: in tree_low_cst, at tree.c:4554
Please
--- Comment #1 from joel at gcc dot gnu dot org 2007-10-17 21:07 ---
Created an attachment (id=14367)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14367action=view)
preprocessed code to generate problem
This is the preprocessed version of the file used to generate the bug.
--
[EMAIL PROTECTED]:/tmp% gcc -c -O2 129.c
[EMAIL PROTECTED]:/tmp% gcc -c -O2 -ftree-vectorize 129.c
129.c: In function 'add_bytes_c':
129.c:1: internal compiler error: in vect_transform_stmt, at
tree-vect-transform.c:6131
Please submit a full bug report,
with preprocessed source if
--- Comment #2 from joel at gcc dot gnu dot org 2007-10-17 21:12 ---
I have tried this code with the following gcc versions:
WORKS 3.2.3: -O2
FAILS 4.1.1: -O2
FAILS 4.2.1: -O2
FAILS 4.2.2: -O2
WORKS 4.2.1: -O0
WORKS 4.2.2: -O0
WORKS 4.1.1:
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-17 21:21
---
comment #12 hints at that this is really the same problem as PR32624 (which
basically says aliasing is fucked up and non-deterministic).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-17 21:23 ---
I doubt this is not an incorrect warning.
what? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
--- Comment #6 from geoffk at gcc dot gnu dot org 2007-10-17 21:28 ---
Shouldn't you have to use
_mm_sll_epi32(s, _mm_cvtsi32_si128 (c))
instead? Or does the 'i' in 'slli' stand for 'int' not 'immediate'?
I thought that the list of _mm_sl* intrinsics in the assembly reference guide
--- Comment #7 from hjl at lucon dot org 2007-10-17 21:48 ---
Icc generates:
#include xmmintrin.h
__m128i
foo (__m128i a, int n )
{
a = _mm_slli_epi32( a, n );
return a;
}
[EMAIL PROTECTED] tmp]$ /opt/intel/cce/10.0/bin/icc -c x.c
[EMAIL PROTECTED] tmp]$ objdump -d x.o
x.o:
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-17 22:32
---
I've been thinking about MINVAL((/NaN,NaN/)), ie minval of an array containing
only NaNs, over and over again, and it's a tough choice. Here's what compilers
currently output for MINVAL and MAXVAL:
Intel: Inf,
I got this error and this made me thinking.
First example produces an error:
m.C:2: error: invalid application of 'sizeof' to incomplete type 'B'
But the second one doesn't.
Why if I take sizeof() of the current class when instantiating the object it's
an error and if I pass the type to the
At revision 129402, gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on
Darwin:
[karma] darwin_buildw/gcc% gfc -m64 -O3 -fcray-pointer
../../_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90
../../_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90: In function
'ptr12':
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-10-17 23:49
---
Well this is just one little opinion:
There is no way that it is realistic to get a valid number out of a NaN
or a group of NaNs. It can only be NaN. It's like a place from which there is
no return. Maybe we
--- Comment #5 from cabanasg at metro dot net 2007-10-17 23:51 ---
I upgraded my gcc and g++ compilers to version 4.0.0. Tried to install
xpdf-3.02 again, the ./configure part goes well, but the make or gmake faile
with the following error message: (Any help will be greatly
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-10-18 00:18
---
Ok for hypot, and that may make sense knowing the nature of the function.
Minval is not a complex or transcendental function. I should not write in
loose general terms.
So maybe approach the question
--- Comment #23 from kargl at gcc dot gnu dot org 2007-10-17 23:57 ---
(In reply to comment #22)
Well this is just one little opinion:
There is no way that it is realistic to get a valid number out of a NaN
or a group of NaNs. It can only be NaN.
Read the hypot man page.
--- Comment #20 from dje at gcc dot gnu dot org 2007-10-18 00:48 ---
Yes, effectively -blazy, because of AIX's loader semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
--- 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
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-18 04:26 ---
(In reply to comment #4)
(In reply to comment #3)
You're right. The assignment even produces the temporary for the lhs index
that it should. Now why on earth does this happen in 64bit mode an not in
32bit??
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-10-18 04:53 ---
(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
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 05:26 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
74 matches
Mail list logo
