Re: Accepted applications for Google Summer of Code 2010
I added some further guidelines to the wiki from my experience this year as a reviewer and from observing other reviewers' comments. http://gcc.gnu.org/wiki/SummerOfCode. Cheers, Manuel. On 28 April 2010 01:44, Diego Novillo wrote: > This year GCC received 10 slots for Google Summer of Code. The full > list of the accepted projects is at > http://gcc.gnu.org/wiki/SummerOfCode. > > Unfortunately, we could not accept all the proposals. But that should > not discourage folks from contributing, anyway. To increase chances > of acceptance for future applications, please make sure to follow the > published guidelines. There are various resources on the net with > suggestions on how to write a solid GSoC application, which we have > listed on the GCC wiki (http://gcc.gnu.org/wiki/SummerOfCode). > > Congratulations to all the accepted applications. Looking forward to > all those contributions! > > > Diego. >
Re: Accepted applications for Google Summer of Code 2010
> This year GCC received 10 slots for Google Summer of Code. The full > list of the accepted projects is at > http://gcc.gnu.org/wiki/SummerOfCode. A quick question: Why is this list not available on the GSoC site for GCC? http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gcc For other projects, one can find the list of accepted proposals on their page, but not so for GCC (where instead one still sees the application template). Is this something the GCC mentors can influence in the web app, or should one contact the Google/Melange folks about this issue? > Congratulations to all the accepted applications. Looking forward to > all those contributions! I want to say thanks for being accepted again. This is already the fourth time I'm participating, and it has always been a pleasure to work with the GCC community (and especially the gfortran sub-community). Cheers, Janus
Re: pattern "s_" not used when generating rtl for float comparison on mips?
On 04/28/2010 03:47 AM, Amker.Cheng wrote:
You can get the RTL for these patterns when expanding stores like
a = (b < c);
In this case, GCC tries to avoid a conditional branch and (I suppose you are
on GCC<4.5) instead of cmp and b you go through cmp and
s. cmp does nothing but stashing away its operands, while
s expands RTL for both the comparison and the above insn.
Thanks, and yes, I'm using GCC 4.4,
But gcc didn't work in this way for me, I tried piece of code like:
extern float a, b;
extern int c;
int main(void)
{
c = (a < b);
return 0;
}
after tracing cc1, found gcc would also do it with set/compare/jump/set code at
the end of function do_store_flag, i.e., unsing cmp and b
sequence.
Indeed, looking at GCC 4.5 there's no cstore expander for floating-point
variables. Maybe you can make a patch! :-)
Paolo
Re: LTO question
On Tue, Apr 27, 2010 at 6:30 PM, Bingfeng Mei wrote: > Hello, > I have been playing with LTO. I notice that LTO doesn't work when > object files are achived into static library files and the final > binary is linked against them, although these object files are compiled > with -flto and I can see all the lto related sections in .a files. > Is this what is described in LTO Wiki page? > > "As an added feature, LTO will take advantage of the plugin feature > in gold. This allows the compiler to pick up object files that may > have been stored in library archives. " > > So do I have to use gold to solve this issue? Yes. Or you fix collect2 to do processing of archives and hand lto1 the required information (it expects archive components with LTO bytecode like archiv...@offset with offset being the offset of the .o file with LTO bytecode inside the archive). See lto/lto-elf.c:lto_obj_file_open for "details". Richard. > Many thanks, > Bingfeng >
Re: cpplib utf8, status?
Manuel López-Ibáñez said: (by the date of Mon, 26 Apr 2010 17:30:18 +0200)
> I added all this to the wiki for future reference:
> http://gcc.gnu.org/wiki/FAQ#utf8_identifiers
> Feel free to improve it.
Thank you :) If I optimize this more, I will add it there.
> > Joseph S. Myers said: (by the date of Mon, 26 Apr 2010 14:15:06 +
> > (UTC))
> >> By using the \u or \U syntax. For example, pipe your code
> >> through
> >>
> >> perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 :
> >> sprintf("\\U%08x", ord($1))/ge;'
Joseph, now that it works - perhaps it is possible to implement above
conversion somewhere within cpplib, or even preprocessor? Just a very
crude one, experimental, that works only with UTF-8. I could make a
lengthy lookup table, with records like Δ : \U0394
And then somewhere in preprocessor (?) or cpplib (where?) there would
be just one extra line, that would filter the input characters
assuming utf-8. A very non-portable, and a very crude solution. But
at least something to start with.
If you see a single point in the source code, where I could add such
a filter, please tell me where it is. Perhaps I'll try to make a
patch for that.
best regards
--
Janek Kozicki http://janek.kozicki.pl/
RE: LTO question
Thanks, I will check what I can do with collect2. LTO seems to save 6-9% code size for applications I tested and should be very useful for us. Bingfeng > -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: 28 April 2010 10:33 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: LTO question > > On Tue, Apr 27, 2010 at 6:30 PM, Bingfeng Mei > wrote: > > Hello, > > I have been playing with LTO. I notice that LTO doesn't work when > > object files are achived into static library files and the final > > binary is linked against them, although these object files > are compiled > > with -flto and I can see all the lto related sections in .a files. > > Is this what is described in LTO Wiki page? > > > > "As an added feature, LTO will take advantage of the plugin feature > > in gold. This allows the compiler to pick up object files that may > > have been stored in library archives. " > > > > So do I have to use gold to solve this issue? > > Yes. Or you fix collect2 to do processing of archives and hand > lto1 the required information (it expects archive components > with LTO bytecode like archiv...@offset with offset being the > offset of the .o file with LTO bytecode inside the archive). See > lto/lto-elf.c:lto_obj_file_open for "details". > > Richard. > > > Many thanks, > > Bingfeng > > > >
Re: Accepted applications for Google Summer of Code 2010
On 4/28/10 04:47 , Janus Weil wrote: > A quick question: Why is this list not available on the GSoC site for GCC? > > http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gcc Thanks for pointing that out. I simply forgot to update that page. I will update it shortly. Diego.
Re: Accepted applications for Google Summer of Code 2010
Hi folks, i'm one of the students who didn't get accepted this year, unfortunately. This doesn't lessen my motivation to get involved, though. Thus i decided to roll up my sleeves and start to work on my proposed project anyway as i think it'd be just perfect for getting familiar with the code base and the project as a whole. The project I proposed addresses RTX traversals as a possible optimization candidate for gaining some overall speedup. I plan to make the currently recursive walks over the RTL non-recursive, which does especially affect FOR_EACH_RTX and co. My proposal for GSoC is not public, so no link provided here, but if you're interested i'd be happy to send it along. I know that Paolo Bonzini tried something similar quite some time ago and i would appreciate his thoughts on what i propose here, a lot. Further, some comments of the reviewers of my proposal, whoever that might be, would be great, too. That said, i have to add that i'd appreciate some feedback by anyone of you very much :) Thanks a lot in advance, Aina On 04/28/2010 01:44 AM, Diego Novillo wrote: > This year GCC received 10 slots for Google Summer of Code. The full > list of the accepted projects is at > http://gcc.gnu.org/wiki/SummerOfCode. > > Unfortunately, we could not accept all the proposals. But that should > not discourage folks from contributing, anyway. To increase chances > of acceptance for future applications, please make sure to follow the > published guidelines. There are various resources on the net with > suggestions on how to write a solid GSoC application, which we have > listed on the GCC wiki (http://gcc.gnu.org/wiki/SummerOfCode). > > Congratulations to all the accepted applications. Looking forward to > all those contributions! > > > Diego.
Re: redundant divmodsi4 not optimized away
Hi, On Tue, 27 Apr 2010, Greg McGary wrote: > (define_insn "*udivmodsi4_libcall" > [(set (reg:SI 4) > (udiv:SI (reg:SI 1) > (reg:SI 2))) >(set (reg:SI 1) > (umod:SI (reg:SI 1) > (reg:SI 2))) >(clobber (reg:SI 2)) >(clobber (reg:SI 3)) >(clobber (reg:CC CC_REGNUM)) >(clobber (reg:SI RETURN_POINTER_REGNUM))] > "" > "call\\t__udivmodsi4" > [(set_attr "length""4")]) So, this pattern uses r2 and clobbers r2+r3. Two calls in a row can't be eliminated because the execution of one destroys one operand of the other as far as GCC knows, and the necessary copies to reload the correct value into r2 before the second call might confuse combine/CSE/DCE/whatever. At least that would be my theory to start from :) Ciao, Michael.
RE: LTO question
I just tried -fwhole-program. It can achieve extra 3%-4% saving. That is brilliant. Thanks. Bingfeng > -Original Message- > From: Jan Hubicka [mailto:hubi...@ucw.cz] > Sent: 28 April 2010 13:59 > To: Bingfeng Mei > Subject: Re: LTO question > > > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr > > and it is just for solving scaling issue of large program.(These two > > options do look similar :-). I shall try next. > > Yep, -fwhopr is not ideal name, but I guess there is not much > to do about it. > With -fwhole-program LTO should be a lot more effective. > > Honza > > > > Bingfeng > > > > > -Original Message- > > > From: Jan Hubicka [mailto:hubi...@ucw.cz] > > > Sent: 28 April 2010 12:21 > > > To: Bingfeng Mei > > > Subject: Re: LTO question > > > > > > > Thanks, I will check what I can do with collect2. LTO > > > > seems to save 6-9% code size for applications I tested > > > > and should be very useful for us. > > > Did you also tested with -fwhole-program? :) > > > > > > Honza > > > > > > > > Bingfeng > > > > > > > > > -Original Message- > > > > > From: Richard Guenther [mailto:richard.guent...@gmail.com] > > > > > Sent: 28 April 2010 10:33 > > > > > To: Bingfeng Mei > > > > > Cc: gcc@gcc.gnu.org > > > > > Subject: Re: LTO question > > > > > > > > > > On Tue, Apr 27, 2010 at 6:30 PM, Bingfeng Mei > > > > > wrote: > > > > > > Hello, > > > > > > I have been playing with LTO. I notice that LTO doesn't > > > work when > > > > > > object files are achived into static library files > and the final > > > > > > binary is linked against them, although these object files > > > > > are compiled > > > > > > with -flto and I can see all the lto related sections > > > in .a files. > > > > > > Is this what is described in LTO Wiki page? > > > > > > > > > > > > "As an added feature, LTO will take advantage of the > > > plugin feature > > > > > > in gold. This allows the compiler to pick up object > > > files that may > > > > > > have been stored in library archives. " > > > > > > > > > > > > So do I have to use gold to solve this issue? > > > > > > > > > > Yes. Or you fix collect2 to do processing of > archives and hand > > > > > lto1 the required information (it expects archive components > > > > > with LTO bytecode like archiv...@offset with offset being the > > > > > offset of the .o file with LTO bytecode inside the > archive). See > > > > > lto/lto-elf.c:lto_obj_file_open for "details". > > > > > > > > > > Richard. > > > > > > > > > > > Many thanks, > > > > > > Bingfeng > > > > > > > > > > > > > > > > > > > > > > > >
Re: Accepted applications for Google Summer of Code 2010
Aina Niemetz writes: > i'm one of the students who didn't get accepted this year, unfortunately. This > doesn't lessen my motivation to get involved, though. Thus i decided to roll > up > my sleeves and start to work on my proposed project anyway as i think it'd be > just perfect for getting familiar with the code base and the project as a > whole. > > The project I proposed addresses RTX traversals as a possible optimization > candidate for gaining some overall speedup. I plan to make the currently > recursive walks over the RTL non-recursive, which does especially affect > FOR_EACH_RTX and co. My proposal for GSoC is not public, so no link provided > here, but if you're interested i'd be happy to send it along. > > I know that Paolo Bonzini tried something similar quite some time ago and i > would appreciate his thoughts on what i propose here, a lot. Further, some > comments of the reviewers of my proposal, whoever that might be, would be > great, > too. That said, i have to add that i'd appreciate some feedback by anyone of > you > very much :) Thanks for your continued interest. I think your proposal is a good one. I think there were two reasons that it didn't make the top ten. The first is a question of scope: it seems like a project that should take a couple of weeks, rather than the whole summer. The second is that it's not clear that it really will save compilation time; recursion is not typically the fastest algorithm, but in order to walk RTL you need to keep some form of stack. When you have a trial implementation you will have to do some measurements to confirm that it is better. Ian
Re: LTO question
On 28/04/2010 10:44, Bingfeng Mei wrote: > Thanks, I will check what I can do with collect2. I was also planning to work on this, but won't have any objection if you get there before me! We have an open PR about this, would you care to use http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376 to co-ordinate? cheers, DaveK
RE: LTO question
Thanks. I am not very familiar with ELF/lto format etc. But making LTO work for our port is definitely in high priority. I shall see what I can achieve in next weeks. Bingfeng > -Original Message- > From: Dave Korn [mailto:dave.korn.cyg...@googlemail.com] > Sent: 28 April 2010 14:59 > To: Bingfeng Mei > Cc: Richard Guenther; gcc@gcc.gnu.org > Subject: Re: LTO question > > On 28/04/2010 10:44, Bingfeng Mei wrote: > > Thanks, I will check what I can do with collect2. > > I was also planning to work on this, but won't have any > objection if you get > there before me! We have an open PR about this, would you care to use > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376 > > to co-ordinate? > > cheers, > DaveK > > >
scheduler dependency bug in the presence of var_location and unspec_volatile
Hello,
I saw a bug in sched1 where it reorders two unspec_volatile
instructions. These instructions do port communications (from the same
port) and doing them in the wrong order is unacceptable. I digged a bit
deeper to see what is happening. Going into sched1, the relevant bit of
basic block is
(debug_insn 184 183 185 12 autogenerated_UlSymbolRateCtrlDummy.c:58
(var_location:SI converter$rawValue (unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) -1 (nil))
(insn 185 184 186 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:58
(set (subreg:SI (reg/v:DI 299 [ trchHeader ])
0)
(unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) 80 {commsGet} (nil))
(note 186 185 188 12 NOTE_INSN_DELETED)
(note 188 186 189 12 NOTE_INSN_DELETED)
(insn 189 188 190 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:58
(set (reg:HI 280 [ trchHeader$D1530$channelCodingEnum ])
(lshiftrt:HI (subreg:HI (reg/v:DI 299 [ trchHeader ]) 0)
(const_int 14 [0xe]))) 64 {lshrhi3} (nil))
(debug_insn 190 189 191 12 (var_location:QI
trchHeader$D1530$channelCodingEnum (subreg:QI (reg:HI 280 [
trchHeader$D1530$channelCodingEnum ]) 0)) -1 (nil))
(debug_insn 191 190 192 12 (var_location:QI
trchHeader$D1530$channelCodingEnum (subreg:QI (reg:HI 280 [
trchHeader$D1530$channelCodingEnum ]) 0)) -1 (nil))
(note 192 191 193 12 NOTE_INSN_DELETED)
(debug_insn 193 192 194 12 autogenerated_UlSymbolRateCtrlDummy.c:58
(var_location:SI converter$rawValue (unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) -1 (nil))
(insn 194 193 195 12
/home/gccuser/systems/products/lib/umtsfdd/rel8_200903/uplink/UlSymbolRate/src/UlSymbolRateCtrlDummy.c:59
(set (subreg:SI (reg/v:DI 299 [ trchHeader ]) 4)
(unspec_volatile:SI [
(const_int 3 [0x3])
] 8)) 80 {commsGet} (nil))
Note that 185 and 194 are the actual port communication instructions
here. If i look at the scheduler forward dependency for this basic block
(at sched1), it looks like this
;; ==
;; -- basic block 12 from 185 to 212 -- before reload
;; ==
;; --- forward dependences:
;; --- Region Dependences --- b 12 bb 0
;; insn codebb dep prio cost reservation
;; -- --- ---
;; 1858012 0 2 1 slot1 : 212 193 191
190 189
;; 1896412 1 1 1 slot0|slot1 : 212 193 191 190
;; 190-112 2 0 0 nothing : 193 191
;; 191-112 3 0 0 nothing : 193
;; 193-112 4 0 0 nothing : 199 194
;; 1948012 0 5 1 slot1 : 212 206 205
204 203 202 201 200 199 198
;; 1986412 1 4 1 slot0|slot1 : 212 206 202
200 199
;; 199-112 3 0 0 nothing : 206 200
;; 200-112 3 0 0 nothing : 206 201
;; 201-112 2 0 0 nothing : 206 202
;; 202-112 3 0 0 nothing : 206 203
;; 203-112 2 0 0 nothing : 206 204
;; 204-112 2 0 0 nothing : 206 205
;; 205-112 2 0 0 nothing : 207 206
;; 2068212 2 3 1 slot1 : 212 210 209
208 207
;; 207-112 2 0 0 nothing : 210 208
;; 208-112 2 0 0 nothing : 210 209
;; 209-112 2 0 0 nothing : 211 210
;; 2108212 1 2 1 slot1 : 212 211
;; 211-112 2 0 0 nothing :
;; 212 712 6 1 1 (slot0+slot1+slot2) :
;; dependencies resolved: insn 185
;; tick updated: insn 185 into ready
;; dependencies resolved: insn 194
;; tick updated: insn 194 into ready
;; Advanced a state.
;; Ready list after queue_to_ready:194:87 185:82
;; Ready list after ready_sort:185:82 194:87
;; Clock 0
;; Ready list (t = 0):185:82 194:87
;; Chosen insn : 194
;;0--> 194 r299#4=unspec/v[0x3] 8:slot1
;; resetting: debug insn 193
Note that there is a dependency 185->193->194. Insn 193 is a debug_insn
for var_location. When we actually get to scheduling, we seem to ignore
this dependency and put both 185 and 194 into ready state and 194 gets
picked, causing my test to go wrong.
I do not have much experience working
Re: LTO question
>> > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr >> > and it is just for solving scaling issue of large program.(These two >> > options do look similar :-). I shall try next. >> >> Yep, -fwhopr is not ideal name, but I guess there is not much >> to do about it. It is marked as experimental, so if it is going to stay for GCC 4.6, then we should change the name. I think one possibility discussed somewhere is that LTO scales back automatically, so the option would be not necessary. Cheers, Manuel.
Re: LTO question
On 4/28/10 10:26 , Manuel López-Ibáñez wrote: Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr and it is just for solving scaling issue of large program.(These two options do look similar :-). I shall try next. >>> >>> Yep, -fwhopr is not ideal name, but I guess there is not much >>> to do about it. > > It is marked as experimental, so if it is going to stay for GCC 4.6, > then we should change the name. I think one possibility discussed > somewhere is that LTO scales back automatically, so the option would > be not necessary. Yes. I think we should just keep -flto and make it use split compilation if needed. -fwhopr is only needed to explicitly enable it. My suggestion is to just keep -flto and invoke whopr with -flto=split or -flto=big (until the automatic threshold is added). Diego.
gcc dependency on unsigned mpc releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am just following up on my earlier email to mpc-discuss to check if some signatures can be made available for the mpc tarballs. Currently it's not possible to install the latest gcc without the risk of using unsigned code. Thanks. - -- Brian Gough -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iJwEAQECAAYFAkvYWhsACgkQ9U2K2oCCH+r+7AP/b/KnQGMhIgusSe9l8wZQ9cP1 HgeG0s1cDrjqi3jrDtNy8OlvVMaeqYbByWu/sLKwfCCkB+db2KD10MQSBhfzMKV7 ER9IQXpQPu24NxiPvWhP/wSJJd7/WqvlNqwxpcvXG30iiw0kQT5wmt28if7n8ojc YIDH7wJYNZcKonD5P/U= =eON1 -END PGP SIGNATURE-
Re: redundant divmodsi4 not optimized away
On 04/28/10 05:58, Michael Matz wrote: On Tue, 27 Apr 2010, Greg McGary wrote: (define_insn "*udivmodsi4_libcall" [(set (reg:SI 4) (udiv:SI (reg:SI 1) (reg:SI 2))) (set (reg:SI 1) (umod:SI (reg:SI 1) (reg:SI 2))) (clobber (reg:SI 2)) (clobber (reg:SI 3)) (clobber (reg:CC CC_REGNUM)) (clobber (reg:SI RETURN_POINTER_REGNUM))] "" "call\\t__udivmodsi4" [(set_attr "length""4")]) So, this pattern uses r2 and clobbers r2+r3. Two calls in a row can't be eliminated because the execution of one destroys one operand of the other as far as GCC knows, and the necessary copies to reload the correct value into r2 before the second call might confuse combine/CSE/DCE/whatever. At least that would be my theory to start from :) The libcall insn above appears only after reload, as the result of a split. All the CSE passes occur before reload when the insn pattern is this: [(set (match_operand:SI 0 "gen_reg_operand" "=r") (udiv:SI (match_operand:SI 1 "gen_reg_operand" "r") (match_operand:SI 2 "gen_reg_operand" "r"))) (set (match_operand:SI 3 "gen_reg_operand" "=r") (umod:SI (match_dup 1) (match_dup 2))) (clobber (reg:SI 1)) (clobber (reg:SI 2)) (clobber (reg:SI 3)) (clobber (reg:SI 4)) (clobber (reg:CC CC_REGNUM)) (clobber (reg:SI RETURN_POINTER_REGNUM))] G
Widening multiplications (was: Re: GCC porting tutorials)
> Date: Tue, 27 Apr 2010 20:41:47 +0200 (CEST)
> From: "Jonas Paulsson"
> I've been following the discussion a bit about contributing, and find
> myself here now even directly pointed at :-) As I mentioned, I am not very
> experienced with GCC, for one thing I have not studied other ports very
> much. To make a GCC patch for this problem to be generally handled is then
> a bit over my head, but perhaps with some mentoring from someone with
> enough experience, I could give it a try!
I'd be happy to help where I can, but I should say I'm not a
tree (gimple, SSA) aficionado.
As a first step, enter a bug report with actual C source (and
the emitted assembly code) showing the lack of widening
multiplication instructions (those [su]mulsi{di3|3_highpart}) in
a context where they should be emitted but aren't (in a loop),
and where they with a small modification are (loop removed).
Pick a familiar target with widening multiplications. It should
come as no surprise that I'd choose CRIS v32 (at least v8), but
for example i386, MIPS and ARM have these instructions as well.
Bonus points if the code shows the general problem for more than
one architecture (shouldn't be a problem, and I think target
maintainers will chime in here). Please do this for current
source trunk, but certainly okay if you do it *also* for a
branch or a release.
> The solution of handling this during expansion that I used, is not wrong
> the way I see it.
Then by all means, pursue. I couldn't see any immediate errors.
The tree-people will most likely make themselves heard, not the
least if the solution is wrong. Beware: you might not get a
clear go-ahead just on a high-level proposal. Be prepared to
code and then rewrite if the suggested solution is judged to be
Not the Right Thing at the higher level.
By the way, this is a good time for getting the copyright
assignment paperwork done. If you wait until code is written,
the paperwork might take long enough that you lose interest or
something else happens; it *can* take months. Mention current
employment status to get the right papers.
brgds, H-P
Re: cpplib utf8, status?
On Mon, 26 Apr 2010, Manuel López-Ibáñez wrote: > http://gcc.gnu.org/wiki/FAQ#utf8_identifiers How is a question that's been asked once a FAQ? :-) Seriously, that's been a problem with the original FAQ, we just got too many things there which would age and become outdated without being maintained (until I started removing them piece by piece). Gerald
Re: cpplib utf8, status?
Gerald Pfeifer said: (by the date of Wed, 28 Apr 2010 19:22:28 +0200 (CEST)) > On Mon, 26 Apr 2010, Manuel López-Ibáñez wrote: > > http://gcc.gnu.org/wiki/FAQ#utf8_identifiers > > How is a question that's been asked once a FAQ? :-) Seriously, that's > been a problem with the original FAQ, we just got too many things there > which would age and become outdated without being maintained (until I > started removing them piece by piece). I received my answer, so I don't care whether it's there or not. And also googling for gcc utf8 cpplib already points to this thread, so it's easy to find this answer anyways. Now if only I knew where to implement that perl filter inside gcc's source code. I'd would perhaps give it a try :) -- Janek Kozicki http://janek.kozicki.pl/ |
Re: Accepted applications for Google Summer of Code 2010
On 04/28/2010 01:44 AM, Diego Novillo wrote: This year GCC received 10 slots for Google Summer of Code. [ This is probably documented on the Google site somewhere, but I couldn't find it. ] How is this division in "projects" determined ? What makes GCC "good for" 10 slots ? [ I was on the 2002 "Freenix" parallel-to-the-ordinary-Usenix program committee, and I remember the 3 day ordeal of figuring out which talks (sooo diverse) to accept ... ] -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: Accepted applications for Google Summer of Code 2010
On Wed, Apr 28, 2010 at 11:34:43AM -0700, Toon Moene wrote: > On 04/28/2010 01:44 AM, Diego Novillo wrote: > > > This year GCC received 10 slots for Google Summer of Code. > > [ This is probably documented on the Google site somewhere, >but I couldn't find it. ] > > How is this division in "projects" determined ? > > What makes GCC "good for" 10 slots ? It's Google's money, so they get to decide. Also, one of the "GCC projects" appears to be a binutils project.
Re: GCC porting tutorials
On 04/27/2010 08:41 PM, Jonas Paulsson wrote: >> I've recently been bitten by the lost-widening-multiplication- >> when-in-loop issue myself, and noted it for revisit Some Day. >> Fixing that by other means made a whopping 27% improvement for >> the application where I saw it: a hot loop doing a MDCT using >> Q31 fixed-point, where a common operation is to widen-multiply >> two 32-bit numbers and pick the high 32 bits of the 64-bit >> result (being the result divided by 2; i.e. Q30-ish for that >> operation). >> >> brgds, H-P Widening multiplies should work again after r158633 and 158643. If there are cases that still don't work for you, please file bugzilla PRs. Bernd
Re: Accepted applications for Google Summer of Code 2010
Toon Moene writes: > On 04/28/2010 01:44 AM, Diego Novillo wrote: > >> This year GCC received 10 slots for Google Summer of Code. > > [ This is probably documented on the Google site somewhere, > but I couldn't find it. ] > > How is this division in "projects" determined ? > > What makes GCC "good for" 10 slots ? Basically, all the organizations accepted to Summer of Code look at their applications and decide how many applications they got that they think are good and that they can handle. Google's Open Source Program Office (which is a completely different set of people from the Google engineers who work on gcc) takes all those numbers into a room, plus the number of overall slots that Google has agreed to fund. They do some magic process divvying up the available slots among the numbers that the organizations request. One reason GCC got more slots than we did in previous years is that we got more good applications, and we asked for more slots. It's also possible that other organizations asked for fewer slots, I have no idea. Ian
Re: Accepted applications for Google Summer of Code 2010
On 4/28/10 14:34 , Toon Moene wrote: > What makes GCC "good for" 10 slots ? It's based on two things: the number of projects that the organization thinks it can handle (which each org determines) and available funding from GSoC. Each organization ranks all the project proposals and decides how many they could accept. GSoC will then try to accommodate the organization by providing funding for those proposals (or fewer, depending on availability). Diego.
Re: LTO question
> On 4/28/10 10:26 , Manuel López-Ibá?ez wrote: > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr > and it is just for solving scaling issue of large program.(These two > options do look similar :-). I shall try next. > >>> > >>> Yep, -fwhopr is not ideal name, but I guess there is not much > >>> to do about it. > > > > It is marked as experimental, so if it is going to stay for GCC 4.6, > > then we should change the name. I think one possibility discussed > > somewhere is that LTO scales back automatically, so the option would > > be not necessary. > > Yes. I think we should just keep -flto and make it use split > compilation if needed. -fwhopr is only needed to explicitly enable it. > My suggestion is to just keep -flto and invoke whopr with -flto=split > or -flto=big (until the automatic threshold is added). Yep, I like this idea too. I hope to be able to drop "experimental" status from mainline whopr soonish (basically I need to implement references and then I will burn a lot of time fixing how clones are streamed to enable ipa-cp). We probably want something like -flto for "do whatever you think is best" (it will be interesting to unify the paths enough so WPA can decide to be LTO at its will after reading in cgraph and concluding on program size) -flto=n to force whopr optimized for N parallel coputations (we probably will end up with more than N units for sufficiently large programs since we anyway can't resonably expect that compile times will be even). -flto=incremental to force inremental LTO. Honza > > > Diego.
Re: LTO question
> > On 4/28/10 10:26 , Manuel López-Ibá?ez wrote: > > Not yet, I mistakenly thought -fwhole-program is the same as -fwhopr > > and it is just for solving scaling issue of large program.(These two > > options do look similar :-). I shall try next. > > >>> > > >>> Yep, -fwhopr is not ideal name, but I guess there is not much > > >>> to do about it. > > > > > > It is marked as experimental, so if it is going to stay for GCC 4.6, > > > then we should change the name. I think one possibility discussed > > > somewhere is that LTO scales back automatically, so the option would > > > be not necessary. > > > > Yes. I think we should just keep -flto and make it use split > > compilation if needed. -fwhopr is only needed to explicitly enable it. > > My suggestion is to just keep -flto and invoke whopr with -flto=split > > or -flto=big (until the automatic threshold is added). > > Yep, I like this idea too. I hope to be able to drop "experimental" status > from mainline whopr soonish (basically I need to implement references and then > I will burn a lot of time fixing how clones are streamed to enable ipa-cp). And do something about paralelizing the whopr build. I guess it means storing ltrans partition list into file and making collect2 to execute compilation and re-invent the Makefile code? It would be great if someone took look at this, I am not at all familiar with that code and in a way I would preffer it to stay that way ;)) Honza
Re: GCC porting tutorials
It feels good to know that the widening mults issue has been resolved as it was a bit of a disapointment I noted the erratic behaviour with GCC 4.4.1. Perhaps you would care to comment on what to expect as a user now, then? Another issue that gave me porting problems was the SIMD memory accesses, for e g doing a wide load into two adjacent narrow registers with one instruction. This was resolved earlier on the mailinglist to not be handleable on RTL, so I wonder now if anything has been done for this, as it too seems rather reasonable, just like the widening loads? /Jonas Paulsson > On 04/27/2010 08:41 PM, Jonas Paulsson wrote: > >>> I've recently been bitten by the lost-widening-multiplication- >>> when-in-loop issue myself, and noted it for revisit Some Day. >>> Fixing that by other means made a whopping 27% improvement for >>> the application where I saw it: a hot loop doing a MDCT using >>> Q31 fixed-point, where a common operation is to widen-multiply >>> two 32-bit numbers and pick the high 32 bits of the 64-bit >>> result (being the result divided by 2; i.e. Q30-ish for that >>> operation). >>> >>> brgds, H-P > > Widening multiplies should work again after r158633 and 158643. If > there are cases that still don't work for you, please file bugzilla PRs. > > > Bernd > >
