Hi All,
For anyone interested, the LLVM project just released LLVM 2.8. Among other
things it includes major updates to the DragonEgg GCC plugin. Other major
improvements include a new debugger (LLDB), a new C++ standard library
(libc++), and Clang C++ support being feature complete and very
I need a confirmation of acceptance to transfer of US$ 21,300,000.00 to you
Eu preciso de uma confirmação da aceitação de transferência de EUA $
21,300,000.00 para você
> DJ Delorie writes:
> > JUMP_ALIGN_MAX_SKIP
> > LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
> > LOOP_ALIGN_MAX_SKIP
> > LABEL_ALIGN_MAX_SKIP
> >
> > None of these macros take any parameters, but for optimal performance
> > on RX, it's key to match the max_skip with the size of the following
> > opcod
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson wrote:
> On 10/04/2010 04:24 PM, H.J. Lu wrote:
>> As I remembered, -mforce-drap exposed issues with register allocator.
>> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
>> it. I don't see why it can't be moved to gen
On Tue, Oct 5, 2010 at 8:57 AM, Richard Henderson wrote:
> On 10/04/2010 04:24 PM, H.J. Lu wrote:
>> As I remembered, -mforce-drap exposed issues with register allocator.
>> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
>> it. I don't see why it can't be moved to gen
Snapshot gcc-4.4-20101005 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101005/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Oct 05, 2010 at 11:40:11PM +0200, Joakim Tjernlund wrote:
> yes, but this could be a new PIC mode that uses a new better
> PIC mode for everything. Especially one that doesn't require each function
> to calculate the GOT address in the function prologue(why is that so?)
The ppc32 ABI is ol
On 10/05/2010 02:40 PM, Joakim Tjernlund wrote:
> Especially one that doesn't require each function
> to calculate the GOT address in the function prologue(why is that so?)
Because PIC code can be called from non-PIC code and because
the non-PIC code does not load the GOT address.
Avoiding re-com
> So, I can bootstrap and regtested this on i686-linux, x86_64-linux, and
> x86_64-darwin. Other platforms, I don't have access to or have trouble
> bootstrapping at all (mingw, I'm looking at you!). My question, thus is:
> what testing is required for this?
You must at least build a cross-compile
Another question cropping up for me is: what are the testing requirements for a
patch of that nature? The final list of files touched in gcc/config/ is:
M alpha/linux.h
M alpha/alpha.h
M alpha/osf5.h
M alpha/netbsd.h
M frv/frv.h
M spu/spu-protos.h
M spu/s
Richard Henderson wrote on 2010/10/05 23:12:19:
>
> On 10/05/2010 01:55 PM, Joakim Tjernlund wrote:
> > I don't do x86 or alpha so let me ask: If you run the code on an address
> > != link address, will it do the right thing?
>
> Yes of course. It wouldn't be -fpic code otherwise.
Just making su
On 10/05/2010 01:55 PM, Joakim Tjernlund wrote:
> I don't do x86 or alpha so let me ask: If you run the code on an address
> != link address, will it do the right thing?
Yes of course. It wouldn't be -fpic code otherwise.
> I tested the #pragma/no #pragma on PPC and the resulting code
> was the
Richard Henderson wrote on 2010/10/05 20:56:55:
>
> On 10/05/2010 06:54 AM, Joakim Tjernlund wrote:
> > Ian Lance Taylor wrote on 2010/10/05 15:47:38:
> >> Joakim Tjernlund writes:
> >>> While doing relocation work on u-boot I often whish for strings/const data
> >>> to be accessible through %pc
On 10/05/2010 06:54 AM, Joakim Tjernlund wrote:
> Ian Lance Taylor wrote on 2010/10/05 15:47:38:
>> Joakim Tjernlund writes:
>>> While doing relocation work on u-boot I often whish for strings/const data
>>> to be accessible through %pc relative address rather than and ABS address
>>> or through
On 10/04/2010 04:24 PM, H.J. Lu wrote:
> As I remembered, -mforce-drap exposed issues with register allocator.
> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
> it. I don't see why it can't be moved to generic. It may expose problems
> for other targets.
I doubt very
Ian Lance Taylor writes:
> Index: configure.ac
> ===
> --- configure.ac (revision 164990)
> +++ configure.ac (working copy)
> @@ -56,15 +56,22 @@ fi
> AC_HEADER_TIME
> ACX_HEADER_STRING
>
> +# Running AC_CHECK_HEADERS i
Jerry Quinn writes:
> This is on Debian testing. I have a clean tree r164966. I configure as
> follows:
>
> ../../gcc-in-cxx/configure --enable-build-with-cxx
> --enable-languages=c,c++ --with-gold
>
>
> I just run make and it fails as below. Any ideas what might be wrong?
It's a problem with
Ian Lance Taylor wrote on 2010/10/05 15:47:38:
>
> Joakim Tjernlund writes:
>
> > While doing relocation work on u-boot I often whish for strings/const data
> > to be accessible through %pc relative address rather than and ABS address
> > or through GOT. Has this feature ever been considered by g
Joakim Tjernlund writes:
> While doing relocation work on u-boot I often whish for strings/const data
> to be accessible through %pc relative address rather than and ABS address
> or through GOT. Has this feature ever been considered by gcc?
The feature can only be supported on processors which
While doing relocation work on u-boot I often whish for strings/const data
to be accessible through %pc relative address rather than and ABS address
or through GOT. Has this feature ever been considered by gcc?
Jocke
This is on Debian testing. I have a clean tree r164966. I configure as
follows:
../../gcc-in-cxx/configure --enable-build-with-cxx
--enable-languages=c,c++ --with-gold
I just run make and it fails as below. Any ideas what might be wrong?
Thanks,
Jerry
Configuring stage 1 in ./libcpp
config
21 matches
Mail list logo
