I had a problem that got solved in an ugly way. I think gcc ought
to provide a few ways to make a nicer solution.
There was an array of structs roughly like so:
struct{int w;float x;char y[4];short z[2];}foo[512][4];
The types within the struct are 4 bytes each; I don't actually
remember anythin
On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote:
> On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote:
> > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> > >
> > > Intuitively, this is wrong because this let's the program take a step
> > > the abstract machine wouldn
On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote:
> On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> >
> > Intuitively, this is wrong because this let's the program take a step
> > the abstract machine wouldn't do. This is different to the sequential
> > code that Peter posted becau
On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote:
> On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote:
> > > > On Thu, 2014-02-06 at 14:11 -0800
- Original Message -
> From: "Rafael Espíndola"
> To: "Jan Hubicka"
> Cc: "Renato Golin" , "gcc" , "Hal
> Finkel"
> Sent: Tuesday, February 11, 2014 3:38:40 PM
> Subject: Re: Fwd: LLVM collaboration?
>
> > My reading of bfd/plugin.c is that it basically walks the directory
> > and look
> My reading of bfd/plugin.c is that it basically walks the directory and looks
> for first plugin that returns OK for onload. (that is always the case for
> GCC/LLVM plugins). So if I instlal GCC and llvm plugin there it will
> depend who will end up being first and only that plugin will be used.
> >> Since both toolchains do the magic, binutils has no incentive to
> >> create any automatic detection of objects.
>
> It is mostly a historical decision. At the time the design was for the
> plugin to be matched to the compiler, and so the compiler could pass
> that information down to the lin
Hello,
> I'd like to hardcode conditional execution of emit_move_insn based on the
> predicate checking that the address in the destination argument is non-NULL.
> The platform supports conditional execution, but doesn't have explicitly
> defined conditional moves (target=tic6x).
> I have alread
> On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
> > On 11 February 2014 12:28, Renato Golin wrote:
> > > Now copying Rafael, which can give us some more insight on the LLVM LTO
> > > side.
> >
> > Thanks.
> >
> > > On 11 February 2014 09:55, Renato Golin wrote:
> > >> Hi Jan,
> > >>
>
Hi Marek,
On Sun, 2014-02-02 23:59:16 +0100, Jan-Benedict Glaw wrote:
> Hi Marek,
>
> it seems your patch produced some fallout for
>
> avr: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=111296
> spu-elf: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=111360
Cu
Hi Folks,
First of all, I'd like to thank everyone for their great responses and
heart warming encouragement for such an enterprise. This will be my
last email about this subject on these lists, so I'd like to just let
everyone know what (and where) I'll be heading next with this topic.
Feel free
On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
> On 11 February 2014 12:28, Renato Golin wrote:
> > Now copying Rafael, which can give us some more insight on the LLVM LTO
> > side.
>
> Thanks.
>
> > On 11 February 2014 09:55, Renato Golin wrote:
> >> Hi Jan,
> >>
> >> I think this is a
On 11 February 2014 12:28, Renato Golin wrote:
> Now copying Rafael, which can give us some more insight on the LLVM LTO side.
Thanks.
> On 11 February 2014 09:55, Renato Golin wrote:
>> Hi Jan,
>>
>> I think this is a very good example where we could all collaborate
>> (including binutils).
I
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
cheers,
--renato
On 11 February 2014 09:55, Renato Golin wrote:
> Hi Jan,
>
> I think this is a very good example where we could all collaborate
> (including binutils).
>
> I'll leave your reply intact, so that Chandle
Hello all.
I have previously succeeded in getting configure to
work for gcc 3.4.6. Unfortunately gcc 3.4.6 is too
buggy to use and needs to wait for Dave Pitts or
someone to fix.
gcc 3.2.3 has no known bugs for the i370 target,
but it has not been done using "configure".
I am now trying to get
On 11 February 2014 16:00, Jan Hubicka wrote:
> I basically think that binutils should have a way for installed compiler to
> register a plugin and load all plugins by default (or perhaps for performance
> or upon detecking an compatible LTO object file in some way, perhaps also by
> information g
On Tuesday 11 February 2014 09:30 PM, Jan Hubicka wrote:
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more c
>
>
>
>
> On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
> >Hi Jan,
> >
> >I think this is a very good example where we could all collaborate
> >(including binutils).
> >
> >I'll leave your reply intact, so that Chandler (CC'd) can get a bit
> >more context. I'm copying him because h
On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote:
> On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> >
> > Intuitively, this is wrong because this let's the program take a step
> > the abstract machine wouldn't do. This is different to the sequential
> > code that Peter poste
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
m
> Matthew Fortune writes:
> > I'm still interested in how successfully the MIPS backend is managing
> > to avoid floating point but I am also convinced there are bugs in
> > ld.so entry points for MIPS.
>
> It uses the standard mechanism to avoid it, which is marking uses of FP
> registers for in
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
more contact with LTO than I had.
If I got it right, LTO today:
Matthew Fortune writes:
> I'm still interested in how successfully the MIPS backend is managing to
> avoid floating point but I am also convinced there are bugs in ld.so
> entry points for MIPS.
It uses the standard mechanism to avoid it, which is marking uses of
FP registers for integer moves, l
23 matches
Mail list logo
