--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-06 06:18 ---
This looks like a vectorizer bug to me. Vectorizer creates:
vector void * * vect_pdtds.39;
vector void * * vect_pdtds.34;
vector unsigned char * vect_cst_.33;
...
vect_cst_.33_33 = {&dtd, &dtd, &dtd, &dtd};
I don't know how to make a preprocessed source,sorry!
$gcc --version
gcc (GCC) 4.4.0 20081005 (experimental)
$cd mpich2-1.1.0a1; mkdir build; cd build
$../configure --prefix=/usr/local/mpich2; make
CC ../../../../src/mpi/coll/opsum.c
../../../../src/mpi/coll/opsum.c: In fun
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-10-06 05:03
---
An easy fix to this would be to disallow kind=2 integer as an argument during
checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
Just get hold of the yabbawhap sources and "make AP". Then sit back and
listen for the gurgles.
Aside: Is it just me, or does -march=k6-2 result in slower code than
-march=k6 does?
Reynir H. Stefánsson ([EMAIL PROTECTED])
--
Scriptures: The sacred books of our holy religion, as distinguished f
nfigured)
../gcc/configure --enable-languages='c c++' --enable-shared --disable-static
--disable-nls
Thread model: posix
gcc version 4.4.0 20081005 (experimental) (GCC)
--
Summary: [C++0x] ICE with shared_ptr in initializer-list of new-
expression
{3.2, i1}; //ok
foo2 f2{3.2, i2}; //ok
new foo2{3.2, i2}; //error, why?
return 0;
}
==
GCC 4.4 svn (4.4.0 20081005) can't compile "new foo2{...}" line:
==
$ g++ -std=c++0x main.cpp
main.cpp: In function
I'm targeting an embedded Arm7 architecture. I've overridden single obj,
array and placement new and delete. My problem is that the override delete
is not called for a class obj when the obj is deleted (neither is the obj's
destructor.) However, if I declare the class destructor as virtual, then t
--- Comment #9 from dodji at gcc dot gnu dot org 2008-10-05 22:54 ---
Fixed in trunk
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #2 from schwab at suse dot de 2008-10-05 21:54 ---
Another workaround is to build with optimisation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- Comment #8 from dodji at gcc dot gnu dot org 2008-10-05 21:30 ---
Subject: Bug 37410
Author: dodji
Date: Sun Oct 5 21:29:32 2008
New Revision: 140895
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140895
Log:
2008-09-30 Dodji Seketeli <[EMAIL PROTECTED]>
gcc/ChangeLog:
--- Comment #7 from pault at gcc dot gnu dot org 2008-10-05 20:26 ---
(In reply to comment #6)
> Jacques,
>
> Now that 4.3 is out of the door, I have no excuse. It's in the queue behind
> completing my move to Barcelona, memory leaks in allocatable components + some
> associated bugs a
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|4.4.0 |4.2.5
http://gcc
--- Comment #13 from hjl dot tools at gmail dot com 2008-10-05 19:44
---
ira-merge branch is OK for i586-pc-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00316.html
It has this patch:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01955.html
--
hjl dot tools at gmail
--- Comment #1 from andreast at gcc dot gnu dot org 2008-10-05 19:25
---
Created an attachment (id=16463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16463&action=view)
workaround patch
Workaround patch to make bootstrap working again.
--
http://gcc.gnu.org/bugzilla/show_b
Since a longer time bootstrap is broken for powerpc-unknown-linux-gnu, 32-bit
at least. The interesting condition is, it only fails when the bootstrapping
compiler is > 4.2.x, iow. 4.3.x and 4.4.x (Well 4.4 I did not confirm myself)
The failure started with r132589, this commit itself does not con
--- Comment #5 from pault at gcc dot gnu dot org 2008-10-05 19:03 ---
(In reply to comment #4)
> At r140286 with the patch in
> http://gcc.gnu.org/ml/fortran/2008-09/msg00210.html, the failure is gone!-(
>
I cannot explain it, other than the old version using something that was not
ini
--- Comment #15 from pault at gcc dot gnu dot org 2008-10-05 18:54 ---
Subject: Bug 35680
Author: pault
Date: Sun Oct 5 18:53:19 2008
New Revision: 140892
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140892
Log:
2008-10-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-05 17:28
---
Confirmed on 4.3 and 4.1.2 so not a regression.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kazu at gcc dot gnu dot org 2008-10-05 15:52 ---
I'm taking this.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|ebotc
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-10-05 15:33
---
Saw there also needless DW_OP_plus_uconst - it could be single DW_OP_addr for
all the common block variables (which would make the GDB support a bit easier).
program a2
INTEGER*4 a
INTEGER*4 b
common /b
tion: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr:
684570)
<3><16d>: Abbrev Number: 5 (DW_TAG_variable)
DW_AT_name: a_i
DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr:
684570)
<1><187>: Abbrev Number: 7 (DW_TAG_subprogram)
--- Comment #6 from esigra at gmail dot com 2008-10-05 13:42 ---
This problem went away for me when I upgraded to GCC 4.3.1 (Gentoo x86), so it
seems to be fixed.
--
esigra at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-05 13:03 ---
Confirmed on (powerpc|i686)-apple-darwin9. Since gfortran produces a wrong
code, I think the "severity" should be increased to "major" or even "critical".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-05 12:58 ---
Confirmed on (powerpc|i686)-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
--- Comment #2 from cfairles at gcc dot gnu dot org 2008-10-05 12:09
---
I believe these are both ice-on-invalid code.
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-10-05 12:02
---
This variant also ice's in same place but issues error first:
ice2.cpp:
template
void f()
{
f();
}
template<>
void f() { }
int main()
{
f();
}
ice2.cpp:8: error: template-id f<> for void f() does not ma
The following snippet ICE's:
void f() { }
template
void f(){ f(); }
int main()
{
f();
}
tree check:
accessed elt 1 of tree_vec with 0 elts in get_innermost_template_args
at cp/pt.c:516
Is this ice-on-valid or will f<>() not be picked up by the non-template
function?
--
Summa
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #8 from pault at gcc dot gnu dot org 2008-10-05 08:45 ---
Fixed on trunk and 4.3. This one is so obvious that I decided not to wait to
commit to 4.3.
Lester, I see that you use overnight builds of 4.4; you should see the benefit
right away then:-)
Thanks for the report.
P
--- Comment #7 from pault at gcc dot gnu dot org 2008-10-05 08:42 ---
Subject: Bug 37706
Author: pault
Date: Sun Oct 5 08:41:00 2008
New Revision: 140881
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140881
Log:
2008-10-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from simartin at gcc dot gnu dot org 2008-10-05 07:27
---
PR37736 opened for the reject valid case (it's a different bug).
Patch for the ICE submitted here:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00134.html
--
simartin at gcc dot gnu dot org changed:
31 matches
Mail list logo
