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>&, con
--- 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
--- 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];
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 05:26 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- 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 docum
--- 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
> > 32b
--- 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 l
--- 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 #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 different
--- 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 #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 appreciated
--- 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 #1 from pcarlini at suse dot de 2007-10-17 23:25 ---
The compiler is correct: per 5.3.3/1, sizeof shall not be applied to an
incomplete type.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
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':
../../_g
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 class
--- 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, -
--- Comment #7 from hjl at lucon dot org 2007-10-17 21:48 ---
Icc generates:
#include
__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: file format el
--- 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 #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 #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 #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: -
[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 app
--- 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=14367&action=view)
preprocessed code to generate problem
This is the preprocessed version of the file used to generate the bug.
--
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 submit
--- 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 tha
--- 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 #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=14366&action=view)
(Big) testcase that allows to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
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 #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
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
htt
For this kind of code:
struct cont
{
typedef const int& const_reference;
};
template
struct iter
{
void
f(const typename C::const_reference value)
{ }
};
int main()
{
iter it;
it.f(5);
}
we do not emit any warning for the 'const' in the signature of f. We simply
ignore it. The EDG f
--- 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. Wh
--- 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 #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 #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=gcc&view=rev&rev=129410
Log:
PR middle-end/33794
* gfortran.dg/pr33794.f90: New
--- 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
AssignedT
--- 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 #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
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 = D.892_19
I
--- 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 -fpreprocess
--- 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=14365&action=view)
Patch to mark external decls to be varargs
--
asl at math dot spbu dot ru changed:
What|Remove
--- 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 ext
--- 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
da
--- 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=14364&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- 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
> freehdl-vit
--- 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=14363&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
$ 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 #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 #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 #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=gcc&view=rev&rev=129406
Log:
PR middle-end/33794
* reg-stack.c (move_for_stack_
--- 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 #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 suppres
--- 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 #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 #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 differe
--- 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 proced
--- 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.
--
http://gcc.gnu.org/bug
--- 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 #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 i
--- 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]
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.
This
--- 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
+++ init.c
--- 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 corre
--- 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 flo
--- 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 #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=14362&action=view)
Reduced Testcase. Small Code, huge datastructure.
In the attached testcase due to an ivopts modificati
--- 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 final_
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 10:23 ---
Bisection points to r129350:
http://gcc.gnu.org/viewcvs?view=rev&revision=129350
PR tree-optimization/33619
* tree-ssa-ter.c (is_replaceable_p): Return false for all
calls.
* gcc.dg/pr3361
--- 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 =
--- 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 #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
--
--
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 #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
--
--- 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 #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=gcc&view=rev&rev=129403
Log:
PR target/32961
* config/i386/i386.c (ix86_expand_b
--- 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
AssignedTo|unassigned
76 matches
Mail list logo
