> I am just starting to think about adding OpenCL support into future versions
> of
> GCC, as it looks like a useful way of programming highly parallel type
> systems,
> particularly with hetrogeneous processors. At this point, I am wondering what
> kind of interest people have in working toget
The GNU Compiler Collection version 4.3.3 has been released.
GCC 4.3.3 is a bug-fix release containing fixes for regressions and
serious bugs in GCC 4.3.2. This release is available from the
FTP servers listed at:
http://www.gnu.org/order/ftp.html
Please do not contact me directly regarding
Hello everyone,
The wait is finally over!
The problem statement of BOTS: AI programming challenge event of Troika'09 -
The annual technical fest organised by IEEE, Delhi College of Engineering
(DCE) has been released.
Register yourself for the event and download the Problem Statement from:
www.
Hi,
On the C side there's a bunch of gcc.dg/pch failures on mipsel-unknown-linux-gnu
on trunk 143818:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html
FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors)
FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pc
Paolo Bonzini wrote:
I am just starting to think about adding OpenCL support into future versions of
GCC, as it looks like a useful way of programming highly parallel type systems,
particularly with hetrogeneous processors. At this point, I am wondering what
kind of interest people have in work
Laurent GUERBY writes:
> Hi,
>
> On the C side there's a bunch of gcc.dg/pch failures on
> mipsel-unknown-linux-gnu
> on trunk 143818:
>
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html
>
> FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors)
> FAIL: gcc.dg/pch/common-1.c
On Feb 1, 2009, at 5:41 AM, Toon Moene wrote:
I am just starting to think about adding OpenCL support into
future versions of
GCC, as it looks like a useful way of programming highly parallel
type systems,
particularly with hetrogeneous processors. At this point, I am
wondering what
kind of
> Although the OpenCL infrastructure doesn't confine itself to it, this
> compute-on-the-graphic-processor type of parallellism mostly concerns
> itself with "let's do the FFT (or DGEMM) really fast on this processor
> and then return to the user".
Not really, it's not about FFT/DGEMM only -- the
On Sat, Jan 31, 2009 at 17:49, Taras Glek wrote:
> Why not start the branch with the API as is described and then change it as
> people find problems with it. I am guessing we should converge on an API
> that the majority of users are happy with fairly quickly.
Yes, that's why I suggested using
On Sun, 1 Feb 2009, Diego Novillo wrote:
> > Where would plugin-centric enhancements such as improvements to the pass
> > manager go? i think it'd be useful to have them land in the plugin branch to
> > make sure the API is satisfactory.
>
> How about /gcc/plugins/? Maybe we could categorize
> t
This applies to GCC 4.2 on AIX 5.3 but probably applies elsewhere as
well.
If gettext is installed, then gcc builds differently. (That is not
surprising.)
gettext depends upon expat and expat depends upon libgcc_s.a. So
there is a circle of dependancies. Again, all this is already know
On Sun, Feb 1, 2009 at 13:50, Joseph S. Myers wrote:
> As plugin-centric enhancements as described seem to be changes to existing
> GCC source code (providing infrastructure of potential use to multiple
> plugins), they don't have a single plugin-name, so the path you gave
> doesn't make sense as
On Sun, 1 Feb 2009, Diego Novillo wrote:
> > As for installation directories, I've already noted that plugins should be
> > installed under libsubdir or libexecsubdir since they will depend on both
> > the target and version of GCC.
>
> Agreed. We'll also need some convention for the API header
Hi,
We like to update x86-64 psABI to pass aggregates of 32 bytes with
single __m256 field
in AVX registers, instead of memory. However, finding the proper
wording seems tricky.
Here is what I got. Any comments?
Thanks.
--
H.J.
Index: low-level-sys-info.tex
===
Laurent GUERBY schrieb:
> Before my testresult I could find only trunk 140564
> in september 2008 with a patch by David Daney then no more testresults:
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html
>
> I could'nt find any 4.3 result on mipsel posted on gcc-testresults (?).
>
>
On Sun, 2009-02-01 at 22:14 +0100, Matthias Klose wrote:
> Laurent GUERBY schrieb:
> > Before my testresult I could find only trunk 140564
> > in september 2008 with a patch by David Daney then no more testresults:
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html
> >
> > I coul
"Bingfeng Mei" wrote on 30/01/2009 14:44:01:
> Hello,
> I try to make modulo scheduling work more efficiently for our VLIW
target. I
> found one serious issue that prevents current SMS algorithm from
achieving
> high IPC is so-called "transitive closure" problem, where scheduling
window is
> only
On Sun, 2009-02-01 at 14:26 -0500, Diego Novillo wrote:
> Yes, that's the path I was describing; plugins distributed with GCC.
> I don't expect we'll have more than a small number of them. Mostly as
> examples.
The usual problem with example plugins is that they stop working. It
would be nice i
Richard Sandiford writes:
> How about the patch below? I'll apply it in the next couple of days
> if there are no objections.
Thanks for patch. I also like the new comments you added.
Adam
19 matches
Mail list logo
