merging the maverick FPU patches

[Martin Guy]

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.

   M

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 06:20, Chris Lattner  wrote:
>
> 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.

Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html


Developer Agreements

With regards to the LLVM copyright and licensing, developers agree to
assign their copyrights to UIUC for any contribution made so that the
entire software base can be managed by a single copyright holder. This
implies that any contributions can be licensed under the license that
the project uses.

When contributing code, you also affirm that you are legally entitled
to grant this copyright, personally or on behalf of your employer. If
the code belongs to some other entity, please raise this issue with
the oversight group before the code is committed.


Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Leif Ekblad]

Joel Sherrill:

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.


The primary issue I had was that some basic configuration was
never updated to GCC (libtool). Because this was the place where the
targets and stuff was defined, it was not even possible to submit specific
patches in the first place, because they would fail without this refresh.


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?


I think I posted pings. 


As for the steps above, nobody requested me to fill out the
copyright assignment, and neither about maintainer for rdos
target.

The 100s of patches related to libc (in this case newlib), not
to gcc. I mixed up those. However, it was not possible to submit
the patches to newlib either until the GCC patches had been
applied.

Leif Ekblad

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

Hello Leif,

* Leif Ekblad wrote on Sun, Apr 25, 2010 at 12:56:21PM CEST:
> The primary issue I had was that some basic configuration was
> never updated to GCC (libtool). Because this was the place where the
> targets and stuff was defined, it was not even possible to submit specific
> patches in the first place, because they would fail without this refresh.

Wait, Libtool has a patch from you from 2006-01-12 in its tree,

Is that the one you're talking about?

Was it that GCC took long to merge the Libtool changes?  Did you ever
ping that?

Nowadays the Libtool sources in GCC track upstream more closely than
they used to do, and updating them should be fairly straightforward.

Thanks,
Ralf

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

[Toon Moene]

Richard Guenther wrote:


On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene  wrote:



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?


Indeed, I do (all of our code ends up in libraries - .a files - so I 
have to, to make -flto -fwhole-program be meaningful).


Is it a problem with COMMON ?  Those typically have umpteen definitions, 
which all have to match ...


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/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > 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.

The latter point is certainly true.  If you work for a company and submit
a patch to ANY project without having a disclaimer, the company can later
sue you, claiming that it owned the copyright to the material that you
submitted.  The only different is who the disclaimer protects: if you
are assigning the patches to an entity (e.g., the FSF) then the disclaimer
protects the FSF.  If you're NOT assigning the patches to somebody, the
disclaimer protects YOU.  Either way, a disclaimer is required.

Re: Why not contribute? (to GCC)

[Eric Botcazou]

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

The situation has improved in this area since the "Reviewer" position was 
introduced a few years ago though.

> 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?

Write small patches.  Even if you know that the change is not a complete 
solution to the problem, it might be good enough as a first try so adding 
a ??? comment would be sufficient.

Eliminate the easy mistakes in patches.  GCC uses strict coding conventions, 
including formatting and commenting conventions, so not following them is a 
mistake that will be flagged as such.  Fortunately this is easy to correct, 
you don't even need to read the (whole) documentation, just look around in 
the existing code you're modifying and make it so that the new code cannot 
be distinguished from the old one in this respect.

Write proper ChangeLogs.  They are kind of executive summaries for patches and 
help to grasp what they do.  The various ChangeLog files have many examples.

-- 
Eric Botcazou

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions, 
> including formatting and commenting conventions, so not following them is a 
> mistake that will be flagged as such.  Fortunately this is easy to correct, 
> you don't even need to read the (whole) documentation, just look around in 
> the existing code you're modifying and make it so that the new code cannot 
> be distinguished from the old one in this respect.
> 
> Write proper ChangeLogs.  They are kind of executive summaries for patches
> and help to grasp what they do.  The various ChangeLog files have many
> examples.

Moreover, I think that having a patch that's improperly formatted or
missing or improper ChangeLog may simply cause reviewers to ignore the
patch because they don't want to have to deal with explaining these
things to people.  This SHOULDN'T happen, but I'm pretty sure it does.

PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:

static u32
add32carry(u32 sum, u32 x)
{
  u32 z = sum + x;
  if (sum + x < x)
  z++;
  return z;
}
Becomes:
add32carry:
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 0,0,3
mr 3,0
Instead of:
addc 3,3,4
addze 3,3

This slows down the the Internet checksum sigificantly

Also, doing this in a loop can be further optimized:

for(;len; --len)
   sum = add32carry(sum, *++buf);


addic 3, 3, 0 /* clear carry */
.L31:
lwzu 0,4(9)
adde 3, 3, 0 /* add with carry */
bdnz .L31

addze 3, 3 /* add in final carry */

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 3:00 PM, Richard Kenner
 wrote:
>> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions,
>> including formatting and commenting conventions, so not following them is a
>> mistake that will be flagged as such.  Fortunately this is easy to correct,
>> you don't even need to read the (whole) documentation, just look around in
>> the existing code you're modifying and make it so that the new code cannot
>> be distinguished from the old one in this respect.
>>
>> Write proper ChangeLogs.  They are kind of executive summaries for patches
>> and help to grasp what they do.  The various ChangeLog files have many
>> examples.
>
> Moreover, I think that having a patch that's improperly formatted or
> missing or improper ChangeLog may simply cause reviewers to ignore the
> patch because they don't want to have to deal with explaining these
> things to people.  This SHOULDN'T happen, but I'm pretty sure it does.

In the aerospace industry we have a somewhat similar problem. Every
part of assembly drawing has to be reviewed ("checked") and approved.
But the common mistakes often are so distracting that checkers don't
even want to begin to comment on to-be-released drawing in the PDM
system. It is very demotivating to review something and you're just
pointing out issues with formalities instead of focusing on the actual
design.

The solution for this in my working environment is an automatic
checker. This checker validates the drawing against a set of
requirements (proper design principles, proper drawing formatting,
correct label, etc.). You can't upload a drawing for check in the PDM
system until it passes the checker (it is part of the PDM system, and
it simply rejects drawings that don't pass).

Perhaps it is possible to create some kind of check-patch script for
GCC too, e.g. one that checks the following things at least:
* ChangeLog presence
* ChangeLog format and completeness
* formatting / coding style of the patch itself

We should perhaps make tools available in contrib/ that help people
set up things properly for patch submission. For example Diego had a
script that extracts a skeleton ChangeLog from a patch, perhaps it
should be put in contrib/ and advertised somewhere (e.g. wiki).

There are many things beside this that we could do to simplify the
patch submission process. It's just part of the problem but perhaps it
helps.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

I don't like self-advertising, but ...

* Steven Bosscher wrote on Sun, Apr 25, 2010 at 03:05:45PM CEST:
> Perhaps it is possible to create some kind of check-patch script for
> GCC too, e.g. one that checks the following things at least:
> * ChangeLog presence
> * ChangeLog format and completeness
> * formatting / coding style of the patch itself
> 
> We should perhaps make tools available in contrib/ that help people
> set up things properly for patch submission. For example Diego had a
> script that extracts a skeleton ChangeLog from a patch, perhaps it
> should be put in contrib/ and advertised somewhere (e.g. wiki).

FWIW, I wrote vc-chlog a while ago (ships together with vc-dwim[1]) which
IMVHO is fairly accurate at creating stub ChangeLog entries if you have
Exuberant Ctags installed.  Without it, updates to the GCC build system
would have been rather painful.

I would add blurb about it in the wiki if that is acceptable.

Cheers,
Ralf

[1] www.gnu.org/software/vc-dwim/

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:

> On 25 April 2010 06:20, Chris Lattner  wrote:
>> 
>> 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.
> 
> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html

The key distinction is that contributing to LLVM does not require you to sign a 
form (which isn't even publicly available) and mail it in to a busy and 
high-latency organization before non-trivial patches will be accepted.

-Chris

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 16:55, Chris Lattner  wrote:
>
> On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
>
>> On 25 April 2010 06:20, Chris Lattner  wrote:
>>>
>>> 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.
>>
>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>
> The key distinction is that contributing to LLVM does not require you to sign 
> a form (which isn't even publicly available) and mail it in to a busy and 
> high-latency organization before non-trivial patches will be accepted.

So, is the copyright disclaimer implicit in the patch submission? Who
defines the conditions?

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
 
 On what do you base these assertions?  Every point seems wrong to me.
>>> 
>>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>> 
>> The key distinction is that contributing to LLVM does not require you to 
>> sign a form (which isn't even publicly available) and mail it in to a busy 
>> and high-latency organization before non-trivial patches will be accepted.
> 
> So, is the copyright disclaimer implicit in the patch submission? Who
> defines the conditions?

That web page is everything that there is.  I am aware that this is not as 
legally air-tight as the FSF disclaimer, but empirically many companies seem to 
have no problem with it.

-Chris

Re: Why not contribute? (to GCC)

[H.J. Lu]

On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner  wrote:
> On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>
> On what do you base these assertions?  Every point seems wrong to me.

 Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>>>
>>> The key distinction is that contributing to LLVM does not require you to 
>>> sign a form (which isn't even publicly available) and mail it in to a busy 
>>> and high-latency organization before non-trivial patches will be accepted.
>>
>> So, is the copyright disclaimer implicit in the patch submission? Who
>> defines the conditions?
>
> That web page is everything that there is.  I am aware that this is not as 
> legally air-tight as the FSF disclaimer, but empirically many companies seem 
> to have no problem with it.
>

Can't resist. So in theory, someone can sue LLVM and win. If it is the
case, I may
not want to use LLVM as my system compiler.


-- 
H.J.

Re: Why not contribute? (to GCC)

[Denys Vlasenko]

On Friday 23 April 2010 21:10, Richard Kenner wrote:
> I've happened to be looking at a number of other free-software projects
> recently (having nothing to do with compilers) and find the quality of the
> code ABSOLUTELY APALLING.

That's because you didn't look at non-open code. It's no better.

> The formatting is random and very hard to read. 
> There are almost no comments.  There are few, if any, indications of what
> each function is supposed to do.

This is typical for most code, open and closed.

> And many of these projects have no 
> documentation AT ALL except for some small FAQs or Wikis.
> 
> When we ask "why is contributing to GCC so hard", we must never forget that
> a large part of the answer to that question is that we have much higher
> STANDARDS than most free-software projects in terms of code quality
> and documentation.

And such attitude (denial that "we" have any problems) is typical too...

> I don't believe that lessening those standards to 
> increase contributions would ever be a good thing in the long term.

This statement carries an implicit assumption that the only barrier
for contribution to GCC is the "high quality of code required".
This is not true. For one, copyright assignment requirement
is an untypical requirement for open-source world,
and may turn away some contributors.

-- 
vda

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Sat, 24 Apr 2010 08:51:17 -0400
"Alfred M. Szmidt"  wrote:

> Not much can be done to either of those, the copyright assignments are
> necessary to keep GCC legally safe.

Given that there are plenty of high-profile projects out there which
seem to be entirely safe in the absence of copyright assignment
policies, why, exactly, does GCC need one to be "legally safe"?

Note that "copyright assignment" and "being sure that the developer
has the right to contribute the code" are two very different things.

Thanks,

jon

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 5:34 PM, Jonathan Corbet  wrote:
> On Sat, 24 Apr 2010 08:51:17 -0400
> "Alfred M. Szmidt"  wrote:
>
>> Not much can be done to either of those, the copyright assignments are
>> necessary to keep GCC legally safe.
>
> Given that there are plenty of high-profile projects out there which
> seem to be entirely safe in the absence of copyright assignment
> policies, why, exactly, does GCC need one to be "legally safe"?
>
> Note that "copyright assignment" and "being sure that the developer
> has the right to contribute the code" are two very different things.

IANAL but the copyright assignment is probably necessary for the FSF
to have the rights to change the license at will (within the
limitations allowed by the copyright assignment). If there are many
copyright holders, like for say the linux kernel, a change of license
requires the approval of at least all major copyright holders, IIUC.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 17:44, Steven Bosscher  wrote:
>
> IANAL but the copyright assignment is probably necessary for the FSF
> to have the rights to change the license at will (within the
> limitations allowed by the copyright assignment). If there are many
> copyright holders, like for say the linux kernel, a change of license
> requires the approval of at least all major copyright holders, IIUC.

I think this is not worth discussing. The FSF is not going to not ask
for copyright assignment. The question is whether the process can be
simplified.

LLVM has also copyright assignment, however, it is implicit in the
patch submission. Whether this is enough or not or the legal
consequences of it are not clear to me.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   IANAL but the copyright assignment is probably necessary for the
   FSF to have the rights to change the license at will (within the
   limitations allowed by the copyright assignment). If there are many
   copyright holders, like for say the linux kernel, a change of
   license requires the approval of at least all major copyright
   holders, IIUC.

This is incorrect, anyone can upgrade the license for GCC (and the
rest of the GNU project), since GCC is licensed under the `GPLv3 or
any later version'.  Linux on the other hand is explicitly licensed
only under GPLv2; i.e. it lacks the `or (at your option) any later
version)' clause.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > Not much can be done to either of those, the copyright assignments are
   > necessary to keep GCC legally safe.

   Given that there are plenty of high-profile projects out there
   which seem to be entirely safe in the absence of copyright
   assignment policies, why, exactly, does GCC need one to be "legally
   safe"?

I do not know what high-profile projects you are refering to, you will
have to ask them why they think they can ignore a paper trail.  Having
one copyright holder solves many issues when enforcing copyright, you
do not need to contact all parties.  There is a short article on why
you should assign copyright to the FSF at:
http://www.gnu.org/licenses/why-assign.html

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
> 
> The key distinction is that contributing to LLVM does not require you to
> sign a form (which isn't even publicly available) and mail it in to a busy
> and high-latency organization before non-trivial patches will be accepted.

I'm confused.  If nothing's signed, then how is the copyright being
assigned?

Re: Why not contribute? (to GCC)

[Richard Kenner]

> That web page is everything that there is.  I am aware that this is not as 
> legally air-tight as the FSF disclaimer, but empirically many companies
> seem to have no problem with it.

There's nothing to have a problem WITH!  No assignment has taken place.
The statement on the web has no legal significance whatsoever.  Unless
the company SIGNS something, they still own the copyright on the code
and can, at any time, decide they don't want it distributed.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> That's because you didn't look at non-open code. It's no better.

Nobody said it was.

> This statement carries an implicit assumption that the only barrier
> for contribution to GCC is the "high quality of code required".
> This is not true. For one, copyright assignment requirement
> is an untypical requirement for open-source world,
> and may turn away some contributors.

I said "A" large part.  There is certainly a perception that the
copyright assignment is an issue too.  But, as was discussed here, there
IDENTICAL liability with and without the assignment.  So this is illusory.
And if the reason for not wanting to assign the copyright is that they
aren't comfortable with the code being part of the project, then there's
a larger problem than the assignment itself.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Note that "copyright assignment" and "being sure that the developer
> has the right to contribute the code" are two very different things.

Although that's true, the stated concern with the assignment document
had to do with the question of the right to contribute the code.

But I'm confused here: if the entity submitting the code doesn't use
an assignment document to guarantee that he has the right to contribute
the code, then what document DOES that entity sign?  What DOES make sure
that no third party has a claim on the submitted code?

Re: Why not contribute? (to GCC)

[Richard Kenner]

> LLVM has also copyright assignment, however, it is implicit in the
> patch submission. 

Do they have any legal opinion which backs the claim that this sort of
"implicit" assignment has any legal force at all?

Re: Why not contribute? (to GCC)

[Michael Witten]

On Sun, Apr 25, 2010 at 11:33, Richard Kenner
 wrote:
> There's nothing to have a problem WITH!  No assignment has taken place.
> The statement on the web has no legal significance whatsoever.  Unless
> the company SIGNS something, they still own the copyright on the code
> and can, at any time, decide they don't want it distributed.

If I submit a patch to the GCC project---necessitating an assignment
of the copyright to the FSF---then can the people of the FSF decide
that they don't want me to distribute my own work in another project
(proprietary or otherwise)?

That is, could I actually become liable for infringing on the
copyright of my own original work? Are we just trusting RMS not to be
a troll (tongue-in-cheek)?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 18:48, Michael Witten  wrote:
> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
>  wrote:
>> There's nothing to have a problem WITH!  No assignment has taken place.
>> The statement on the web has no legal significance whatsoever.  Unless
>> the company SIGNS something, they still own the copyright on the code
>> and can, at any time, decide they don't want it distributed.
>
> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?
>
> That is, could I actually become liable for infringing on the
> copyright of my own original work? Are we just trusting RMS not to be
> a troll (tongue-in-cheek)?

This is explicitly mentioned on the copyright assignment form from the
FSF. And the answer is NO.

On the other hand, when the assignment is implicit like for LLVM, I
really don't know. You need to ask your own lawyer (not the ones from
Apple or from the U. of Illinois).

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?

No, because the assignment agreement says that the FSF "agrees to
grant the Assigner non-exclusive rights to use the Work (i.e. the
changes and enhancements, not the program which was enhanced) as it
sees fit".  And, indeed, this is commonly done.  For example, Cygwin
had two different license agreements, one when it's distributed by the
FSF and one when it's purchased by Cygnus.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten  wrote:
> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?

No. This is very explicitly mentioned in the copyright assignment
papers. For example, from my own copy (2002):

"1.(d) FSF agrees to grant back to Developer, and does hereby grant,
non-exclusive, royalty-free and non-cancellable rights to use the
Works (i.e., Developer's changes and/or enhancements, not The Program
that they enhance), as Developer sees fit."

In other words, you can distribute your own work in another project in
any way you want.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Richard Kenner]

> On the other hand, when the assignment is implicit like for LLVM, I
> really don't know. You need to ask your own lawyer (not the ones from
> Apple or from the U. of Illinois).

I don't believe there IS such a thing as an "implicit assignment".
You either signed a contract that assigns the copyright or you
haven't.  If an employee of some large company (say, Microsoft) writes
a patch for LLVM and submits it, what in the world would bind
Microsoft to having given up their copyright interest in that patch?
Certainly not some statement buried someplace in a web site.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 17:04, Chris Lattner  wrote:
> On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>
> On what do you base these assertions?  Every point seems wrong to me.

 Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>>>
>>> The key distinction is that contributing to LLVM does not require you to 
>>> sign a form (which isn't even publicly available) and mail it in to a busy 
>>> and high-latency organization before non-trivial patches will be accepted.
>>
>> So, is the copyright disclaimer implicit in the patch submission? Who
>> defines the conditions?
>
> That web page is everything that there is.  I am aware that this is not as 
> legally air-tight as the FSF disclaimer, but empirically many companies seem 
> to have no problem with it.

So, the copyright transfer is implicit in the patch submission
process. And any submitter that does not have a legal document stating
that his employer company allows the submitter to send that particular
code to LLVM is exposed to be sued not only by his/her employer but
also by the U. of Illinois. Nice.

I can understand companies not having problem with it. If something
goes wrong, they can always blame the employee because there is no
paper proving he or she had permission from his/her employer. Perhaps
the FSF is a bit too cautious, but this rings as a bit reckless. I
find surprising that the U. of Illinois has such relaxed approach to
copyright. But perhaps it is also in their interest to not ask many
questions. If something goes bad, they can just sue the individual
contributor rather than dealing with the whole legal department of a
company. Even more, if the company sues the contributor but not the U.
of Illinois, they may even get to keep the code. Sweet.

Have you made a poll in LLVM asking how many contributors actually
have some legal paper allowing them to contribute? That is how many
are currently legally exposed to a lawsuit. Would LLVM remove code if
a contributor starts doubting his legal position?

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I find surprising that the U. of Illinois has such relaxed approach to
> copyright. But perhaps it is also in their interest to not ask many
> questions. If something goes bad, they can just sue the individual
> contributor rather than dealing with the whole legal department of a
> company. Even more, if the company sues the contributor but not the U.
> of Illinois, they may even get to keep the code. Sweet.

A University is a big place.  Do we know that their legal department is
even AWARE of this?  Or did some group within the University who doesn't
understand copyright law just decide this is the "right way to do it"?

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> FWIW, I wrote vc-chlog a while ago (ships together with vc-dwim[1]) which
> IMVHO is fairly accurate at creating stub ChangeLog entries if you have
> Exuberant Ctags installed.  Without it, updates to the GCC build system
> would have been rather painful.
>
> I would add blurb about it in the wiki if that is acceptable.

Certainly acceptable for the wiki.  Thanks.

Ian

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 7:23 PM, Richard Kenner
 wrote:
>> I find surprising that the U. of Illinois has such relaxed approach to
>> copyright. But perhaps it is also in their interest to not ask many
>> questions. If something goes bad, they can just sue the individual
>> contributor rather than dealing with the whole legal department of a
>> company. Even more, if the company sues the contributor but not the U.
>> of Illinois, they may even get to keep the code. Sweet.
>
> A University is a big place.  Do we know that their legal department is
> even AWARE of this?  Or did some group within the University who doesn't
> understand copyright law just decide this is the "right way to do it"?

Whatever their reasons, this has very little to do with GCC. If
copyright assignment is an obstacle for contributing to GCC, we should
do something about that (clarify the reasons, simplify and speed up
the process, etc.). Let's talk about that instead :-)

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner  writes:

> The key distinction is that contributing to LLVM does not require
> you to sign a form (which isn't even publicly available) and mail it
> in to a busy and high-latency organization before non-trivial
> patches will be accepted.

For the record (Chris probably knows this), the exact copyright forms
are no longer posted online because in practice it often slowed down
the copyright assignment process.  Contributors routinely downloaded
the wrong form and arranged to have it signed by their employer.  When
the FSF received the wrong form, they had to request a different form,
and the contributors had to go through the signing process again.

That is, the forms are not publically available not because they are
secret, but to avoid confusion because international law is
unavoidably complex.  This fear of confusion is based not on
hypothesis, but on actual experience.

Instead, the process is to fill out a "request for assignment"
form--those forms are publically available--and the FSF will send you
the correct form.  For most contributors, the correct "request for
assignment" form may be found here:

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future


I agree that this is all far more complex and time consuming than it
ought to be.  I hope that the SC can work with the FSF to simplify the
process.  However, the legalities are there for a reason, as seen by
the copyright challenge from Unipress long ago and the SCO lawsuit
against the Linux kernel.  Apple and the University of Illinois are
taking a risk by permitting patches without any paperwork.  It's a low
probability risk, but it's one that the FSF wants to avoid based on
actual past experience.

Ian

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

[Ian Lance Taylor]

Jon  writes:

> 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.

We are now back in stage 1.  I approved the patch in
http://gcc.gnu.org/ml/gcc/2010-02/msg00281.html .

Sadly, one of the many ways that I am unable to contribute to GCC is
the time consuming process of picking up approved patches and
committing them to the repository.  Can somebody with write access
take it from here?

Ian

Re: merging the maverick FPU patches

[Ian Lance Taylor]

Martin Guy  writes:

> 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.

For a backend specific patch like this, I would recommend contacting
the ARM backend maintainers directly to ask how they would prefer to
proceed.  They can be found in the top level MAINTAINERS file:

arm portNick Cliftonni...@redhat.com
arm portRichard Earnshawrichard.earns...@arm.com
arm portPaul Brook  p...@codesourcery.com

Ian

Re: PowerPC suboptimal "add with carry" optimization

[Ian Lance Taylor]

Joakim Tjernlund  writes:

> Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:

Please file a missed-optimization report according to
http://gcc.gnu.org/bugs/ .  Thanks.

Ian

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 9:33 AM, Richard Kenner wrote:

>> That web page is everything that there is.  I am aware that this is not as 
>> legally air-tight as the FSF disclaimer, but empirically many companies
>> seem to have no problem with it.
> 
> There's nothing to have a problem WITH!  No assignment has taken place.
> The statement on the web has no legal significance whatsoever.  Unless
> the company SIGNS something, they still own the copyright on the code
> and can, at any time, decide they don't want it distributed.

It's unclear whether the LLVM-style implicit copyright assignment is really 
enforceable, and this certainly isn't a forum to debate it.  In any case, it 
doesn't really matter, because the only reason copyright needs to be assigned 
(AFAIK) is to change the license.  The LLVM project does not aim to be able to 
change the license in the future, all that is really important is that 
contributors agree to license their code under the llvm "bsd" license.

For at least some contributors, not being able to change the license is 
actually a major feature.  They aren't comfortable with assigning code to an 
organization which can then change the license of the code to something they 
don't agree with.  This is exactly what happened when code written and 
contributed under GPL2 got relicensed as GPL3 for example.  I'm not saying that 
this is right or wrong, but perceptions are held by people.

In any case the aims of the FSF are quite clear, and IMO it seems that the 
explicit copyright assignment is a real and necessary part of achieving those 
aims.  Different projects just have different goals.

-Chris

Re: Why not contribute? (to GCC)

[Mark Mielke]

Copying David Daney's response to contrast against it:

GCC is a mature piece of software that works really well and it is in a 
programming domain which is not as well understood and for people such 
as myself, I would be intimidated from the start, to delve in and expect 
any contributions I make to be valuable enough to bother the existing 
machine with. :-)


But yes, if I overcame that intimidation, I'm sure David Daney's 
comments would describe the *next* barrier to overcome...


Cheers,
mark


On 04/23/2010 03:33 PM, David Daney wrote:

On 04/23/2010 11:39 AM, Manuel López-Ibáñez wrote:

This seems to be the question running around the blogosphere for
several projects. And I would like to ask all people that read this
list but hardly say or do anything.

What reasons keep you from contributing to GCC?



I am going to answer why I think it is, even though I like to think 
that I do do something.



GCC has high standards, so anybody attempting to make a contribution 
for the first time will likely be requested to go through several 
revisions of a patch before it can be accepted.


After having spent considerable effort developing a patch, there can 
be a sense that the merit of a patch is somehow related to the amount 
of effort expended creating it.  Some people don't have a personality 
well suited to accepting criticism of something into which they have 
put a lot of effort.  The result is that in a small number of cases, 
people Bad Mouth GCC saying things like:  The GCC maintainers are a 
clique of elitist idiots that refuse to accept good work from outsiders.


Personally I don't agree with such a view, and I don't think there is 
much that can be done about it.  There will always be Vocal 
Discontents, and trying to accommodate all of them would surly be 
determental to GCC.


I think that some potential contributors are discouraged from 
contributing because they have been frightened away (by the Vocal 
Discontents mentioned above) before they can get started.



David Daney

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

[Richard Guenther]

On Sun, Apr 25, 2010 at 1:24 PM, Toon Moene  wrote:
> Richard Guenther wrote:
>
>> On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene  wrote:
>
>>> 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?
>
> Indeed, I do (all of our code ends up in libraries - .a files - so I have
> to, to make -flto -fwhole-program be meaningful).
>
> Is it a problem with COMMON ?  Those typically have umpteen definitions,
> which all have to match ...

No, gold should choose a single prevailing definition.  The issue is that
gold and the linker-plugin seem to be unmaintained.  Can you make sure
you have an up-to-date gold?  There was a gold bugfix related to the
above this month.

Richard.

> 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/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
>

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 06:18 PM, Alfred M. Szmidt wrote:

My personal opinion is that this legal reason is a *huge*
bottleneck against external contributions. In particular, because
you need to deal with it *before* submitting any patch, which,
given the complexity (4MLOC) and growth rate (+30% in two years) of
GCC, means in practice that people won't even start looking
seriously inside GCC before getting that legal paper.

Simply not true, you can submit patches without the legal leg work
done.  The patch cannot be commited to the tree though.  And the time
it takes to do this is less than it took me to read your message...
   


I don't follow this comment...

Wouldn't contributing a patch to be read by the person who will be 
solving the problem, but without transferring of rights, introduce risk 
or liability for the FSF and GCC?


I thought "clean room implementation" implies not seeing how somebody 
else did it first, as the "clean" part is tainted after somebody 
examines the patch?


Cheers,
mark

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

[Steven Bosscher]

On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
 wrote:
>
> No, gold should choose a single prevailing definition.  The issue is that
> gold and the linker-plugin seem to be unmaintained.

Looking at the binutils list, there seems to be a lot of gold patching
going on. Why do you believe it is unmaintained?

For the plugin: is this not covered in the test suite (and if that's
the problem, then what can we do about it)?

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 08:37 PM, Basile Starynkevitch wrote:
However, I would believe that most GCC contributors do not actively 
check their patch against the US patent system (because I perceive the 
US patent system to be very ill w.r.t. software). I confess I don't do 
that - it would be a full time & boring job.




At some companies, the lawyers specifically request that employees do 
NOT check for violation of patents or research any patents before 
writing code, as this process actually increases liability. It's similar 
to the "clean room implementation" model. If I look, then my ability to 
say "I wrote this myself without any input" is tainted. If I just write 
it myself without researching what others have done, then I can at least 
claim I never copied any ideas, and although I might still be found in 
violation of a patent, this can be addressed if and when it is found 
(either pay license/royalty fees or re-write the code to NOT use the 
now-known-to-be-patented ideas).


Just thought that this "opposite approach" might be interesting to 
readers... :-)


Cheers,
mark

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 08:47 PM, Ian Lance Taylor wrote:

Basile Starynkevitch  writes:

I also never understood what would happen if I had a brain illness to
the point of submitting illegal patches (I have no idea if such things
could exist; I am supposing today that if I wrote every character of
every patch I am submitting to GCC they cannot be illegal.),
 

The liability for the action would land on you rather than on the
FSF.  That is what matters for the future of the gcc project.

...

There is no unlimited liability in the copyright assignment, either in
words or in action.
   


In the first quote "The liability..." you agree that there is liability. 
In the second you say no unlimited liability.


So how much liability is required for somebody to accept in order to be 
allowed to contribute to GCC?


Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sun, Apr 25, 2010 at 2:40 PM, Eric Botcazou  wrote:
>> So we need more patch reviewers.  How can that be addressed?
>
> The situation has improved in this area since the "Reviewer" position was
> introduced a few years ago though.
>
>> 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?
>
> Write small patches.  Even if you know that the change is not a complete
> solution to the problem, it might be good enough as a first try so adding
> a ??? comment would be sufficient.
>
> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions,
> including formatting and commenting conventions, so not following them is a
> mistake that will be flagged as such.  Fortunately this is easy to correct,
> you don't even need to read the (whole) documentation, just look around in
> the existing code you're modifying and make it so that the new code cannot
> be distinguished from the old one in this respect.
>
> Write proper ChangeLogs.  They are kind of executive summaries for patches and
> help to grasp what they do.  The various ChangeLog files have many examples.

Do not followup your patch with new versions every other day.  Doing so
sticks with reviewers and so you get ignored until they are confident
enough their review time is not wasted.

Thus, be confident of your own patches!  Have them tested _before_
submitting them (well, if you're not in the small group of people that
patch reviewers forgive when doing so).  Test your patches on a
common target (like i?86/x86_64-linux).

Richard.

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

[Richard Guenther]

On Sun, Apr 25, 2010 at 9:37 PM, Steven Bosscher  wrote:
> On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
>  wrote:
>>
>> No, gold should choose a single prevailing definition.  The issue is that
>> gold and the linker-plugin seem to be unmaintained.
>
> Looking at the binutils list, there seems to be a lot of gold patching
> going on. Why do you believe it is unmaintained?

I meant that the combination of LTO + gold/-fuse-linker-plugin is
unmaintained.  Nobody is actively looking at bugreports with
that combination.

> For the plugin: is this not covered in the test suite (and if that's
> the problem, then what can we do about it)?

The testsuite does not cover -fuse-linker-plugin at all - it lacks at least
a feature test for it (not all configurations support it).  Thus, it's not
unfortunately possible to write a testcase excercising the
-fuse-linker-plugin path.

I'm somewhat uncomfortable that we have the two paths into LTO,
by using collect2 or the linker plugin.  Unfortunately the linker-plugin
is currently the only path that supports LTOing static libs.  As soon
as that issue is solved we should IMHO remove the linker-plugin path
again.

Richard.

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

[Manuel López-Ibáñez]

On 25 April 2010 20:03, Ian Lance Taylor  wrote:
> Jon  writes:
>
>> 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.
>
> We are now back in stage 1.  I approved the patch in
> http://gcc.gnu.org/ml/gcc/2010-02/msg00281.html .
>
> Sadly, one of the many ways that I am unable to contribute to GCC is
> the time consuming process of picking up approved patches and
> committing them to the repository.  Can somebody with write access
> take it from here?

Ian, how can I check that there is a copyright assignment in place?

Jon, would you mind writing a proper Changelog?

I will test that the patch still passes the regression test and commit
it for you. OK?

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Whatever their reasons, this has very little to do with GCC. If
> copyright assignment is an obstacle for contributing to GCC, we should
> do something about that (clarify the reasons, simplify and speed up
> the process, etc.). Let's talk about that instead :-)

This discussion is part of "clarify the reasons".

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

[Jon]

Hi Manuel

Manuel López-Ibáñez wrote, On 25/04/10 22:00:
[.]

Jon, would you mind writing a proper Changelog?


I've attached the Changelog I wrote before. I can change if needed, 
let me know what info I should add.



I will test that the patch still passes the regression test and commit
it for you. OK?


That would be great, thank you.

BTW, I returned the copyright assignment to FSF @ 17 Feb 2010, I think 
copyright-cl...@fsf.org will be able to confirm this.


Best regards, Jon
Index: collect2.c
===
--- collect2.c	(revision 156482)
+++ collect2.c	(working copy)
@@ -174,7 +174,7 @@
   int number;
 };
 
-int vflag;/* true if -v */
+bool vflag;/* true if -v or --version */ 
 static int rflag;			/* true if -r */
 static int strip_flag;			/* true if -s */
 static const char *demangle_flag;
@@ -193,7 +193,8 @@
 /* Current LTO mode.  */
 static enum lto_mode_d lto_mode = LTO_MODE_NONE;
 
-int debug;/* true if -debug */
+bool debug;/* true if -debug */
+bool helpflag;			/* true if --help */
 
 static int shared_obj;			/* true if -shared */
 
@@ -1228,7 +1229,7 @@
 for (i = 1; argv[i] != NULL; i ++)
   {
 	if (! strcmp (argv[i], "-debug"))
-	  debug = 1;
+	  debug = true;
 else if (! strcmp (argv[i], "-flto") && ! use_plugin)
 	  {
 	use_verbose = true;
@@ -1458,7 +1459,7 @@
   if (use_verbose && *q == '-' && q[1] == 'v' && q[2] == 0)
 	{
 	  /* Turn on trace in collect2 if needed.  */
-	  vflag = 1;
+	  vflag = true;
 	}
 }
   obstack_free (&temporary_obstack, temporary_firstobj);
@@ -1588,7 +1589,7 @@
 
 	case 'v':
 	  if (arg[2] == '\0')
-		vflag = 1;
+		vflag = true;
 	  break;
 
 	case '-':
@@ -1619,6 +1620,10 @@
 		}
 	  else if (strncmp (arg, "--sysroot=", 10) == 0)
 		target_system_root = arg + 10;
+	  else if (strncmp (arg, "--version", 9) == 0)
+		vflag = true;
+	  else if (strncmp (arg, "--help", 9) == 0)
+		helpflag = true;
 	  break;
 	}
 	}
@@ -1720,6 +1725,20 @@
   fprintf (stderr, "\n");
 }
 
+  if (helpflag)
+{
+  fprintf (stderr, "Usage: collect2 [options]\n");
+  fprintf (stderr, " Wrap linker and generate constructor code if needed.\n");
+  fprintf (stderr, " Options:\n");
+  fprintf (stderr, "  -debug  Enable debug output\n");
+  fprintf (stderr, "  --help  Display this information\n");
+  fprintf (stderr, "  -v, --version   Display this program's version number\n");
+  fprintf (stderr, "Overview: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html\n";);
+  fprintf (stderr, "Report bugs: %s\n", bug_report_url);
+
+  collect_exit (0);
+}
+
   if (debug)
 {
   const char *ptr;
Index: collect2.h
===
--- collect2.h	(revision 156482)
+++ collect2.h	(working copy)
@@ -38,7 +38,7 @@
 extern const char *c_file_name;
 extern struct obstack temporary_obstack;
 extern char *temporary_firstobj;
-extern int vflag, debug;
+extern bool vflag, debug;
 
 extern void error (const char *, ...) ATTRIBUTE_PRINTF_1;
 extern void notice (const char *, ...) ATTRIBUTE_PRINTF_1;
2010-03-13  Jon Grant <0...@jguk.org>
* collect2.c: debug changed to bool so true/false can be used. bool 
helpflag added.
* collect2.c: --version now sets vflag true. --help no sets helpflag 
true.
* collect2.c: when --help passed, standard help information is output 
on stderr
* collect2.h: vflag changed to bool so true/false can be used. 

Re: Why not contribute? (to GCC)

[Richard Kenner]

> because the only reason copyright needs to be assigned (AFAIK) is to
> change the license.

False.  See a discussion of this earlier in the thread.

> The LLVM project does not aim to be able to change the license in the
> future, 

Nobody "aims" to change something in the future, but nobody has a crystal
ball either and it can often be hard to predict what might have to be done
in the future.


But this misses an important point.  There are TWO reasons for what we've
been calling the assignment form.  One is to actually assign the copyright.
The other is to have a signed statement by the contributor that they have
the ownership rights to make the contribution and are indemnifying the
entity they are contributing to in case they don't.  What document serves
this purpose for LLVM if there's no assignment form?

If there's no such document, then what does the project do if, unknown to
them, some employee of a large company contributed code without the
permission of his employer, the project distributes that code, and then the
large software company sues for infringment?  You can't even go after the
employee because not even he has signed anything.

Instability in guality testsuite? [was Re: [PATCH,4.6/4.5.1,PR42776] Implement LTO for Windows (PE-COFF) targets.]

[Dave Korn]

On 19/04/2010 01:45, Dave Korn wrote:

>   Something strange, unexpected and a bit alarming happened:

  For context, it is necessary to explain that I was testing a patch (target
i686-pc-linux-gnu running on FC10) that mechanically renamed a bunch of
functions matching "lto_elf_*" to match "lto_obj_*" instead, and updated their
callers, so I was very strongly expecting to see no change in the testresults.
 Instead, I got:

>> -# of expected passes   72800
>> +# of expected passes   72799

> ... which turns out to be because:

>> -PASS: gcc.dg/guality/pr43479.c  -O1  line 13 i == 6
>> +UNSUPPORTED: gcc.dg/guality/pr43479.c  -O1  line 13 i == 6

  So, I'm looking at the logs of the two tests, and here is the passing case:

> PASS: gcc.dg/guality/pr43479.c  -O1  execution test
> Spawning: gdb -nx -nw -quiet -x pr43479.gdb ./pr43479.exe
> [?1034hBreakpoint 1 at 0x80483b7: file 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> 
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13  k++;  /* { dg-final { gdb-test 13 "i" "6" } } */
> $1 = 6
> $2 = 6
> The program is running.  Exit anyway? (y or n) [answered Y; input not from 
> terminal]
> PASS: gcc.dg/guality/pr43479.c  -O1  line 13 i == 6

... and here is what it did in the failing case:

> PASS: gcc.dg/guality/pr43479.c  -O1  execution test
> Spawning: gdb -nx -nw -quiet -x pr43479.gdb ./pr43479.exe
> [?1034hBreakpoint 1 at 0x80483b7: file 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> 
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9fUNSUPPORTED: 
> gcc.dg/guality/pr43479.c  -O1  line 13 i == 6

  Now, there is code in gcc/testsuite/lib/gcc-gdb-test.exp#gdb-test that looks
out for this condition:

>   # Too old GDB
>   -re "Unhandled dwarf expression|Error in sourced command file" {
>   unsupported "$testname"

... so probably, it should have been treated as unsupported on both clean and
patched builds.  Rebuilding the executables and reinvoking gdb on them and
running to the same breakpoint manually, produces identical results for the
patched and unpatched compilers: clean

> [da...@ubique gcc]$ /gnu/gcc/obj.clean/gcc/xgcc -B/gnu/gcc/obj.clean/gcc/ 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c   -O1  -g  -lm   -o 
> ./pr43479.exe
> [da...@ubique gcc]$ gdb -nx -nw -quiet  ./pr43479.exe
> (gdb) b 13
> Breakpoint 1 at 0x80483a7: file 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> (gdb) r
> Starting program: /gnu/gcc/obj.clean/gcc/testsuite/gcc/pr43479.exe 
> 
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13  k++;  /* { dg-final { gdb-test 13 "i" "6" } } */
> (gdb) 

versus patched:

> [da...@ubique gcc]$ /gnu/gcc/obj.patched/gcc/xgcc -B/gnu/gcc/obj.patched/gcc/ 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c   -O1  -g  -lm   -o 
> ./pr43479.exe
> [da...@ubique gcc]$ gdb -nx -nw -quiet  ./pr43479.exe
> (gdb) b 13
> Breakpoint 1 at 0x80483a7: file 
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> (gdb) r
> Starting program: /gnu/gcc/obj.patched/gcc/testsuite/gcc/pr43479.exe 
> 
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13  k++;  /* { dg-final { gdb-test 13 "i" "6" } } */
> (gdb) 

  Well, I think I can guess what happened here.  (This often happens as a
side-effect of taking the time to clearly explain the problem in the form of a
mailing list post asking for help!)  The code in gcc-gdb-test.exp that invokes
gdb and looks for output from it is structured like so:

remote_expect target [timeout_value] {
-re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
set first $expect_out(1,string)
set second $expect_out(2,string)
if { $first == $second } {
pass "$testname"
} else {
send_log "$first != $second\n"
fail "$testname"
}
remote_close target
return
}
# Too old GDB
-re "Unhandled dwarf expression|Error in sourced command file" {
unsupported "$testname"
remote_close target
return
}
timeout {
unsupported "$testname"
remote_close target
return
}
}

  My theory is that, depending on system load, the stdout coming from gdb and
being received by remote_expect is getting received in chunks in some way, and
that, depending how far the expect-launched gdb and its inferior progress,
expect might receive either all the output, or only the first couple of lines.

 If all the output turns up in one chunk, the code above will match on the
first -re expression, and give a PASS, despite the unhandled 

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Wouldn't contributing a patch to be read by the person who will be 
> solving the problem, but without transferring of rights, introduce risk 
> or liability for the FSF and GCC?
> 
> I thought "clean room implementation" implies not seeing how somebody 
> else did it first, as the "clean" part is tainted after somebody 
> examines the patch?

That's true, but is much less of a risk than actually integrating the patch
into a codebase.  There's already a level of indirection here in any
infringement and the code WAS posted to a public list.

I'm shortening a complex concept here, but when you want to see if an item
infringes on a copyrighted item, you are entitled to look at each level of
abstraction independently.  When you have the sort of infringement you're
talking about above, it's occuring at a higher level of abstraction than
code and most GCC patches have little protectable content at that level.

But indeed people DO have to be careful in how much they look at patches
from people who don't have assignments, especially if the patch is very
large and has a lot of nontrivial stuff in it.

[LTO] Open items in the ToDo list

[Andi Hellmund]

Hey,

I was recently reading through the wiki pages of the LTO branch and 
found several open items in the ToDo list which are generally interesting.


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.


Is someone already working on this item? Or are there any reasons to NOT 
start working on this item? :-)



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.


Thanks,
Andi

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:20 AM, H.J. Lu wrote:

On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner  wrote:
   

On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
 

So, is the copyright disclaimer implicit in the patch submission? Who
defines the conditions?
   

That web page is everything that there is.  I am aware that this is not as 
legally air-tight as the FSF disclaimer, but empirically many companies seem to 
have no problem with it.
 

Can't resist. So in theory, someone can sue LLVM and win. If it is the
case, I may
not want to use LLVM as my system compiler.
   


Considering that Linux, as the system kernel for many of us, is in a 
similar position, I don't see why the compiler, which isn't even a 
necessary part of a running system, would need to be more strict...


In any case, the FSF disclaimer is paper work. It may help in some 
theoretical situation - or maybe it will be called invalid at the time 
it is presented. The question is whether the added paper work is really 
providing protection, or is it just slowing contributions? I don't have 
the answer to that - I only see that LLVM and many other projects under 
various free / open source licenses are proceeding just fine without 
such paper work, so on the surface, it does seem like an overall loss 
for GCC. One day might it prove its value? Who knows...


Cheers,
mark

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

[Manuel López-Ibáñez]

On 25 April 2010 23:17, Jon  wrote:
> Hi Manuel
>
> Manuel López-Ibáñez wrote, On 25/04/10 22:00:
> [.]
>>
>> Jon, would you mind writing a proper Changelog?
>
> I've attached the Changelog I wrote before. I can change if needed, let me
> know what info I should add.

Ideally, the format should follow the example in:

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

Basically, in your case, do not repeat the filename and mention which
function is affected (if any).

Thanks,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> At some companies, the lawyers specifically request that employees do 
> NOT check for violation of patents or research any patents before 
> writing code, as this process actually increases liability. It's similar 
> to the "clean room implementation" model. If I look, then my ability to 
> say "I wrote this myself without any input" is tainted. If I just write 
> it myself without researching what others have done, then I can at least 
> claim I never copied any ideas, and although I might still be found in 
> violation of a patent, this can be addressed if and when it is found 
> (either pay license/royalty fees or re-write the code to NOT use the 
> now-known-to-be-patented ideas).

Indeed this difference between patents and copyrights is worth repeating
since it's critical and non-intuitive.  If you and I both write an
identical piece of music, neither of us can succeed in a copyright
infringement case against the other if we can prove we never SAW the work
of the other: in order to infringe on a copyright, you actually have to
COPY the work.

That's NOT true for patents.  Even if I independently "invent" the same
thing you do, I owe you royalties if you patented it and I didn't.  This is
why patents are a very serious threat to free software.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> So how much liability is required for somebody to accept in order to be 
> allowed to contribute to GCC?

This was answered already.  It's the same for EVERY software project
(not unique to GCC): if I steal somebody's copyrighted material and
"contribute" it to a software project, I am liable for the FULL EXTENT
of damages that my action caused.  This is true whether I sign an
"assignment" document or not.

Re: [LTO] Open items in the ToDo list

[Manuel López-Ibáñez]

On 25 April 2010 23:35, Andi Hellmund  wrote:
>
> 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.

Good idea, I will suggest that you move the TODO list to the top of
the file, before the notice that the branch was merged. Otherwise it
feels as if everything has been done already.

Cheers,

Manuel.

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

[Dave Korn]

On 25/04/2010 21:41, Richard Guenther wrote:

> I'm somewhat uncomfortable that we have the two paths into LTO,
> by using collect2 or the linker plugin.  Unfortunately the linker-plugin
> is currently the only path that supports LTOing static libs.  As soon
> as that issue is solved we should IMHO remove the linker-plugin path
> again.

  Is there a PR open about this, or any notes anywhere?  Being as I use a
non-ELF platform and so gold is not an option, I'd be pleased to help with
making this work.

cheers,
  DaveK

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 05:49 PM, Richard Kenner wrote:

So how much liability is required for somebody to accept in order to be
allowed to contribute to GCC?
 

This was answered already.  It's the same for EVERY software project
(not unique to GCC): if I steal somebody's copyrighted material and
"contribute" it to a software project, I am liable for the FULL EXTENT
of damages that my action caused.  This is true whether I sign an
"assignment" document or not.
   


Yep - but that's my point. "Full extent" without any number listed is 
effectively unlimited liability.


I saw people trying to suggest unlimited = infinity and that it will not 
be infinity, therefore it is not unlimited - but this just sounds like a 
wording game. One poster tried to argue that it was limited by 
describing that it was only 3 times some unspecified amount. But they 
missed that unspecified is unlimited. 3 times unspecified = 3 times 
unlimited = unlimited.


The fact is, it is unlimited liability because no limit has been set.

Whether this is unique to copyright assignment vs the more common shared 
ownership model? It's a good point that in either case, the liability 
may exist. This is where it becomes a bit complicated to me. As a "for 
example", I could see somebody suing the FSF because it is a funded 
organization that can be easily listed as "the defendant", whereas an 
open source project with hundreds of committers each with individual 
assignments for the parts they contributed, would be very difficult to 
list as "the defendant", so they would have to target the people 
involved with the specific patch - or "me". I couldn't see somebody 
suing me (my bank account hovers pretty low most of the time). Companies 
are not going to sue nobodies such as myself because there is no money 
in it. So, in practice, is there a difference or not? I think there is. 
With the assignment comes responsibility - except the FSF is explicitly 
requiring unlimited liability indemnity from the author, so they are 
accepting responsibility for the value, but not accepting responsibility 
for the risk. I can see why the FSF would want this - but I cannot see 
why I would want this. What's in it for me?


Honestly, this discussion has resurrected my concerns about the FSF in 
general. And since I don't really want to argue about this here, I think 
I'll cut it off by just repeating that there are a lot of GPL / BSD / 
etc. projects out there that don't seem to have the problems that are 
being predicted. The only one I see of any value is the ability to 
change the license in the future, without my explicit consent. Honestly, 
I'm a bit concerned about having my code be distributed under a 
different license without my explicit consent, especially as my 
definition of free does not match the definition of free provided by the 
FSF.


Cheers,
mark

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

[Steven Bosscher]

On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn
 wrote:

>  Is there a PR open about this, or any notes anywhere?  Being as I use a
> non-ELF platform and so gold is not an option, I'd be pleased to help with
> making this work.

See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some
first steps.

I don't understand this, actually. When I look at lto-elf/lto-coff,
there seems to be AR support already. But this doesn't work,
apparently?

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Yep - but that's my point. "Full extent" without any number listed is 
> effectively unlimited liability.

But what does that have to do with the FSF, GCC, or an assignment agreement?

You have EXACTLY THE SAME unlimited liability if you contribute to GCC,
LLVM, Linux, ECLIPSE, or any other project and whether you sign an
assignment or not.

> I couldn't see somebody suing me (my bank account hovers pretty low
> most of the time). Companies are not going to sue nobodies such as
> myself because there is no money in it. So, in practice, is there a
> difference or not?

No, because then the FSF wouldn't sue you EITHER!  There's NO
DIFFERENCE in theory or in practice as to your liability whether there's
an assignment or not and whether it's GCC or some other project.

gcc-4.3-20100425 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20100425.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20100425.tar.bz2 C front end and core compiler

gcc-ada-4.3-20100425.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20100425.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20100425.tar.bz2  C++ front end and runtime

gcc-java-4.3-20100425.tar.bz2 Java front end and runtime

gcc-objc-4.3-20100425.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20100425.tar.bz2The GCC testsuite

Diffs from 4.3-20100418 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 06:27 PM, Richard Kenner wrote:

I couldn't see somebody suing me (my bank account hovers pretty low
most of the time). Companies are not going to sue nobodies such as
myself because there is no money in it. So, in practice, is there a
difference or not?
 

No, because then the FSF wouldn't sue you EITHER!  There's NO
DIFFERENCE in theory or in practice as to your liability whether there's
an assignment or not and whether it's GCC or some other project.
   


Obviously there is a difference, otherwise FSF wouldn't be requesting 
copyright assignment. The difference is that the FSF "owns" the entire 
project. Does this affect liability in theory or in practice? You say 
no. I say it might. Consolidated ownership means an easy target for a 
greedy company and a lazy judge (neither of which are in poor 
abundance). Under such a model, this "easy target", if successfully sued 
and if damages are awarded, would pull up the copyright assignment 
agreement and hold me liable for the amount. Distributed ownership 
provides a difficult target and a less likely candidate for either a law 
suit in the first place, or a high $$$ amount once they figure out that 
they can only really sue me (and not a well funded organization). The 
ultimate in free, for me, is if every single person in the world 
contributed at least one line of code to the project, and retains 
ownership to their piece. Each person is then liable to each other 
person, and a true community owned project exists. Consolidated 
ownership can't do this.


The real reason for FSF copyright assignment is control. The FSF wants 
to control GCC. This presents a chore for potential contributors with 
very little value (if any) in return for their efforts. The published 
explanation (why-assign.html) states clearly that the FSF believes it is 
easier to defend the software and all derived software as being "free" 
(as defined by the FSF) using a consolidated ownership mode. I don't see 
how this benefits me in any way. If I'm giving software that I write to 
the community for "free", why do I care what they will do with it? If I 
control how they can use it - it's not free. It's limited use.


In some ways, I wish a group did fork GCC under GPL and drop the 
copyright assignment requirement. In other ways, this entire issue is 
just so minor to me that it isn't worth going beyond this thread. GCC 
works, but so do other compilers (Intel CC, LLVM, ...). GCC is 
distributed under the GPL, so if the FSF ever becomes a real problem (as 
opposed to merely having a political agenda), it can be forked at this 
later time.


All in all, pretty minor. GCC wants FSF copyright assignment and 
employer disclaimers? GCC will not have as many contributors. Your choice.


There are plenty of projects that we (lurkers / non contributors) can 
contribute to other projects that are not as mature and require more 
attention, or even other compilers (LLVM?).


Referring to the people and employees who have gone through the 
copyright assigment and employer disclaimers in the past and saying 
("they didn't have a problem signing") isn't evidence that the process 
is practical, efficient, or acceptable. These people probably just felt 
they had no other choice. If given the option of NOT doing this process, 
I'm sure most of them would happily have chosen option B.


Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Obviously there is a difference, otherwise FSF wouldn't be requesting 
> copyright assignment. 

I didn't say there's no different AT ALL: of course there is and that's
indeed why the assignment is needed.  What we were talking about is whether
there's a difference in the LIABILITY of a patch author.

> Distributed ownership provides a difficult target and a less likely
> candidate for either a law suit in the first place, or a high $$$
> amount once they figure out that they can only really sue me (and
> not a well funded organization).

I find the above quite confusing since in the liability scenario there's
only ONE "target", not a distributed one.  You are liable if and only if
you contribute code you don't own.  This is true whether there's a
copyright assignment or not.  The true copyright holder of the code you've
contributed, once they find out that their copyright has been violated,
will sue whoever it is that owns that code, which is either you or the
FSF, depending on which project it is.  I don't see what the ownership
status of some unrelated code has to do with this.

> The ultimate in free, for me, is if every single person in the world
> contributed at least one line of code to the project, and retains
> ownership to their piece. Each person is then liable to each other
> person, and a true community owned project exists.

Note that, as you said earlier, liability is, as a practical matter, only
relevant for companies since people don't have enough assets to be
worth suing. 

Re: Why not contribute? (to GCC)

[Jack Howarth]

On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
...
> In some ways, I wish a group did fork GCC under GPL and drop the  
> copyright assignment requirement. In other ways, this entire issue is  
> just so minor to me that it isn't worth going beyond this thread. GCC  
> works, but so do other compilers (Intel CC, LLVM, ...). GCC is  
> distributed under the GPL, so if the FSF ever becomes a real problem (as  
> opposed to merely having a political agenda), it can be for...@this  
> later time.
>
   Is it even possible to fork? Wouldn't that require the new compiler
to start over again from the last non-GPLv3 version of the source code
(read 4.2.1...which is why Apple's gcc is stuck there). Weren't things
simplier when egcs forked from gcc (ie that they were both under the same
license)?
Jack

...
>
> Cheers,
> mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Is it even possible to fork? Wouldn't that require the new compiler
> to start over again from the last non-GPLv3 version of the source code
> (read 4.2.1...which is why Apple's gcc is stuck there). Weren't things
> simplier when egcs forked from gcc (ie that they were both under the same
> license)?

No.  The issue of choice of license is completely orthogonal to the
issue of whether to have assignments or not.  Neither of those decisions
made by a project affects the other.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 02:29, Jack Howarth  wrote:
> On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
> ...
>> In some ways, I wish a group did fork GCC under GPL and drop the
>> copyright assignment requirement. In other ways, this entire issue is
>> just so minor to me that it isn't worth going beyond this thread. GCC
>> works, but so do other compilers (Intel CC, LLVM, ...). GCC is
>> distributed under the GPL, so if the FSF ever becomes a real problem (as
>> opposed to merely having a political agenda), it can be for...@this
>> later time.
>>
>   Is it even possible to fork? Wouldn't that require the new compiler

You can still fork GCC as long as the fork is GPLv3. It is less clear
if you can fork LLVM. Will Apple come after you with a portfolio of
patents? If you can make uninformed wild claims, so can I.

> to start over again from the last non-GPLv3 version of the source code
> (read 4.2.1...which is why Apple's gcc is stuck there). Weren't things

No, Apple is stuck there because they don't like the GPL v3. One may
speculate what is that they don't like: the new patents protections?
the new anti-drm-subversion? For sure their lawyers know what the GPL
protects against, they even participated in the process. So only Apple
knows. They seem to prefer a project with less clear terms, and less
protections against potential legal threats. I wonder why.

Cheers,

Manuel.

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

[Dave Korn]

On 25/04/2010 23:16, Steven Bosscher wrote:
> On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote:
> 
>>  Is there a PR open about this, or any notes anywhere?  Being as I use a
>> non-ELF platform and so gold is not an option, I'd be pleased to help with
>> making this work.
> 
> See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some
> first steps.
> 
> I don't understand this, actually. When I look at lto-elf/lto-coff,
> there seems to be AR support already. But this doesn't work,
> apparently?

  There is support for offsetting an arbitrary way into a file before
beginning reading, which in theory would let us read an archive member given
some parsing of the archive header, but I think that we still lack any means
of reading and parsing the archive, knowing what's there, and selecting the
member we want.  So, we have support for reading a single archive member as an
object for LTOing, but we need guidance about which ones and where from.

  If I understand correctly, what we farm out to gold/lto-plugin is the task
of identifying a) which archive members are required to be pulled into the
final link depending on the undefined references found in the existing object
files and b) what offsets those members begin at.

  On the other hand, I may not understand correctly.

cheers,
  DaveK

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 02:12, Mark Mielke  wrote:
>
> All in all, pretty minor. GCC wants FSF copyright assignment and employer
> disclaimers? GCC will not have as many contributors. Your choice.
>
> There are plenty of projects that we (lurkers / non contributors) can
> contribute to other projects that are not as mature and require more
> attention, or even other compilers (LLVM?).

Are you 100% sure that the fact that LLVM does not ask for your
employer disclaimer means that you do not need to ask your employer
for some paper to legally contribute code? Are you sure you are not
exposing yourself to a legal risk? I would check with a lawyer if that
is the case. A real lawyer, not some computer guy that says "Oh, just
give us your code, it will be fine. Don't worry! We don't ask for
anything."  And a lawyer that is not interested in keeping you at risk
just in case they need to sue you at some moment.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Sun, Apr 25, 2010 at 21:12, Manuel López-Ibáñez
 wrote:
> On 26 April 2010 02:12, Mark Mielke  wrote:
>>
>> All in all, pretty minor. GCC wants FSF copyright assignment and employer
>> disclaimers? GCC will not have as many contributors. Your choice.
>>
>> There are plenty of projects that we (lurkers / non contributors) can
>> contribute to other projects that are not as mature and require more
>> attention, or even other compilers (LLVM?).
>
> Are you 100% sure that the fact that LLVM does not ask for your
> employer disclaimer means that you do not need to ask your employer
> for some paper to legally contribute code? Are you sure you are not
> exposing yourself to a legal risk? I would check with a lawyer if that
> is the case. A real lawyer, not some computer guy that says "Oh, just
> give us your code, it will be fine. Don't worry! We don't ask for
> anything."  And a lawyer that is not interested in keeping you at risk
> just in case they need to sue you at some moment.

I thought it was decided in the course of this thread that the
liability of an individual contributor is ultimately NOT changed by
the assignment of the copyrights to the FSF.

Also, Mark's point (I think) is that a copyright lawsuit against the
FSF is much more likely than a lawsuit against some no-name
contributor, and (more importantly) a lawsuit against the FSF is
likely to trigger the FSF to launch a lawsuit against the individual
contributor. Thus, it sort of seems to the individual contributor that
assigning copyrights to the FSF while maintaining 'unlimited
liability' is less safe than not assigning copyrights to the FSF.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Also, Mark's point (I think) is that a copyright lawsuit against the
> FSF is much more likely than a lawsuit against some no-name
> contributor, and (more importantly) a lawsuit against the FSF is
> likely to trigger the FSF to launch a lawsuit against the individual
> contributor. Thus, it sort of seems to the individual contributor that
> assigning copyrights to the FSF while maintaining 'unlimited
> liability' is less safe than not assigning copyrights to the FSF.

Perhaps, but liability is less of an issue for individual than
corporations because individuals have few assets.  This thread started
with a complaint about unlimited liability FROM A CORPORATION, who
are the people that tend to worry about such things.

On the other hand, the FSF doesn't exactly have a lot of assets, so suing
it wouldn't be very productive either.

To me, point is this: if you don't have many assets, there isn't a
difference between a "unlimited" liability and the sort of limit that
would exist in this context.  If you DO have a large number of assets,
then you're actually a BETTER target than the FSF!

And then there's the argument I made before: if you're INNOCENT of an
accuses infringment and you DON'T assign to somebody, then YOU get the
job of defending the merits of the case instead of the entity you
assign it to.

The bottom line, to me, is this: if you ARE guilty of infringement,
you ARE sued and they prevail, then there's no difference whatsoever
between the assignment case.  That's the only case where there's
significant liability and what people are most worried about.

If one of those three ISN'T true, then you can make various arguments
one way or the other based on the perceived likelihood of somebody
suing somebody else, the costs of a defence, and the chance of losing a
case that you "should" have won.  Some scenarios seem to go one way and
some the other, but basically it's all a guess.

That's why I say there's no difference in the two cases.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 03:32, Michael Witten wrote:

> I thought it was decided in the course of this thread that the
> liability of an individual contributor is ultimately NOT changed by
> the assignment of the copyrights to the FSF.
> 
> Also, Mark's point (I think) is that a copyright lawsuit against the
> FSF is much more likely than a lawsuit against some no-name
> contributor, and (more importantly) a lawsuit against the FSF is
> likely to trigger the FSF to launch a lawsuit against the individual
> contributor. Thus, it sort of seems to the individual contributor that
> assigning copyrights to the FSF while maintaining 'unlimited
> liability' is less safe than not assigning copyrights to the FSF.

  Well, it seems to me that the FSF will not launch a lawsuit against me
unless there is actually some at least prima facie evidence that I have indeed
taken someone else's copyrighted software and presented it as if it were my
own to gift to the FSF, which would be an act of theft on my part.  Since I
know that I'm not going to do that, I'm convinced that this protects me
against copyright related actions, because I know any such action launched
against the FSF would be spurious and I can prove it and they have every
reason to believe I can and that therefore they would lose; contrariwise, if I
have not done that (stealing code and presenting it as my own), then they can
be confident that they will be able to successfully defend any case brought
against them.

  It probably does reduce the number of contributors who would copy and paste
someone else's code from the web or somewhere and submit it as a patch to GCC,
but the ability to get lumbered with the liabilities of code from unknown
provenance would not be such a huge benefit to GCC as to be worth it, I think.

cheers,
  DaveK

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 01:12, Mark Mielke wrote:
> On 04/25/2010 06:27 PM, Richard Kenner wrote:
>>> I couldn't see somebody suing me (my bank account hovers pretty low 
>>> most of the time). Companies are not going to sue nobodies such as 
>>> myself because there is no money in it. So, in practice, is there a 
>>> difference or not?
>>> 
>> No, because then the FSF wouldn't sue you EITHER!  There's NO DIFFERENCE
>> in theory or in practice as to your liability whether there's an
>> assignment or not and whether it's GCC or some other project.
>> 
> 
> Obviously there is a difference, otherwise FSF wouldn't be requesting 
> copyright assignment.

  There is a difference between requesting assignment and not doing so, but it
is to do with things other than liability.

> The real reason for FSF copyright assignment is control. The FSF wants to
> control GCC.

  Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
copyright holder can license code to anyone, whether under GPL or whatever
terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
GPL, and therefore cannot enforce it.

> mode. I don't see how this benefits me in any way. If I'm giving software
> that I write to the community for "free", why do I care what they will do
> with it? If I control how they can use it - it's not free. It's limited
> use.

  You're only looking at it from one side, that of an author.  The benefits of
the GPL are primarily to users.  Since all us authors are also users of
software, we should weigh up the inconveniences against the benefits.

  There is value for me, as a user, in the existence of free software that
can't be restricted by proprietary acts of "enclosure".  The GPL is
unashamedly a political strategy with a goal that can be seen to benefit all,
even without your needing to agree with the political stance: that goal is to
create a commons, and to make it impossible for there ever to be a tragedy of
that commons.  Whether you agree about the value (social or financial) or
likelihood of success of the exercise or not, you still benefit from that
commons, under pretty much any philosophical or political stance except for
the most extreme "everything is a zero-sum game and therefore anything that
benefits anyone except me is a harm to me" viewpoints.  Or so I think, anyway.

  So, why should you care what others will do with it?  Enlightened
self-interest.   You and others both benefit from the common wealth of free
software, therefore both you and others should, in theory, not want anyone to
try and hoard those benefits to themselves, because that's how tragedies of
commons arise.  This is what can happen with the proprietarisation of open
source software, the GPL is a way to avoid that from happening by caring about
what others do with it, hence you should care what others do with it.  You
release your software to the world because you hope people will benefit from
it, for the same reason you should continue to care what happens to it 
afterward.

> Referring to the people and employees who have gone through the copyright
> assigment and employer disclaimers in the past and saying ("they didn't
> have a problem signing") isn't evidence that the process is practical,
> efficient, or acceptable. These people probably just felt they had no other
> choice. If given the option of NOT doing this process, I'm sure most of
> them would happily have chosen option B.

  (Heh.  Making arbitrary claims about how many people you suppose or not
would make a certain choice or not and what their motives were or were not is
even more spurious than using ancedotal evidence, no?  It's a bit like saying
"although there is no evidence from their behaviour because they did something
else, I nonetheless assert that all these people secretly agree with me",
isn't it?)

  I do think there's a lot of confusion though, because throughout this
discussion there has been a lot of conflation between the *assignment* and the
*disclaimer*, and I'm not sure how anyone could have a problem with the
_assignment_ that was in any way connected to their employer.

  In my experience, the assignment process is simple and trivial: you email
the FSF, receive some paper documents through the snail within a couple of
weeks at the most, but if you're lucky it can be as little as a few days; you
sign them and shove them back in the post, job done.  Sometimes it takes
longer, paperwork is the kind of thing that goes missing and sometimes the FSF
office is understaffed and snowed in with work and it can take weeks, but it
basically doesn't require any significant effort on your point.  The vital
point that I think is missed when these two separate processes get conflated is:

  *Your employer has nothing to do with this process and no say nor interest
in nor right to involvement in it.*

  The assignment is a personal agreement between you as an individual and the
FSF, you agree to assign them your copyrights - not your 

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
> copyright holder can license code to anyone, whether under GPL or whatever
> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
> GPL, and therefore cannot enforce it.

Unless I'm missing something, that argues that the FSF must have
copyright to SOME of the code.  I don't see how having copyright for
all of the code would be needed to do that.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 04:30, Richard Kenner wrote:
>> Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
>> copyright holder can license code to anyone, whether under GPL or whatever
>> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
>> GPL, and therefore cannot enforce it.
> 
> Unless I'm missing something, that argues that the FSF must have
> copyright to SOME of the code.  I don't see how having copyright for
> all of the code would be needed to do that.

  Well, if the FSF don't own all the code, they can only license the bits they
do own.  That would leave the rest of it vulnerable to predation, at least.

cheers,
  DaveK

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I think it is possible that some of the people who have (or have had)
> trouble with the process with their employers, would find it easier if they
> realised that the assignment was something they can do without anyone's
> permission regardless of the terms of their employment, and subsequently
> present as a fait accompli, and that at that point it then actually
> facilitates getting the disclaimer from the employer, which is the only part
> they have to be involved in.

This is only the case for people who are not working on GCC as part of
their jobs.  For those who ARE, a disclaimer would be inappropriate: the
appropriate thing is an assignment from the company to the FSF.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 04:32, Richard Kenner wrote:
>> I think it is possible that some of the people who have (or have had)
>> trouble with the process with their employers, would find it easier if they
>> realised that the assignment was something they can do without anyone's
>> permission regardless of the terms of their employment, and subsequently
>> present as a fait accompli, and that at that point it then actually
>> facilitates getting the disclaimer from the employer, which is the only part
>> they have to be involved in.
> 
> This is only the case for people who are not working on GCC as part of
> their jobs.  For those who ARE, a disclaimer would be inappropriate: the
> appropriate thing is an assignment from the company to the FSF.

  I don't quite see that.  If the company disclaims ownership of the stuff
that you create working on GCC as part of your job, well, they've disclaimed
ownership of it, regardless of the fact that you created it while working on
GCC as part of your job, no?  Berne convention and all that, it is you who
created the creative work, the copyright is yours *unless and until* you have
assigned it to someone, and usually that someone is your employer because the
assignment is part of your contract of employment.  In that circumstance, a
disclaimer from the employer is equivalent to a semi-waiver of that part of
your contract of employment for that part of your work that they agree to
disclaim; but equally, it is possible to conceive being offered a contract of
employment that did *not* require you to assign any copyright to your employer
in some or all of the software you write while employed by them - unlikely, as
ownership of IP is one of the benefits to the employer that they get in
exchange for the money they pay you to work, but certainly not impossible or a
legal nonsense as far as I can see.

cheers,
  DaveK

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

[Ian Lance Taylor]

Manuel López-Ibáñez  writes:

> Ian, how can I check that there is a copyright assignment in place?

http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

Jon does have a copyright assignment.

Ian

Re: Why not contribute? (to GCC)

[Russ Allbery]

Dave Korn  writes:

>   I don't quite see that.  If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no?  Berne convention and all
> that, it is you who created the creative work, the copyright is yours
> *unless and until* you have assigned it to someone, and usually that
> someone is your employer because the assignment is part of your contract
> of employment.

I should probably not really be responding to legal threads on this list,
and I'm sure someone will point out that it's more complicated than this
and one needs to talk to a real lawyer, but note that the disposition of
copyright around work-for-hire is an aspect of the law, not something that
exists only in contracts.  Even if your contract with your employer says
absolutely nothing about copyright, work done for hire for your employer
is still owned by that employer.  I believe the contract would have to
explicitly say that this is *not* the case for you to be able to retain
ownership of copyright of work that you did for hire.

-- 
Russ Allbery (r...@stanford.edu) 

Re: Why not contribute? (to GCC)

[Richard Kenner]

>   I don't quite see that.  If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no?

My point is that they aren't likely to DO that and it would be
inappropriate to ask them to.  Legal documents usually work out better the
closer they match reality.

> In that circumstance, a disclaimer from the employer is equivalent to a
> semi-waiver of that part of your contract of employment for that part of
> your work that they agree to disclaim; but equally, it is possible to
> conceive being offered a contract of employment that did *not* require
> you to assign any copyright to your employer in some or all of the
> software you write while employed by them - unlikely, as ownership of IP
> is one of the benefits to the employer that they get in exchange for the
> money they pay you to work, but certainly not impossible or a legal
> nonsense as far as I can see.

I wouldn't call it "legal nonsense" and perhaps one could see some sort of
unusual situation where it was the best approach, but normally doing it
that way could open the door to all sorts of OTHER issues.  For example, if
the employee isn't being paid to do this work, then what IS he being paid
for?  Is the employee's salary a legiminate business expense?  What about
the R&D tax credit?  Etc.

To use a GCC analogy, we always tell people when writing machine
descriptions to "not lie" and be as faithful to what the hardware actually
does as possible.  It's certainly possible to write MD files that don't do
that, and historically many have, but when you do that, you risk adding
kludge upon kludge to keep things working optimally.

It's the same here: if you try to use a disclaimer when an assignment is
the appropriate document, you may well find yourself trying to patch things
up later.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I believe the contract would have to explicitly say that this is
> *not* the case for you to be able to retain ownership of copyright
> of work that you did for hire.

That's my understanding as well, but where it gets tricky is whether
a SEPARATE disclaimer would have the effect of doing that as it relates
to a particular work.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke  writes:

> Wouldn't contributing a patch to be read by the person who will be
> solving the problem, but without transferring of rights, introduce
> risk or liability for the FSF and GCC?
>
> I thought "clean room implementation" implies not seeing how somebody
> else did it first, as the "clean" part is tainted after somebody
> examines the patch?

Clean room implementation techniques are not required to avoid
copyright violations.  Copyright only covers the expression of an
idea; it does not cover the idea itself.  Expressing the same idea in
different code is not a copyright violation.  Even independent
identical expressions are not copyright violations if they are truly
independent.  And if there is only one possible way to express an
idea, then copyright does not apply at all, as there is no creative
aspect to the work.

Ian

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 05:28, Richard Kenner wrote:
>> I believe the contract would have to explicitly say that this is
>> *not* the case for you to be able to retain ownership of copyright
>> of work that you did for hire.
> 
> That's my understanding as well, but where it gets tricky is whether
> a SEPARATE disclaimer would have the effect of doing that as it relates
> to a particular work.

  Well, as a data point: under the contracts that I used to write computer
games under back in the late 80s, I very definitely owned the copyright and
retained it, and was only granting the employer a licence to distribute and
exploit in various mediums and territories.  (But that was in a different
jurisdiction to the one that the FSF is based in, and I can't say for certain
how the more recent updates to the law might undermine my rights or award them
to a possible employer.)

  And yes, they were generous terms.  I was very happy with them.
Particularly when the firm selling the games was shut down and their assets,
when sold off, did not include my copyrights.  One of my fellow authors at the
time did indeed consult a lawyer, and the company in question
kind-of-pathetically sent us all copyright assignments, in case we'd like to
give them our copyright for the benefit of their fire-sale.  Not
unsurprisingly, none of us saw any reason to sign...

cheers,
  DaveK

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Expressing the same idea in different code is not a copyright violation.

Unlike patents, in copyright law, whether something is infringing
strongly depends on whether you actually COPIED something.  Writing a
piece of code to do the same as another piece of code that you're looking
at when doing it is dubious.

> Even independent identical expressions are not copyright violations
> if they are truly independent.

Certainly!  But if you've seen one, they aren't independent.

> And if there is only one possible way to express an idea, then
> copyright does not apply at all, as there is no creative aspect to
> the work.

Agreed.  As I said earlier, this is what probably would save you in
practice: the only things that you'd be "copying" would be the unique
way to implement the idea.

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Sun, Apr 25, 2010 at 12:36:46PM -0400, Richard Kenner wrote:
> I said "A" large part.  There is certainly a perception that the
> copyright assignment is an issue too.  But, as was discussed here, there
> IDENTICAL liability with and without the assignment.  So this is illusory.

Oh please.  Asking an entity that has no rights on your code to
actually say they have no rights on your code is not an illusory
requirement.  I realize that work contracts in the US tend towards the
thinly veiled slavery contract, but that's not the case in other
places[1] where, as a consequence, employers have never heard of that
kind of disclaimers and having someone with authority sign them is
close to impossible in large structures.  Finding who that someone
would be (short of the CEO or equivalent) is a challenge by itself.

I know I've decided long ago not to look at FSF code because I may be
tempted to patch it and I can't stand the hassle of the assignment.

  OG.

[1] France in my case, probably Europe in general.  What you do in
your free time is yours by default, land grab clauses are not
accepted, and it's only when you work at home on things you also do at
work that questions can be asked.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:30 PM, Richard Kenner wrote:
>> The LLVM project does not aim to be able to change the license in the
>> future, 
> 
> Nobody "aims" to change something in the future, but nobody has a crystal
> ball either and it can often be hard to predict what might have to be done
> in the future.

We'll see.  Fortunately the future comes sooner than anyone expects.

> If there's no such document, then what does the project do if, unknown to
> them, some employee of a large company contributed code without the
> permission of his employer, the project distributes that code, and then the
> large software company sues for infringment?

This would be on topic if the thread were "Why not contribute? (to LLVM)", but 
it isn't.  If you're really concerned about LLVM developers, that's one thing, 
but this is certainly not the place to discuss it.

I find it amusing the willingness of various developers to debate the veracity 
of the LLVM policies, but the simulataneous (apparent) unwillingness to address 
GCC's (perceived) problems.  Why not spend your time helping improve the 
documentation, increase modularity, or improve the copyright assignment 
process, rather than participate so much in this thread?


On Apr 25, 2010, at 7:12 PM, Manuel López-Ibáñez wrote:
> Are you 100% sure that the fact that LLVM does not ask for your
> employer disclaimer means that you do not need to ask your employer
> for some paper to legally contribute code? Are you sure you are not
> exposing yourself to a legal risk?

This is such an incredibly immense scoop of FUD that I couldn't help but 
respond to it :-)  Isn't this thread supposed to be about finding ways to 
improve GCC?

-Chris

Re: Why not contribute? (to GCC)

[Richard Kenner]

> [1] France in my case, probably Europe in general.  What you do in
> your free time is yours by default, land grab clauses are not
> accepted, and it's only when you work at home on things you also do at
> work that questions can be asked.

That's true in the US as well, but the sticky part is when you try to
define such nebulous things as "free time", "company equipment", and
"things you also do at work".  If you're not doing programming at work, you
don't need a disclaimer.  And if you are, then how broadly "things" are
defined becomes potentially relevant.

The point is that although intellectual property law does differ between
countries, it's not simple in ANY of them.  A disclaimer protects not only
the entity the code is being assigned to, but the person submitting the
code.  The only way you can be SURE that a company you work for has no
claim on your code is by asking them to tell you that in writing (if it's
ALREADY in your contract, I'd expect the FSF to accept a copy of that
contract as a disclaimer).  Otherwise, you, as a non-attorney, are doing
what attorneys don't even like doing: trying to guess how a court might
rule on a complex set of facts and the law.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > If there's no such document, then what does the project do if, unknown to
> > them, some employee of a large company contributed code without the
> > permission of his employer, the project distributes that code, and then the
> > large software company sues for infringment?
> 
> This would be on topic if the thread were "Why not contribute? (to LLVM)",
> but it isn't.  If you're really concerned about LLVM developers, that's one
>  thing, but this is certainly not the place to discuss it.

OK, then I'll rephrase it:

If the GCC project were to change their policy so that there is no longer
any document signed between the submitter of the code and the FSF, then
what would the project do if, unknown to them, some employee of a large
company contributed code without the permission of his employer, the
project distributes that code, and then the large software company sues for
infringment?