The program goto endless loops when run erase() in a for loop,as fallows:
#include
#include
std::map mymap;
int main() {
mymap[2] =3 ;
mymap[1] = 4;
printf("**test map.erase*\n");
std::map::iterator it;
it = mymap.begin();
for (; it != mymap.end() ; it++) {
mymap.erase
--- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
(In reply to comment #1)
> The interesting thing is that data-ref analysis sees 128bit alignment but
> the vectorizer still produces
> vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
> D.2564_12 = *D.2563_11;
>
--- Comment #54 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:03 ---
(In reply to comment #51)
For 4.4, the designers held two wrong assumptions:
1) the incoming stack is always aligned on -mincoming-stack-boundary (wrong for
functions called from assembler or
--- Comment #55 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:07 ---
"If we assume incoming stack is 4byte aligned, we have to realign stack for
every function due to #2, which isn't acceptable."
No, you don't. All you have to do is to allocate the stack frame
Compile following code with options -Os -march=armv5te -mthumb,
class A
{
public:
int ah;
unsigned field : 2;
};
void foo(A* p)
{
p->ah = 1;
p->field = 1;
}
We can get:
mov r3, #1 // A
str r3, [r0]
ldrbr3, [r0, #4]
mov r2, #3
--- Comment #1 from carrot at google dot com 2009-09-27 09:13 ---
Created an attachment (id=18662)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18662&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41481
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-27 09:25 ---
The new attribute "basetype_mode" (see
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
provide a way to solve this, as it makes sure that it is associated to the base
type, instead of the curr
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-27 09:28 ---
(In reply to comment #7)
> The new attribute "basetype_mode" (see
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could
> provide a way to solve this, as it makes sure that it is associated to the
--- Comment #56 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:36 ---
As for this "old code that assumes 16-byte alignment": this is wrong code
generated by old versions of gcc. It only works as long as it is called from
other gcc >= 3 code (call it from gcc < 3,
--- Comment #5 from rguenther at suse dot de 2009-09-27 09:43 ---
Subject: Re: vector loads are unnecessarily
split into high and low loads
On Sun, 27 Sep 2009, irar at il dot ibm dot com wrote:
> --- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
> (In repl
--- Comment #9 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:51 ---
The common linker definitions were made to exactly to make code like this work
and share the array between two object.
So if you think it is undefined, don't support it (make -fno-common defaul
--- Comment #6 from irar at il dot ibm dot com 2009-09-27 09:56 ---
(In reply to comment #5)
> >
> > "aligned to" refers to the offset misalignment and not to the misalignment
> > of
> > base.
> Hmm, I believe it refers to base + offset + constant offset.
tree-data-refs.h:
/* Alignme
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-27 09:59 ---
Closed this bug. As it is solved. At least provide testcase doesn't ice with
native gcc for w64 anymore.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 09:59 ---
I also see it on *-apple-darwin9 gcc 4.2.4, 4.3.4, 4.4.1, and trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-27 10:03 ---
I tested given scenario and g++ could find the headers in Stage 2 (using msys
make). So this seems to be a configure/environment setup issue, if it still
exists for you.
--
ktietz at gcc dot gnu dot org changed:
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 10:04 ---
> Regarding the intent(out) issue. I will defer to others.
If the issue is valid, this a [4.3/4.4/4.5 Regression]. On *-apple-darwin9 GCC
4.2.4 gives:
[ibook-dhum] f90/bug% gfc42 pr41479.f90
[ibook-dhum] f90/bug% a
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2009-09-27 10:10
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAI
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-27 10:28 ---
GCC 4.2 is no longer maintained. It works for me with GCC 4.2.4 on i?86-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-27 10:36 ---
Confirmed on i?86-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC build
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 11:44 ---
Running valgrind I got:
--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib:
--77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes
--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/l
--- Comment #6 from dominiq at lps dot ens dot fr 2009-09-27 11:45 ---
> Works for me on FreeBSD.
Is anyone understanding why?
valgrind gives:
==77290== Invalid free() / delete / delete[]
==77290==at 0x167FB: free (vg_replace_malloc.c:323)
==77290==by 0x2EAE: MAIN__ (in ./pr41
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-27 12:27 ---
Target issue. r151907 is not the revision that caused this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-27 12:32 ---
Simple googling leads me to
http://wiki.dwarfstd.org/index.php?title=Apple's_"Lazy"_DWARF_Scheme
which in turn makes me think a recent libtool update may be the
real "cause" of this, making this a libtool bug, not
--- Comment #34 from ubizjak at gmail dot com 2009-09-27 12:35 ---
It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is added
to BOOT_CFLAGS. If tree.o is substituted with the one from the build without
BOOT_CFLAGS, gcc is again able to compile hello.c without crashi
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-09-27 13:12 ---
Different libc, different behavior on double-free
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-09-27 13:59 ---
Fixed
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #35 from ubizjak at gmail dot com 2009-09-27 14:29 ---
Bingo!
It is build_function_type_list_1 from tree.c that makes problems:
static tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
This probably makes alpha specific bootstrap failure duplica
--- Comment #1 from schwab at gcc dot gnu dot org 2009-09-27 15:27 ---
Subject: Bug 41476
Author: schwab
Date: Sun Sep 27 15:27:08 2009
New Revision: 152220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152220
Log:
PR c/41476
* c-typeck.c (build_conditional_expr
--- Comment #2 from schwab at linux-m68k dot org 2009-09-27 15:44 ---
Fixed.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from danglin at gcc dot gnu dot org 2009-09-27 15:54 ---
(gdb) p *cfun->eh->region_array
$5 = {base = {num = 1, alloc = 4, vec = {0x0}}}
(gdb) p lp
$6 = (eh_landing_pad) 0x0
(gdb) p debug_rtx (insn)
(call_insn 6 5 8 3 /home/dave/gcc-4.5/gcc/gcc/testsuite/gcc.dg/20021014-1.
--- Comment #36 from ubizjak at gmail dot com 2009-09-27 16:11 ---
This band-aid patch enables bootstrap with patch from comment #22 reverted to
proceed a bit further:
Index: tree.c
===
--- tree.c (revision 152218)
+++
--- Comment #27 from ubizjak at gmail dot com 2009-09-27 16:12 ---
Blocker, blocks bootstrap on alpha, see PR41395.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from jv244 at cam dot ac dot uk 2009-09-27 17:03 ---
target independent bug.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #6 from kargl at gcc dot gnu dot org 2009-09-27 17:20 ---
(In reply to comment #0)
> The example below shows that besides the fact that declared as INTENT(OUT) the
> component 'n' is not initialized per default the second time.
It's not initialized on the first call to INIT(
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-09-27 17:30
---
Created an attachment (id=18663)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18663&action=view)
Patch to cfgrtl.c commit_one_edge_insertion()
The problem is in cfgrtl.c function commit_one_edge_inse
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- Comment #7 from kargl at gcc dot gnu dot org 2009-09-27 18:18 ---
Checking the 4.2 branch and trans-expr.c in trunk, it appears that
this chunk of code in gfc_conv_function_call() has gone missing.
2148 /* If an INTENT(OUT) dummy of derived type has a default
2149initializer, it
ols --with-mpfr=/opt/devtools
--with-ppl=/opt/devtools --with-cloog=/opt/devtools
--enable-version-specific-runtime-libs --disable-rpath --disable-win32-registry
--enable-languages=c,c++,fortran --disable-bootstrap --target=arm-elf
Thread model: single
gcc version 4.4.2 20090927 (prerelease) (GC
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-09-27 18:51
---
Uros, did you fix the alpha backend vaarg gimplification yet?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.5.0
http://gcc
In the following code:
void h(void);
static void g()
{
h();
}
static void (*f)(void) = g;
void k(void)
{
f();
}
It is trivial to see that 'f' cannot change and thus the statement 'f();' can
be compiled as a direct call or jump. gcc however emits an indirect jump on
x86_64:
0: 48
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-09-27 19:15
---
Same for AVR target. Numerous example (though not same testcase)
/home/andy/gccsvn/gcc/testsuite/gcc.c-torture/compile/pr38123.c:13:1: internal
compiler error: in mem_loc_descriptor, at dwarf2out.c:11292
Wa
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-09-27
19:30 ---
Subject: Re: [4.5 Regression] ICE in
get_eh_region_and_lp_from_rtx at except.c:1692
I'm testing the attached target fix.
Dave
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-27 19:39 ---
Try providing a real prototype for g:
static void g(void)
{
h();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41483
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-09-27 20:27 ---
static void g()
is weird in C, it really means g(...) .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
SSE4.1 introduced zero-extending and sign-extending loads, such as
pmovzxbd (%rax), %mm0
which takes four bytes from (%rax), zero-extends them to four 32-bit dwords,
and put them into %mm0. However, GCC's intrinsics support only the form
pmovzxbd %mm1, %mm0
which take the lower 32 bits
--- Comment #29 from ubizjak at gmail dot com 2009-09-27 21:09 ---
(In reply to comment #28)
> Uros, did you fix the alpha backend vaarg gimplification yet?
Hm, I'm not aware of anything broken with gimplification (judging by the fact
that it worked until recent changes)... The only pat
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-27 21:19 ---
As per private communication, you can't do it this way. You'd loose the
effect of the inserted insn, as the jump jumps over it. You need to search
backward from the jump to the cc0 setter and insert it in front of tha
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Component|c |target
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c
-B/test/gnu/gcc/
objdir/hppa64-hp-hpux11.11/./libgomp/
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgomp -I/test/gnu/gcc/gcc/libgomp/testsuite/.. -fme
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-28
01:18 ---
(In reply to comment #6)
this issue was introduced by the changes in 151901.
(I can obtain a successful bootstrap by reverting the changes of 151815, the
dsymutil fail is then present, not present at 1
--- Comment #2 from lifelong830114 at gmail dot com 2009-09-28 01:39
---
The error occured on cygwin not linux, and I referenced
http://gcc.gnu.org/gcc-4.2/buildstat.html
--
lifelong830114 at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from hjl dot tools at gmail dot com 2009-09-28 02:22 ---
Hardware went bad.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Stat
--- Comment #31 from davek at gcc dot gnu dot org 2009-09-28 05:48 ---
(In reply to comment #30)
> I still get
>
> /bin/sh ./libtool --tag CC --mode=link
> /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/
> -B/usr/loc
--- Comment #3 from avi at argo dot co dot il 2009-09-28 05:51 ---
Of course, sorry about the noise. Marking as invalid.
--
avi at argo dot co dot il changed:
What|Removed |Added
55 matches
Mail list logo
