Joseph S. Myers wrote:
I tried building GCC with Graphite enabled and all the libraries it
requires in a Canadian cross configuration (build = i686-pc-linux-gnu,
host = i686-mingw32, target = arm-none-eabi). This failed with:
configure:11279: checking for the possibility to control the FPU
co
On Mon, Mar 16, 2009 at 6:10 AM, Paolo Bonzini wrote:
> NightStrike wrote:
>> On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
>> wrote:
>>> Given the SC request we need to stay in Stage 4 rather than trying to work
>>> around it.
>>
>> What if GCC went back to stage 3 until the issue is resolved
Ben Elliston wrote:
> Ah, good, a duplicate question that I just answered. :-)
> See http://gcc.gnu.org/ml/gcc/2009-03/msg00554.html
>
> Ben
I bet Guilherme and Eduardo are in the same class at college!
http://www.din.uem.br/~hppca/membros.html
Ah! We can expect emails from Diego, Egidio,
The fortran development branch has been created. The purpose is to
allow continuation of development of new Fortran 95 and Fortran 2003
features. A primary objective will be testing these features before
committing over to mainline, when appropriate.
A complete list of objectives can be foun
Ah, good, a duplicate question that I just answered. :-)
See http://gcc.gnu.org/ml/gcc/2009-03/msg00554.html
Ben
On Thu, 2009-03-19 at 23:29 -0300, Eduardo Cruz wrote:
> I thought gcc used bison as a syntax analyser, but when I saw the gcc
> c-parser source code I realized that it didn't use bison.
> I read in the gcc mailist that gcc now has a recursive descent parser.
That's right.
> Do you have any docu
Hello to All,
I'm new in gcc list. And as all new members I have a problem.
I will copy an email whose I've sent to Joe Buck. If someone can
answer it for me, I really appreciate that.
"Hi Joe Buck,
My name is Guilherme and I am a Brazilian undergraduate student in
Computer Science.
First of al
NightStrike wrote:
On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
wrote:
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
I agree about the bisecting-in-case-of-bugs issue.
However, what I see happening in practice is that all GCC developers
keep on doing their development work on br
Hello, my name is Eduardo Cruz. I am an studen.t of Computer Science
at the State University of Maringa, in Brazil.
One of our teachers gave us a work in wich we are supposed to modify
the c language to support some parallel programming stuff.
I want to modify the gcc c frontend to support these fe
On Sun, Mar 15, 2009 at 9:39 PM, Gerald Pfeifer wrote:
>> I can't find any test results in gcc-testresults reported with
>> -mtune=itanium1 [1].
>
> ...especially if theye do not even contribute test results or
> feedback when things are broken (as in this case). Deprecating
> Itanium 1 with GCC
2009/3/16 Jack Howarth :
> What about allowing for more backports from the graphite
> branch if this drags out for an extended period of time? In
> particular, I am thinking of those changes in graphite branch
> that might reduce those cases where -fgraphite-identity
> degrades the performance
Snapshot gcc-4.3-20090319 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090319/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I tried building GCC with Graphite enabled and all the libraries it
requires in a Canadian cross configuration (build = i686-pc-linux-gnu,
host = i686-mingw32, target = arm-none-eabi). This failed with:
configure:11279: checking for the possibility to control the FPU
configure:11282: error: in
On Thu, 2009-03-19 at 20:14 +0100, Ralf Wildenhues wrote:
> * Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
> > Richard Guenther wrote:
> >>
> >> Note that merging the branch will be painful (as in, please dissect
> >> the branch into the individual patches again to make bisecting the
>
Hi Ian,
> Student applications will be accepted from March 23 to April 3. Each
> student will work with a mentor from the project. As we've done in past
> years, we need to have a set of mentors who are prepared to work with
> students. I would like to encourage any interested experienced GCC
>
Regarding ARC and MMIX we might expect some action from Joern and H-P
respectively, but nobody is probably going to do the work for the others
AFAIK ARC has no plans to do work on the old ARCtangent-A4 port that
is currently in gcc trunk. The ARCompact code is not suitable to be
integrated into
I'm pleased to report that GCC was once again accepted as a supported
project for Google's Summer of Code program. Summer of Code is a
program sponsored by Google in which students are paid to contribute to
open source projects. This will be GCC's fourth year of participation.
For more informatio
For some reason sourceware seems to think this message was sent as
HTML instead of plaint text. Retry...
-- Forwarded message --
From:
Date: Thu, Mar 19, 2009 at 8:15 PM
Subject: Re: Re: Proposed gfortran development branch
To: (hidden)
On Mar 19, 2009 8:06pm, Steve Kargl wrot
* Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
> Richard Guenther wrote:
>>
>> Note that merging the branch will be painful (as in, please dissect
>> the branch into the individual patches again to make bisecting the
>> trunk SVN possible).
> I agree about the bisecting-in-case-of-bugs
On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
wrote:
>
> On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
> >
> > I agree about the bisecting-in-case-of-bugs issue.
> >
> > However, what I see happening in practice is that all GCC developers
> > keep on doing their development work on br
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
>
> I agree about the bisecting-in-case-of-bugs issue.
>
> However, what I see happening in practice is that all GCC developers
> keep on doing their development work on branches - only the gfortran
> developers are left out, because th
> Besides obvious register allocation differences
m32c is very sensitive to register allocation issues.
> you basically duplicate the cmp patterns into cbranch and
m32c already has a cbranch, though. It gets split after reload.
Also, m32c needs a separate compare RTL insn in the end
because i
Richard Guenther wrote:
On Thu, Mar 19, 2009 at 1:44 AM, Jerry DeLisle wrote:
Hi folks,
In light of all the delays, I would like to propose that we create a
development / test branch for gfortran.
We could then start committing all the pending patches and if mainline
ever branches, just merg
On Thu, Mar 19, 2009 at 8:25 PM, Kai Tietz wrote:
> 2009/3/19 Ozkan Sezer :
>> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definit
I now went through all backends except sh and made the required changes.
So far all I tested is that gcc compiles with one target per port. :-)
Plus, i386-linux bootstraps and regtests okay.
Right now I aim at 100% identical assembly, maybe I'll have to relax
that. Besides obvious register allo
2009/3/19 Ozkan Sezer :
> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
>>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>>> compiler but the definition of DWORD is not.. In any case, it should be
>>> fixed
Ozkan Sezer wrote:
> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>> However you are wrong about DWORD definition it has always be defined
>> like this :
>>
>> typedef unsigned long DWORD, *PDWORD, *LPDWORD;
>>
>> at least windows.
>>
>
> A DWORD on windows is an unsigned 32 bit integer, t
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>> compiler but the definition of DWORD is not.. In any case, it should be
>> fixed easily by changing DWORD into
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
> I'm a bit amazed that the prototype for VirtualProtect() is known to the
> compiler but the definition of DWORD is not.. In any case, it should be
> fixed easily by changing DWORD into unsigned int which is what a
> DWORD is always defined a
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of DWORD is not.. In any case, it should be
fixed easily by changing DWORD into unsigned int which is what a
DWORD is always defined as. And PR 39063 is still open anyway.
--
Ozkan
>> Given that the svn://gcc.gnu.org/svn/gcc/branches/plugin branch is not
>> really active, I suggest to
>>
>> svn mv svn://gcc.gnu.org/svn/gcc/branches/plugin
>> svn://gcc.gnu.org/svn/gcc/branches/old-plugin
>>
>> What do you think about that?
>
> I have no opinion on this. Eric and Sean should
On Thu, Mar 19, 2009 at 4:45 PM, bajrang kumar wrote:
> > Sir,
> > I want to know about gnu compiler project's aim.
> http://gcc.gnu.org/gccmission.html
>
> > Can i work for Gnu C compiler only.
On Thu, Mar 19, 2009 at 05:21:06AM -0700, satyaakam goswami wrote:
> Yes
See http://gcc.gnu.org/c
Hello everyone,
In attach I included the patch Albert Cohen was referring to.
Middle-end selection is performed by marking the regions of the source
code, that should be compiled for an specific ISA, using pragmas such
as:
#pragma target
Or even to reset the above by just doing:
#pragma ta
On Thu, Mar 19, 2009 at 7:49 AM, Vincent R. wrote:
> Hi,
>
> I tried to generate a cross-compiler from trunk a few hours ago and I have
> noticed that
> libgcc2.c doesn't compile anymore because of the following function :
It is caused by:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00822.html
Hi,
I tried to generate a cross-compiler from trunk a few hours ago and I have
noticed that
libgcc2.c doesn't compile anymore because of the following function :
int
mprotect (char *addr, int len, int prot)
{
DWORD np, op;
if (prot == 7)
np = 0x40;
else if (prot == 5)
np = 0x20;
On Thu, Mar 19, 2009 at 4:45 PM, bajrang kumar wrote:
> Sir,
> I want to know about gnu compiler project's aim.
http://gcc.gnu.org/gccmission.html
> Can i work for Gnu C compiler only.
Yes
-Satya
http://www.linkedin.com/in/satyaakam
On Thu, Mar 19, 2009 at 05:32, Basile STARYNKEVITCH
wrote:
> The only difference in the branches name is a single letter (the last s of
> plugins).
Yeah, I had forgotten about that branch and only remembered when I
went to edit the svn web page.
> Given that the svn://gcc.gnu.org/svn/gcc/branch
Sir,
I want to know about gnu compiler project's aim.
Can i work for Gnu C compiler only.
Yours Sincerely
Bajrang Kr
> [Naganna] I would like to know all phases of GCC OpenMP(Paser level,
> intermediate reprsentation, code generation and OpenMP runtime librariy)
>
> could you please point documents which explain work flow of GOMP?
The GOMP project page:
http://gcc.gnu.org/projects/gomp/
The only article A
ation, the best way
is to take a look at the code in gcc/omp-low.c
As side point, I am very new to GCC development.
Welcome then :)
Antoniu
__ NOD32 3947 (20090319) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
Hello All,
The current SVN tree contain two branches on plugins.
% svn info svn://gcc.gnu.org/svn/gcc/branches/plugin
Path: plugin
URL: svn://gcc.gnu.org/svn/gcc/branches/plugin
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-041
Hi,
> I would like to do backend work to convert OpenMP to GPGPU
> langauages(Brook+).
I'm not sure this would be best suited for backend work. The OpenMP
pragma expansion is done very early and the decision to offload parts
of the computation to the GPGPU would probably need to be taken before
Hi every one,
I would like to do backend work to convert OpenMP to GPGPU
langauages(Brook+).
could you please send me pointers to documents which explains the
source code details for OpenMP backend code generation?
As side point, I am very new to GCC development.
Thanks in advanc
43 matches
Mail list logo