On Fri, Mar 14, 2014 at 10:46 PM, Richard Biener
wrote:
> On Fri, Mar 14, 2014 at 4:31 PM, Prathamesh Kulkarni
> wrote:
>> On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
>> wrote:
>>> On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
>>> wrote:
On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh K
Hello,
I just enrolled in Google Summer of Code and would like to contribute
to GCC. I'm not very familiar with the process of getting a project
for GSoC nor with free software development in general, but I would
like to learn. Can someone give me some hints please?
Thank you very much.
Win7 - 64bit
gcc (GCC) 4.8.2
g++ -w -DYYDEBUG=1 -DDEBUG_IO -c -g -MMD -MP -MF
"build/Debug/Cygwin-Windows/SlipRegister.o.d" -o
build/Debug/Cygwin-Windows/SlipRegister.o SlipRegister.cpp
There is no generated code for "retval = true;" in the conditional block. I am
including the code fragmen
On 2014.03.16 at 09:20 -0700, Arthur Schwarz wrote:
>
>
> Win7 - 64bit
> gcc (GCC) 4.8.2
> g++ -w -DYYDEBUG=1 -DDEBUG_IO -c -g -MMD -MP -MF
> "build/Debug/Cygwin-Windows/SlipRegister.o.d" -o
> build/Debug/Cygwin-Windows/SlipRegister.o SlipRegister.cpp
>
> There is no generated code for "retv
Hi Ian
I have spend these 3 days to read lots of documents about Go and
gccgo. And scan many papers about escape analysis.
I plan to use about next 2 days to read more source code of gccgo.
In order to dig more and come to a more detailed and efficient
proposal. I need your suggestio
On 10/03/14 22:37, DJ Delorie wrote:
The use of "volatile" disables many of GCC's optimizations. I
consider this a bug in GCC, but at the moment it needs to be "fixed"
in the backends on a case-by-case basis.
Hi,
I've looked into the differences between the steps taken when using a
variabl
On 16 March 2014 16:20, Arthur Schwarz wrote:
> If the issue seems to be a bug then I will include whatever additional data
> is required to help gcc identify the error. If it is not a bug then I truly
> apologize for wasting your time.
It's not a bug, as you could easily have discovered by usin
I have made a proposal and wonder if it is clearly and realistic?
Thanks for every correction.
Ray
GCC Go escape analysis
The Project
The Project aims to accomplish escape analysis for gccgo.
Goal:
escape analysis
(optimization) converting heap allocation to stack a
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> >> I think instead we should have a configuration switch that allows
> >> >> a particular -mfp option to be inserted alongside -mabi=32 if no
> >> >> explicit -mfp is given. This
On Sun, 2014-03-16 at 19:48 +0100, Richard Hulme wrote:
> On 10/03/14 22:37, DJ Delorie wrote:
> >
> > The use of "volatile" disables many of GCC's optimizations. I
> > consider this a bug in GCC, but at the moment it needs to be "fixed"
> > in the backends on a case-by-case basis.
> >
>
> Hi,
>
On Sun, Mar 16, 2014 at 9:59 AM, Ray Li wrote:
>
> I have spend these 3 days to read lots of documents about Go and
> gccgo. And scan many papers about escape analysis.
>
> I plan to use about next 2 days to read more source code of gccgo.
>
> In order to dig more and come to a more de
Thank you. I will made it a little more specific.
And now I've made it a little bit slower ...
And divide my first stage work into 2 parts for the present.
I'll look for more information to accomplish it.
On Mon, Mar 17, 2014 at 3:26 AM, Joel Sherrill
wrote:
>
> On Mar 16, 2014 2:15 PM, Ray Li
> Maybe we should add a target hook/macro to control this to avoid
> duplicated code of 'general_operand' in various places?
Even in the msp430, not all patterns can be safely used with volatile
MEMs (i.e. the macro patterns). So, not all general_operand's were
replaced.
This is similar to what I had to do for msp430 - I made a new
constraint that was what general_operand would have done if it allowed
volatile MEMs, and used that for instructions where a volatile's
volatileness wouldn't be broken.
On Sun, 2014-03-16 at 17:22 -0400, DJ Delorie wrote:
> This is similar to what I had to do for msp430 - I made a new
> constraint that was what general_operand would have done if it allowed
> volatile MEMs, and used that for instructions where a volatile's
> volatileness wouldn't be broken.
Maybe
Snapshot gcc-4.9-20140316 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140316/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
16 matches
Mail list logo
