--- Comment #9 from singler at gcc dot gnu dot org 2009-10-22 06:57 ---
I can reproduce the bug on my machine (2 Quadcore Nehalems, 48GB RAM)
4 x 10^9 ints: 65 seconds used in sort
5 x 10^9 ints: 193 seconds used in sort
--
singler at gcc dot gnu dot org changed:
What
--- Comment #2 from gcczilla1 at achurch dot org 2009-10-22 06:57 ---
Sorry! Not sure how I missed that one in my search.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41789
--- Comment #10 from singler at gcc dot gnu dot org 2009-10-22 07:15
---
The problem is in multiseq_selection.h, where this line has an overflow
(static_castuint64_t(__total) * __rank / __N - __leftsize)
if (__total * __rank) exceeds 64 bits. The quick fix is to use a temporary
--- Comment #11 from singler at gcc dot gnu dot org 2009-10-22 07:16
---
Created an attachment (id=18862)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18862action=view)
Patch replacing uint64_t by double to avoid overflow, for trunk.
--
--- Comment #12 from singler at gcc dot gnu dot org 2009-10-22 07:17
---
Created an attachment (id=18863)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18863action=view)
Patch replacing uint64_t by double to avoid overflow, for branch 4.4.
--
--- Comment #13 from singler at gcc dot gnu dot org 2009-10-22 07:42
---
(In reply to comment #10)
However, I do not fully trust the double arithmetics yet, although some test
cases work.
Er, this sounded a bit pessimistic, all sort tests I have tried so far work
with the patch.
The following snippet looks legal to me, but it does not compile:
#include list
struct aaa {};
struct bbb {
aaa operator ( void ) const {
return aaa();
}
};
bool operator ( bbb lhs, bbb rhs ) {
return ( false );
}
int main ( void ) {
std::list bbb a;
}
I run into the same
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-22 08:53 ---
Subject: Bug 41781
Author: janus
Date: Thu Oct 22 08:53:26 2009
New Revision: 153446
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153446
Log:
2009-10-22 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #14 from pluto at agmk dot net 2009-10-22 09:01 ---
(In reply to comment #10)
However, I do not fully trust the double arithmetics yet, although some test
cases work. Does anybody else know a better way to avoid an overflow in ((a *
b) / c) with only integer arithmetics
Test case:
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
printf(0x%llx\n,(t.b-8));
}
The output of gcc42 is 0xfa (which is yield to be 40bits)
Why not
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-22 09:10 ---
With r153446, the codes in comment #1, #2 and #4 work as expected. I wanted to
get this out of the way quickly, so that we can make progress on Salvatore's
PSBLAS code, which still does not compile fully and continues
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-22 09:22 ---
Because C does not promote the bitfield type to its underlying type and thus
ends up passing a 40bit field to the varargs function (which obviously doesn't
work too good).
Works with the C++ FE.
--
rguenth at
Test case:
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
printf(0x%llx\n,(t.b-8));
}
The output of gcc42 is 0xfa (which is yield to be 40bits)
Why not
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-22 09:26 ---
Confirmed. We do not stream the in_system_header bits of locations.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41790
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-22 09:31 ---
Here is an even smaller test case with just one module:
module m
type :: A
end type
type, extends(A) :: B
end type
end module
use m, only: A
end
Backtrace (same as in comment #2):
#0 0x7fb6d07bd6a0
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-22 09:32 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at linux-m68k dot org 2009-10-22 09:32 ---
*** This bug has been marked as a duplicate of 41793 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #2 from schwab at linux-m68k dot org 2009-10-22 09:32 ---
*** Bug 41794 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-22 09:34 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-22 09:39 ---
Confirmed the 4.4 ICE. -O2 -ftracer -fsched2-use-superblocks -fpic -m32.
Cannot reproduce on 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from shenrfen at gmail dot com 2009-10-22 09:42 ---
Confused for the result.
int main()
{
struct s t = {1, 2, 3};
printf(0x%llx\n,(t.a-8));
printf(0x%llx\n,(t.b-8));
printf(0x%llx\n,(t.c-8));
}
the output is as following
0xfff9 (32
--- Comment #5 from pault at gcc dot gnu dot org 2009-10-22 09:55 ---
Created an attachment (id=18864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18864action=view)
Fix for the PR
This is, as yet, not regtested etc. I'll do so on Saturday, when back from my
travels, and commit
--- Comment #5 from pault at gcc dot gnu dot org 2009-10-22 09:58 ---
Created an attachment (id=18865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18865action=view)
A fix for the PR
I'll regtest etc. on Saturday, when I am back from my travels.
Paul
--
pault at gcc dot gnu
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-22 10:05 ---
(In reply to comment #5)
Created an attachment (id=18865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18865action=view) [edit]
A fix for the PR
This patch fixes fixes comment #3, but not comment #4 and
--- Comment #15 from jaffe at broadinstitute dot org 2009-10-22 10:22
---
Subject: Re: [parallel-mode] parallel sort run time
increases ~10 fold when vector size gets over ~4*10^9
Wonderful! Thank you very much for fixing this problem.
--
Consider the following example
begin of test.c
int main(int argc, char *argv[])
{
char *sz = (Is this a correct warning???);
return main(1, sz);
}
end of test.c
If compiled, it displays a warning
# gcc -o test test.c
test.c:3:42: warning: trigraph ??) ignored, use
--- Comment #2 from jarausch at igpm dot rwth-aachen dot de 2009-10-22
10:35 ---
(In reply to comment #1)
I don't think this is misparsing this at all. This is one place in the C++
standard that says it should be parsed as a function declaration rather than a
variable declaration
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-22 11:01 ---
The warning is correct, ??) is a trigraph.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-10-22 11:40 ---
Subject: Bug 40556
Author: hubicka
Date: Thu Oct 22 11:40:18 2009
New Revision: 153450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153450
Log:
PR tree-optimize/40556
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-22 12:48 ---
Still ICEs for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-10-22 12:50 ---
Please follow the bug reporting instructions
http://gcc.gnu.org/bugs/
when reporting bugs. They tell you to use -Wall, which would have shown
that your code has undefined behavior:
t.c:11:9: warning: format '%llx'
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-10-22
12:57 ---
Fixed with r153057.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
lto/41730
* g++.dg/lto/20091022-1_0.C: New testcase.
Added:
trunk/gcc/testsuite/g++.dg/lto/20091022-1_0.C
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41730
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-22 13:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following code fails for GCC:
struct A { int a; };
struct B : A {};
struct C : A {};
struct D : B, C { };
int main() { (void) sizeof(D::a); }
According to the current draft, such use is correct: Name lookup will resolve
to a single declaration, and sizeof does not make additional
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-10-22 13:32 ---
Subject: Bug 41730
Author: hubicka
Date: Thu Oct 22 13:31:48 2009
New Revision: 153456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153456
Log:
* ipa-cp.c (ipcp_read_summary): Remove now invalid
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-10-22 13:32 ---
Subject: Bug 40556
Author: hubicka
Date: Thu Oct 22 13:31:48 2009
New Revision: 153456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153456
Log:
* ipa-cp.c (ipcp_read_summary): Remove now invalid
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-22 13:46 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-22 14:06 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from alban dot linard at gmail dot com 2009-10-22 14:20
---
Seems related to bug #41752
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-22 14:39 ---
(In reply to comment #5)
Created an attachment (id=18865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18865action=view) [edit]
A fix for the PR
If I add
@@ -4008,6 +4014,9 @@ load_derived_extensions (void)
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-22 15:09 ---
(In reply to comment #7)
If I add [...] to this patch (borrowed from other places in module.c),
comment #4 and comment #1 are also fixed.
The ICEs do go away, but on Salvatore's original code I now get:
--- Comment #11 from matz at gcc dot gnu dot org 2009-10-22 15:13 ---
Have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Testcase attached.
$ cd testcase
$ make
mkdir test.gch
gcc -x c-header -c test.h -o test.gch/c
gcc -c -include test test.c
arm-alt-linux-gnueabi-gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://bugzilla.altlinux.org for instructions.
make: ***
--- Comment #1 from kirill at shutemov dot name 2009-10-22 15:13 ---
Created an attachment (id=18866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18866action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
--- Comment #2 from matz at gcc dot gnu dot org 2009-10-22 15:26 ---
Works with 4.3 and 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-22 15:27 ---
Slightly more reduced testcase:
extern __SIZE_TYPE__ strlen (const char *);
extern int f1 (void *);
extern char *f2 (void);
extern void f3 (int, int);
static char *a;
char *b, *c, *d, *e;
void
foo (void)
{
int f,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-22 15:37 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from shenrfen at gmail dot com 2009-10-22 15:46 ---
Thanks very much for all your reply.
But I also have another question, Why is the 3rd output 40bits?
int main()
{
struct s t = {1, 2, 3};
printf(0x%llx\n,(t.a-8));
printf(0x%llx\n,(t.b-8));
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-22 15:59
---
Note, the ICE happens only with checking enabled, error otherwise.
Again, CC-ing Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-22 16:12 ---
If you bothered to use -Wall, you would see.
/tmp/x.c:13:3: warning: format â%llxâ expects type âlong long unsigned
intâ, but argument 2 has type âintâ
/tmp/x.c:14:3: warning: format â%llxâ expects
--- Comment #2 from nenad at tensilica dot com 2009-10-22 16:22 ---
By the way, if comment #7 from bug 26670 still applies,
then the code is correct with -Wpacked, and wrong without it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41788
--- Comment #3 from kirill at shutemov dot name 2009-10-22 16:34 ---
(In reply to comment #2)
Works with 4.3 and 4.5
Did you reproduce it on 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
--- Comment #4 from hjl dot tools at gmail dot com 2009-10-22 16:34 ---
It is caused by revision 149188:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00065.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
--- Comment #16 from singler at gcc dot gnu dot org 2009-10-22 16:41
---
(In reply to comment #14)
(In reply to comment #10)
However, I do not fully trust the double arithmetics yet, although some test
cases work. Does anybody else know a better way to avoid an overflow in
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-10-22
17:09 ---
Subject: Re: Bootstrap with Sun Studio 12.1 fails
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-10-21 19:51 ---
(In reply to comment #3)
(Also, you don't mention what version of gmp
I'm building the git master of mesa on an i686-linux-gnu box (basically
slackware 12.2) using
gcc configured/built with
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr
--with-gnu-as --enable-shared --with-gnu-ld
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22
17:27 ---
Created an attachment (id=18867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18867action=view)
Preprocessed file leading to ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41798
--- Comment #2 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22
17:28 ---
Created an attachment (id=18868)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18868action=view)
Resulting .s file
This is basically empty.
--
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-22
17:33 ---
removing -floop- flags hides/removes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41798
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-22 17:34 ---
(In reply to comment #3)
removing -floop- flags hides/removes the problem.
Removes the problem. graphite.c code is only involved when the -floop-*
options are supplied.
--
--- Comment #5 from spop at gcc dot gnu dot org 2009-10-22 17:44 ---
Fixed in the Graphite branch. I will do a merge back to trunk in the next
days.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from paolo dot carlini at oracle dot com 2009-10-22 17:46
---
Is something known about the actual size of a, b, and c? Also, I don't know
which is the required precision for the result: must be exact if representable?
I suppose not, otherwise the suggestiong of using
--- Comment #6 from spop at gcc dot gnu dot org 2009-10-22 17:48 ---
Oh, well, this is reported against gcc4.4.
I do not intend to fix graphite there anymore, as there are way too many
changes to backport. You should try gcc 4.5 if you intend to use -floop-block.
Sebastian
--
--- Comment #11 from mikpe at it dot uu dot se 2009-10-22 17:55 ---
Created an attachment (id=18869)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18869action=view)
reduced test case in plain C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #5 from manu at gcc dot gnu dot org 2009-10-22 17:56 ---
@Alfonso,
We need the preprocessed testcase. See my previous comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
--- Comment #1 from paolo dot carlini at oracle dot com 2009-10-22 18:07
---
Didn't I reply to this issue already on the mailing list, recently? Anyway,
within C++03 the is supposed to not be overloaded, you can take it for
example from the lines in the standard about
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-10-22 18:13 ---
(In reply to comment #6)
I'm not sure we can claim there is GMP breakage at all: they could argue
that anyone including gmp.h can be expected to link with -lgmp as well.
I just don't know if it is correct to assume
--- Comment #34 from paolo dot carlini at oracle dot com 2009-10-22 18:18
---
Excellent. As soon as you get the papers back, let us know...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2009-10-22
18:20 ---
Subject: Re: Bootstrap with Sun Studio 12.1 fails
Even so, there is breakage in GCC as well:
* ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc
doesn't support extern inline.
--- Comment #5 from janis at gcc dot gnu dot org 2009-10-22 18:24 ---
Subject: Bug 41049
Author: janis
Date: Thu Oct 22 18:24:31 2009
New Revision: 153468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153468
Log:
Backport from 4.3 branch:
2009-09-21 Janis
--- Comment #6 from cepeda at gmail dot com 2009-10-22 18:30 ---
Created an attachment (id=18870)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18870action=view)
Preprocessed file of the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
--- Comment #7 from cepeda at gmail dot com 2009-10-22 18:31 ---
Unfortunately and surprisely, printf is needed in this testcase. I think that a
different testcase without the printf can be found because the bigger code that
I used had not got the printf.
I have attatched the
--- Comment #1 from schaub-johannes at web dot de 2009-10-22 18:42 ---
I found the same problem occurs with decltype - same diagnostic. Wasn't sure
whether i should open another bug report for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
The __enable_execute_stack code introduced for the target mingw32 in r134089
doesn't work for kernel-mode components. These components can link to libgcc,
but never link to kernel32.
It would be good if there was a way to turn off this code, for example by a
-f/-fno compiler flag.
--
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-22 20:09 ---
(In reply to comment #8)
The ICEs do go away, but on Salvatore's original code I now get: ...
I get such problem now and then when using an obsolete module file and in
general it goes away after recompiling it. Now
Hi,
the attached code leads to an internal error:
abstract_conjugate_gradients.f90: In function cg:
abstract_conjugate_gradients.f90:6:0: internal compiler error: in
fold_convert_loc, at fold-const.c:2789
Cheers,
-ha
--
Summary: [OOP] ICE in fold_convert_loc, at
--- Comment #1 from anlauf at gmx dot de 2009-10-22 21:34 ---
Created an attachment (id=18871)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18871action=view)
Modules and compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41800
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-10-22 21:34
---
THis has been fixed for awhile now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The included test case is cut down from
libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc and ICE's when
compiled with '-milp32 -O1 -g -std=gnu++0x' on IA64 HP-UX. It works in 64 bit
mode and it works with -O0. The ICE is:
x.C: In function 'int main()':
x.C:16:1: internal compiler error:
--- Comment #1 from meissner at gcc dot gnu dot org 2009-10-22 21:53
---
Created an attachment (id=18872)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18872action=view)
Patch to fix both problems in 41787
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41787
--- Comment #5 from hjl dot tools at gmail dot com 2009-10-22 21:55 ---
This is fixed on trunk by revision 149082:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01067.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
make -C ../java_libs
make[1]: Entering directory `/home/p679492/src/pdftk-1.41/java_libs'
make -C /home/p679492/src/pdftk-1.41/java_libs/com/lowagie/text;
make[2]: Entering directory
`/home/p679492/src/pdftk-1.41/java_libs/com/lowagie/text'
gcj -O2 -w --encoding=UTF-8
In the source code there are two classes, Point and Edge. A series of points
are stored in a std::multiset. Edges are formed between the points, referenced
by multiset iterators. The points are given pointers to the edge they are a
part of.
In the function Edge::splitEdge, an edge is broken up
--- Comment #1 from dont_spam_james at yahoo dot com 2009-10-22 22:47
---
Created an attachment (id=18873)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18873action=view)
Simple C++ file showing the build error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41803
--- Comment #6 from hjl dot tools at gmail dot com 2009-10-22 22:48 ---
Created an attachment (id=18874)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18874action=view)
A patch backported from trunk
This patch works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
--- Comment #2 from dont_spam_james at yahoo dot com 2009-10-22 22:52
---
Created an attachment (id=18875)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18875action=view)
.ii file
Obtained using
g++ -v -save-temps -m32 -o -Wall -Werror -pedantic testLinuxBuildError.cpp
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-22 22:56 ---
Looks like a bug in multiset:
typedef typename _Rep_type::iterator const_iterator;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from spop at gcc dot gnu dot org 2009-10-22 23:03 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from zsojka at seznam dot cz 2009-10-22 23:07 ---
This patch works for me.
Does it work for testcase from #1 as well?
I was bisecting trunk to find where this is fixed, it seems to be somewhere
between r151400 (20090904) and r151500 (20090908).
However, I was testing
--- Comment #4 from chris at bubblescope dot net 2009-10-22 23:14 ---
The reason that in general changing the Point a std::multisetPoint::iterator
refers to is forbidden is that doing so will break the invariant on which the
multiset is based, resulting in random crashes occuring later
--- Comment #5 from paolo dot carlini at oracle dot com 2009-10-22 23:21
---
*** This bug has been marked as a duplicate of 14410 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2009-10-22 23:21
---
*** Bug 41803 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from mikpe at it dot uu dot se 2009-10-23 00:29 ---
The ARM misalignment bug in this PR was fixed for gcc-4.4 by r141742, an
apparently ia64- and Ada-motivated generic patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-10-23 01:03 ---
Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
When I try running 'gmake check' after compile I get such log:
skipped
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for
target.
Using
--- Comment #5 from ccoutant at gcc dot gnu dot org 2009-10-23 01:44
---
Created an attachment (id=18876)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18876action=view)
Proposed fix for PR 41700.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
--- Comment #6 from ccoutant at gcc dot gnu dot org 2009-10-23 01:46
---
I'm inclined to classify this as a debug problem rather than middle-end. Does
that seem reasonable?
Steve, could you see if this patch fixes the failure on PA and Itanium?
-cary
--
ccoutant at gcc dot gnu
1 - 100 of 109 matches
Mail list logo
