--- 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
--- 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 #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 #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 #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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Component|c |target
--- 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
--- 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
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 #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
--- 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 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 #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
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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.5.0
http://gcc
--- 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
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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- 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
--- 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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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;
>
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
55 matches
Mail list logo
