> The most visible ongoing effort is the conversion from target macros
> to target hooks (which is incomplete). The goal was to allow "hot
> swapping" of backends. This is still the most obvious, most complete,
> and least unappealing (from a technical POV) approach IMHO. But Kaveh
> showed at on
On Wed, 18 Mar 2009, Ralf Wildenhues wrote:
> I tried to send the message below to the list, without subscribing. It
> was thus rejected. I then tried to send it to you off-list, which your
> mail server doesn't like either, due to unblock.secureserver.net. Would
> you please forward it for me?
On Wed, 18 Mar 2009, Joern Rennecke wrote:
> It would be easier to implement if C++ with virtual member functions
> would be allowed for the target vector. Then, where this is not already
> readily available, we can tweak the optimizers and/or the code so that
> we obtain de-virtualization and in
Quoting Steven Bosscher :
The most visible ongoing effort is the conversion from target macros
to target hooks (which is incomplete). The goal was to allow "hot
swapping" of backends. This is still the most obvious, most complete,
Yes, I initially thought about this one.
and least unappealin
Steven Bosscher wrote:
On Wed, Mar 18, 2009 at 8:17 PM, Albert Cohen wrote:
Antoniu Pop wrote:
(...)
The multiple backends compilation is not directly related, so you
should use a separate branch. It makes sense to go in that direction.
Indeed.
Work has been going on for years in this direc
On Wed, Mar 18, 2009 at 8:17 PM, Albert Cohen wrote:
> Antoniu Pop wrote:
> (...)
>>
>> The multiple backends compilation is not directly related, so you
>> should use a separate branch. It makes sense to go in that direction.
>
> Indeed.
Work has been going on for years in this direction, but it
Ralf Wildenhues wrote:
> * Andrew Haley wrote on Sat, Mar 14, 2009 at 11:05:03AM CET:
>> Ralf Wildenhues wrote:
>>> * Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
I have a patch (accompanying those other ones on gcc-paches) to fix
; Warnings handled by ecj.
-;
Snapshot gcc-4.2-20090318 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090318/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
* Andrew Haley wrote on Sat, Mar 14, 2009 at 11:05:03AM CET:
> Ralf Wildenhues wrote:
> > * Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
> >> I have a patch (accompanying those other ones on gcc-paches) to fix
> >>
> >> ; Warnings handled by ecj.
> >> -; FIXME: document them
> >>
* Kaveh Ghazi wrote on Wed, Mar 18, 2009 at 06:17:46PM CET:
> If you would like to help out by testing MPC on your favorite platforms
> (especially those from the GCC primary/secondary platform list) then please
> download the latest MPC tarball from the above LORIA link and send your
> results to
Antoniu Pop wrote on 18/03/2009 18:55:52:
> > I'd like to explore distributing threads across a heterogenous NUMA
> > architecture. I.e. input/output data would have to be transferred
> > explicitly, and the compiler would have to have more than one backend.
>
> I'm currently working on somethi
Antoniu Pop wrote:
(...)
The multiple backends compilation is not directly related, so you
should use a separate branch. It makes sense to go in that direction.
Indeed.
There has been some work in the area, using different approaches. I've
been involved in one attempt, for the Cell, with Cupe
On Mon, Mar 16, 2009 at 07:16:33PM +0100, Steven Bosscher wrote:
> On Mon, Mar 16, 2009 at 7:06 PM, Toon Moene wrote:
> > [ Perhaps we need a somewhat larger audience for this one, as it isn't a
> > gfortran specific issue (despite the COMMONs). ]
> >
> > The reporter of this problem (perhaps it'
I'm hoping to integrate GCC with the complex math library MPC. You can read
the gory details here:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00671.html
To ensure widespread portability, the MPC developers are keeping track of
the platforms where the latest MPC works here:
http://www.loria.fr/
> I'd like to explore distributing threads across a heterogenous NUMA
> architecture. I.e. input/output data would have to be transferred
> explicitly, and the compiler would have to have more than one backend.
I'm currently working on something that looks quite similar, in the
"streamization" br
I'd like to explore distributing threads across a heterogenous NUMA
architecture. I.e. input/output data would have to be transferred
explicitly, and the compiler would have to have more than one backend.
Would such work be appropriate for an existing branch, or should I better
work on my own br
Vladimir thanks for help!
With respect to your answer I would like to point to you a possible way to
solve the scheduling problem
(which I think wont be too difficult to be implemented in genautomata).
To explain it, I will make use of the “move insn” example pointed in the
previous email.
17 matches
Mail list logo
