Re: Long paths with ../../../../ throughout
On 27 April 2010 02:16, Dave Korn wrote: > Here, sometimes it's easier to show than to explain in terms of rules: The wiki link has a template and an example. If you think it can be improved, please do so. > Summary: Asterisks are only used for the first line of each file's changes. > TABs at the start of every line. Place the name of the affected entity - > function, variable or macro - in brackets at the start of each line, colon, > space, then say what not why. I will add this as well to the wiki link. Cheers, Manuel.
Re: Why not contribute? (to GCC)
[trimming Cc list] It wouldn't be worth my time and I have trouble understanding how I could demonstrate personal loss making the law suit worth persuing in the first place. Perhaps because you know the code better than anyone else, so you could provide paid support on that derivative as well. This is true whether the code is GPL or truly free. First of all, let's avoid equivocal language (and politics). you'll probably agree that the meaning of "truly free" is in the eye of the beholder. So, let's simplify things and say BSD. The difference is that if that for BSD code the other person has the right to close up the derivative, and you know that in this case you won't be able to provide any kind of paid support. (There's also the case of someone copylefting the derivative; how to approach this case is a wholly different topic). In the case of the GPL, the other person is violating your copyright. You may decide to let it go, but if your or your company's finances depend on providing paid support for that project, or on dual licensing it as GPL/commercial, he's hurting you. Or maybe because you have to. There was a case of a free software project (JMRI) being sued for patent infringement by a proprietary software company. It turned out that the proprietary software included source code from the free software project without attribution (copyleft was not even necessary, as the project was under the Artistic License!). In this case, the possibility to counter-sue saved the free software programmer from having to pay millions of dollars. I think this might be an over simplification. There were many statements in this history (new to me - just read it all - good read) that demonstrate that the patents were incorrectly granted. The copyright issue was involved, and the defense of free / open source copyrights was involved, but it looks pretty clear to me that JMRI wanted to shut down *all* violations. They wanted the incorrectly granted patents dropped, and they wanted their copyrights held intact. Was the latter required for the former victory, or was that just how things played out? From my understanding, it was the easiest way to get the case settled. I'll also note that even if it was required, it was the Artistic License, and it was demonstrated as being valid in a court of law. Yes, I mentioned it above. My points were basically two: 1) patents are a big threat to free/open source software, so it's better to keep our main counter-weapon (copyright) strong. 2) you might be forced to sue even for violation of a permissive license, so watering down the ability to defend your rights may turn out to be a bad idea, even if you choose to skip copyleft. I hope nothing of this happens to anyone involved in this thread, of course! Paolo
Re: vectorization, scheduling and aliasing
Hi,
I have looked a bit more and tried also ia-64 and bfin and actually I
can't find a single example where vectorized code using __restrict__
variables would break the dependency between stores and loads.
for this simple program:
unsigned short xxx(unsigned short* __restrict__ a, unsigned short*
__restrict__ b)
{
int i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
return 0;
}
After unrolling and vectorization I get for all architectures that
there is a dependency between the first store (to a) and the second
load (from b).
since these are restrict variables I think this behavior is incorrect.
Can someone please show me such an example? Or is this feature not yet
supported?
Thanks, Roy.
LLVM 2.7 Released
Hi All, For anyone interested, LLVM 2.7 was just released. You can read the announcement here: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2010-April/34.html and read much more detailed release notes here: http://llvm.org/releases/2.7/docs/ReleaseNotes.html In addition to a huge assortment of improvements and new features, this is the first release to officially include the DragonEgg GCC plugin. See http://dragonegg.llvm.org/ for more details. -Chris
Re: LLVM 2.7 Released
> and read much more detailed release notes here: > http://llvm.org/releases/2.7/docs/ReleaseNotes.html The correct writing of GCC is "GCC", all capitalized. In particular "gcc-4.5" should be written GCC 4.5 (like LLVM 2.7). -- Eric Botcazou
pattern "s_" not used when generating rtl for float comparison on mips?
Hi : There is a pattern "define_insn "s_"" in mips md file, like (define_insn "s_" [(set (match_operand:CC 0 "register_operand" "=z") (swapped_fcond:CC (match_operand:SCALARF 1 "register_operand" "f") (match_operand:SCALARF 2 "register_operand" "f")))] "" "c..\t%Z0%2,%1" [(set_attr "type" "fcmp") (set_attr "mode" "FPSW")]) I am wondering whether this insn pattern would ever be used when generating float comparison, Since we use cmp and branch expand to do the job And comparison operation are normally followed by a branch. Am i right? Any idea? Thanks for helping. -- Best Regards.
Re: Why not contribute? (to GCC)
> To stay US-centric, have a look at: > http://www.copyright.gov/title17/92chap5.html > > Any law that makes something illegal has to define the available > penalties associated. You are confusing criminal and civil law. What you say is certainly true for criminal law, where the other party is the government. But in a civil dispute between two entities, there are few limits on what can be ordered to remedy an "injury". What you site are a list (not meant to be complete) of possible sanctions in the case of pure copyright infringement. But normally when there's a copyright dispute between two entities, there are OTHER claims alleged too. This is getting WAY off topic ...
RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Hi all, I created the page on GCC Wiki with this info: http://gcc.gnu.org/wiki/GCC_Research Please, feel free to update or rewrite completely (if you feel that something is wrong, etc)... Hope it will be of any use ;) ... Cheers, Grigori -Original Message- From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] Sent: Friday, April 16, 2010 6:51 PM To: Grigori Fursin Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.ro...@inria.fr; David Edelsohn Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) On 16 April 2010 13:21, Grigori Fursin wrote: > > I think, the main problem for students and researchers is that they > see lots of stuff going on with GCC and on mailing lists but they may > be shy/scared/not sure where to start if they want to contribute > or even if they will be welcome to contribute. The reason is that > some of their ideas/work may not be necessarily immediately useful to the > community > and they may be concerned that they can get lots of aggressive, negative > feedback That is why mentoring could be helpful. Technical discussions by email sometimes appear harsh and dry to newcomers. Moreover, negative opinions are more vocal than positive ones. So something that most people think is a good idea or they are indifferent may only get negative feedback from a few. > no matter how useful they are in the future. However, such feedback can > immediately > drive away young and motivated students who can otherwise become really active > contributors (look at the GRAPHITE and students contributing to GCC now, for > example). > > So, what I think could be useful, is to try to agree on what can be > some general common suggestions/recommendations to students/researchers A short list out of the top of my head for proposing ideas in gcc mailing lists: * If you do not have the time/resources/people to implement your own idea, do not expect GCC developers dropping what they are doing to help you. Volunteers have very very limited time and paid developers are paid to do something else. In fact, asking GCC developers to do anything for you, no matter how trivial it seems to you, will likely result in negative feedback. Probably it is no trivial at all. * if your idea may potentially slow down the compiler, increase memory consumption, increase complexity, remove features, or change defaults, it will receive negative feedback. Guaranteed. If you are sure that this is not the case or that the benefits outweigh the drawbacks, but GCC developers disagree, discussion is not going to solve it. The only way is to implement your idea (or a working prototype) and give substantial experimental evidence in many scenarios/targets that you are right. * If you have a great idea implemented and provide a substantial patch, expect negative feedback. There are many ongoing projects in GCC. A patch that comes out of the blue and breaks those projects will not be welcome by the people working on those projects. * Your email/patch may not receive much feedback. This may happen if you provide your idea in an old thread (people stop reading long threads after a while), your subject line was not interesting/descriptive enough (I do not read all emails from the list), the main audience of your email just missed/overlooked it by chance (bad luck, busy period, vacations), your email was too long (people stopped reading before reaching the interesting part), ... The only feasible choice is to try again sometime later with an improved message. * There is also the IRC channels (http://gcc.gnu.org/wiki), which are more interactive, but the same rules apply to them. Specially being ignored despite people talking to each other. That is because people are working, and sometimes they have deadlines, urgent stuff to do, they want to go home early... * Read the gcc and the gcc-patches lists for a while to get to know how things work and who is who. I am sure there are many more little rules-of-thumb I can come up with. > who may want to contribute but not sure how to approach GCC community. > Maybe we can make a page on GCC Wiki with such recommendations or even Anyone can edit the wiki, so be my guest. > maybe make a separate pre-processing mailing list for > novel/crazy/future/unclassified > ideas so that only those of you who are interested in that can follow/discuss > them > and from time to time approach this mailing list with already mature ideas > to avoid bothering others who are distracted by such discussions on this > mailing list? An example of how *not* to get things done is this "maybe we" attitude. It is likely to get no feedback, negative feedback, or positive feedback that sounds a bit negative (like my "be my guest" above for the wiki page): * It does not specify who is "we". It could be understood as asking the reader to do something that takes time and effort. Everybody is busy already, so bad strategy. It can also be understood as only you or people that
The usage of the "clobber "match_scratch""
Hi. Right now I know confused by the usage of "clobber "match_scratch"". The scene is as follows: 1.Target cpu is with only a 8 bit ACC register( but I make 16 virtual registers, for reload problems). 2.For HImode operands, I let them never to goto ACC combined with other virtual registers. 3.for addhi operations, the ACC reg needs to be the source/destine register, and the "addhi" operation needs to be performed by 2 "8 bit add" insns, for example: for virtual register reg: HI VR0 = reg: HI VR0 + reg: HI VR2 VR0 for low part of reg:HI VR0, VR1 for high part of reg:HI VR0, VR2 for low part of reg:HI VR2, VR3 for high part of reg:HI VR2, MOV ACC,VR0 <---mov VR0 to ACC ADD ACC, VR2 <---ACC= ACC+ VR2 MOV VR0,ACC <---VR0= ACC MOV ACC, VR1<---mov VR1 to ACC ADDC ACC, VR3 <---ACC= ACC+ VR3 MOV VR1, ACC
Re: pattern "s_" not used when generating rtl for float comparison on mips?
On 04/27/2010 11:42 AM, Amker.Cheng wrote: Hi : There is a pattern "define_insn "s_"" in mips md file, like (define_insn "s_" [(set (match_operand:CC 0 "register_operand" "=z") (swapped_fcond:CC (match_operand:SCALARF 1 "register_operand" "f") (match_operand:SCALARF 2 "register_operand" "f")))] "" "c..\t%Z0%2,%1" [(set_attr "type" "fcmp") (set_attr "mode" "FPSW")]) I am wondering whether this insn pattern would ever be used when generating float comparison, Since we use cmp and branch expand to do the job And comparison operation are normally followed by a branch. Am i right? 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. For GCC >=4.5 there is no cmp anymore, and branches and store go through cbranch4 and cstore4 respectively. The logic however is the same, with cstore4 emitting the RTL for both the comparison and the conditional store. Hope this helps, Paolo
Re: Why not contribute? (to GCC)
On 04/27/2010 03:46 AM, Russ Allbery wrote: This is all relatively easily handled under the copyright policy on the academic side of the house for students and faculty. Unless it's "institutional work"... I was in the same boat during my own Ph.D. studies, cherrypicking what to send for inclusion into FSF GCC and what not. It just shows that the handling of the disclaimer is not at all black-and-white and very much left to the whims of the contributor. BTW, thanks for the detailed answer, I did read it entirely and it was very interesting. Paolo
Re: The usage of the "clobber "match_scratch""
redriver jiang writes:
> test3.c:27: error: insn does not satisfy its constraints:
> (insn 52 51 32 0 (parallel [
> (set (reg:HI 16 BASE0)
> (plus:HI (reg:HI 16 BASE0)
> (const_int -2 [0xfffe])))
> (clobber (scratch:QI))
> ]) 9 {*addhi3} (nil)
> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 20 BASE2)
> (const_int -2 [0xfffe]))
> (nil)))
> test3.c:27: internal compiler error: in reload_cse_simplify_operands,
> at postreload.c:391
Looks like this insn didn't get a register at all. Reload can
sometimes generate add insns directly, which could perhaps cause this
to happen.
> I think I may not understand the usage of "match_scratch" properly,
> and I make the ACC hard register to be clobbered in rtl generation
> pass:
>
> (define_expand "addhi3"
> [(parallel [(set (match_operand:HI 0 "nonimmediate_operand" "")
> (plus:HI (match_operand:HI 1 "nonimmediate_operand" "")
> (match_operand:HI 2 "general_operand"
> "")))
> (clobber (reg: QI REG_ACC))])]
> ""
> "")
>
> the former problem disappeared.
I would do it that way. There isn't too much point to forcing the
register allocator to allocate a scratch register when you already
know what the register has to be. It can make sense to allocate a
normal register even if the register is fixed, because that will let
reload move the value onto the stack if necessary. But I can't see
any reason to allocate a fixed scratch register.
Ian
Re: Long paths with ../../../../ throughout
On 27/04/2010 08:17, Manuel López-Ibáñez wrote: > On 27 April 2010 02:16, Dave Korn wrote: >> Here, sometimes it's easier to show than to explain in terms of rules: > > The wiki link has a template and an example. If you think it can be > improved, please do so. I hadn't even read it at that point, I just wanted to do Jon's changelog for him so that he didn't have to go through another round of revisions! > I will add this as well to the wiki link. Thanks. I couldn't think of much else to say so I added a link to the GCS :) cheers, DaveK
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On 27 April 2010 14:27, Grigori Fursin wrote: > Hi all, > > I created the page on GCC Wiki with this info: > http://gcc.gnu.org/wiki/GCC_Research > > Please, feel free to update or rewrite completely > (if you feel that something is wrong, etc)... > I think that a verbatim copy of the email seems like something set on stone, when in fact it is just my opinion and not as well written as it could have been. I converted it to a set of bullet points so people can add/remove/edit more freely. Cheers, Manuel.
LTO question
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? Many thanks, Bingfeng
Thanks GSoC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey I want to say a quick thank you for accepting my proposal "Partial Implementation of Python as a GCC Front-end". Can't wait to get started :). - --Phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXFL0ACgkQAhcOgIaQQ2HBWACgjGcGA5eZagf4Wcmob+Znu3G4 rgsAn06a1BbXLsmAfKUwm3BXVyR8d0Lz =N0Nv -END PGP SIGNATURE-
Re: redundant divmodsi4 not optimized away
On 04/26/10 22:09, Ian Lance Taylor wrote: Greg McGary writes: I have a port without div or mod machine instructions. I wrote divmodsi4 patterns that do the libcall directly, hoping that GCC would recognize the opportunity to use a single divmodsi4 to compute both quotient and remainder. Alas, GCC calls divmodsi4 twice with the same divisor and dividend operands. Is this supposed to work? Is there a special trick to help the optimizer recognize the redundant insn? I saw the 4yr-old thread regarding picochip's desire for the same effect and followed the same approach implemented in the current picochip.md (as well as my own approach) but no luck. Using a divmodsi4 insn instead of divsi3/modsi3 insns ought to work. You may need to give more information, such as the test case you are using, and what your divmodsi4 insn looks like. Ian The test case is __udivmoddi4 from libgcc2.c, specifically the macro __udiv_qrnnd_c from longlong.h, which does this: __r1 = (n1) % __d1; __q1 = (n1) / __d1; ... and this ... __r0 = __r1 % __d1; __q0 = __r1 / __d1; Below is my original insn set. The __udivmodsi4 libcall accepts operands in r1/r2, then returns quotient in r4 and remainder in r1 (define_insn_and_split "udivmodsi4" [(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))] "" "#" "reload_completed" [(set (reg:SI 1) (match_dup 1)) (set (reg:SI 2) (match_dup 2)) (parallel [(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))]) (set (match_dup 0) (reg:SI 4)) (set (match_dup 3) (reg:SI 1))]) (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")]) Here is an alternative patterned after the approach in picochip.md. I had hoped since the picochip guys reported the same trouble four years ago, the current picochip.md might have the magic bits. (define_expand "udivmodsi4" [(parallel [(set (reg:SI 1) (match_operand:SI 1 "gen_reg_operand" "r")) (clobber (reg:CC CC_REGNUM))]) (parallel [(set (reg:SI 2) (match_operand:SI 2 "gen_reg_operand" "r")) (clobber (reg:CC CC_REGNUM))]) (parallel [(unspec_volatile [(const_int 0)] UNSPEC_UDIVMOD) (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))]) (set (match_operand:SI 0 "gen_reg_operand" "=r") (reg:SI 4)) (set (match_operand:SI 3 "gen_reg_operand" "=r") (reg:SI 1))]) (define_insn "*udivmodsi4_libcall" [(unspec_volatile [(const_int 0)] UNSPEC_UDIVMOD) (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")]) Alas, neither of them eliminates the redundant libcall. If no clues are forthcoming, I'll begin debugging CSE. G
RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
Looks good! Thanks! By the way, I sent it to the HiPEAC mailing lists too ... Cheers, Grigori -Original Message- From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] Sent: Tuesday, April 27, 2010 6:02 PM To: Grigori Fursin Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.ro...@inria.fr; David Edelsohn Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) On 27 April 2010 14:27, Grigori Fursin wrote: > Hi all, > > I created the page on GCC Wiki with this info: > http://gcc.gnu.org/wiki/GCC_Research > > Please, feel free to update or rewrite completely > (if you feel that something is wrong, etc)... > I think that a verbatim copy of the email seems like something set on stone, when in fact it is just my opinion and not as well written as it could have been. I converted it to a set of bullet points so people can add/remove/edit more freely. Cheers, Manuel.
Re: GCC porting tutorials
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! Problem: even if a widening pattern is defined in the .md-file, it may not end up being used, as it should per definition if it is prior to other mul-patterns in the file. If it is located afterwards, then it may be a matter of discussion, if one would not like to consider these preferable. The solution of handling this during expansion that I used, is not wrong the way I see it. Since more than one Gimple pass is involved in this problem - rewriting the code so that the RTL-expander will use a wide mult-insn - it seems quite logical to simply undo this during expansion in terms of reactivating the original operands. Much simpler to have this fix in one place, as it is a bit of a side issue, I think. I would like to see that all widening mult-patterns defined prior to wide mult-patterns in the .md file, end up being used when feasable - this is logical. An extended solution to what I used could perhaps do this work prior to emitting wide mult-insns: 1. initialization: generate extension RTL, so that the extending insns (lists) can be recognized on each target. 2. prior to expanding a multiplication: if widening mult-pattern that suits the mode is defined try to find both operands origins of extension per point 1. if both operands extended: emit widening pattern else emit wide pattern I am not certain this is a complete solution, it is merely my immediate thoughts, so please correct me. If somebody believes in correcting this GCC behaviour and have the time to guide me, I would be happy to participate. /Jonas >> From: "Jonas Paulsson" >> Date: Mon, 26 Apr 2010 11:07:04 +0200 > >> I recently completed my degree project on LTH on retargeting GCC. See >> http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved >> to >> http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon). > > Interesting observations there; I wish there was incentive for > you to actually resolve them the right way in GCC, meaning this > project. > > 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 >
Re: Why not contribute? (to GCC)
> And how are potential contributors supposed to know this? They're really not. The fundamental problem here is that this area of the law is not only very complicated, but is really all guesswork since there are few, if any, relevant cases. Moreover, this is an area of the law where details matter, often quite a bit. My suggestion for this process is develop an online form where a person specifies various things about their contribution including what program it's for an how long it is. It should ask whether the person anticipates submitting more changes. Then it needs to ask what the person's employment status is and in which country. It should ask about terms relating to IPR in any employment agreements. And so on. Then it should be able to come up with a set of choices that would cover this person's unique situation. That is more or less what a potentional contributor gets via email when submitting a patch. I don't see how a web form would make things different.
Re: Why not contribute? (to GCC)
"Alfred M. Szmidt" writes: > That is more or less what a potentional contributor gets via email > when submitting a patch. I don't see how a web form would make things > different. True, but I think it would make a significant difference if the web form could be filled out online without requiring a piece of paper, a pen, and a stamp. Ian
Re: LTO question
"Bingfeng Mei" writes: > 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. Speaking of which, I'd sure like to see a MIPS port for gold Ian
Re: Why not contribute? (to GCC)
On Mon, Apr 26, 2010 at 21:03, Mark Mielke wrote: > They can take a copy of your code and modify it, but at no time does your > original code become non-free. As long as people continue to copy from your > "free" version of the code, they can continue to use it for "free". > > The GPL isn't free though. The GPL is a limited use license that restricts > freedoms in such a way that there is some expectation that the lost freedoms > can purchase future freedom, and this compromise is justified. > > Many of us don't agree that the compromise is justified. You keep missing the fact that the GPL is meant to protect the USER's right to play with the software. Read about Tivoization. As far as the rights of the author, the GPL basically just protect's the author's wish that his software be distributed under the GPL.
Re: [LTO] Open items in the ToDo list
On 4/25/10 17:35 , Andi Hellmund wrote: > I mainly kept an eye on item 7 (Browsing/dumping tools for LTO files), > which seems for me to be a good task to deepen the knowledge about GCC > internals. I had some patches, but they are old now and won't apply. This would be a very good thing to add. It would help with debugging. You are more than welcome to start working on them. > It is not only related to this ToDo list of LTO, but to all ToDo lists > in the wiki. I think we should try to keep the ToDo lists up-to-date in > the sense that someone working on an item should put his/her name in the > list to signal that this item is work-in-progress. Others could then > specifically contact this person if they would like to contribute/support. Makes sense. Perhaps incorporate them in http://gcc.gnu.org/wiki/Partial_Transitions? Moving them to the individual wiki page, as Manuel suggested, would work too, but perhaps having them in a central place helps keeping them organized. Diego.
Re: Why not contribute? (to GCC)
> That is more or less what a potentional contributor gets via > email when submitting a patch. I don't see how a web form would > make things different. True, but I think it would make a significant difference if the web form could be filled out online without requiring a piece of paper, a pen, and a stamp. There are two forms to be filled out, the `request' and then the `assignment'. I'm guessing you are refering to the assignment here, since that is the paper form--I was refering to the request form. I'd love to see that, and all GNU project maintainers would be happy about it, but that is a topic for the FSF, its lawyers and Richard.
Re: Why not contribute? (to GCC)
On 27 April 2010 22:45, Alfred M. Szmidt wrote: > > That is more or less what a potentional contributor gets via > > email when submitting a patch. I don't see how a web form would > > make things different. > > True, but I think it would make a significant difference if the web > form could be filled out online without requiring a piece of paper, > a pen, and a stamp. > > There are two forms to be filled out, the `request' and then the > `assignment'. I'm guessing you are refering to the assignment here, > since that is the paper form--I was refering to the request form. I'd > love to see that, and all GNU project maintainers would be happy about > it, but that is a topic for the FSF, its lawyers and Richard. Given the feedback we have got in this thread, it would make a significant difference if all the process could be done via a web form. I regularly sign copyright papers for conferences and publishers via web, e.g., IEEE and ACM. If the FSF insists that a hard-copy signature is absolutely necessary, then the web form should provide a personalized pdf that can be printed, signed and sent by fax or email, which is the method that have been used in academia since faxes were invented. If snail mail is absolutely necessary, still a clear and flexible web form could greatly improve the situation. As for clear, we have seen that the process is more than obscure. As for flexible, it seems clear that the current form is not sufficiently personalized, which makes it more difficult to get it signed by an employer. It is not sufficient to put the current procedure in the web. The procedure itself has to be improved. Cheers, Manuel.
Re: Plan for gc-improv merge
On 4/19/10 10:43 , Laurynas Biveinis wrote: > 1) New API in libiberty for creating of hash tables and splay trees > with user-specified callbacks for allocation. Needs libiberty > maintainer review. > 2) Make gengtype accept variable_size GTY option and output typed GC > allocators to gtype-desc.h. Needs global maintainer review. > 3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal > interface for gengtype output to use, fix MEM_STAT accounting, partly > fix zone allocator, partly fix zone allocator interaction with PCH, > and related minor ggc-*.c and stringpool.c changes. It is basically a > ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end > maintainer review. > 4) Annotate several types with variable_size option. Needs all the > front-end maintainers' and middle-end maintainer review, or, maybe > easier, global maintainer review together with the next patch. > 5) Change all the allocation sites. Touches all the frontends, > significant parts of middle ends, and probably all the backends too. > The changes here are mechanical, so it would be easiest to get a > global approval from a global maintainer instead of specific area > maintainers. > 6) GTY documentation update in GCC internals manual. Makes sense to me. These all seem to be independent in terms of what they touch, but interdependent to apply. Is that correct? Diego.
Re: Why not contribute? (to GCC)
As for flexible, it seems clear that the current form is not sufficiently personalized, which makes it more difficult to get it signed by an employer. If you need something specific, you should contact le...@gnu.org. They are quite flexible, I do not know where people got the idea that they are not.
Re: Why not contribute? (to GCC)
> If you need something specific, you should contact le...@gnu.org. > They are quite flexible, I do not know where people got the idea that > they are not. You're missing the point. If flexibilty isn't the DEFAULT people won't know about it and will think it doesn't exist and complain. I strongly agree with previous post: this needs to move to a web-based mostly-automatic and and approach much more personalized to a person's individual situation.
Re: Why not contribute? (to GCC)
On 27 April 2010 23:27, Alfred M. Szmidt wrote: > As for flexible, it seems clear that the current form is not > sufficiently personalized, which makes it more difficult to get it > signed by an employer. > > If you need something specific, you should contact le...@gnu.org. > They are quite flexible, I do not know where people got the idea that > they are not. But this is precisely the problem we are discussing. Lack of information and clarity. I know they are very flexible because I drafted my form together with the legal department of my university and they just accepted it. However, it was just a bold move on my part to get things moving when my university told they will never sign the original form. But this thread shows precisely that: 1) The back-and-forth is too much for casual contributors. If it is more effort to do the legal work than to submit the first patch, then they will never submit any patch at all. 2) Potential contributors are lost as to what changes to make. I was lucky that someone helped me to draft the document but this is probably an exception. 3) Depending on the complexity of the organisation, you may have one chance to get the paper signed. Afterwards, the organisation won't bother again to consider the issue. Even in my case, I had to go in person and wait for hours to get the paper that they drafted signed by them. Cheers, Manuel.
Re: Why not contribute? (to GCC)
People will always find reasons to complain, but most people (and companies) seem to be happy with how the copyright assignments look today.
Re: Why not contribute? (to GCC)
1) The back-and-forth is too much for casual contributors. If it is more effort to do the legal work than to submit the first patch, then they will never submit any patch at all. Please do not exaggerate, if people have time for threads like these, then they have time to send a short email with some questions or wait a few days for a piece of paper to sign. 2) Potential contributors are lost as to what changes to make. I was lucky that someone helped me to draft the document but this is probably an exception. Wether a change is required is up to who is signing the form, if they are not willing to sign it then respective legal departments should be contacted. Please contact le...@gnu.org for further discussions about the topic.
gcc-4.4-20100427 is now available
Snapshot gcc-4.4-20100427 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100427/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 158811 You'll find: gcc-4.4-20100427.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100427.tar.bz2 C front end and core compiler gcc-ada-4.4-20100427.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100427.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100427.tar.bz2 C++ front end and runtime gcc-java-4.4-20100427.tar.bz2 Java front end and runtime gcc-objc-4.4-20100427.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100427.tar.bz2The GCC testsuite Diffs from 4.4-20100420 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
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. 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: pattern "s_" not used when generating rtl for float comparison on mips?
>
> 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.
--
Best Regards.
