avr compilation

[Paulo J. Matos]

Hi all,

I am looking at the avr backend in order to try to sort some things out 
on my own backend.


One of the tests I am doing is by compiling the following:
int x = 0x1010;
int y = 0x0101;

int add(void)
{
  return x+y;
}

It compiles to (in gcc-4.3.5_avr with -Os)
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r18,r24
adc r19,r25
mov r24,r18
mov r25,r19
/* epilogue start */
ret

I don't know much avr assembler so bear with me but I would expect this 
to be written:

add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r24,r18
adc r25,r19
/* epilogue start */
ret

By inverting the add arguments we save two mov instructions.

If it can be written like this any ideas on why GCC is avoiding it?

Cheers,

--
PMatos

Re: avr compilation

[WANG.Jiong]

This may related with subreg regmove finding
Suggest specifiy -fdump-rtl-regmove to see what happen after this pass
Maybe avr need a target dependent regmove pass to handle this


Best,
Jiong

On 03/18/2011 04:47 PM, Paulo J. Matos wrote:

Hi all,

I am looking at the avr backend in order to try to sort some things 
out on my own backend.


One of the tests I am doing is by compiling the following:
int x = 0x1010;
int y = 0x0101;

int add(void)
{
  return x+y;
}

It compiles to (in gcc-4.3.5_avr with -Os)
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r18,r24
adc r19,r25
mov r24,r18
mov r25,r19
/* epilogue start */
ret

I don't know much avr assembler so bear with me but I would expect 
this to be written:

add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r24,r18
adc r25,r19
/* epilogue start */
ret

By inverting the add arguments we save two mov instructions.

If it can be written like this any ideas on why GCC is avoiding it?

Cheers,

--
PMatos

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 10:08, WANG.Jiong wrote:

This may related with subreg regmove finding
Suggest specifiy -fdump-rtl-regmove to see what happen after this pass
Maybe avr need a target dependent regmove pass to handle this



It doesn't look like it's regmove, whose result looks pretty sane:
;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)

(insn 5 2 6 2 add.c:5 (set (reg:HI 42)
(mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] 0x7f40954201e0 y>) [2 y+0 S2 A8])) 8 {*movhi} (nil))


(insn 6 5 7 2 add.c:5 (set (reg:HI 44 [ x ])
(mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] 0x7f4095420140 x>) [2 x+0 S2 A8])) 8 {*movhi} (nil))


(insn 7 6 25 2 add.c:5 (set (reg:HI 42)
(plus:HI (reg:HI 42)
(reg:HI 44 [ x ]))) 20 {*addhi3} (expr_list:REG_DEAD 
(reg:HI 44 [ x ])

(nil)))

(insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24)
(subreg:QI (reg:HI 42) 0)) 4 {*movqi} (nil))

(insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ])
(subreg:QI (reg:HI 42) 1)) 4 {*movqi} (expr_list:REG_DEAD 
(reg:HI 42)

(nil)))

(insn 18 26 0 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil))
;; End of basic block 2 -> ( 1)


If psr 42 and 44 are allocated to the proper registers, i.e. 42 is 
allocated to the return registers insn 25/26 could be deleted, however, 
that's not what happens after register allocation:


;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)

(insn 5 2 6 2 add.c:5 (set (reg:HI 18 r18 [42])
(mem/c/i:HI (symbol_ref:HI ("y") [flags 0x2] 0x7f40954201e0 y>) [2 y+0 S2 A8])) 8 {*movhi} (nil))


(insn 6 5 7 2 add.c:5 (set (reg:HI 24 r24 [orig:44 x ] [44])
(mem/c/i:HI (symbol_ref:HI ("x") [flags 0x2] 0x7f4095420140 x>) [2 x+0 S2 A8])) 8 {*movhi} (nil))


(insn 7 6 25 2 add.c:5 (set (reg:HI 18 r18 [42])
(plus:HI (reg:HI 18 r18 [42])
(reg:HI 24 r24 [orig:44 x ] [44]))) 20 {*addhi3} (nil))

(insn 25 7 26 2 add.c:7 (set (reg:QI 24 r24)
(reg:QI 18 r18 [42])) 4 {*movqi} (nil))

(insn 26 25 18 2 add.c:7 (set (reg:QI 25 r25 [+1 ])
(reg:QI 19 r19 [+1 ])) 4 {*movqi} (nil))

(insn 18 26 27 2 add.c:7 (use (reg/i:HI 24 r24)) -1 (nil))
;; End of basic block 2 -> ( 1)

So, I guess it's probably something else...



Best,
Jiong

On 03/18/2011 04:47 PM, Paulo J. Matos wrote:

Hi all,

I am looking at the avr backend in order to try to sort some things
out on my own backend.

One of the tests I am doing is by compiling the following:
int x = 0x1010;
int y = 0x0101;

int add(void)
{
return x+y;
}

It compiles to (in gcc-4.3.5_avr with -Os)
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r18,r24
adc r19,r25
mov r24,r18
mov r25,r19
/* epilogue start */
ret

I don't know much avr assembler so bear with me but I would expect
this to be written:
add:
/* prologue: function */
/* frame size = 0 */
lds r18,y
lds r19,(y)+1
lds r24,x
lds r25,(x)+1
add r24,r18
adc r25,r19
/* epilogue start */
ret

By inverting the add arguments we save two mov instructions.

If it can be written like this any ideas on why GCC is avoiding it?

Cheers,

--
PMatos

Re: avr compilation

[David Brown]

On 18/03/2011 11:15, Paulo J. Matos wrote:

On 18/03/11 10:08, WANG.Jiong wrote:

This may related with subreg regmove finding
Suggest specifiy -fdump-rtl-regmove to see what happen after this pass
Maybe avr need a target dependent regmove pass to handle this



It doesn't look like it's regmove, whose result looks pretty sane:


As far as I can see, you are correct - avr-gcc generates subobtimal code 
here, and your version is better.


There are only a few people who work with the AVR backend, and while 
these people are both clever and dedicated, they are limited in how much 
they can do - correct code generation and support for newer devices or 
features rightly takes priority over optimisation issues.  Thus there 
are a fair number of "missed optimisation" issues filed for the AVR 
backend, and many more cases like this of suboptimal code that don't 
even have issues filed.


There are also a number of patches that are generally applied to avr-gcc 
builds (most of which eventually make it into the main FSF tree).  I 
could not say if any of these are relevant here.


If you are digging through the AVR backend and find ways to improve code 
sequences like this, the avr-gcc community would be very grateful.


There is an avr-gcc mailing list at 
, which may be of 
interest to you.

RE: Same cross-gcc toolchain on different hosts produces different target code?

[McCall, Ronald SIK]

> In particular, isn't it a known issue that 32-bit hosts and 64-bit hosts can
> generate different constant-loading sequences owing to the differing size of
> HOST_WIDE_INT?
>
> Was that 32-bit Solaris?
>
> cheers,
> DaveK

The system is 64-bit Solaris 9 but the native gcc is sparc-sun-solaris2.9 which 
I believe is 32-bit (sparcv9-sun-solaris2.9 is the 64-bit target if memory 
serves).  

Re: avr compilation

[Georg-Johann Lay]

Paulo J. Matos schrieb:
> Hi all,
> 
> I am looking at the avr backend in order to try to sort some things out
> on my own backend.
> 
> One of the tests I am doing is by compiling the following:
> int x = 0x1010;
> int y = 0x0101;
> 
> int add(void)
> {
>   return x+y;
> }
> 
> It compiles to (in gcc-4.3.5_avr with -Os)
> add:
> /* prologue: function */
> /* frame size = 0 */
> lds r18,y
> lds r19,(y)+1
> lds r24,x
> lds r25,(x)+1
> add r18,r24
> adc r19,r25
> mov r24,r18
> mov r25,r19
> /* epilogue start */
> ret
> 
> I don't know much avr assembler so bear with me but I would expect this

note that the last moves are two QI moves, the add is HI.

Without splitting HI the moves will disappear, try -fno-split-wide-types.

Johann

> to be written:
> add:
> /* prologue: function */
> /* frame size = 0 */
> lds r18,y
> lds r19,(y)+1
> lds r24,x
> lds r25,(x)+1
> add r24,r18
> adc r25,r19
> /* epilogue start */
> ret
> 
> By inverting the add arguments we save two mov instructions.
> 
> If it can be written like this any ideas on why GCC is avoiding it?

Try newer version of gcc, like 4.5.2
> 
> Cheers,
> 
> -- 
> PMatos

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 12:10, David Brown wrote:

If you are digging through the AVR backend and find ways to improve code
sequences like this, the avr-gcc community would be very grateful.

There is an avr-gcc mailing list at
, which may be of
interest to you.



Thanks for your reply. Just subscribed to avr-gcc through gmane.
Georg-Johann Lay suggests correctly that -fno-split-wide-types helps. 
With this option the code is as I suggested.


I will try 4.5.2 to see if it works out of the box! :)

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 13:26, Georg-Johann Lay wrote:

note that the last moves are two QI moves, the add is HI.



Yes, correct, this seems to cause some confusion on gcc side then... humm!


Without splitting HI the moves will disappear, try -fno-split-wide-types.



It does work! It's enabled by -O1, maybe it should be disabled by -Os if 
it improves the code size consistently.




Try newer version of gcc, like 4.5.2



Thanks, I will. Hopefully it will do the optimisation out of the box 
without the need for the extra option.



Cheers,

--
PMatos

ส่งต่อ: ส่งไม่ได้: failure notice

[fiveissara]

ส่งจากโทรศัพท์ Nokia ของฉัน
-ข้อความต้นฉบับ-
จาก: five...@hotmail.com
ส่งแล้ว:  18-03-2011 20:41:40
หัวข้อ:  ส่งไม่ได้: ส่งต่อ: failure notice

อีเมลไม่ถูกต้อง: 0876167523

-ข้อความต้นฉบับ-


ส่งจากโทรศัพท์ Nokia ของฉัน
-ข้อความต้นฉบับ-
จาก: mailer-dae...@sourceware.org
ส่งแล้ว:  18-03-2011 17:33:20
หัวข้อ:  failure notice

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
ezmlm-reject: fatal: Sorry, I don't accept message with empty Subject (#5.7.0)

--- Enclosed are the original headers of the message.

Re: avr compilation

[Ian Lance Taylor]

"Paulo J. Matos"  writes:

>> Without splitting HI the moves will disappear, try -fno-split-wide-types.
>>
>
> It does work! It's enabled by -O1, maybe it should be disabled by -Os
> if it improves the code size consistently.

-fsplit-wide-types is an improvement on most targets, in which ints and
pointers have the size UNITS_PER_WORD.  On AVR that appears not to be
the case, and it seems possible that AVR should set
flag_split_wide_types to 0 in TARGET_OPTION_OPTIMIZATION_TABLE.

Ian

Re: avr compilation

[Paulo J. Matos]

On 18/03/11 14:20, Ian Lance Taylor wrote:


-fsplit-wide-types is an improvement on most targets, in which ints and
pointers have the size UNITS_PER_WORD.  On AVR that appears not to be
the case, and it seems possible that AVR should set
flag_split_wide_types to 0 in TARGET_OPTION_OPTIMIZATION_TABLE.


That does explains why split-wide-types causes improvement on avr. Thanks.

Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

I am getting several failures in decimal/mixed-mode_neg.cc:

FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 195)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 196)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 197)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 198)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 199)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 200)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 201)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 202)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 203)

This test expects syntax errors in all these lines, and the compiler
is indeed flagging them but the output from the compiler is so big
that dejagnu truncates it.  The testsuite never sees the error
messages starting at line 195 (I can see the output truncated in
libstdc++.log).

Is there a way to increase dejagnu's buffering?  This does not happen,
if I simply run the build in a shallower build tree, but that is not a
viable alternative.

Any suggestions on how to address this, short of butchering this test?


Thanks.  Diego.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Paolo Carlini]

Hi

I am getting several failures in decimal/mixed-mode_neg.cc:

FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 195)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 196)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 197)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 198)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 199)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 200)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 201)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 202)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 203)

This test expects syntax errors in all these lines, and the compiler
is indeed flagging them but the output from the compiler is so big
that dejagnu truncates it.  The testsuite never sees the error
messages starting at line 195 (I can see the output truncated in
libstdc++.log).

Is there a way to increase dejagnu's buffering?  This does not happen,
if I simply run the build in a shallower build tree, but that is not a
viable alternative.
Honestly, I know very little about the dejagnu buffering, but I'm having 
a quick look to the issue and I'm rather surprised that you are seeing 
it for these particular errors and nowhere else in the testsuite: here, 
on the libstdc++.log of x86_64-linux, I see just 9 candidates listed, 
and I'm pretty sure that in terms of error messages we have much, much, 
longer examples, when templates are involved in particular. What I'm 
missing?


Paolo.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

On Fri, Mar 18, 2011 at 11:30, Paolo Carlini  wrote:
> Hi
>>
>> I am getting several failures in decimal/mixed-mode_neg.cc:
>>
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 195)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 196)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 197)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 198)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 199)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 200)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 201)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 202)
>> FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 203)
>>
>> This test expects syntax errors in all these lines, and the compiler
>> is indeed flagging them but the output from the compiler is so big
>> that dejagnu truncates it.  The testsuite never sees the error
>> messages starting at line 195 (I can see the output truncated in
>> libstdc++.log).
>>
>> Is there a way to increase dejagnu's buffering?  This does not happen,
>> if I simply run the build in a shallower build tree, but that is not a
>> viable alternative.
>
> Honestly, I know very little about the dejagnu buffering, but I'm having a
> quick look to the issue and I'm rather surprised that you are seeing it for
> these particular errors and nowhere else in the testsuite: here, on the
> libstdc++.log of x86_64-linux, I see just 9 candidates listed, and I'm
> pretty sure that in terms of error messages we have much, much, longer
> examples, when templates are involved in particular. What I'm missing?

I don't really know why the others don't fail, but I will take a look.
 In this particular case, the output is truncated after 1,032,134
bytes are printed.  So I can only speculate that no other tests
generate more than this number of bytes in output.  I'll take a look.


Diego.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Paolo Carlini]

On 03/18/2011 04:35 PM, Diego Novillo wrote:

I don't really know why the others don't fail, but I will take a look.
  In this particular case, the output is truncated after 1,032,134
bytes are printed.  So I can only speculate that no other tests
generate more than this number of bytes in output.  I'll take a look.
For sure if it's the *overall* number of bytes that matters, working 
around the issue is simple, because the testcase can be trivially split 
to 14 separate tests, one for each operation.


Paolo.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

On Fri, Mar 18, 2011 at 11:40, Paolo Carlini  wrote:
> On 03/18/2011 04:35 PM, Diego Novillo wrote:
>>
>> I don't really know why the others don't fail, but I will take a look.
>>  In this particular case, the output is truncated after 1,032,134
>> bytes are printed.  So I can only speculate that no other tests
>> generate more than this number of bytes in output.  I'll take a look.
>
> For sure if it's the *overall* number of bytes that matters, working around
> the issue is simple, because the testcase can be trivially split to 14
> separate tests, one for each operation.

Yeah, I was thinking of splitting the test in several files.  I'll
send a patch later, if you think that's a reasonable thing to do.


Thanks.  Diego.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Andreas Schwab]

Diego Novillo  writes:

> Is there a way to increase dejagnu's buffering?

expect(1):

   match_max [-d] [-i spawn_id] [size]
 defines the size of the buffer  (in  bytes)  used  internally  by
 expect.  With no size argument, the current size is returned.

 With  the -d flag, the default size is set.  (The initial default
 is 2000.)  With the -i flag, the size is set for the named  spawn
 id, otherwise it is set for the current process.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Joseph S. Myers]

On Fri, 18 Mar 2011, Diego Novillo wrote:

> I don't really know why the others don't fail, but I will take a look.
>  In this particular case, the output is truncated after 1,032,134
> bytes are printed.  So I can only speculate that no other tests
> generate more than this number of bytes in output.  I'll take a look.

There are a couple of places in DejaGnu's remote.exp that compare numbers 
of bytes with 512000; try increasing those to a much bigger figure, say 
512.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

On Fri, Mar 18, 2011 at 11:55, Andreas Schwab  wrote:
> Diego Novillo  writes:
>
>> Is there a way to increase dejagnu's buffering?
>
> expect(1):
>
>       match_max [-d] [-i spawn_id] [size]
>             defines the size of the buffer  (in  bytes)  used  internally  by
>             expect.  With no size argument, the current size is returned.
>
>             With  the -d flag, the default size is set.  (The initial default
>             is 2000.)  With the -i flag, the size is set for the named  spawn
>             id, otherwise it is set for the current process.

Thanks, but I don't think match_max affects this.  It's the output
from the compiler that is being truncated.  I modified conformance.exp
with a match_max value 10x the limit I need, but the failures are
still there:

Index: testsuite/libstdc++-dg/conformance.exp
===
--- testsuite/libstdc++-dg/conformance.exp  (revision 171068)
+++ testsuite/libstdc++-dg/conformance.exp  (working copy)
@@ -21,6 +21,8 @@
 # Initialization.
 dg-init

+match_max -d 1000
+
 # Build the support objects.
 v3-build_support

Running /libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 196)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 197)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 198)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 199)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 200)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 201)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 202)
FAIL: decimal/mixed-mode_neg.cc  (test for errors, line 203)

The output is clearly truncated, right before the first 'PASS' result, I see:

[ ... ]/x86_64-unknown-linux-gnu/libstdc++-v3/include/decimal/decimal.h:83:3:
note: std::decimal::decimal32&
std::decimal::decimal32::operator/=(long int)^M
/usr/local/google/hom   TRUNCATED
PASS: decimal/mixed-mode_neg.cc  (test for errors, line 43)
PASS: decimal/mixed-mode_neg.cc  (test for errors, line 44)


Diego.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

On Fri, Mar 18, 2011 at 11:43, Joseph S. Myers  wrote:

> There are a couple of places in DejaGnu's remote.exp that compare numbers
> of bytes with 512000; try increasing those to a much bigger figure, say
> 512.

Thanks.  Given that my output is truncated at ~1Mb, I'm not sure if
this will help.  Even if it did, I really cannot touch remote.exp, as
this is installed in a system location that is not feasible for us to
modify.

I think my best bet will be to simply split this test case.


Diego.

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Andreas Schwab]

Diego Novillo  writes:

> Thanks, but I don't think match_max affects this.  It's the output
> from the compiler that is being truncated.

I don't see that problem on powerpc-linux (and I couldn't find any such
failure on gcc-testresults).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Spurious libstdc++ testsuite failures because of truncated buffered output

[Diego Novillo]

On Fri, Mar 18, 2011 at 14:05, Andreas Schwab  wrote:
> Diego Novillo  writes:
>
>> Thanks, but I don't think match_max affects this.  It's the output
>> from the compiler that is being truncated.
>
> I don't see that problem on powerpc-linux (and I couldn't find any such
> failure on gcc-testresults).

It only happens in our builds that have very deep directory trees.
The extra long path names contribute to filling up whatever buffer
that dejagnu uses for output.  I believe that if you manage to build
inside a tree this long, you'll be able to reproduce the problem:

$ pwd -P | wc -c
236


Diego.

Enquiry on GSoC projects

[Levon Haykazyan]

Dear gcc contributors,

My name is Levon Haykazyan, I am a PhD student at Yerevan 
State University (Armenia) studying theoretical computer 
science. I am considering applying to Summer of Code for 
adding some C++0x support in gcc. I would like to ask 
potential mentors

1. which of C++0x language features are relevant as a soc 
project?

2. some guidance for a simple project to familiarize myself 
with internals of gcc and demonstrate my coding skills.

Thank you for your time.

Kind regards,
Levon

-- 
You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 2GB of Storage!

http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748&STATUS=MAIN

gcc-4.6-20110318 is now available

[gccadmin]

Snapshot gcc-4.6-20110318 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110318/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 171171

You'll find:

 gcc-4.6-20110318.tar.bz2 Complete GCC (includes all of below)

  MD5=7adc4b04c8deff89b36411742807ad04
  SHA1=5ae304878bdbc48eab55569825092ef5866c1591

 gcc-core-4.6-20110318.tar.bz2C front end and core compiler

  MD5=fa76d3e584167d47346747f7a95fa87b
  SHA1=f2ca7c7cc28b8c5e9c59176027c0e1fff9ff47e6

 gcc-ada-4.6-20110318.tar.bz2 Ada front end and runtime

  MD5=1e88a632f680547e39e7afc5d2902fb0
  SHA1=a0a9726e14ed6568a4d0e56a9371d283ee8ad7aa

 gcc-fortran-4.6-20110318.tar.bz2 Fortran front end and runtime

  MD5=be1934741d459a9a312a7b6a3b5e2a0b
  SHA1=a240778bd7ed3836c56c183bdc796297c9c431a9

 gcc-g++-4.6-20110318.tar.bz2 C++ front end and runtime

  MD5=2fe6febaa39b2cb6c7854cd7d2f9f8f1
  SHA1=e5f79e31800d7a05fba8e18865d50d040e20f546

 gcc-go-4.6-20110318.tar.bz2  Go front end and runtime

  MD5=0aa770baf0f7c7cdcc2590b712af94eb
  SHA1=12e5c9fd4ba030278dc8207ac64f4c7074a2b0ab

 gcc-java-4.6-20110318.tar.bz2Java front end and runtime

  MD5=e68aecc3402f141b03a0eed1b2ff04f2
  SHA1=5ba9b39e4ece0066a0d4f6d58a2d8d9709212dbc

 gcc-objc-4.6-20110318.tar.bz2Objective-C front end and runtime

  MD5=e65c566a5244737fc12247b2a74c447b
  SHA1=579e3208ba3017235818ef8a654265931df830ca

 gcc-testsuite-4.6-20110318.tar.bz2   The GCC testsuite

  MD5=040512d67c9e9a12e238c68288fd3626
  SHA1=93576953358906e5eec51652c669de60c8492716

Diffs from 4.6-20110312 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Google Summer of Code 2011 - Call for Mentors

[Diego Novillo]

We are glad to announce that GCC has been accepted Google's Summer of
Code 2011 program (GSoC 2011).  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 6th year of participation.  For more
information, see http://code.google.com/soc/ .

Student applications will be accepted from 28 March 2011 to 8 April
2011.  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.  We would like to encourage any
interested experienced GCC developer to become a mentor for the
project.  Being a mentor does not require that you actually work with
a student: we normally have many more available mentors than we do
students.  All mentor volunteers (and only mentor volunteers) will be
able to see and vote on all student project proposals.

As last year, I will act as administrator for the program and Ian will
be our backup admin.  We will acept as a mentor anybody who is listed
as a maintainer of some part of gcc in the MAINTAINERS file.  If you
are not a maintainer but still want to be a mentor, we are open to
being convinced.

To become a mentor, you need to go http://socghop.appspot.com/ and
create an account.  Then click on "Apply to become a mentor" over on
the left and select the GCC project.  If you are a returning mentor,
you can use the same login ID you created in the past.  For
documentation on applying and managing your mentor profile, see
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/userguide#depth_mentor


Thanks.  Diego.

Re: Enquiry on GSoC projects

[Diego Novillo]

On Fri, Mar 18, 2011 at 18:53, Levon Haykazyan  wrote:
> Dear gcc contributors,
>
> My name is Levon Haykazyan, I am a PhD student at Yerevan
> State University (Armenia) studying theoretical computer
> science. I am considering applying to Summer of Code for
> adding some C++0x support in gcc. I would like to ask
> potential mentors
>
> 1. which of C++0x language features are relevant as a soc
> project?

Jason (CC'd) is probably the best person to ask.  I thought there was
a wiki page describing the status of C++0x, but I can't seem to find
it (see http://gcc.gnu.org/wiki).

> 2. some guidance for a simple project to familiarize myself
> with internals of gcc and demonstrate my coding skills.

Your best bet is to start with http://gcc.gnu.org/wiki/GettingStarted

Some suggestions are listed on
http://gcc.gnu.org/projects/beginner.html as well.


Diego.

Executing already executed optimization passes again

[Niranjan Hasabnis]

Hello,

I'm using GCC plugin to do some analysis and modification on strict-RTL.
Both things are done after all optimization passes are over, and just
before strict-RTL is converted into assembly.
I would be happy to know if it is possible to execute all already
executed optimization passes again after my analysis.

I read GCC online documentation, but I could not find answer to the question.
It seems to me that pass manager also does not allow something like this.

I went through the mailing list archive to find out if this question
is already answered, but I couldn't find any.
Please forgive me if this is already answered.

--

Thanks,
Niranjan Hasabnis,
PhD student,
Stony brook University.

Re: Executing already executed optimization passes again

[Paul Koning]

I don't know the answer to your specific question, but I was wondering: if you 
think it is useful to do optimization again, I think that means that the 
transformations you have in mind should be done at an earlier stage.

By the time you hit register allocation, it's almost too late for anything.

paul

On Mar 18, 2011, at 9:03 PM, Niranjan Hasabnis wrote:

> Hello,
> 
> I'm using GCC plugin to do some analysis and modification on strict-RTL.
> Both things are done after all optimization passes are over, and just
> before strict-RTL is converted into assembly.
> I would be happy to know if it is possible to execute all already
> executed optimization passes again after my analysis.
> 
> I read GCC online documentation, but I could not find answer to the question.
> It seems to me that pass manager also does not allow something like this.
> 
> I went through the mailing list archive to find out if this question
> is already answered, but I couldn't find any.
> Please forgive me if this is already answered.
> 
> --
> 
> Thanks,
> Niranjan Hasabnis,
> PhD student,
> Stony brook University.

GNU MPFR 3.0.1 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.0.1 ("boudin aux pommes" patch level 1)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.xz
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.gz
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.zip

The MD5's:
9ffa2416f765d18a588f5ff39c26f944  mpfr-3.0.1-rc1.tar.xz
bddb9e2c121c7fe4f4b5ee41599f58b8  mpfr-3.0.1-rc1.tar.bz2
8cba3aed67c97f4edbe508e30fd0694a  mpfr-3.0.1-rc1.tar.gz
55cc8652f860d694f0d6c9e764c4523f  mpfr-3.0.1-rc1.zip

The SHA1's:
3304afd2c6c7725bfd7b45dc10a6da269ab77798  mpfr-3.0.1-rc1.tar.xz
6d2c4882f8261b8691930bb602af197f21880d7b  mpfr-3.0.1-rc1.tar.bz2
20982ab044570011ae36e4a0b6263e358e472ab8  mpfr-3.0.1-rc1.tar.gz
127046c587d7ce847bd1246a4dcdf86feab80989  mpfr-3.0.1-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1-rc1.zip.asc

Changes from version 3.0.0 to version 3.0.1:
- Bug fixes (see  or ChangeLog file).
  Note: The mpfr_subnormalize implementation up to MPFR 3.0.0 did not change
  the flags. In particular, it did not follow the generic rule concerning
  the inexact flag (and no special behavior was specified). The case of the
  underflow flag was more a lack of specification.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.0.1 should be released
around 2011-03-30.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Enquiry on GSoC projects

[Jason Merrill]

On 03/18/2011 08:14 PM, Diego Novillo wrote:

On Fri, Mar 18, 2011 at 18:53, Levon Haykazyan  wrote:

Dear gcc contributors,

My name is Levon Haykazyan, I am a PhD student at Yerevan
State University (Armenia) studying theoretical computer
science. I am considering applying to Summer of Code for
adding some C++0x support in gcc. I would like to ask
potential mentors

1. which of C++0x language features are relevant as a soc
project?


Jason (CC'd) is probably the best person to ask.  I thought there was
a wiki page describing the status of C++0x, but I can't seem to find
it (see http://gcc.gnu.org/wiki).


http://gcc.gnu.org/projects/cxx0x.html

There are a few unimplemented features left.  I'm aware of someone 
working on ref-qualifiers and someone working on attributes, but the 
others are open.


Jason