Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
>libmudflap needs to know the know the name of the entry point symbol,
>to enable one of its heuristics. See the ENTRY_POINT area in
>configure.ac, and update it for your own runtime. Be aware that
>libmduflap's libc-wrapper functions may need porting
On Jun 4, 2007, at 12:09 AM, Deepen Mantri wrote:
Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
libmudflap needs to know the know the name of the entry point symbol,
to enable one of its heuristics. See the ENTRY_POINT area in
configure.ac, and update it for your own runtime. Be aware that
l
Eric Christopher wrote:
>Perhaps, but you want to build it as part of your target libraries
>using --enable-libmudflap. When you build it after you're not using
>host and target and therefore it's being built for your machine (i386-
>redhat-linux).
Thanks for the reply.
I did remove --enable-
Hi,
Now, i wanna generate a switch table just like ARM tbb instruction.
The switch table should be located at .rdata section, so I should use
.L3-.L8_1, but not .L3-.L8.
How could i implement this? Any target macro can do it?
Please look at the following code fragment. (.L3-.L8_1)/2 is what i wa
Thanks for the reply.
I did remove --enable-libmudflap option from the build script and
followed following steps for libmudflap configuration:
Why on earth would you do this?
I created a separate build folder and from there
a) [libmudflap source path]/configure --target=sh-elf --prefix=[M
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
> If I can reproduce it I'll see if I can find some webspace.
If you mail me a SSH public key you can also put it on
git.infradead.org.
--
dwmw2
David Woodhouse wrote:
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
If I can reproduce it I'll see if I can find some webspace.
If you mail me a SSH public key you can also put it on
git.infradead.org.
Come visit git.infradead.org and its GCC development fork.
--
// Bernardo
> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
> > encounte
Eric Christopher wrote:
>No, at the toplevel (just like your normal build of the compiler and
>target libraries):
>configure --enable-languages=c --disable-multilib --enable-libmudflap
>--target=sh-elf ; make -j8 all-gcc all-target
>and you'll get this:
>configure: error: none of the known s
Hi -
> >which means that libmudflap needs to be ported to sh-elf.
>
> How should I start the porting? Do you have any document related to such
> porting? [...]
First thing is to get past that autoconf error. Check your linker
script for the default entry point symbol's name, and give it to
libm
phew, a few of the cygwin failures show up like this:
Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
(timeout = 300)
spawn /usr/
On Mon, 2007-06-04 05:17:17 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
> David Woodhouse wrote:
> > On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
> > > If I can reproduce it I'll see if I can find some webspace.
> >
> > If you mail me a SSH public key you can also put it on
>
On 6/1/07 3:45 PM, Seema S. Ravandale wrote:
> int b; //local variable
>
> array[b] = c
>
> will be translated to
> b.0 = b;
> array[b.0] = c
>
> anything to do with SSA?
Is 'b' an addressable variable or is it a regular local stack variable?
If the latter, then this is a buglet in the convers
On 6/4/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml
-Original Message-
From: "Timothy C Prince" <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
Date: Mon, 04 Jun 2007 16:20:34 +
In the message
http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html
Dave Korn wrote:
So, am I correct to believe that we need to use plain 'inline' for c99 after
gcc
On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
> On Sun, 3 Jun 2007, Ben Elliston wrote:
> >> Are they mentioned in any gcc changes.html?
> > No, they're not. They probably should be.
>
> Do you think we could talk the submitters/maintainers into donating a
> patch? :-)
Support
On Mon, Jun 04, 2007 at 01:23:16PM -0700, Janis Johnson wrote:
> On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
> > On Sun, 3 Jun 2007, Ben Elliston wrote:
> > >> Are they mentioned in any gcc changes.html?
> > > No, they're not. They probably should be.
> >
> > Do you think we c
Snapshot gcc-4.1-20070604 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"Timothy C Prince" <[EMAIL PROTECTED]> writes:
> So, am I correct to believe that we need to use plain 'inline' for c99
> after gcc 4.4, and 'extern inline' before that? That is, I think I need to
> write a test that looks like...
>
>
> #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MIN
> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 31, 2007 9:05 AM
> To: Joseph S. Myers
> Cc: Fu, Chao-Ying; Richard Henderson; GCC
> Subject: Re: Fixed-point branch?
>
>
> Joseph S. Myers wrote:
>
> > I haven't examined it. When the branch main
[EMAIL PROTECTED] wrote:
phew, a few of the cygwin failures show up like this:
Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
(
Jan-Benedict Glaw wrote:
Come visit git.infradead.org and its GCC development fork.
*cough* No reason to fork. At least I'm just too used to GIT these
days and like it quite a lot, that's why I work on getting the
toolchain repos converted (and kept up-to-date!) somewhere as GIT
repos.
Err.
Ian Romanick wrote:
Over the years, I have encountered *may* bugs like this. One way to
help combat them is to have a policy that empty loop parts are
documented with a comment of /* empty */. It makes it explicit to
people reading the code that the missing parts are intentionally
missing. It
Can someone explain why libjava *must* commit binary files to the
repository? A merge of trunk to the fortran-experiments branch
generated 70 conflicts that I need to resolve. This is a complete
waste of time that would have been spent towards cutting a diff
of the branch against trunk for patch
24 matches
Mail list logo
