Hi everybody,
Im interested whether there is gcc support (at the RTL
level) after unrolling which allows to disambiguate
memory accesses present in RTL constructs (specially
among memory accesses generated due to unrolling) for
machines that do not support indexed addressing modes.
I am aware of
2008/3/31 Tom Tromey <[EMAIL PROTECTED]>:
> > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
>
> Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
> Joe> who has just enough technical knowledge to derail conversation.
>
> I think that if we've reached the point where an
Hi,
I am facing the same problem as mentioned by you. Is there any solution
or workaround? Please guide.
I have successfully built the mingw native compiler with the following
sources,
mingw-runtime-3.12
w32api-3.9
binutils-2.17.50-20060824-1-src
gcc-3.4.5-20060117-1
I want to build the mingw c
On Tue, 1 Apr 2008, Hasjim Williams wrote:
> > That illustrates the sort of thing that needs changing to implement
> > unwind
> > support for a new coprocessor. Obviously you need to get the unwind
> > specification in the official ARM EABI documents first before
> > implementing
> > it in GCC
"Ian Lance Taylor" <[EMAIL PROTECTED]> writes:
"Chad Attermann" <[EMAIL PROTECTED]> writes:
I can not confirm that it was the i386 code included in the gcc build
but it appears that way from the signature. Is this perhaps a problem
with the way that gcc 3.4.3 shipping with Solaris 10 x86 wa
...uz jsem podepsala, poslete to taky dal... www.nechciradar.cz
Lucka
- Original Message -
From: "Jan Dvorak" <[EMAIL PROTECTED]>
Sent: Monday, March 31, 2008 11:04 AM
Subject: Fwd: On-line petice proti radaru
Původní zpráva
Od: Eva Vaňková
Komu: Evička Š.;
> That only covers call-preserved registers. Testing call-clobbered
> registers is harder (but normally unwind information won't be generated
> for them, so they matter less); for iWMMXt I tried testing using
> -fcall-saved-wr0 -fcall-saved-wr1 ... but found that
> CONDITIONAL_REGISTER_USAGE overr
Diego Novillo wrote on :
> 2008/3/31 Tom Tromey <[EMAIL PROTECTED]>:
> > > > > > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
> >
> > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking
> > troll,
> > There's no benefit that I can see to putting up with this kind of bad
> >
"Chad Attermann" <[EMAIL PROTECTED]> writes:
Running at least i486 code would make sense on AMD Opteron processors. I
am shocked that the gcc version shipped by Sun Microsystems would be
compiled for i386. I compiled my own version of gcc 4.2.2 n the same
platform and it too appears to have
Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
Joe> who has just enough technical knowledge to derail conversation.
I think that if we've reached the point where an SC member feels the
need to post disclaimers about someone's posts, then that someone
ought to simply be
Hi,
On Mon, 31 Mar 2008, Tom Tromey wrote:
> > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
>
> Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
> Joe> who has just enough technical knowledge to derail conversation.
>
> I think that if we've reached the point where
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit
Dave> of a harsh way to describe a hapless victim of mental illness to
Dave> me.
In my message, I purposely described his behavior, not him. I don't
know him, I wouldn't p
Tom Tromey wrote on 01 April 2008 15:34:
> > > > > > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>
> Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit
> Dave> of a harsh way to describe a hapless victim of mental illness to
> Dave> me.
>
> In my message, I purposely des
> I checked in the change to gcc-4.3/changes.html and added a comment
> to the PR about other changes we should make to the section about
> decimal floating-point support in the GCC Manual. Thanks for the
> reminder, I had planned to do this long ago and then forgot all
> about it.
Thanks, appre
David Daney wrote on 01 April 2008 17:10:
> Does the intent really matter?
Well, it certainly has a bearing on how amenable to modification under
social pressure his behaviour might or might not be.
cheers,
DaveK
--
Can't think of a witty .sigline today
I am now testing a patch for this issue.
--
Joseph S. Myers
[EMAIL PROTECTED]
Dave Korn wrote:
David Daney wrote on 01 April 2008 17:10:
Does the intent really matter?
Well, it certainly has a bearing on how amenable to modification under
social pressure his behaviour might or might not be.
We have determined this empirically over the course of many months, the
Dave Korn wrote:
Tom Tromey wrote on 01 April 2008 15:34:
"Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit
Dave> of a harsh way to describe a hapless victim of mental illness to
Dave> me.
In my message, I purposely descri
we use the following logic:
... :
@for f in $? $@; do test -f $$f || exit 0; done; \
echo Touching [EMAIL PROTECTED]; \
touch $@
We have the following chain of dependencies:
gcc/configure: gcc/configure.ac
gcc/cstamp-h.in: gcc/configure.ac
gcc/config.in: gcc/cstamp-h.in
Hi David,
I added gcc mailing list.
H.J.
On Tue, Apr 1, 2008 at 10:53 AM, Dave Kreitzer
<[EMAIL PROTECTED]> wrote:
>
> > I think we should align _Decimal64 and _Decimal128 to their natural
> > alignments when passing a function. The same should apply to x86-64
> > when they are passed on stack
.o] Error 1
[ gdb ] r
GNU C (GCC) version 4.4.0 20080401 (experimental) [trunk revision 133793]
(m32c-elf)
compiled by GNU C version 4.3.0 20071207 (experimental) [trunk revision
130693], GMP version 4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-
emangle_name_to_style':
> ../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in
> build2_stat, at tree.c:3107
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
ttp://gcc.gnu.org/bugs.html> for instructions.
make: *** [cplus-dem.o] Error 1
[ gdb ] r
GNU C (GCC) version 4.4.0 20080401 (experimental) [trunk revision
133793] (m32c-elf)
compiled by GNU C version 4.3.0 20071207 (experimental)
[trunk revision 130693], GMP version 4.2.2, MPFR v
#0 fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c", line=3107,
function=0x87f2e43 "build2_stat") at ../../gcc/gcc/diagnostic.c:654
#1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7db5dd0, arg0=0xb7b19340,
arg1=0xb7a7d5e4)
at ../../gcc/gcc/tree.c:3107
#2 0x0822501e in fold_binar
On Tue, Apr 01, 2008 at 05:09:32PM +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 31 Mar 2008, Tom Tromey wrote:
>
> > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
> >
> > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
> > Joe> who has just enough technical knowled
Hello,
I found a memory leak on regcomp function - gcc-4.4.2 (i used Memory validator
tool to confirm it) .
On regcomp this line if (re_compile_fastmap (preg) == -2)
is the cause to the memory leak (it calls to re_compile_fastmap function that
allocates memory that is not release)
The code o
Swapna Pawar wrote:
configure:4542: checking for correct version of mpfr.h
configure:4573: i386-pc-mingw32msvc-gcc -o conftest.exe -O2
-I/home/manjunathm1/gmp/prefix/include
-I/home/manjunathm1/mpfr/prefix/include conftest.c -L/h
ome/manjunathm1/gmp/prefix/lib -L/home/manjunathm1/mpfr/prefix/l
27 matches
Mail list logo
