GCC porting tutorials

[Radu Hobincu]

Hello,

My name is Radu Hobincu, I am part of a team at "Politehnica" University
of Bucharest that is developing a massive parallel computing architecture
and currently my job is to port the GCC compiler to this new machine.

I've been looking over the GCC official site at http://gcc.gnu.org/ but I
couldn't find an official porting tutorial. Is there such a thing? And
maybe a small example for a lightweight architecture?

Regards,
Radu

Re: GCC porting tutorials

[Sergio Ruocco]

Hi Radu,

Check both the GCC Wiki and the work done at IIT Bombay:
http://www.cse.iitb.ac.in/grc/reach.html
Activities->Workshops

They developed some tutorials on porting GCC and writing new backends, such as:
http://www.cse.iitb.ac.in/grc/gcc-workshop-09/
http://www.cse.iitb.ac.in/~uday/gcc-mini-workshop/


On 24 April 2010 10:53, Radu Hobincu  wrote:
> Hello,
>
> My name is Radu Hobincu, I am part of a team at "Politehnica" University
> of Bucharest that is developing a massive parallel computing architecture
> and currently my job is to port the GCC compiler to this new machine.
>
> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?
>
> Regards,
> Radu
>

Re: Why not contribute? (to GCC)

[Jonathan Wakely]

On 23 April 2010 22:49, Michael Witten  wrote:
>>
>> Anyway, this is off-topic, and stop trying to incite people to fight,
>> in this and other threads, please. It is not the first time you do it.
>> If you just hate gcc so much, just leave. Thanks,
>
> I don't know what you're talking about.

Probably this: http://gcc.gnu.org/ml/gcc/2010-04/msg00542.html

Re: GCC porting tutorials

[Michael Hope]

Hi Radu.  I found the MMIX backend to be quite useful.  It's
reasonably small and acceptably up to date.  Keep in mind that the
MMIX is a 64 bit machine though.

The Picochip and ARM are good as well.  The ARM port is very
complicated due to the number of targets that it supports but fairly
clean once you get into it.

-- Michael

On 24 April 2010 20:53, Radu Hobincu  wrote:
> Hello,
>
> My name is Radu Hobincu, I am part of a team at "Politehnica" University
> of Bucharest that is developing a massive parallel computing architecture
> and currently my job is to port the GCC compiler to this new machine.
>
> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?
>
> Regards,
> Radu
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 02:05, Basile Starynkevitch  wrote:
> Manuel López-Ibáñez wrote:
>>
>> On 24 April 2010 00:18, Alfred M. Szmidt  wrote:
>>>
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that they have
>>> copyright over a change.
>>
>> BTW, in this aspect there is no difference between GCC and LLVM. The
>> latter also requires to assign copyright to the University of
>> Illinois. If you don't have a copyright disclaimer before contributing
>> to LLVM, you are exposing yourself to some future legal troubles.
>
> The real issue is not the copyright disclaimer, it is the legal terms
> inside. Maybe U.Illinois don't use words like "unlumited liaibility".
>
> But we cannot know for sure, these documents are not public.
>

The university of Illinois is in the same legal position as the FSF
and they probably have good lawyers too, so the terms are with almost
certainty similar. Perhaps someone made a mistake during your process
or they sent the wrong papers or whatever. But again, in this aspect
there is not (or there should not be) any difference between the GCC
and LLVM, except for the process itself, which I am starting to see
that it is more problematic than I thought.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Eric Botcazou]

> But again, in this aspect there is not (or there should not be) any
> difference between the GCC and LLVM, except for the process itself, which I
> am starting to see that it is more problematic than I thought.

But there is nothing new, this has been so for decades.  And this prevented 
neither dozens of invididual contributors nor dozens of companies, including 
some of the biggest ones in the computing industry, from contributing and 
assigning the copyright to the FSF.  It isn't clear why this all of a sudden 
appears to have become an insurmountable obstacle.

-- 
Eric Botcazou

Re: Why not contribute? (to GCC)

[Paweł Sikora]

On Friday 23 April 2010 22:36:21 Manuel López-Ibáñez wrote:

> (...). In the free-software world, you can actually help to fix it.
> (...) we need more contributors. Wanna help?

i haven't so much free time (c++work/family/studies) for learn internal
gcc structures and non-trivial design to start full power contributing.
i'm doing what i can at this point of my gcc knowledge and currently
i'm focused on testing each gcc release on my work codebase and isolating
testcases which is also hard and ugly piece of work. e.g, from few months
i'm trying to isolate a fancy (i think) gcc wrong-code bug (at -O0! on
4.4/4.5 while -O2 on 4.3 works fine) that causes memory over(under)runs
in very big C++/EDA software. long dancing in free time with gdb, valgrind
and electric fence is my little contribution to the quality of g++
- my favourite compiler. 

from the rookie point of view i can say that the new gcc plugin framework
is a fantastic tool for learning gcc internals on the fly via debugging
when partial information on the onlinedocs/gccint/GENERIC are not enough.
this process could be improved by gdb7 python based pretty printers which
e.g. allow easier 'tree' union analyzing.

> In any case, I think coming from you it is a bit hurtful because I
> have personally fixed many of your bugs and I haven't seen a single
> beer yet!

no offence please but that weren't my bugs but compiler bugs :-)
your effort in fixing gcc-bad/false-warnings is great and keep
the "-Wall -Werror" still usable for large projects.
once again many thanks!

btw. i have another PR in this area. wanna help? :-)

> Where is my beer?

http://www.bigstockphoto.com/image-298233/stock-photo-beer-drinking-emoticon
:-)

BR,
Pawel.

Re: Why not contribute? (to GCC)

[Andi Hellmund]

Hey,

are these documents, copyright assignment and employer disclaimer, 
publicly available in the WEB or do I need to explicitly request these 
documents?


I plan to start contributing in the near future and I'm currently in the 
process to get the approval from my employer. After getting the company 
approval, the next obvious step would be to sign these FSF documents.


If someone could send me a link (I searched through the web but couldn't 
find any links at GCC, GNU and FSF) would be really helpful ...


Thanks,
Andi

Re: GSoC application

[Artem Shinkarov]

Thanks a lot for your help. At least I know that something is happening.


--
Artem

On Fri, Apr 23, 2010 at 9:42 PM, Ian Lance Taylor  wrote:
> Artem Shinkarov  writes:
>
>> I've submitted an application to gcc in terms of Google Summer of Code
>> 2010, but I have not received any comments yet. The idea of this
>> application was discussed here in the mailing list and I received
>> quite some support.
>>
>> If people are still thinking whether accept it or not than it is ok,
>> but if it is unreviewed then it is sadly.
>>
>> If anyone is in the position of a reviewer or anyone can provide some
>> information I would be very appreciated.
>>
>> Application: 
>> http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/ashinkarov/t127065494824
>
>
> The proposal has in fact been reviewed, even though nobody has made
> any public comments on it.  A lack of public comments is a good thing
> though I can understand that it could make you nervous.  It looks like
> a strong proposal to me.
>
> Ian
>

Re: Why not contribute? (to GCC)

[Joseph S. Myers]

On Sat, 24 Apr 2010, Andi Hellmund wrote:

> Hey,
> 
> are these documents, copyright assignment and employer disclaimer, publicly
> available in the WEB or do I need to explicitly request these documents?
> 
> I plan to start contributing in the near future and I'm currently in the
> process to get the approval from my employer. After getting the company
> approval, the next obvious step would be to sign these FSF documents.
> 
> If someone could send me a link (I searched through the web but couldn't find
> any links at GCC, GNU and FSF) would be really helpful ...

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright

The relevant form is normally request-assign.future.  I don't know if the 
document that the FSF will send you when you send them 
request-assign.future is available online (there are certainly various 
forms that aren't included in gnulib git).

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

Re: Why not contribute? (to GCC)

[Ross Ridge]

Manuel López-Ibáñez writes:
>What reasons keep you from contributing to GCC?

The big reason the copyright assignment.  I never even bothered to read
it, but as I don't get anything in return there's no point.  Why should
put obligaitons on myself, open myself up to even unlikely liabilities,
just so my patches can merged into the official source distribution?
I work on software on my own time to solve my own problems.  I'm happy
enough not "horde" it and give it away for "free", but it doesn't
make much difference to me if anyone else actually ends up using it.
I can have my own patched version of GCC that does what I want without
signing anything.

Another reason is the poor patch submission process.  Why e-mail a patch
if I know, as a new contributor, there's a good chance it won't even be
looked at by anyone?  Why would I want to go through I a process where I'm
expected to keep begging until my patch finally gets someone's attention?

I also just don't need the abuse.  GCC, while not the most of hostile of
open source projects out there, it's up there.  Manuel López-Ibáñez's
unjustified hostility towards Michael Witten in this thread is just a
small example.

Finally, it's also a lot of work.  Just building GCC can be pain, having
to find upto date versions of a growing list of math libraries that
don't benefit me in the slightest way.  Running the test suite takes a
long time, so even trivial patches require a non-trivial amount of work.
Anything more serious can take a huge ammount of time.  I've abandonded
projects once I realized it would be lot quicker to find some other
solution like using assembly, rather than trying to get GCC to do what
I wanted it to do.

Now these are just the main reasons why I don't contribute to GCC.
I'm not arguing that any these issues need to be or can be fixed.  If I
had what I thought where good solutions that would be better overall to
GCC then I'd have suggested them long ago.

I will add, that I don't think code quality is a problem with GCC.  I hate
the GNU coding style as much as anyone, but it's used consistantly and
that's what matters.  Compared other open and closed projects I've seen
it's as easy to understand and maintain as anything.  GNU binutils is
a pile of poo, but I don't know of any codebase the size of GCC that's
as nice to work with.

Ross Ridge

Re: Why not contribute? (to GCC)

[Matthew J Fletcher]

Like many people it seems I've read the gcc lists for many years but 
never contributed. I am an embedded developer using GCC on x86 and ARM.


- GCC works really well, i've never found a serious GCC bug so there is 
nothing that i have had to fix. No "itch to scratch".


- When i modified GCC for C++ support on a propitiatory RTOS (Nucleus), 
it was a bit of a bodge so i knew it would not get accepted, but it 
works well enough for me.


- I have reported bugs mostly to do with cross compiling but the proper 
fix is often more complex than my 5 minute hack to build the cross 
compiler, you generally only build these things once so its a lot of 
effort for a small gain.




- Matthew J Fletcher

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   The big reason the copyright assignment.  I never even bothered to
   read it, but as I don't get anything in return there's no point.
   Why should put obligaitons on myself, open myself up to even
   unlikely liabilities, just so my patches can merged into the
   official source distribution?

You are still open to liabilities for your own project, if you
incorporate code that you do not have copyright over, the original
copyright holder can still sue you.

   Another reason is the poor patch submission process.  Why e-mail a
   patch if I know, as a new contributor, there's a good chance it
   won't even be looked at by anyone?  Why would I want to go through
   I a process where I'm expected to keep begging until my patch
   finally gets someone's attention?

We are all humans, patches fall through the cracks.  Would you like to
help keeping an eye out for patches that have fallen through?  Would
anyone else like to do this?

   I also just don't need the abuse.  GCC, while not the most of
   hostile of open source projects out there, it's up there.  Manuel
   L�pez-Ib��ez's unjustified hostility towards Michael Witten in this
   thread is just a small example.

Please refer to GCC as a free software project, it was written by the
GNU project and the free software community.  Manuel might have been
rough, but it wasn't hostile.


It seems that the major complaints fall into these categories:

 - Copyright assignments

 - Complex and big project with high standards

Not much can be done to either of those, the copyright assignments are
necessary to keep GCC legally safe.  If a assignment takes a long
time, please contact either r...@gnu.org or ass...@gnu.org; if nobody
says anything then nobody knows anything.

Compilers are complex programs (specially if you support as many front
ends as GCC does), lowering the quality would be disastrous and nobody
really wants that.  The bigger the project, the longer it takes to
become accustomed to it, and not everyone has enough time to get up to
par.  This is not specific to GCC, it affects all large projects.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> The university of Illinois is in the same legal position as the FSF
> and they probably have good lawyers too, so the terms are with almost
> certainty similar. Perhaps someone made a mistake during your process
> or they sent the wrong papers or whatever. But again, in this aspect
> there is not (or there should not be) any difference between the GCC
> and LLVM, except for the process itself, which I am starting to see
> that it is more problematic than I thought.

Actually, the University of Illinois is NOT in the same legal position
as the FSF and needs to be much MORE careful!  The FSF has no assets:
anybody suing it and winning will get a symbolic victory only, but no
real money.  Universities own a lot of buildings, to say nothing of
their endowment!  All of that would be a jeopardy if they messed up on
the handling of a patch.  That gives people much MORE incentive to sue
them than the FSF.

I haven't seen the documents from them, but I'd expect them to be even
stricter than those from the FSF since they have so much more at stake.

If somebody sues the FSF for $10M and wins, the FSF goes away, but no
money is lost.  If somebody sues a university for $10M and wins, they
get that money and the university loses it.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright
> 
> The relevant form is normally request-assign.future.  I don't know if the 
> document that the FSF will send you when you send them 
> request-assign.future is available online (there are certainly various 
> forms that aren't included in gnulib git).

Although the wording to describe what's being assigned varies slightly
between the documents, if you're interested in knowing what the terms
of the asignments and disclaimers are, any of the assign.* and
disclaim.* documents (respectively) will give you that.

Re: Why not contribute? (to GCC)

[Richard Kenner]

>The big reason the copyright assignment.  I never even bothered to
>read it, but as I don't get anything in return there's no point.
>Why should put obligaitons on myself, open myself up to even
>unlikely liabilities, just so my patches can merged into the
>official source distribution?
> 
> You are still open to liabilities for your own project, if you
> incorporate code that you do not have copyright over, the original
> copyright holder can still sue you.

That's a critical point, which almost everybody misses, so I want to
repeat it and expand on it.

There is ABSOLUTELY NO DIFFERENCE in your legal liability in contributing
patches to a program in the case where you assign copyright to the owner of
that program and in the case you don't.  The difference is who you're
liable TO and who'll defend you, not the amount or the conditions under
which you're liable.

In fact, for an individual, you're better off WITH the assignment, which
people also don't realize!

Let's look at two cases.  Suppose I contribute two patches, one to GCC
where I'm required to assign the patch to the FSF, and one to Linux where,
as I understand it, I can keep ownership of the patch and don't have to
assign it to anybody.

Now let's suppose some company claims my patches violate their copyright.
What happens?  In the GCC case, they can't come to me since I no longer own
that code.  They sue the FSF, who defends the case.  If they lose (because
I DID, in fact, violate somebody's copyright), the FSF now has a claim
against me for what they owe plus legal fees.  But if they WIN (because I
DIDN'T violate the copyright), I haven't had any responsibility beyond
possibly being a witness.

But now let's look at the case where there WASN'T an assignment.  Then the
company comes and sues ME.  It's now MY responsibility to find and hire
attorneys.  If I lose, I have pay both the judgement and the legal fees,
just like the assignment case.  But if I WIN, I may or may not recover my
legal fees, unlike the assignment case where I don't HAVE any legal fees.

Now, in the case of a large corporation submitting the patch, they DO have
the resources to hire attorneys, so in their case the advantage of the
assignment isn't there.

But the point to take away from this, which is worth emphasizing yet again,
is that the assignment does not affect your legal liability AT ALL!

lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

[Toon Moene]

While compiling our Weather Forecasting code with the latest trunk, I 
got the following (don't know how long this has been a problem, as I 
haven't tried -flto recently):


lto1: internal compiler error: in lto_symtab_merge_decls_1, at 
lto-symtab.c:549

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: gfortran returned 1 exit status
/usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld: 
fatal error: lto-wrapper failed

collect2: ld returned 1 exit status

lto-symtab.c:549:

524
525 /* Helper to process the decl chain for the symbol table entry 
*SLOT.  */

526
527 static int
528 lto_symtab_merge_decls_1 (void **slot, void *data ATTRIBUTE_UNUSED)

545   /* Assert it's the only one.  */
546   if (prevailing)
547 for (e = prevailing->next; e; e = e->next)
548   gcc_assert (e->resolution != LDPR_PREVAILING_DEF_IRONLY
549   && e->resolution != LDPR_PREVAILING_DEF);

Of course, I'd like to make a test case out of this - but what is this 
assert checking ?  Reducing from several 100's of thousands of lines of 
Fortran might be more difficult than to reason from first principles 
about how this assert might be hit.


Thanks in advance,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 12:39, Paweł Sikora  wrote:
> On Friday 23 April 2010 22:36:21 Manuel López-Ibáñez wrote:
>
>> (...). In the free-software world, you can actually help to fix it.
>> (...) we need more contributors. Wanna help?
>
> i haven't so much free time (c++work/family/studies) for learn internal

And who has free time? I am not your boss or your customer, and you
are not mine. Raising awareness about existing bugs is one thing.
Demanding (some people angrily) that they get fixed is another. This
is something that I didn't understand completely until I started
contributing to gcc. And it caused me a lot of frustration.

If you can only contribute bug reports, ok, that is fine, but we also
need people that contribute to fix those bugs. Otherwise there will be
more open bug reports than people fixing them.

> btw. i have another PR in this area. wanna help? :-)

I am specially busy nowadays and a long queue of patches that I would
like to finish, test and submit. But you can always add
m...@gcc.gnu.org to the CC and then it will be in my (long) list of
things to look at.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Toon Moene]

Manuel López-Ibáñez wrote:


And who has free time? I am not your boss or your customer, and you
are not mine. Raising awareness about existing bugs is one thing.
Demanding (some people angrily) that they get fixed is another. This
is something that I didn't understand completely until I started
contributing to gcc. And it caused me a lot of frustration.


I wonder what your day time job is.

Compared to *my* day time job, GCC development is a heaven of meritocracy.

Complaints are a dime a dozen - ignore them.

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 14:12, Ross Ridge  wrote:
> I can have my own patched version of GCC that does what I want without
> signing anything.

Then we change that code and your patch is broken. Or your patch has a
bug and you never find out. Or we decide to remove something essential
for your patch to work because we think nobody is using it.

> I also just don't need the abuse.  GCC, while not the most of hostile of
> open source projects out there, it's up there.  Manuel López-Ibáñez's
> unjustified hostility towards Michael Witten in this thread is just a
> small example.

Perhaps his intention was not trolling but it strongly felt like that
given past behaviour.

http://gcc.gnu.org/ml/gcc-help/2008-01/msg00304.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00542.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00583.html

It wasn't my intention to be hostile just to state the obvious: If you
feel gcc is doomed, why are you still in this list repeating this
mantra over and over? does it make you feel better? how is that not
trolling?

But I have also found previous good posts, so it was a mistake from my
part to assume he was trolling.


> Finally, it's also a lot of work.  Just building GCC can be pain, having
> to find upto date versions of a growing list of math libraries that
> don't benefit me in the slightest way.  Running the test suite takes a
> long time, so even trivial patches require a non-trivial amount of work.

Everything is already setup for you here:

http://gcc.gnu.org/wiki/CompileFarm

I have a script that allows me to do the following in a single step:

gccfarming cleanup
gccfarming bootstrap
gccfarming patch PATCH=mypatch.diff
gccfarming bootstrap
compare_tests clean.log mypatch.log

It takes computer time, yes, but I am not in a hurry. If I were, I
would use one of the computers with 8 or 16 cores.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 15:26, Richard Kenner  wrote:
>>    The big reason the copyright assignment.  I never even bothered to
>>    read it, but as I don't get anything in return there's no point.
>>    Why should put obligaitons on myself, open myself up to even
>>    unlikely liabilities, just so my patches can merged into the
>>    official source distribution?
>>
>> You are still open to liabilities for your own project, if you
>> incorporate code that you do not have copyright over, the original
>> copyright holder can still sue you.
>
> That's a critical point, which almost everybody misses, so I want to
> repeat it and expand on it.

I certainly was missing this point!
Please, could you write this down in the wiki somewhere? For example, here:

http://gcc.gnu.org/wiki/FAQ

This is so good explanation and so obvious once you have explained it
that we should be pointing people to this answer (and the one above
about the U. of Illinois) everytime  the copyright assignment comes
up.

Many thanks!

Manuel.

Re: Why not contribute? (to GCC)

[Gabriel Dos Reis]

On Sat, Apr 24, 2010 at 9:13 AM, Manuel López-Ibáñez
 wrote:

> It wasn't my intention to be hostile just to state the obvious: If you
> feel gcc is doomed, why are you still in this list repeating this
> mantra over and over? does it make you feel better? how is that not
> trolling?

I don't think that line of discussion is going to make people more comfortable
about the whole thing of getting more contributors.  You can't complain about
angry people, and at the same time send messages that suggest that
you might yourself be angry.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:23, Gabriel Dos Reis  wrote:
> On Sat, Apr 24, 2010 at 9:13 AM, Manuel López-Ibáñez
>  wrote:
>
>> It wasn't my intention to be hostile just to state the obvious: If you
>> feel gcc is doomed, why are you still in this list repeating this
>> mantra over and over? does it make you feel better? how is that not
>> trolling?
>
> I don't think that line of discussion is going to make people more comfortable
> about the whole thing of getting more contributors.  You can't complain about
> angry people, and at the same time send messages that suggest that
> you might yourself be angry.

Again, I apologize for overreacting to a (mistakenly perceived)
trolling attempt. I can only say that I completely missed that my post
could be understood as hostile or angry. You tell me I was wrong. I
say sorry. Can we be friends? ;-)

I am not angry. It is very sunny here. :-)

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   I have a script that allows me to do the following in a single step:

   gccfarming cleanup
   gccfarming bootstrap
   gccfarming patch PATCH=mypatch.diff
   gccfarming bootstrap
   compare_tests clean.log mypatch.log

That seems useful, could you post a copy of it somewhere?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:34, Alfred M. Szmidt  wrote:
>   I have a script that allows me to do the following in a single step:
>
>   gccfarming cleanup
>   gccfarming bootstrap
>   gccfarming patch PATCH=mypatch.diff
>   gccfarming bootstrap
>   compare_tests clean.log mypatch.log
>
> That seems useful, could you post a copy of it somewhere?

It is just a modified version of the gcc_build script in contrib/. You
can find my version in /home/manuel/bin/gccfarming in both gcc11 and
gcc12 nodes in the compile farm. But there is also
contrib/patch_tester.sh which is probably even better implemented and
more clear.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:39, Manuel López-Ibáñez  wrote:
> On 24 April 2010 16:34, Alfred M. Szmidt  wrote:
>>   I have a script that allows me to do the following in a single step:
>>
>>   gccfarming cleanup
>>   gccfarming bootstrap
>>   gccfarming patch PATCH=mypatch.diff
>>   gccfarming bootstrap
>>   compare_tests clean.log mypatch.log
>>
>> That seems useful, could you post a copy of it somewhere?
>
> It is just a modified version of the gcc_build script in contrib/. You
> can find my version in /home/manuel/bin/gccfarming in both gcc11 and
> gcc12 nodes in the compile farm. But there is also
> contrib/patch_tester.sh which is probably even better implemented and
> more clear.

It is also here:

http://gcc.gnu.org/wiki/ManuelLópezIbáñez

Cheers,

Manuel.

Re: GCC porting tutorials

[Ian Lance Taylor]

"Radu Hobincu"  writes:

> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?

I don't know of a tutorial, but I want to make sure that you are
looking at the internal docs: http://gcc.gnu.org/onlinedocs/gccint/ .
They include the information you need for a new port, though not
organized as a tutorial.

Ian

Re: Why not contribute? (to GCC)

[Дмитрий Дьяченко]

Thank You, Manual and Joel

I'll try to choose smth appropriate to start.

I am a little confused by the term:
http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
"3. AND at least one free software project you are a contributor of. "

I have accepted patches (well, very small and very obvious) into
llvm/clang, pcsclite. And how this may be applied to gcc-devel? I.e.,
how i may answer to Q.3? I have no patches to gcc yet.

Looks as "egg -- chicken" problem?

Sorry for waste Your time with trivial questions.

Thank You.
Dmitry

2010/4/23 Joel Sherrill :
> On 04/23/2010 02:39 PM, Manuel López-Ibáñez wrote:
>>
>> On 23 April 2010 21:24, Дмитрий Дьяченко  wrote:
>>
>>>
>>> I have no hardware to test patches, small free time to work and my
>>> english is bad.
>>>
>>
>> I always test patches in the
>> CompileFarm.http://gcc.gnu.org/wiki/CompileFarm
>> In fact, I only do development in the CompileFarm. I have a not very
>> powerful laptop that is already overworked.
>> I only use linux x86 machines but they have plenty of esoteric
>> hardware and setups for testers.
>>
>
> I am the maintainer of RTEMS (http://www.rtems.org).  We
> do all development cross and run all automated tests on
> simulators.  There is a wide variety of free simulators for
> the esoteric hardware and all can run on Linux x86.  We
> have scripts to help run a lot of the simulators.
>
> I think we have scripts to drive about 20 different simulator
> configurations.
>
>> I don't have a good answer to the lack of time. I also have very
>> little free time and the most interesting work is time-consuming.
>> However, just checking whether an unconfirmed PR is still valid takes
>> 5 minutes. When you get proficient writing patches, the most consuming
>> task of fixing a bug may be writing the Changelog. (ok ok, for some
>> very very simple bugs, but they exist!).
>>
>>
>
> This is a very important task.
>
> Also helping ensure the PR is decent to start with is important.
> Reminding people to submit preprocessed source that
> can be used to reproduce the problem.  Getting them to try
> different optimization flags and CPU model settings.  Sometimes
> a maintainer will hone right in on the problem if you just give them
> enough details up front.
>
> Checking if it worked on a previous major branch.  Say broken
> in 4.4.2 but worked in 4.3.3.  Then a binary search can find it.
>
> Personally I don't fix any code generation problems.  But I
> try to narrow things down so that someone else can use their
> time effectively fixing it, not narrowing the problem space.
>>
>> If you read up to here your English is good enough. We do not need
>> Shakespeare writing code. We need good programmers. Good patches talk
>> by themselves.
>>
>>
>
> And don't be afraid when someone finds a simple mistake
> in your patch.  I get caught on this all the time.  Forgetting
> to update the copyright year, etc.
>>>
>>> But sometimes i submit bug reports :)
>>>
>>
>> Good! Thanks! Maybe the next step could be checking whether bug
>> reports are valid or not. ;-)
>>
>>
>
> Indeed. :)
>>
>> Manuel.
>>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherr...@oarcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>
>
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 17:00, Дмитрий Дьяченко  wrote:
> Thank You, Manual and Joel
>
> I'll try to choose smth appropriate to start.
>
> I am a little confused by the term:
> http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
> "3. AND at least one free software project you are a contributor of. "

I think it means to say explicitly what you want to do in the compile
farm. I added Laurent Guerby to the CC list. He may have a better
answer.

Cheers,

Manuel.

Re: GCC porting tutorials

[Bernd Roesch]

Hello 

On 24.04.10, you wrote:


> I don't know of a tutorial, but I want to make sure that you are
> looking at the internal docs: http://gcc.gnu.org/onlinedocs/gccint/ .
> They include the information you need for a new port, though not
> organized as a tutorial.

I know only Porting GCC for Dunces from Hans Peter-Nillson May 21. 2000
Its here

ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

It help me to understand GCC better, but i think this is now outdate, because 
of lots internal
changes.
maybe here can somebody update it.

> 
> Ian
Regards

Re: Why not contribute? (to GCC)

[Joel Sherrill]

Hi,

Taking a slightly different tack on this.  One of the things
we at RTEMS have taken away from Google Summer of Code
is that your project has to be approachable to new users
from your target audiences.  You want to minimize the
barrier to entry for each type of users. For us, this
was experienced embedded developers, students with
no cross development experience, students with no
Linux computer, instructors wanting to use RTEMS in
a class, etc.

I think many of the ideas which have been suggested
are great and needed.  Can we identify different types
of users and what might present them hurdles?  Then
we can identify what would be required to lower those
hurdles.

Then work to give each type of user a roadmap, howto,
getting started, resources, etc. on the wiki.

One thing I like to do periodically with RTEMS is
only answer questions with URLs.  This means that
there was an answer in our knowledge base.  If new
info has to be added, it is a hint.  If the user couldn't
find it, it indicates a problem in the way the information
is presented. This is often just due to language barriers
and not thinking like someone unfamiliar to the project.

This is all under the general umbrella of "making
your project approachable".

--joel

Re: RFC: merging GUPC into the GCC trunk?

[Gerald Pfeifer]

On Wed, 7 Apr 2010, Gary Funck wrote:
> What is the recommended process for having GUPC reviewed
> (and hopefully, subsequently approved) for being merged
> into the GCC mainline?

Are there any fixes / enhancements you need in common GCC code?  If
so, submitting those first and separately might make sense (and will
simplify maintaining the branch).

The question beyond that is how important / relevant this is for GCC
mainline?  That's what makes me a bit hesitant since every frontend
does have some cost, and doing this as a plug-in might be an alternative?

Gerald

Re: Why not contribute? (to GCC)

[Laurent GUERBY]

On Sat, 2010-04-24 at 19:00 +0400, Дмитрий Дьяченко wrote:
> Thank You, Manual and Joel
> 
> I'll try to choose smth appropriate to start.
> 
> I am a little confused by the term:
> http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
> "3. AND at least one free software project you are a contributor of. "
> 
> I have accepted patches (well, very small and very obvious) into
> llvm/clang, pcsclite. And how this may be applied to gcc-devel? I.e.,
> how i may answer to Q.3? I have no patches to gcc yet.
> 
> Looks as "egg -- chicken" problem?

The "GCC Compile Farm" project is open to all free software (1)
contributors and is not limited to GCC contributors.

As part of the application process just mention URLs of
patches, bug reports, etc... you have already contributed to
one or more free software project and what project(s)
you intend to use the compile farm for. If you don't have done any
contribution yet, we also have accepted applications in the past when
sponsored by a developper who qualifies (for example internships).

> Sorry for waste Your time with trivial questions.

Questions are always welcomed :).

Sincerely,

Laurent

(1) http://www.gnu.org/licenses/license-list.html

Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

[Richard Guenther]

On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene  wrote:
> While compiling our Weather Forecasting code with the latest trunk, I got
> the following (don't know how long this has been a problem, as I haven't
> tried -flto recently):
>
> lto1: internal compiler error: in lto_symtab_merge_decls_1, at
> lto-symtab.c:549
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: gfortran returned 1 exit status
> /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
> fatal error: lto-wrapper failed
> collect2: ld returned 1 exit status
>
> lto-symtab.c:549:
>
>    524
>    525 /* Helper to process the decl chain for the symbol table entry *SLOT.
>  */
>    526
>    527 static int
>    528 lto_symtab_merge_decls_1 (void **slot, void *data ATTRIBUTE_UNUSED)
>    
>    545   /* Assert it's the only one.  */
>    546   if (prevailing)
>    547     for (e = prevailing->next; e; e = e->next)
>    548       gcc_assert (e->resolution != LDPR_PREVAILING_DEF_IRONLY
>    549                   && e->resolution != LDPR_PREVAILING_DEF);
>
> Of course, I'd like to make a test case out of this - but what is this
> assert checking ?

It is checking that for one symbol we only have one definition.

You are using -fuse-linker-plugin?

Richard.

>  Reducing from several 100's of thousands of lines of
> Fortran might be more difficult than to reason from first principles about
> how this assert might be hit.
>
> Thanks in advance,
>
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/
> Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
>

Re: Stepping down as SPU backend maintainer

[Gerald Pfeifer]

On Sun, 28 Mar 2010, Andrew Pinski wrote:
>  I am stepping down as the spu backend maintainer since Sony removed
> GNU/Linux (OtherOS) support from their newer PS3 firmware.  The main
> reason is I will no longer have access to a machine to support the
> target.  But really this is also a step backwards for free software
> support from Sony.

Yes, that is sad to see.  (I noticed that your entry in 
gcc/doc/contrib.texi does not mention SPU at all, if you
want to propose a change?)

Gerald

Re: mirror proposition

[Gerald Pfeifer]

Hi James,

On Thu, 25 Mar 2010, James Miller wrote:
> We would like to raise an HTTP GCC mirror on our dedicated server in
> Canada and I would be very grateful if you provided me with
> instructions.

you can just start by mirroring our server and then advise us of it
via the last paragraph at http://gcc.gnu.org/mirrors.html (or by
simply submitting a patch against that page, actually).

Thanks,

Gerald

Re: GCC 4.5.0 Released

[Gerald Pfeifer]

On Tue, 20 Apr 2010, Dave Korn wrote:
> But I agree with this: a release announcement is just an email someone
> sends out after a new release is uploaded, it is not a major PR effort 

Let's not underestimate the effect our releases have in terms of PR
and how much GCC actually is in need of PR.  I know (us) engineers
are generally not too fond of marketing, but it's more important than
one might think.

On Wed, 21 Apr 2010, Joe Buck wrote:
> But the RMs have enough work to do as is, so it shouldn't be up to
> Mark to produce a beautifully written "white paper".

I agree.  My suggestion would be that we support the RMs by helping
them create such announcements; for example, they could post them to
our mailing list and review/update them here.

On Wed, 21 Apr 2010, Manuel López-Ibáñez wrote:
> Actually, now that you mention it. I already planned to submit an
> article about all the goodness of GCC 4.5 to LWN.

Cool, very cool!

Gerald

Re: GCC 4.5.0 Released

[Gerald Pfeifer]

On Mon, 19 Apr 2010, Richard Guenther wrote:
> I see plugins as a new feature for GCC developers.  There is little 
> value in announcing "we have plugin support" to our users if you can't 
> name at least one that is supported out-of-the-box (and obviously we 
> don't support plugins at all).

Our release announcements and documentation aren't just for end users,
though, but also distributors, (potential) contributors, the media,
people interested in free software,...

(Not sure we should have mentioned plug-ins in that e-mail, the above
is more of general note.)

Gerald

Documentation legal issues (Was: Re: Poor internal documentation)

[Joern Rennecke]

Quoting Manuel López-Ibáñez :


On 23 April 2010 15:05, Philipp Thomas  wrote:

* Ian Lance Taylor (i...@google.com) [20100413 00:41]:


Details of GIMPLE IR: poor.
Details of tree IR: poor.
How to write a new optimization pass: poor.
How to write a new frontend: nonexistent.
General overview of compiler source: nonexistent.
Overview of internal compiler datastructures: nonexistent.


I'd say these these warrant an additional bullet "Documentation" under
"Improving GCC" on the GCC wiki that then lists (at least) these points.
It's not much, but it at least shows the GCC developers are aware and just
maybe it does attract the interest of someone.


Great! Go ahead, please. The wiki is easy to edit. Bonus points if you
collect there links to the existing documentation, so anyone wishing
to help has the many sources at hand.


However, is that not putting well-meaning contributers in peril of infringing
on the Copyright of the FSF in GCC by putting GPLed code into a GFDLed
document?  Often, you want to use some snippets of code from the sources as
an example, or lift some explanation from a comment in order to write
documentation.
If the legal entity doing this is not the one who contributed the code in
the first place, the only right they have to the code is what is granted
under the GPL.  Posting a patch with such code to the GCC mailing list
without a GFDL license grant would be Copyright infringement, unless
the poster could be construed to act on behalf of the FSF due to a
maintainership held, or the post is considered internal to the FSF -
I'm not sure if either of these would apply, but I don't think that
could possibly apply for a new contributer who has not at least
write-after-approval status.
Or will there be a license grant to cover such uses of GPLed code under
the GPL?

Is the steering committee empowered and willing to do that?

Re: Why not contribute? (to GCC)

[Leif Ekblad]

Why do I not contribute to GCC? Well, I tried to get some really simple 
patches for RDOS
accepted in 2006, but it seemed to take forever. I'm not sure if they have 
been accepted now,
or if the binutils patches (which were accepted) are still there. For 
somebody wanting to support
a new OS with GCC (that is not unix-style), the patch acceptance policy is 
simply making the
whole process impossible to do in reasonable time. Such a new OS will need 
hundreds or
even thousands of patches, and getting all of these accepted in reasonable 
time seems more

or less impossible.

When I had given up on GCC, I got interested in OpenWatcom. They gave me a 
new branch
to work in, and eventually helped me integrate my changes with trunk. This 
worked very well

and RDOS will be supported in the upcoming 1.9 release.

The 2006 patches I worked a lot to find out are probably totally obsolete 
today, and needs to
be done from scratch again. This is the nature of supporting new OSes. I 
just doesn't work
to find out the patches if nobody cares to incorporate them, as they will 
quickly become obsolete.
However, I suspect that the community is only interested in supporting 
unix-like environments,

where these issues doesn't exist.

Leif Ekblad



- Original Message - 
From: "Ross Ridge" 

To: 
Sent: Saturday, April 24, 2010 2:12 PM
Subject: Re: Why not contribute? (to GCC)



Manuel López-Ibáñez writes:

What reasons keep you from contributing to GCC?


The big reason the copyright assignment.  I never even bothered to read
it, but as I don't get anything in return there's no point.  Why should
put obligaitons on myself, open myself up to even unlikely liabilities,
just so my patches can merged into the official source distribution?
I work on software on my own time to solve my own problems.  I'm happy
enough not "horde" it and give it away for "free", but it doesn't
make much difference to me if anyone else actually ends up using it.
I can have my own patched version of GCC that does what I want without
signing anything.

Another reason is the poor patch submission process.  Why e-mail a patch
if I know, as a new contributor, there's a good chance it won't even be
looked at by anyone?  Why would I want to go through I a process where I'm
expected to keep begging until my patch finally gets someone's attention?

I also just don't need the abuse.  GCC, while not the most of hostile of
open source projects out there, it's up there.  Manuel López-Ibáñez's
unjustified hostility towards Michael Witten in this thread is just a
small example.

Finally, it's also a lot of work.  Just building GCC can be pain, having
to find upto date versions of a growing list of math libraries that
don't benefit me in the slightest way.  Running the test suite takes a
long time, so even trivial patches require a non-trivial amount of work.
Anything more serious can take a huge ammount of time.  I've abandonded
projects once I realized it would be lot quicker to find some other
solution like using assembly, rather than trying to get GCC to do what
I wanted it to do.

Now these are just the main reasons why I don't contribute to GCC.
I'm not arguing that any these issues need to be or can be fixed.  If I
had what I thought where good solutions that would be better overall to
GCC then I'd have suggested them long ago.

I will add, that I don't think code quality is a problem with GCC.  I hate
the GNU coding style as much as anyone, but it's used consistantly and
that's what matters.  Compared other open and closed projects I've seen
it's as easy to understand and maintain as anything.  GNU binutils is
a pile of poo, but I don't know of any codebase the size of GCC that's
as nice to work with.

Ross Ridge

Re: Why not contribute? (to GCC)

[Thomas Neumann]

> What reasons keep you from contributing to GCC?
I tried this a while ago, but ultimately gave up because I could not get my 
patches in. Some were applied, but many never made it. Admittedly they were 
perhaps not of general interested, there were only improving compatibility 
of the gcc base with C++ (what Ian Lance Taylor then did later).
The most frustrating part was not getting patches rejected (I could then 
improve them, after all), but having patches ignored. You submit a number of 
patches, and the result is... nothing. No response at all. Not exactly what 
encourages gcc as a free time activity.

On the other hand I am a professional developer, too (even working on 
compilers), and I myself would perhaps also be reluctant to spend time on 
reviewing and merging patches that I do not really care about. So I 
understand the gcc developers. But it is still frustrating for outsiders.

Thomas

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 02:07 PM, Leif Ekblad wrote:

Why do I not contribute to GCC? Well, I tried to get some really simple
patches for RDOS
accepted in 2006, but it seemed to take forever. I'm not sure if they have
been accepted now,
or if the binutils patches (which were accepted) are still there. For
somebody wanting to support
a new OS with GCC (that is not unix-style), the patch acceptance policy is
simply making the
whole process impossible to do in reasonable time. Such a new OS will need
hundreds or
even thousands of patches, and getting all of these accepted in reasonable
time seems more
or less impossible.
   

Maybe my search is wrong but "rdos site:gcc.gnu.org" doesn't
turn it up.

I don't know how divergent rdos from any other OS that is
not self-hosted and is cross-compiled but there shouldn't
be 100s or 1000s of patches required to support an OS on gcc
unless you have a divergent object format or are including
a new CPU.

Also you haven't mentioned two major issues that are
not "patch" related.

(1) Did you arrange for a maintainer for the rdos target?

(2) Did you submit test results with the port?

(3) Has copyright assignment paperwork been dealt with?

I maintain the *-rtems* targets (~12 architectures) and there
just isn't much special to them in contrast to the large amount of
code that just works fine with a bit of OS specific configuration
and glue.

Not to pick but from Google'ing the mailing list, I just see you
asking questions.  I didn't find code being submitted.

And speaking from experience, if you submit code and it doesn't
get reviewed and merged.  Ask again.  The submitter cares a lot
more about it than anyone else and that's just the nature of the
game.  If you don't care enough about your area to follow up, why
should anyone else?

When I had given up on GCC, I got interested in OpenWatcom. They gave me a
new branch
to work in, and eventually helped me integrate my changes with trunk. This
worked very well
and RDOS will be supported in the upcoming 1.9 release.
   

And if you had arranged for the things above, the gcc community
would have supported you doing the same.  There are a number of
Microblaze and other special project branches.



The 2006 patches I worked a lot to find out are probably totally obsolete
today, and needs to
be done from scratch again. This is the nature of supporting new OSes. I
just doesn't work
to find out the patches if nobody cares to incorporate them, as they will
quickly become obsolete.
However, I suspect that the community is only interested in supporting
unix-like environments,
where these issues doesn't exist.

   

Depends.  Not seeing the patches I can't say but I have maintained
patches for odd RTEMS targets (e.g. sparc64 and nios) off the
main source across multiple major gcc releases without any
real problems.

--joel

Leif Ekblad



- Original Message -
From: "Ross Ridge"
To:
Sent: Saturday, April 24, 2010 2:12 PM
Subject: Re: Why not contribute? (to GCC)


   

Manuel López-Ibáñez writes:
 

What reasons keep you from contributing to GCC?
   

The big reason the copyright assignment.  I never even bothered to read
it, but as I don't get anything in return there's no point.  Why should
put obligaitons on myself, open myself up to even unlikely liabilities,
just so my patches can merged into the official source distribution?
I work on software on my own time to solve my own problems.  I'm happy
enough not "horde" it and give it away for "free", but it doesn't
make much difference to me if anyone else actually ends up using it.
I can have my own patched version of GCC that does what I want without
signing anything.

Another reason is the poor patch submission process.  Why e-mail a patch
if I know, as a new contributor, there's a good chance it won't even be
looked at by anyone?  Why would I want to go through I a process where I'm
expected to keep begging until my patch finally gets someone's attention?

I also just don't need the abuse.  GCC, while not the most of hostile of
open source projects out there, it's up there.  Manuel López-Ibáñez's
unjustified hostility towards Michael Witten in this thread is just a
small example.

Finally, it's also a lot of work.  Just building GCC can be pain, having
to find upto date versions of a growing list of math libraries that
don't benefit me in the slightest way.  Running the test suite takes a
long time, so even trivial patches require a non-trivial amount of work.
Anything more serious can take a huge ammount of time.  I've abandonded
projects once I realized it would be lot quicker to find some other
solution like using assembly, rather than trying to get GCC to do what
I wanted it to do.

Now these are just the main reasons why I don't contribute to GCC.
I'm not arguing that any these issues need to be or can be fixed.  If I
had what I thought where good solutions that would be better overall to
GCC then I'd have suggested them long ago.

I will add, that I don't think code qu

Re: Why not contribute? (to GCC)

[Florian Weimer]

* Richard Kenner:

> Now let's suppose some company claims my patches violate their copyright.
> What happens?  In the GCC case, they can't come to me since I no longer own
> that code.  They sue the FSF, who defends the case.  If they lose (because
> I DID, in fact, violate somebody's copyright), the FSF now has a claim
> against me for what they owe plus legal fees.  But if they WIN (because I
> DIDN'T violate the copyright), I haven't had any responsibility beyond
> possibly being a witness.

Isn't it far more likely that you would be co-defendant because your
posting to gcc-patches was a copyright violation in itself?

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 02:35 PM, Thomas Neumann wrote:

What reasons keep you from contributing to GCC?
 

I tried this a while ago, but ultimately gave up because I could not get my
patches in. Some were applied, but many never made it. Admittedly they were
perhaps not of general interested, there were only improving compatibility
of the gcc base with C++ (what Ian Lance Taylor then did later).
The most frustrating part was not getting patches rejected (I could then
improve them, after all), but having patches ignored. You submit a number of
patches, and the result is... nothing. No response at all. Not exactly what
encourages gcc as a free time activity.

   

And this is the type of problem I was referring to as
"making the project approachable".  If timely patch review
and feedback is an issue, then we need to figure out a
workflow solution.

I am sure the people who need to review a particular patch
are busy enough that they won't necessarily go hunting for
work.  Maybe a patch triage team that assigns them to
the right person(s) for review.

On the other hand I am a professional developer, too (even working on
compilers), and I myself would perhaps also be reluctant to spend time on
reviewing and merging patches that I do not really care about. So I
understand the gcc developers. But it is still frustrating for outsiders.

   

And I admit to often privately emailing the person I think
needs to review a patch I care about.  But a new person
wouldn't be comfortable doing that.  A triage step
and a tracking system for patches might help.

There is definitely a workflow problem though.  I have
had patches I submitted through Bugzilla which didn't
get reviewed until I was asked to submit them to
gcc-patches.  And vice-versa.  A triage team and
tracking system might have prevented this.

This is also an opportunity for persons to contribute.

--joel

Thomas


   

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > Now let's suppose some company claims my patches violate their copyright.
> > What happens?  In the GCC case, they can't come to me since I no longer own
> > that code.  They sue the FSF, who defends the case.  If they lose (because
> > I DID, in fact, violate somebody's copyright), the FSF now has a claim
> > against me for what they owe plus legal fees.  But if they WIN (because I
> > DIDN'T violate the copyright), I haven't had any responsibility beyond
> > possibly being a witness.
> 
> Isn't it far more likely that you would be co-defendant because your
> posting to gcc-patches was a copyright violation in itself?

Perhaps, but the point is that since the FSF is involved, THEY would be the
ones primarily responsible for the defense, whereas if I had not assigned
the copyright, everything would rest completely on my shoulders.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 21:48, Joel Sherrill  wrote:
>
> There is definitely a workflow problem though.  I have
> had patches I submitted through Bugzilla which didn't
> get reviewed until I was asked to submit them to
> gcc-patches.  And vice-versa.  A triage team and
> tracking system might have prevented this.

A patch tracking system would already be an improvement and it would
be fantastic if someone contributed such thing.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sat, Apr 24, 2010 at 10:23 PM, Manuel López-Ibáñez
 wrote:
> On 24 April 2010 21:48, Joel Sherrill  wrote:
>>
>> There is definitely a workflow problem though.  I have
>> had patches I submitted through Bugzilla which didn't
>> get reviewed until I was asked to submit them to
>> gcc-patches.  And vice-versa.  A triage team and
>> tracking system might have prevented this.
>
> A patch tracking system would already be an improvement and it would
> be fantastic if someone contributed such thing.

We had a patch tracking system, and it was completely ignored by most
maintainers.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:28, Steven Bosscher  wrote:
>
> We had a patch tracking system, and it was completely ignored by most
> maintainers.

But *submitters* did use it until it went down. So it was useful for
tracking unreviewed patches, not for improving reviewing. Right now, I
have no way to check what unreviewed patches there may be interesting
for me apart from searching the gcc-patches mailing list. Even the
psychological effect of having your patch tracked somewhere instead of
completely ignored would be effective. Perhaps more importantly, it
showed which parts of the compiler were more in need of further
reviewers.

I think it was really bad that we lost the patch tracker.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sat, Apr 24, 2010 at 10:28 PM, Steven Bosscher  wrote:
> On Sat, Apr 24, 2010 at 10:23 PM, Manuel López-Ibáñez
>  wrote:
>> On 24 April 2010 21:48, Joel Sherrill  wrote:
>>>
>>> There is definitely a workflow problem though.  I have
>>> had patches I submitted through Bugzilla which didn't
>>> get reviewed until I was asked to submit them to
>>> gcc-patches.  And vice-versa.  A triage team and
>>> tracking system might have prevented this.
>>
>> A patch tracking system would already be an improvement and it would
>> be fantastic if someone contributed such thing.
>
> We had a patch tracking system, and it was completely ignored by most
> maintainers.

Indeed - we do not need another piece of infrastructure.  Note that good
patch review takes a lot of time and we (unfortunately again) do not have
many active patch reviewers.  So it happens that patches from people
with excellent track history get approved quickly but others are just
left behind.  Pinging the patches does usually help here, as well as
working with maintainers during the patch creation so that the final
review is easy.

Richard.

> Ciao!
> Steven
>

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sat, Apr 24, 2010 at 10:37 PM, Manuel López-Ibáñez
 wrote:
> On 24 April 2010 22:28, Steven Bosscher  wrote:
>>
>> We had a patch tracking system, and it was completely ignored by most
>> maintainers.
>
> But *submitters* did use it until it went down. So it was useful for
> tracking unreviewed patches, not for improving reviewing. Right now, I
> have no way to check what unreviewed patches there may be interesting
> for me apart from searching the gcc-patches mailing list. Even the
> psychological effect of having your patch tracked somewhere instead of
> completely ignored would be effective. Perhaps more importantly, it
> showed which parts of the compiler were more in need of further
> reviewers.
>
> I think it was really bad that we lost the patch tracker.

You can use bugzilla, the patch keyword and the URL field to track patches
for bugs.

Richard.

> Cheers,
>
> Manuel.
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:37, Richard Guenther  wrote:
>>
>> We had a patch tracking system, and it was completely ignored by most
>> maintainers.
>
> Indeed - we do not need another piece of infrastructure.  Note that good
> patch review takes a lot of time and we (unfortunately again) do not have
> many active patch reviewers.  So it happens that patches from people
> with excellent track history get approved quickly but others are just
> left behind.  Pinging the patches does usually help here, as well as
> working with maintainers during the patch creation so that the final
> review is easy.

But this is not a piece of infrastructure for reviewers but for *submitters*.

Anyway, the patch tracker is not the main point. The point is how we
alleviate this problem? You see that a few already mentioned that this
was a reason to NOT contribute to GCC. People that probably have
solved the legal issues, were knowledgeable enough to modify, build
and test GCC, and then submit a patch. And they left because of this.
That is sad.

Cheers,

Manuel.



>
> Richard.
>
>> Ciao!
>> Steven
>>
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 21:35, Thomas Neumann  wrote:
>> What reasons keep you from contributing to GCC?
> I tried this a while ago, but ultimately gave up because I could not get my
> patches in. Some were applied, but many never made it. Admittedly they were
> perhaps not of general interested, there were only improving compatibility
> of the gcc base with C++ (what Ian Lance Taylor then did later).
> The most frustrating part was not getting patches rejected (I could then
> improve them, after all), but having patches ignored. You submit a number of
> patches, and the result is... nothing. No response at all. Not exactly what
> encourages gcc as a free time activity.

Patches falling through the cracks is a well-known problem. Currently,
the only advice is insisting politely. Even a patch from a
long-standing contributor may require four or five pings. The person
in charge may not even be aware that the patch is for them because of
the subject or they might be in vacation or very busy. Often they are
unsure about the patch and waiting for others to comment. Not getting
your patch reviewed after four or five pings would be enough to raise
the issue in a more general email.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Martin Guy]

OK, now that stage3 is over I'm thinking of updating the
MaverickCrunch FPU fixes (currently for 4.3) and merging them but
would appreciate some guidance.

There are 26 patches in all and I can't expect anyone to understand
them because they require a good understanding of the FPU and its
hardware bugs (and there are a lot of them!) :) What's the best path?
Create a branch, work there and then merge when done?

I have done the copyright assignment stuff but don't have an account
on gcc.gnu.org. They all affect files under config/arm/ apart from one
testsuite fix and the docs.

The missing part is a huge testsuite for it. I confess I find that
daunting; it is potentially huge in that it replaces a non-working
code generator with a working one, and for the non-working one there
were *no* fpu-specific tests.
Do I really need to write an entire validation suite?

M

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:46, Martin Guy  wrote:
> OK, now that stage3 is over I'm thinking of updating the
> MaverickCrunch FPU fixes (currently for 4.3) and merging them but
> would appreciate some guidance.

I think you should send a new email with a different subject to gcc@,
otherwise this thread goes off-topic and more importantly, the
relevant people may be not reading this long thread anymore.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Andi Hellmund]

Richard Guenther wrote:


Indeed - we do not need another piece of infrastructure.  Note that good
patch review takes a lot of time and we (unfortunately again) do not have
many active patch reviewers.  So it happens that patches from people
with excellent track history get approved quickly but others are just
left behind.  Pinging the patches does usually help here, as well as
working with maintainers during the patch creation so that the final
review is easy.

Richard.


This all sounds like a typical "dead-lock" problem. The projects 
obviously needs more patch reviewers, but to be qualified for a patch 
reviewer, you clearly require a _thorough_ understanding of the GCC 
internals. And I think to get this deep knowledge - at least for my 
person - I need the motivation to look and work through the source code 
to understand the internals. And to get this motivation or keep it up 
and running, I need to work productively on this project by submitting 
patches among others. Documentation is important and could make fun as 
well, but the real fun is to work on the code and submit - at one time - 
patches to the main line.


All the mentioned aspects sound somehow devastating for me that it is 
_that_ hard to get into the real contribution and I could generally 
understand that a lot of persons decided to NOT contribute.


Although some might think this is stupid SPAM, I think this thread is 
really good (Thanks Manuel!) to get an overview of the current 
"problems" of the GCC projects and what could be improved so that the 
project becomes more attractive to potential contributors.


A patch tracking system might basically be a good idea for contributors 
but it nevertheless doesn't solve the real problem, the limited amount 
and time of the patch reviewers!!!

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 04:27 PM, Andi Hellmund wrote:

Richard Guenther wrote:

   

Indeed - we do not need another piece of infrastructure.  Note that good
patch review takes a lot of time and we (unfortunately again) do not have
many active patch reviewers.  So it happens that patches from people
with excellent track history get approved quickly but others are just
left behind.  Pinging the patches does usually help here, as well as
working with maintainers during the patch creation so that the final
review is easy.

Richard.
 

This all sounds like a typical "dead-lock" problem. The projects
obviously needs more patch reviewers, but to be qualified for a patch
reviewer, you clearly require a _thorough_ understanding of the GCC
internals. And I think to get this deep knowledge - at least for my
person - I need the motivation to look and work through the source code
to understand the internals. And to get this motivation or keep it up
and running, I need to work productively on this project by submitting
patches among others. Documentation is important and could make fun as
well, but the real fun is to work on the code and submit - at one time -
patches to the main line.
   

So we need more patch reviewers.  How can that be addressed?

It is also important to make more effective use of the patch
reviewers we already have.  What could be done to make the
patch review process easier or less time-consuming?

All the mentioned aspects sound somehow devastating for me that it is
_that_ hard to get into the real contribution and I could generally
understand that a lot of persons decided to NOT contribute.
   

Would a mentoring program of some type help?  I don't
know how to associate people who want to become a long
term part of GCC with the right people.

Although some might think this is stupid SPAM, I think this thread is
really good (Thanks Manuel!) to get an overview of the current
"problems" of the GCC projects and what could be improved so that the
project becomes more attractive to potential contributors.

   

That's the goal.  And to make the workflow as easy as possible
for those who are already contributing.

A patch tracking system might basically be a good idea for contributors
but it nevertheless doesn't solve the real problem, the limited amount
and time of the patch reviewers!!!

   

Yep.  But both the submitter and reviewer sides of the patch
tracking are important.

--joel

Re: Long paths with ../../../../ throughout

[Jon]

Ian Lance Taylor wrote, On 15/03/10 03:12:

Jon  writes:


How long is it until back in stage 1 development phase?


Reasonably soon, I hope, but there is no specific schedule.


Hi Ian,
Just wanted to ask if it had been possible to integrate the patch.

Would it be useful for me to create a bugzilla ticket and add the 
patch there?


Cheers, Jon

Re: Long paths with ../../../../ throughout

[Manuel López-Ibáñez]

On 25 April 2010 00:19, Jon  wrote:
> Ian Lance Taylor wrote, On 15/03/10 03:12:
>>
>> Jon  writes:
>>
>>> How long is it until back in stage 1 development phase?
>>
>> Reasonably soon, I hope, but there is no specific schedule.
>
> Hi Ian,
> Just wanted to ask if it had been possible to integrate the patch.
>
> Would it be useful for me to create a bugzilla ticket and add the patch
> there?

That is always useful since it allows tracking why a patch was
committed (the log will contain the PR number) and find the report in
the bugzilla database.

Cheers,

Manuel.

gcc-4.6-20100424 is now available

[gccadmin]

Snapshot gcc-4.6-20100424 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100424/
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/trunk revision 158693

You'll find:

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

gcc-core-4.6-20100424.tar.bz2 C front end and core compiler

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

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

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

gcc-java-4.6-20100424.tar.bz2 Java front end and runtime

gcc-objc-4.6-20100424.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.6-20100424.tar.bz2The GCC testsuite

Diffs from 4.6-20100417 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.

__builtin_choose_expr: type-genericity and side-effects

[Jörg Leis]

Hi,

I'm currently implementing a few type-generic macros in C with
__builtin_choose_expr and noticed the following:

1) The documentation does not mention if const_expr has side-effects.
One may, for example, use the return type of a function call; I expect
the expression to not be evaluated. The same remark applies also to
typeof.

2) Is it possible to really remove the unused expression? One often
gets either warnings about pointers having the wrong type, or, after
adding all explicit conversions, about strict aliasing.

Although I would strongly prefer a solution to (2), do you know how to
remove the warnings about strict aliasing for one particular conversion
that is known to be safe?

Thanks and best regards,
Jörg

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 5:05 PM, Basile Starynkevitch wrote:

> Manuel López-Ibáñez wrote:
>> On 24 April 2010 00:18, Alfred M. Szmidt  wrote:
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that they have
>>> copyright over a change.
>> BTW, in this aspect there is no difference between GCC and LLVM. The
>> latter also requires to assign copyright to the University of
>> Illinois. If you don't have a copyright disclaimer before contributing
>> to LLVM, you are exposing yourself to some future legal troubles.
> 
> The real issue is not the copyright disclaimer, it is the legal terms inside. 
> Maybe U.Illinois don't use words like "unlumited liaibility".
> 
> But we cannot know for sure, these documents are not public.

I'm not sure why you think that.  Unlike the FSF, all of the LLVM projects' 
requirements are public:
http://llvm.org/docs/DeveloperPolicy.html

LLVM does not require a copyright assignment.  People can send in random 
patches and they get immediately applied.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:

> On 24 April 2010 00:18, Alfred M. Szmidt  wrote:
>> 
>> The disclaimers are legally necessary though, the FSF needs a paper
>> trail in the case your employer comes back and claims that they have
>> copyright over a change.
> 
> BTW, in this aspect there is no difference between GCC and LLVM. The
> latter also requires to assign copyright to the University of
> Illinois. If you don't have a copyright disclaimer before contributing
> to LLVM, you are exposing yourself to some future legal troubles.

On what do you base these assertions?  Every point seems wrong to me.

-Chris