--- 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];
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- 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
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
--- 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.
--
--- 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
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,
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++
--- 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
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
--
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
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
--- 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
--- 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]
*
--- 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
--- 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
--- 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
--
--- 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:
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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]
+
+ *
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--
--- 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
--- 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
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;
--- 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
--- 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]
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:
--- 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
--- 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
--- 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
--- 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
--- 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
73 matches
Mail list logo
