Re: redundant divmodsi4 not optimized away

[Ian Lance Taylor]

Greg McGary  writes:

> I have a port without div or mod machine instructions.  I wrote
> divmodsi4 patterns that do the libcall directly, hoping that GCC would
> recognize the opportunity to use a single divmodsi4 to compute both
> quotient and remainder.  Alas, GCC calls divmodsi4 twice with the same
> divisor and dividend operands.  Is this supposed to work?  Is there a
> special trick to help the optimizer recognize the redundant insn?  I
> saw the 4yr-old thread regarding picochip's desire for the same effect
> and followed the same approach implemented in the current picochip.md
> (as well as my own approach) but no luck.

Using a divmodsi4 insn instead of divsi3/modsi3 insns ought to work.
You may need to give more information, such as the test case you are
using, and what your divmodsi4 insn looks like.

Ian

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 02:00:30PM -0400, Richard Kenner wrote:
> Olivier Galibert wrote:
> > You can't force some entity to release source code they have
> > copyright to, that's not part of the legal remedies that are
> > available to a judge.
> 
> What makes you say that?

The law, *duh*

> Why couldn't that be a legal remedy?

Because it hasn't be voted so.

To stay US-centric, have a look at:
  http://www.copyright.gov/title17/92chap5.html

Any law that makes something illegal has to define the available
penalties associated.  Otherwise it's not a law, it's just a
non-binding statement on intent.  Everything else is of the domain of
the settlement, i.e. something to which both parties agree and the
judge considers fair.  And settlement-wise, releasing source and
assigning copyright are at exactly the same level, i.e. something the
opponent can accept or not, and if not decide to try their luck with
the legal remedies.

  OG.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke  writes:

> This presumes that NeXT would not have discovered the value of free
> software and done the right thing eventually anyways. I think anybody
> who truly believes in free software should believe in it for practical
> reasons. It's not just a religion - it's the right way to do
> business. Business can understand dollars, and free software can be
> demonstrated to provide value in terms of $$$.
>
> I think anybody who truly believes in the *merit* of free software,
> should be approaching companies who do not understand the merit with a
> business plan, not a class action law suit.
>
> Of course, if you don't believe in the *merit* of free software, and
> just think it's something cool to screw around with and force ideas
> down other people's throats -- Feel free to pursue the class action
> law suit approach, or consolidate ownership with the FSF and make it a
> straight forward law suit instead.
>
> Cheers,
> mark
>
> P.S. Objective C in particular has a sour taste in my mouth, as it
> seems to be a key component to Apple's vendor lock in strategy. If you
> can't lock people in through closed source - just choose a barely used
> open source project extension to base the entire front end of your
> software on and cross your fingers the rest of the world won't bother
> to catch up any time soon because it is simply too much effort.


This subthread no longer has anything to do with gcc.

Ian

Re: GCC porting tutorials

[Hans-Peter Nilsson]

> From: "Jonas Paulsson" 
> Date: Mon, 26 Apr 2010 11:07:04 +0200

> I recently completed my degree project on LTH on retargeting GCC. See 
> http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved to 
> http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon).

Interesting observations there; I wish there was incentive for
you to actually resolve them the right way in GCC, meaning this
project.

I've recently been bitten by the lost-widening-multiplication-
when-in-loop issue myself, and noted it for revisit Some Day.
Fixing that by other means made a whopping 27% improvement for
the application where I saw it: a hot loop doing a MDCT using
Q31 fixed-point, where a common operation is to widen-multiply
two 32-bit numbers and pick the high 32 bits of the 64-bit
result (being the result divided by 2; i.e. Q30-ish for that
operation).

brgds, H-P

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 07:41 AM, Paolo Bonzini wrote:

On 04/26/2010 11:23 AM, Mark Mielke wrote:

Personally, this whole issue is problematic to me. I really can't see
why I would ever sue somebody for using software that I had declared
free.


Because (a derivative of) it is being made nonfree?


How does this hurt me? Instead of being concerned how people might try 
to exploit my code, why shouldn't I be spending effort making sure that 
the best solution for all parties, including greedy corporations, is to 
work with me, to make sure the code is kept in a small number of 
branches all available in the free and open source community? Why can't 
I demonstrate the merits of free software in such a way that even the 
most stubborn of CEOs will understand what I am offering to them?



It wouldn't be worth my time and I have trouble understanding how
I could demonstrate personal loss making the law suit worth persuing in
the first place.


Perhaps because you know the code better than anyone else, so you 
could provide paid support on that derivative as well.


This is true whether the code is GPL or truly free.

Or maybe because you have to.  There was a case of a free software 
project (JMRI) being sued for patent infringement by a proprietary 
software company.  It turned out that the proprietary software 
included source code from the free software project without 
attribution (copyleft was not even necessary, as the project was under 
the Artistic License!).  In this case, the possibility to counter-sue 
saved the free software programmer from having to pay millions of 
dollars.


I think this might be an over simplification. There were many statements 
in this history (new to me - just read it all - good read) that 
demonstrate that the patents were incorrectly granted. The copyright 
issue was involved, and the defense of free / open source copyrights was 
involved, but it looks pretty clear to me that JMRI wanted to shut down 
*all* violations. They wanted the incorrectly granted patents dropped, 
and they wanted their copyrights held intact. Was the latter required 
for the former victory, or was that just how things played out?


I'll also note that even if it was required, it was the Artistic 
License, and it was demonstrated as being valid in a court of law. So, 
the GPL was not really part of this equation, and therefore not really 
part of this discussion, as off topic as it has gone. From my 
perspective, licenses like the Artistic License, the Apache license, or 
the BSD license, are great choices for free software projects.


I see your point that the possibility to counter-sue is valid, but I 
think the scope is the scenario provided is limited to the scope of 
ensuring that the copyright is valid at all, rather than any additional 
restrictions that the GPL defines. I think, though, that this is 
somewhat self-evident, and that the case really shows how a clever 
lawyer can confuse judges into providing poor judgements. This will 
always be a risk, and copyright is not the ultimate defense against this 
risk. It was an option in the case you listed, but I think there were 
other options. It's unfortunate that persuing options in court can cost 
large amount of money, but that's the society we live in. The best 
direction to take from the above case is to attack the problem at the 
source. 1) Patents, at least under the current system, are evil, and 
provide a lot of risk for what is becoming a questionable amount of 
value. 2) The courts need a better way to figure out when somebody is 
lying in their court room.


As demonstrated, there exists adequate laws to protect copyrights. No 
changes required on this front, at least for this scenario.


Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> However, that isn't only/quite what I meant. My understanding of 
> copyright law is that it *only* protects distribution rights of the 
> works. For example, as long as I use the software internally within a 
> single legal entity (company, house hold, or whatever is acceptable to 
> the courts), I do not need to abide by *any* of the rules listed in the 
> license, as I am not re-distributing the works.

VERY FALSE!  If a company buys one copy of a book, they most certainly may
NOT make a copy of that book for every employee!  To give a more relevant
example, do you really think that a company can buy one copy of Windows and
install it on all their computers?

The owner of a copyright gets to say under what conditions somebody can
COPY their work.  Executing a computer program involves COPYING it from
disk into memory.  That's making a copy.  There was even a case where a
jury held that calling a subroutine in a separate library is making a copy
of that library.

> Most licenses, specifically including the GPL, specify rules that
> define what requirements I must meet before I am allowed to
> re-distribute the works.

No, they specify the conditions under which you're allowed to COPY the
works.  Some, like the GPL, choose only to deal with "redistribution"
(which, by the way, isn't as well-defined as you might like to think it is:
I distinction remember an in-person discussion with RMS years ago where the
question was whether it was a violation of the GPL to only have binary, and
not sources, in a bomb, specifically whether dropping the bomb on somebody
was "distributing" the software), but most proprietary licenses talk about
the conditions under which you're allowed to make a COPY, whether that copy
is considered "distributing" or NOT.

> If re-distribute these works according to requirements, and then 
> somebody down stream from me obtains a copy through me and then violates 
> their licensing agreement in such a that I can demonstrate loss to a 
> judge. I think I can sue.

If you are the copyright holder and somebody (no matter how they got it)
violates the copyright, then yes, you can.

> Why do I have to "own" the software to have a case? 

You have to own the COPYRIGHT: it's not clear what "owning" the software
means.  If you don't own the copyright, then you have no legal interest in
the work.  You are confusing yourself by thinking in terms of a "license".
The license is just a way of conveying a set of permissions under which
copies can be made.  Although it somewhat has the status of a contract,
and so contract law applies, it's primarily an instrument of COPYRIGHT law.
Most importantly, you can't license something you don't have copyright 
ownership of.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 11:11 AM, Alfred M. Szmidt wrote:

>  If I have the rights to re-license software, and I re-license the
>  software, why do I not have permission to enforce these rights?

Because you have the permission to re-DISTRIBUTE (not "re-LICENSE")
the software and nothing else.

In case of GCC, you have the explicit permission to relicense the work
under a later version of the GPL.  In the case of the GNU Lesser GPL,
you have explicit permission to relicense the work under the GPL.  So
depending on the license, you might have permission to relicense the
work.

   


I think the ability to re-license in the sense of changing the license 
to a different license (as allowed) is a significant freedom offered by 
the GPL. It's a significant enough freedom that Linus chose to deny it 
for Linux as he apparently felt it provided the wrong sort of freedom, 
at least at the time he made that call.


However, that isn't only/quite what I meant. My understanding of 
copyright law is that it *only* protects distribution rights of the 
works. For example, as long as I use the software internally within a 
single legal entity (company, house hold, or whatever is acceptable to 
the courts), I do not need to abide by *any* of the rules listed in the 
license, as I am not re-distributing the works. Most licenses, 
specifically including the GPL, specify rules that define what 
requirements I must meet before I am allowed to re-distribute the works. 
If re-distribute these works according to requirements, and then 
somebody down stream from me obtains a copy through me and then violates 
their licensing agreement in such a that I can demonstrate loss to a 
judge. I think I can sue. Or, rather, I don't see why I wouldn't be able 
to sue. I am required to include the license in the copy I distribute. 
They accepted the license as I provided. They violated the license. I 
can demonstrate losses as a result. How is this not a valid law suit? 
Why do I have to "own" the software to have a case? I think I just have 
to prove that a violation exists that I was the victim which resulted in 
a direct loss to me. I don't know where this "own" requirement comes 
from. But then, as I said in the thread two back that both of you are 
responding to - I am not a lawyer, and maybe the FSF knows something I 
do not. I think I've seen cases where users of software have leaned on 
companies to produce software under threat of a law suit, without 
necessarily involving each and every owner of the software. The WRT54G 
situation leaps right up to the top for me. I think the "must legally 
own the works to be listed as a victim with losses in a law suit" is not 
a true requirement. I think it might be convenient and might improve the 
chance of success - but I don't think that one requires access and 
commitment from the owners in order to create a law suit.


As somebody else pointed out, the freedoms of the GPL are designed for 
the users. The people who are the most likely to be the victims are the 
users. The authors gave the software away for free, so attempting to 
demonstrate losses on something you give away for free is almost 
laughable (I'm sure many here would not laugh). It is the *users* who 
should be able to create the law suit, because it is the *users* who are 
impacted, and it is the *users* who can put a $$$ figure on their 
losses. In the Objective C case, users can claim that without the 
Objective C code being contributed back, it would take X million man 
hours @ $N/hour to re-create the code for use in future projects. This 
is a loss which can be accurately demonstrated. Sue NeXT for 
X*N+penalties. They have the option of paying out the full amount, 
funding the free software community to create their own (hopefully 
better) Objective C implementation, settling for a smaller amount (if 
agreeable to the users), or releasing their software.


So again, I think copyright assignment is a matter of convenience and 
optimization - and not a legal requirement. But then, what do I really 
know...


Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I think anybody who truly believes in the *merit* of free software, 
> should be approaching companies who do not understand the merit with a 
> business plan, not a class action law suit.

Most certainly.  And a number of companies have relicensed their software
under the GPL when presented with a business plan showing why that's a
good thing to do.  But that doesn't mean you give up the right to sue
when somebody infringes a copyright.

It's like international relations.  We all hope that disputes between
nations can be settled using diplomacy, but nobody's willing to give up
their armed forces because of a belief that ALL can be solved that way.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Nobody can take your code and make it non-free.
> 
> They can take a copy of your code and modify it, but at no time does 
> your original code become non-free. As long as people continue to copy 
> from your "free" version of the code, they can continue to use it for 
> "free".

Correct.  A perhaps better way of putting is "use my code as part of
something that's non-free".

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I can say from my 15 years of experience working here that in general
> Stanford *hates* signing legal documents.  This is true even of
> procurement contracts.  Stanford negotiates legalities very aggressively,
> negotiates vendor contracts very aggressively, and does not generally sign
> things unless the university has some compelling reason to do so.  This
> is, from the university perspective, an obviously correct legal position
> since it keeps the university out of trouble from documents that they
> didn't need to sign.
> 
> In order to get a disclaimer signed, the last time I investigated this, I
> would need to go through the Office of Technology Licensing because the
> central IT staff are probably not people with sufficient authority to sign
> such a document on behalf of the university.  All university intellectual
> property is handled by the OTL.  And the entire purpose of the OTL is
> serve as steward of university property and hence to handle the
> university's intellectual property to the university's advantage (mostly
> around the income that the university derives from licensing of its patent
> portfolio; we hold some patents that came out of the Human Genome Project
> work, for example).  They don't have much of an incentive to sign such a
> document, and their first concern is going to be how much it might cost
> the university to do so.

This is, unfortunately, true for most universities.  The only reason
NYU assigned GNAT to the FSF was because the contract with the Air
Force REQUIRED them to do so.  This is probably the best way to get
these to happen.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 03:23 PM, Ian Lance Taylor wrote:

Chris Lattner  writes

w.r.t. "hoarding", I'll point out that (in the context of GCC) being
able to enforce copyright is pretty useless IMO.  While you can
force someone to release their code, the GPL doesn't force them to
assign the copyright to the FSF.  In practice this means that you
can force someone to release their GCC changes, but you can't merge
them back to mainline GCC.  In a warped way you could argue that the
FSF using the GPL encourages their software to fork :-)
 

Again, just for the record.  History shows that this is not entirely
useless.  People at NeXT wrote the Objective C frontend to GCC.  They
did not intend to release the source code.  The FSF objected.  In the
end, NeXT wound up contributing the code, and that is why GCC has an
Objective C frontend.  In other words, the whole process worked as the
GPL intended.


This presumes that NeXT would not have discovered the value of free 
software and done the right thing eventually anyways. I think anybody 
who truly believes in free software should believe in it for practical 
reasons. It's not just a religion - it's the right way to do business. 
Business can understand dollars, and free software can be demonstrated 
to provide value in terms of $$$.


I think anybody who truly believes in the *merit* of free software, 
should be approaching companies who do not understand the merit with a 
business plan, not a class action law suit.


Of course, if you don't believe in the *merit* of free software, and 
just think it's something cool to screw around with and force ideas down 
other people's throats -- Feel free to pursue the class action law suit 
approach, or consolidate ownership with the FSF and make it a straight 
forward law suit instead.


Cheers,
mark

P.S. Objective C in particular has a sour taste in my mouth, as it seems 
to be a key component to Apple's vendor lock in strategy. If you can't 
lock people in through closed source - just choose a barely used open 
source project extension to base the entire front end of your software 
on and cross your fingers the rest of the world won't bother to catch up 
any time soon because it is simply too much effort.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 02:00 PM, Richard Kenner wrote:

If I own 1% of the code of a program and somebody makes it non-free, I'm
going to be upset, but probably not enough to either sue the person or try
to organize a group do to collectively.  But if instead I assigned that
software to a group that decided to sue, I'd be very happy they did and
glad that my assignment let them be able to do it.
   


Nobody can take your code and make it non-free.

They can take a copy of your code and modify it, but at no time does 
your original code become non-free. As long as people continue to copy 
from your "free" version of the code, they can continue to use it for 
"free".


The GPL isn't free though. The GPL is a limited use license that 
restricts freedoms in such a way that there is some expectation that the 
lost freedoms can purchase future freedom, and this compromise is justified.


Many of us don't agree that the compromise is justified. This will 
forever be a political difference between the two sides, and is unlikely 
to be resolved here. This is an FSF/GPL issue more than a GCC issue. It 
just so happens that GCC is one of the most easily recognized and widely 
used FSF-owned projects, so it is an easy target for us GPL haters. :-)


For the record: There is no ill will about the project. Some of us just 
don't understand why GCC couldn't survive or thrive under a less 
restrictive contribution and/or licensing model. We know of other 
projects that are near equal or in some cases greater than GCC in terms 
of actual impact on the world today that do not seem to share the same 
contribution and/or licensing model. Before anybody gets upset about 
this - please realize that I see GCC primarily as a compiler that 
translates from source form to executable form, and that there exists 
compatible or near compatible alternatives to GCC that could be switched 
to within a few months or less for most projects with an annoying but 
minimum amount of fuss. I also think that any truly free platform should 
have alternative implementations to avoid vendor lock and to enable 
healthy competition that will lead to better overall results for the end 
users.


Cheers,
mark

Re: Why not contribute? (to GCC)

[Russ Allbery]

Paolo Bonzini  writes:

> And even in the US we lost a patch for 4.5 due to a problem with the
> disclaimer.  I read this recently on gcc-patches:

>The FSF has a personal copyright assignment for me, but I could not
>get one from my employer at the time, Stanford (according to
>Stanford's policies they would not claim copyright on this patch).

> I suppose that this referred to http://rph.stanford.edu/5-2.html which
> shows that the matter is not black-and-white:

>BOOKS, ARTICLES, AND SIMILAR WORKS, INCLUDING UNPATENTABLE SOFTWARE
>In accord with academic tradition, except to the extent set forth in
>this policy, Stanford does not claim ownership to pedagogical,
>scholarly, or artistic works, regardless of their form of
>expression. Such works include those of students created in the
>course of their education, such as dissertations, papers and
>articles. The University claims no ownership of popular nonfiction,
>novels, textbooks, poems, musical compositions, unpatentable
>software, or other works of artistic imagination which are not
>institutional works and did not make significant use of University
>resources or the services of University non-faculty employees working
>within the scope of their employment.

At Stanford, if you're on the academic side, Stanford mostly only cares
about patents.  Copyright generally vests in the academic author and the
university doesn't try to claim any copyright on that.

Work done for the university as part of the job of a staff member, such as
my work done during working hours, is of course owned by the university
under the work-for-hire provisions of copyright law and is a whole
different kettle of newts.

> Yet copyright.list has:
> - 3 disclaimers from Stanford dating back to 1989
> - 10 contributors with a Stanford email, all without a disclaimer

> So?

Stanford has a lot of staff as well as faculty and students.  :)
Universities are akin to both large villages and moderate-sized
corporations.  We have multiple significant internal IT departments, and
some of us do significant free software work.  Whether or not you need a
disclaimer given Stanford's copyright policy is going to depend on the
nature of your relationship with the university and the contribution.

The problem, as I alluded to in an earlier message, is that this is all
relatively easily handled under the copyright policy on the academic side
of the house for students and faculty.  But if you're staff doing free
software work as part of your job, finding someone at the university who
will sign the disclaimer is extremely difficult.

I can say from my 15 years of experience working here that in general
Stanford *hates* signing legal documents.  This is true even of
procurement contracts.  Stanford negotiates legalities very aggressively,
negotiates vendor contracts very aggressively, and does not generally sign
things unless the university has some compelling reason to do so.  This
is, from the university perspective, an obviously correct legal position
since it keeps the university out of trouble from documents that they
didn't need to sign.

In order to get a disclaimer signed, the last time I investigated this, I
would need to go through the Office of Technology Licensing because the
central IT staff are probably not people with sufficient authority to sign
such a document on behalf of the university.  All university intellectual
property is handled by the OTL.  And the entire purpose of the OTL is
serve as steward of university property and hence to handle the
university's intellectual property to the university's advantage (mostly
around the income that the university derives from licensing of its patent
portfolio; we hold some patents that came out of the Human Genome Project
work, for example).  They don't have much of an incentive to sign such a
document, and their first concern is going to be how much it might cost
the university to do so.

It's much simpler, from their perspective (and somewhat understandably so)
if I just don't contribute to FSF projects on work time unless there's
some particularly compelling reason for me to do so.  Most of the free
software work I do on university time I release under the copyright of the
university with a free software license; the university is more
comfortable with that than with signing legal agreements with third
parties, at least for things that are not particularly central to the
mission of the university and therefore warrant the time and attention
required to vet the agreement.

This is all a digression, as I don't have anything to contribute at the
moment -- this specific case is not a problem that anyone needs to try to
solve.  I describe it in this much detail just so that people are aware of
the sort of challenges that the policy creates and that contributors need
to work through.

Please also note that much of this information is about ten years old, and
the situation may have ch

redundant divmodsi4 not optimized away

[Greg McGary]

I have a port without div or mod machine instructions.  I wrote 
divmodsi4 patterns that do the libcall directly, hoping that GCC would 
recognize the opportunity to use a single divmodsi4 to compute both 
quotient and remainder.  Alas, GCC calls divmodsi4 twice with the same 
divisor and dividend operands.  Is this supposed to work?  Is there a 
special trick to help the optimizer recognize the redundant insn?  I saw 
the 4yr-old thread regarding picochip's desire for the same effect and 
followed the same approach implemented in the current picochip.md (as 
well as my own approach) but no luck.


G

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

[Dave Korn]

On 26/04/2010 23:18, Jon wrote:
> Hi Manuel
> 
> Manuel López-Ibáñez wrote, On 25/04/10 22:37:
> [.]
>> http://gcc.gnu.org/wiki/ChangeLog
>>
>> Basically, in your case, do not repeat the filename and mention which
>> function is affected (if any).
> 
> 2010-03-13  Jon Grant <0...@jguk.org>
> * collect2.h: vflag extern changed to bool so true/false can be
> used.
> * collect2.c: "debug" global variable changed to bool so
> true/false can be used.
> * "helpflag" bool global variable added.
> * (main) sets "debug" to true instead of 1 when -debug is passed
> in argv
> * --help now sets "helpflag" to true instead of 1
> * --version now sets "vflag" global bool true instead of 1
> * if "helpflag" is true, standard help information is output on
> stderr
> 
> I have reworked it into that format. 

  Here, sometimes it's easier to show than to explain in terms of rules:

* collect2.c (vflag): Change type from int to bool.
(debug): Likewise.
(helpflag): New global bool.
(main): Set vflag and debug with boolean, not integer truth
values.  Accept new "--help" option and output usage text if
found.
* collect2.h (vflag): Update prototype.
(debug): Likewise.

  Summary: Asterisks are only used for the first line of each file's changes.
 TABs at the start of every line.  Place the name of the affected entity -
function, variable or macro - in brackets at the start of each line, colon,
space, then say what not why.

cheers,
  DaveK

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

[Jon]

Hi Manuel

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

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

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


2010-03-13  Jon Grant <0...@jguk.org>
* collect2.h: vflag extern changed to bool so true/false can 
be used.
* collect2.c: "debug" global variable changed to bool so 
true/false can be used.

* "helpflag" bool global variable added.
* (main) sets "debug" to true instead of 1 when -debug is 
passed in argv

* --help now sets "helpflag" to true instead of 1
* --version now sets "vflag" global bool true instead of 1
* if "helpflag" is true, standard help information is output 
on stderr


I have reworked it into that format. I've not created PR. As approved, 
is this ok to go in without a PR?


Cheers, 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;

Re: Why not contribute? (to GCC)

[Toon Moene]

On 04/26/2010 10:53 PM, Ian Lance Taylor wrote:


Chris Lattner  writes:



This is a often repeated example, but you're leaving out the big
part of the story (at least as far as I know).  The license *did
not* force the ObjC frontend to be merged back into GCC, there were
other factors at work.  This 'victory' has nothing to do with the
license, but it did cause them to release the code.


Yes.  I was pointing out that forcing the release of the code *also*
caused the code to be contributed to the FSF.  As you say, other
factors were at work, but that's OK: there are always other factors.


There's a funny side effect here:

One of the major reasons I bought a NeXT Station in November 1991 was 
that I considered NeXT's move to use free software a significant point 
on the scale of "doing something differently from the rest".


Little did I know the problems that were underlying these decisions.

Which made me one of the ~ 10,000 proud owners of a NeXT Station (now 
retired) at the cost of a reasonably sized family car :-)


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

[Chris Lattner]

On Apr 26, 2010, at 1:53 PM, Ian Lance Taylor wrote:

>> Beyond that, the changes to support Objective C 2.0 (and later) have
>> never been merged back in, despite being published and widely
>> available under the GPL.  Also, the GNU runtime and the NeXT
>> runtimes are wildly incompatible, and the ObjC frontend in GCC is
>> one of the most disliked (I'll leave out the pejoratives :) because
>> its design has not kept up with the other front-ends.
>> 
>> Even in the shining example of the GPL succeeding, are you sure it
>> was a good thing in retrospect? :)
> 
> That is due to a different set of other factors.  Objective C is not a
> shining example of the GPL succeeding.  But it is an example of a case
> where the GPL forced release of code *and* it was contributed to gcc,
> which is exactly the case that you were skeptical of.
> 
> In other words: theory says one thing will happen ("GPL encourages
> [FSF] software to fork"); history shows that a different thing
> happened.  I'm a pragmatist; given a reasonable choice, I prefer
> history over theory.

Heh, ok, but if you're looking for history, look at both sides of it. 



I wrote a long and detailed email about GCC forks, long term corporate 
branches, the impact of the GPL on all this, etc.  However, it is so off topic, 
I'm happy to just delete it and drop the issue :-)

-Chris

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner  writes:

> On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:
>> 
>> Again, just for the record.  History shows that this is not entirely
>> useless.  People at NeXT wrote the Objective C frontend to GCC.  They
>> did not intend to release the source code.  The FSF objected.  In the
>> end, NeXT wound up contributing the code, and that is why GCC has an
>> Objective C frontend.  In other words, the whole process worked as the
>> GPL intended.
>
> This is a often repeated example, but you're leaving out the big
> part of the story (at least as far as I know).  The license *did
> not* force the ObjC frontend to be merged back into GCC, there were
> other factors at work.  This 'victory' has nothing to do with the
> license, but it did cause them to release the code.

Yes.  I was pointing out that forcing the release of the code *also*
caused the code to be contributed to the FSF.  As you say, other
factors were at work, but that's OK: there are always other factors.


> Beyond that, the changes to support Objective C 2.0 (and later) have
> never been merged back in, despite being published and widely
> available under the GPL.  Also, the GNU runtime and the NeXT
> runtimes are wildly incompatible, and the ObjC frontend in GCC is
> one of the most disliked (I'll leave out the pejoratives :) because
> its design has not kept up with the other front-ends.
>
> Even in the shining example of the GPL succeeding, are you sure it
> was a good thing in retrospect? :)

That is due to a different set of other factors.  Objective C is not a
shining example of the GPL succeeding.  But it is an example of a case
where the GPL forced release of code *and* it was contributed to gcc,
which is exactly the case that you were skeptical of.

In other words: theory says one thing will happen ("GPL encourages
[FSF] software to fork"); history shows that a different thing
happened.  I'm a pragmatist; given a reasonable choice, I prefer
history over theory.

Ian

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:

> Chris Lattner  writes:
> 
>> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
>> able to enforce copyright is pretty useless IMO.  While you can
>> force someone to release their code, the GPL doesn't force them to
>> assign the copyright to the FSF.  In practice this means that you
>> can force someone to release their GCC changes, but you can't merge
>> them back to mainline GCC.  In a warped way you could argue that the
>> FSF using the GPL encourages their software to fork :-)
> 
> Again, just for the record.  History shows that this is not entirely
> useless.  People at NeXT wrote the Objective C frontend to GCC.  They
> did not intend to release the source code.  The FSF objected.  In the
> end, NeXT wound up contributing the code, and that is why GCC has an
> Objective C frontend.  In other words, the whole process worked as the
> GPL intended.

This is a often repeated example, but you're leaving out the big part of the 
story (at least as far as I know).  The license *did not* force the ObjC 
frontend to be merged back into GCC, there were other factors at work.  This 
'victory' has nothing to do with the license, but it did cause them to release 
the code.

Beyond that, the changes to support Objective C 2.0 (and later) have never been 
merged back in, despite being published and widely available under the GPL.  
Also, the GNU runtime and the NeXT runtimes are wildly incompatible, and the 
ObjC frontend in GCC is one of the most disliked (I'll leave out the 
pejoratives :) because its design has not kept up with the other front-ends.

Even in the shining example of the GPL succeeding, are you sure it was a good 
thing in retrospect? :)  

-Chris

Re: Why not contribute? (to GCC)

[Richard Kenner]

> And how are potential contributors supposed to know this?

They're really not.  The fundamental problem here is that this area of
the law is not only very complicated, but is really all guesswork
since there are few, if any, relevant cases.  Moreover, this is an
area of the law where details matter, often quite a bit.

My suggestion for this process is develop an online form where a
person specifies various things about their contribution including
what program it's for an how long it is.  It should ask whether the
person anticipates submitting more changes.  Then it needs to ask what
the person's employment status is and in which country.  It should ask
about terms relating to IPR in any employment agreements.  And so on.

Then it should be able to come up with a set of choices that would
cover this person's unique situation.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 21:28, Ian Lance Taylor  wrote:
> Jonathan Corbet  writes:
>
>> What you agree to is the developers certificate of origin (DCO), which
>> says you have the right to contribute the code to the kernel.  No
>> copyright assignment takes place.  Trust me, I have thousands of lines
>> of code in the kernel, and the copyright remains mine.
>
> The FSF permits something like this as well, in the form of a
> copyright disclaimer.  The FSF prefers to get an assignment, but a
> disclaimer is also acceptable.  The important point is the explicit
> signature.

And how are potential contributors supposed to know this?

If there is something that I can take from this thread is:

* The reasons for the copyright assignment/disclaimer, and their legal
effects are totally misunderstood by almost any potential contributor
and by a large number of existing contributors. After the whole
thread, I am perhaps a bit more confused than before. It would be
extremely useful if anyone that feels confident on the subject wrote a
FAQ-like document in the wiki that we could use as a reference for the
future. Otherwise, I feel that all the heated discussion will be for
nothing.

* The process is overly complex, obscure, confusing  and slow. It does
not seem that it needs to be so. It is scaring away potential
contributors and slowing down GCC development. Couldn't the SC
intercede with the FSF to make it as simpler (and clear) as possible?
In the ideal world, a web form would be sufficient to explain all
details and gather all required information.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Jonathan Corbet  writes:

> What you agree to is the developers certificate of origin (DCO), which
> says you have the right to contribute the code to the kernel.  No
> copyright assignment takes place.  Trust me, I have thousands of lines
> of code in the kernel, and the copyright remains mine.

The FSF permits something like this as well, in the form of a
copyright disclaimer.  The FSF prefers to get an assignment, but a
disclaimer is also acceptable.  The important point is the explicit
signature.

Ian

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner  writes:

> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
> able to enforce copyright is pretty useless IMO.  While you can
> force someone to release their code, the GPL doesn't force them to
> assign the copyright to the FSF.  In practice this means that you
> can force someone to release their GCC changes, but you can't merge
> them back to mainline GCC.  In a warped way you could argue that the
> FSF using the GPL encourages their software to fork :-)

Again, just for the record.  History shows that this is not entirely
useless.  People at NeXT wrote the Objective C frontend to GCC.  They
did not intend to release the source code.  The FSF objected.  In the
end, NeXT wound up contributing the code, and that is why GCC has an
Objective C frontend.  In other words, the whole process worked as the
GPL intended.

Ian

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 26.04.2010 20:03, schrieb Jakub Jelinek:
> On Mon, Apr 26, 2010 at 07:59:46PM +0200, Rainer Emrich wrote:
>> I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to
>> i686-w64-mingw32.
>>
>> i686-pc-mingw32-gcc -c  -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC
>> - -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes
>> - -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
>> - -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
>> - -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
>> - -I../../../../../../../src/gcc-4.4.4/gcc
>> - -I../../../../../../../src/gcc-4.4.4/gcc/.
>> - -I../../../../../../../src/gcc-4.4.4/gcc/../include -I./../intl
>> - -I../../../../../../../src/gcc-4.4.4/gcc/../libcpp/include
>> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
>> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
>> - -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber
>> - -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber/dpd 
>> -I../libdecnumber
>> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
>> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include 
>> -DCLOOG_PPL_BACKEND
>> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c -o dbxout.o
>> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c: In function 'dbxout_symbol':
>> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c:2491: internal compiler 
>> error:
>> Segmentation fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[2]: *** [dbxout.o] Error 1
> 
> ICE when building a cross compiler (the host stuff, not the target
> libraries) is a bug in whatever compiler you are using.
> Is that 4.4.4 too?  If yes, is it a regression from 4.4.3?
> 
>   Jakub

Yes, I use the same gcc-4.4.4 revision to build the cross compiler, and yes it's
an regression from gcc-4.4.3 and used to work until a few weeks ago.
I didn't use the RC, I'm using svn revision 158626.

Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvV10sACgkQoUhjsh59BL5t7gCgjwfmXml0lFMnuUwr3ql6IzrN
F6YAn3K6ARtPGP7XG/l/Jt8R8lFBFJ4E
=5gF5
-END PGP SIGNATURE-

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

On Mon, Apr 26, 2010 at 07:59:46PM +0200, Rainer Emrich wrote:
> I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to
> i686-w64-mingw32.
> 
> i686-pc-mingw32-gcc -c  -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC
> - -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes
> - -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
> - -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
> - -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
> - -I../../../../../../../src/gcc-4.4.4/gcc
> - -I../../../../../../../src/gcc-4.4.4/gcc/.
> - -I../../../../../../../src/gcc-4.4.4/gcc/../include -I./../intl
> - -I../../../../../../../src/gcc-4.4.4/gcc/../libcpp/include
> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
> - -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber
> - -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber/dpd 
> -I../libdecnumber
> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
> - -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -DCLOOG_PPL_BACKEND
> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c -o dbxout.o
> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c: In function 'dbxout_symbol':
> ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c:2491: internal compiler error:
> Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[2]: *** [dbxout.o] Error 1

ICE when building a cross compiler (the host stuff, not the target
libraries) is a bug in whatever compiler you are using.
Is that 4.4.4 too?  If yes, is it a regression from 4.4.3?

Jakub

Re: Why not contribute? (to GCC)

[Richard Kenner]

Chris Lattner wrote:
> To be perfectly clear, I'm not suggesting that the FSF or GCC
> project change their policies. 

Sure.  But others have and that's what this thread is all about.

Jonathan Corbet wrote:
> If the copyright holders don't wish to sue, then, one presumes, they
> are not unhappy about the use of their code?

No, certainly not. One presumes, instead, that they feel it's too much
TROUBLE to sue, which is exactly the point here.  If I'm walking down the
street and somebody's careless and knocks me down and I'm in pain for a
couple of days because of injuring my ankle and I choose not to sue the
person, does that mean I'm not unhappy he injured me?

If I own 1% of the code of a program and somebody makes it non-free, I'm
going to be upset, but probably not enough to either sue the person or try
to organize a group do to collectively.  But if instead I assigned that
software to a group that decided to sue, I'd be very happy they did and
glad that my assignment let them be able to do it.

Olivier Galibert wrote:
> You can't force some entity to release source code they have
> copyright to, that's not part of the legal remedies that are
> available to a judge.

What makes you say that?  Why couldn't that be a legal remedy?  When you
lose a suit, the whole point is you lose something of value.  Maybe it's
money, maybe it's real property, maybe it's a vehicle, maybe it's
custody of a child, or maybe it's loss of rights to illectual property.
The remedy you say a judge "can't" do is, in fact, not that uncommon.

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to
i686-w64-mingw32.

i686-pc-mingw32-gcc -c  -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC
- -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes
- -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
- -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
- -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
- -I../../../../../../../src/gcc-4.4.4/gcc
- -I../../../../../../../src/gcc-4.4.4/gcc/.
- -I../../../../../../../src/gcc-4.4.4/gcc/../include -I./../intl
- -I../../../../../../../src/gcc-4.4.4/gcc/../libcpp/include
- -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
- -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
- -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber
- -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber/dpd -I../libdecnumber
- -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include
- -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -DCLOOG_PPL_BACKEND
../../../../../../../src/gcc-4.4.4/gcc/dbxout.c -o dbxout.o
../../../../../../../src/gcc-4.4.4/gcc/dbxout.c: In function 'dbxout_symbol':
../../../../../../../src/gcc-4.4.4/gcc/dbxout.c:2491: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [dbxout.o] Error 1

I will open a PR.

Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvV1JIACgkQoUhjsh59BL7ziQCeNHEvzx1X5UxdKrA78wf5kw29
zHgAn1/JhTaFcl2vMO4uQBPAaZnCtn56
=1IdP
-END PGP SIGNATURE-

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 07:03:25PM +0200, Steven Bosscher wrote:
> There is so much negativism about a mere nuisance in this thread. It's
> a shame, but I guess it's just more proof that negative discussions
> about GCC are more popular than positive ones.

Seriously, depending on the country it's not a mere nuisance.  To put
things in perspective, for a lot of people in France it's equivalent
to, in the US, go to the bank that owns your mortgage[1] and ask them
a paper saying that they have no copyright interests on your interior
decoration.  Or a landlord of the thousands of places on rent kind.

  OG.

[1] If you don't have one, imagine you do.

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 09:53:51AM -0700, Chris Lattner wrote:
> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
> able to enforce copyright is pretty useless IMO.  While you can
> force someone to release their code, the GPL doesn't force them to
> assign the copyright to the FSF.  In practice this means that you
> can force someone to release their GCC changes[...]

No, you can't.  You can't force some entity to release source code
they have copyright to, that's not part of the legal remedies that are
available to a judge.  What the judge can do is preventing the entity
to distribute the code and/or money and/or jail.

When source code is released, it's through a settlement.  And a
settlement can contain anything the parties agree on and the judge
considers fair, including copyright assignments.

  OG.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke  writes:

> What are clean room implementations for if not for avoiding copyright
> violation?

Avoiding contract violations such as promises to keep source code
secret.  A strict clean room implementation also makes it clear that
no copyright violation could have occurred.


> At my company, we took things seriously to the point of
> dividing the GPL designers from the non-GPL designers to prevent code
> fragments from being leaked to one side or the other, even if just a
> faint memory that ends up resulting in code that looks just about
> exactly like the original, even if the author cannot identify what the
> original was.

I think that was entirely unnecessary on your part, though of course
lawyers, like anybody else, will tend to ask for whatever they can
get.

I won't respond further on this subthread on the list, it has nothing
to do with gcc.

Ian

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Mon, Apr 26, 2010 at 7:03 PM, Steven Bosscher  wrote:
> On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet  wrote:
>> I would not presume to tell the GCC project what its policy should be;
>> that's a decision for the people who are doing the work.
>
> Actually it's not. The FSF sets the rules, and you either play along
> or you don't do the work (not for the FSF anyway).

And to avoid being misunderstood: I don't say I like this situation.
It's just the facts as I understand them.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Frank Ch. Eigler]

Mark Mielke  writes:

> [...]  What are clean room implementations for if not for avoiding
> copyright violation?

It's a paranoid measure to preclude the appearance of the possibility
of conceivable copyright violation.  (It's also sometimes used in the
case of trade secrets.)

> At my company, we took things seriously [...]

I hope this degree of defensiveness is well justified and not too
costly in terms of your productiveness.

- FChE

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet  wrote:
> I would not presume to tell the GCC project what its policy should be;
> that's a decision for the people who are doing the work.

Actually it's not. The FSF sets the rules, and you either play along
or you don't do the work (not for the FSF anyway).

But to toss in $0.02 from someone who occasionally does some of the
work: I honestly just don't think of this copyright assignment as a
problem. I have assignments on file for g95 and for gcc, and I
assigned them because it allows me to contribute to a project that
gives me joy and fun (most of the time anyway) and the feeling I am
contributing to something useful for everyone. Every time I see a
device built in part with GCC (android phones, playstations,
Google(!)), I think "hey, some of my work helped build that".

There is so much negativism about a mere nuisance in this thread. It's
a shame, but I guess it's just more proof that negative discussions
about GCC are more popular than positive ones.

Shall we continue hacking now? There's enough to do.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Mon, 26 Apr 2010 12:50:14 -0400
"Alfred M. Szmidt"  wrote:

> If with kernel you mean Linux, then they require you to agree to an
> type of assignment (though not in paper form), same for git.  

No.

What you agree to is the developers certificate of origin (DCO), which
says you have the right to contribute the code to the kernel.  No
copyright assignment takes place.  Trust me, I have thousands of lines
of code in the kernel, and the copyright remains mine.

> Apache requires an assignment as well from the looks, see
> http://www.apache.org/licenses/icla.txt

Did you read it?  It's not a copyright assignment agreement.

> I do not know about MeeGo. 

http://meego.com/about/licensing-policy

MeeGo project will neither require nor accept copyright
assignment for code contributions. The principle behind this is
on the one hand to avoid extra bureaucracy or other obstacles
discouraging contributions. On the other hand the idea is to
emphasize that contributors themselves carry the rights and
responsibilities associated with their code.

> Regarding BusyBox, it was Erik Anderseen who filed suite (via SFLC),
> but he can only file suite for the code he holds the copyright over.
> If a company manages to remove the code he holds copyright over, and
> nobody of the other copyright holders wish to sue, then the company
> can go about violating the license.

If the copyright holders don't wish to sue, then, one presumes, they
are not unhappy about the use of their code?

Anyway, I've probably irritated this list more then enough already;
I'll stop now, sorry for the noise.

jon

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 8:11 AM, Alfred M. Szmidt wrote:
>   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.
> 
> This is not the only reason (and in the GNU projects case, not a
> reason at all), the main reason is to be able to enforce the copyright
> of the work without having to call in everyone into court.  If only
> parts of GCC where copyrighted by the FSF, then the FSF could only sue
> only for those parts.

Someone else pointed this out elsewhere in the thread, so perhaps it is worth 
responding.  Being able to enforce copyright is specifically useful if your 
code is under a GPL-style license.  For code under a bsd-style "do whatever you 
want, but don't sue us" style license, this is much less important.  That is 
why I claimed that the license change aspect is most important: for me 
personally, "enforcing copyright" is not a particular exciting prospect.

w.r.t. "hoarding", I'll point out that (in the context of GCC) being able to 
enforce copyright is pretty useless IMO.  While you can force someone to 
release their code, the GPL doesn't force them to assign the copyright to the 
FSF.  In practice this means that you can force someone to release their GCC 
changes, but you can't merge them back to mainline GCC.  In a warped way you 
could argue that the FSF using the GPL encourages their software to fork :-)


On Apr 25, 2010, at 10:23 PM, Richard Kenner wrote:
>> 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,

To be perfectly clear, I'm not suggesting that the FSF or GCC project change 
their policies.  I'm just disputing some claims about LLVM system, and pointing 
out that LLVM and GCC's policies differ because there are substantially 
different goals involved.  The LLVM project is much more focused on the 
technology and the community, the GCC project is more focused on ensuring 
software freedom (as defined by the FSF).  There isn't anything wrong with 
having different goals.

-Chris

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   >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

   Kernel, apache, MeeGo, git, for starters.

If with kernel you mean Linux, then they require you to agree to an
type of assignment (though not in paper form), same for git.  Linux
(and git) started with this right around when SCO started threatening
free software projects.  If such a such an agreement is legally
binding or not is for the court to decide, the assignments from the
FSF are legally binding, though (they are contracts).

Apache requires an assignment as well from the looks, see
http://www.apache.org/licenses/icla.txt

I do not know about MeeGo. 

Regarding BusyBox, it was Erik Anderseen who filed suite (via SFLC),
but he can only file suite for the code he holds the copyright over.
If a company manages to remove the code he holds copyright over, and
nobody of the other copyright holders wish to sue, then the company
can go about violating the license.

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Sun, 25 Apr 2010 12:00:13 -0400
"Alfred M. Szmidt"  wrote:

>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

Kernel, apache, MeeGo, git, for starters.

> you will
> have to ask them why they think they can ignore a paper trail.  

Copyright assignment != paper trail.

> Having
> one copyright holder solves many issues when enforcing copyright, you
> do not need to contact all parties.

The projects with the most public success at enforcing free licensing
are the kernel and busybox.  Neither requires copyright assignment.
The enforcement actions did not require the contacting of all parties -
where did that assertion come from?

I would not presume to tell the GCC project what its policy should be;
that's a decision for the people who are doing the work. But I do get
irritated when people claim that copyright assignment is required to
somehow keep a project "safe" or to make the copyright enforceable.
Both claims are demonstrably false.

jon

Re: Why not contribute? (to GCC)

[Ross Ridge]

Ross Ridge writes:
> Years ago, I was asked to sign one of these documents for some public
> domain code I wrote that I never intended to become part of a FSF project.
> Someone wanted to turn it a regular GNU project with a GPL license,
> configure scripts, a cute acronym and all that stuff.   I said no.
> It's public domain, take it or leave it.  Why I should I sign some
> legally binding document for some code I had in effect already donated
> to the public?

Richard Kenner writes:
> Because that's the only way to PUT something in the public domain!

That's absurd and beside the point.  

>> How would you feel if some charity you donated money to came back
>> with a piece of paper for you to sign?
>
>A closer analogy: a charity receives an unsolicited script for a play from
>you.

No, that's not a closer analogy.  As I said, I never intended for my
code to become part of an FSF project.  I didn't send them anything
unsolicited.

I'm contributing to this thread solely to answer the question asked.
Either take the time to read what I've written and use it try to
understand why I don't and others might not contribute to GCC, or please
just ignore it.  Your unsubstantiated and irrelevent legal opinions
aren't helping.

Ross Ridge

Re: cpplib utf8, status?

[Manuel López-Ibáñez]

I added all this to the wiki for future reference:

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

Feel free to improve it.

Cheers,

Manuel.

On 26 April 2010 17:12, Janek Kozicki  wrote:
> Joseph S. Myers said:     (by the date of Mon, 26 Apr 2010 14:15:06 + 
> (UTC))
>
>> > I suppose that "raw/real" UTF-8 will not work ;)
>> > So how do I express UCN in the code?
>>
>> By using the \u or \U syntax.  For example, pipe your code
>> through
>>
>> perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 : 
>> sprintf("\\U%08x", ord($1))/ge;'
>
>
> Wow! It works. Thanks a lot! Unbelievable!
>
> //file UCN_almost_UTF8_identifiers.cpp
>
> #include
> int main()
> {
>        double Δ_电场velocity(0);
>        std::cout << "Δ_v电场elocity= " << Δ_电场velocity << "\n";
> }
>
> // with following makefile:
>
> UCN_almost_UTF8_identifiers:UCN_almost_UTF8_identifiers.cpp
>        /home/janek/bin/to_UCN.sh UCN_almost_UTF8_identifiers.cpp
>        g++ -fextended-identifiers -o UCN_almost_UTF8_identifiers 
> /tmp/UCN_almost_UTF8_identifiers.cpp
>
> //and the helper script: to_UCN.sh:
>
> #!/bin/bash
> cat $1 | perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 
> : sprintf("\\U%08x", ord($1))/ge;' > /tmp/$1
>
>
> I'm happy that now, for quick testing purposes, I can use UTF8 symbols
> for variable names in  C++, even though the code is totally not
> portable, it will work locally, and will help me a lot in writing
> physical stuff.
>
> --
> Janek Kozicki                               http://janek.kozicki.pl/  |
>

Re: PowerPC suboptimal "add with carry" optimization

[Manuel López-Ibáñez]

On 26 April 2010 16:33, Pekka Enberg  wrote:
>
> I guess the conventional wisdom says that the way to attract new
> developers is to first attract users and testers and then turn them
> into contributors.

Unfortunately, this is not the case. We have probably hundreds of
thousands of users, people that can certainly program in the language
that GCC is written. We do not have many contributors. I don't have
numbers but I have the intuition that the ratio between users that are
developers and contributors to the project is much higher in GCC than
for the Linux kernel.

> I can understand what you're trying to achieve with your bug tracking
> system but I'm questioning if it's working for you. I am looking at

That depends what you mean by working. It works for me because
bugzilla does not get in my way when fixing bugs and most of the time
is very useful. It also works for people that spend time reporting
good bugs. Perhaps it doesn't work for people that don't have the time
to follow up on bugs. But then, we have already a lot of open reports
and features to work on, so perhaps missing those reports is actually
saving us time. On the other hand, if people are willing to spent time
reporting good bugs and perhaps providing a patch, and they don't have
the tools or the infrastructure to help them, *that* is really bad.
That is the people that we want to help.

> this from Linux kernel development point of view and the lessons
> learned there is that the lower you can make the barrier for entry
> (bug reports, patches, etc.), the more likely you're going to keep old
> people around and attract new ones.

Thanks for your comments, even if we disagree. I am spending a lot of
time thinking about these issues lately and I certainly appreciate
your input.

Cheers,

Manuel.

Re: cpplib utf8, status?

[Janek Kozicki]

Joseph S. Myers said: (by the date of Mon, 26 Apr 2010 14:15:06 + (UTC))

> > I suppose that "raw/real" UTF-8 will not work ;)
> > So how do I express UCN in the code?
> 
> By using the \u or \U syntax.  For example, pipe your code 
> through
> 
> perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 : 
> sprintf("\\U%08x", ord($1))/ge;'


Wow! It works. Thanks a lot! Unbelievable!

//file UCN_almost_UTF8_identifiers.cpp

#include
int main()
{
double Δ_电场velocity(0);
std::cout << "Δ_v电场elocity= " << Δ_电场velocity << "\n";
}

// with following makefile:

UCN_almost_UTF8_identifiers:UCN_almost_UTF8_identifiers.cpp
/home/janek/bin/to_UCN.sh UCN_almost_UTF8_identifiers.cpp
g++ -fextended-identifiers -o UCN_almost_UTF8_identifiers 
/tmp/UCN_almost_UTF8_identifiers.cpp

//and the helper script: to_UCN.sh:

#!/bin/bash
cat $1 | perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 : 
sprintf("\\U%08x", ord($1))/ge;' > /tmp/$1


I'm happy that now, for quick testing purposes, I can use UTF8 symbols
for variable names in  C++, even though the code is totally not
portable, it will work locally, and will help me a lot in writing
physical stuff.

-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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.

This is not the only reason (and in the GNU projects case, not a
reason at all), the main reason is to be able to enforce the copyright
of the work without having to call in everyone into court.  If only
parts of GCC where copyrighted by the FSF, then the FSF could only sue
only for those parts.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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?

That risk always exists; some level of trust has to exist somewhere.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > If I have the rights to re-license software, and I re-license the
   > software, why do I not have permission to enforce these rights?

   Because you have the permission to re-DISTRIBUTE (not "re-LICENSE")
   the software and nothing else.

In case of GCC, you have the explicit permission to relicense the work
under a later version of the GPL.  In the case of the GNU Lesser GPL,
you have explicit permission to relicense the work under the GPL.  So
depending on the license, you might have permission to relicense the
work.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

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

   That's irrlevent.  By signing the FSF's document I'd be doing
   nothing to reduce anyone's ability to sue me, I could only be
   increasing them.  And please don't try to argue that's not true,
   because I have no reason to believe you.

Well, it isn't true, the liabilities are exactly the same against you.

   Years ago, I was asked to sign one of these documents for some
   public domain code I wrote that I never intended to become part of
   a FSF project.  Someone wanted to turn it a regular GNU project
   with a GPL license, configure scripts, a cute acronym and all that
   stuff.

If you wrote it, then it is copyrighted and not public domain.
Putting code into the PD is complex, and depending on the place
impossible.  So unless you are a ghost from say 90 years back, the
code was infact copyrighted by you and not in the PD.  The general
method is to ask either for an assignment, or an explicit `free for
all' license.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > Years ago, I was asked to sign one of these documents for some
   > public domain code I wrote that I never intended to become part
   > of a FSF project.  Someone wanted to turn it a regular GNU
   > project with a GPL license, configure scripts, a cute acronym and
   > all that stuff.  I said no.  It's public domain, take it or leave
   > it.  Why I should I sign some legally binding document for some
   > code I had in effect already donated to the public?

   Because that's the only way to PUT something in the public domain!

Well, not entiterly correct... It is very hard to put something into
the public domain (legally) other than dropping dead, and waiting N
years.  What you do is just give a `free for all' license.

Re: PowerPC suboptimal "add with carry" optimization

[Pekka Enberg]

Hi Manuel,

On Mon, Apr 26, 2010 at 4:27 PM, Manuel López-Ibáñez
 wrote:
>> I guess that's the point, really. 15 minutes for what exactly? All the
>> information is right there in the email Joakim sent. You are trying to
>> make life easier for developers, not users or testers.
>
> I think you misunderstood the thread then. More users and more testers
> would be nice but we really need more developers (or people
> contributing documentation, infrastructure support, etc). So making
> life easier for developers is contributing. Making life harder for
> developers is not.

I guess the conventional wisdom says that the way to attract new
developers is to first attract users and testers and then turn them
into contributors.

I can understand what you're trying to achieve with your bug tracking
system but I'm questioning if it's working for you. I am looking at
this from Linux kernel development point of view and the lessons
learned there is that the lower you can make the barrier for entry
(bug reports, patches, etc.), the more likely you're going to keep old
people around and attract new ones.

But anyway, I'm not trying to argue with you or force my views on you.
I'm just stating my observation which is extremely biased towards what
I see as a working model (the Linux kernel).

On Mon, Apr 26, 2010 at 4:27 PM, Manuel López-Ibáñez
 wrote:
> You mention "reality" below. If you really want a particular bug
> fixed, then you should try to help the developers to fix it. Reality
> is that bugs that are not in bugzilla do not get fixed because
> developers prefer to spend their time efficiently on well-structured
> reports and on high impact bugs. So my comment is trying to help you
> to increase the chances that your bug gets fixed. But if yourself
> don't care, then why do you expect others do?

That's something you can change. But trying to convince people that
your bug tracking system is not a pain in the ass isn't going to
change things.

Pekka

Re: vectorization, scheduling and aliasing

[Richard Guenther]

On Mon, Apr 26, 2010 at 3:42 PM, roy rosen  wrote:
> Hi Richard,
>
> Here is the relevant block from the dump:
>
> :
>  __vect_var__26_6 = *__vect_p_14_19;
>  *__vect_p_18_25 = __vect_var__26_6;
>  # PT = nonlocal { __PARM_RESTRICT_2 } (restr)
>  __vect_p_22_11 = __vect_p_14_19 + 8;
>  # PT = nonlocal { __PARM_RESTRICT_1 } (restr)
>  __vect_p_27_12 = __vect_p_18_25 + 8;
>  __vect_var__26_45 = *__vect_p_22_11;
>  *__vect_p_27_12 = __vect_var__26_45;
>
> I guess that it recognizes the restrict pointer so I don't understand
> why later it creates a dependency between the insns.
> Do you see here something relevant?

No, it looks good.  At least if both __vect_p_22 and __vect_p_27
are restrict qualified.

The RTL dumps should show *__vect_p_27_12 and similar
expressions in their MEM_ATTRS as well.

Note that IVOPTs is known to not preserve alias information so
you might want to try -fno-ivopts

> Thanks, Roy.
>

Re: cpplib utf8, status?

[Joseph S. Myers]

On Mon, 26 Apr 2010, Janek Kozicki wrote:

> Joseph S. Myers said: (by the date of Mon, 26 Apr 2010 12:35:49 + 
> (UTC))
> 
> > If you wish to experiment with extended identifiers, use 
> > -fextended-identifiers.  This only supports UCNs in identifiers, not 
> > extended characters represented other than with UCNs.  Point 14 out of 15 
> > on my list is support for actual UTF-8 in identifiers.
> 
> Thank you,
> 
> Currently I have gcc version 4.4.3 20100108 (prerelease)
> (Debian 4.4.2-9), should use a newer version?

Although there are some relevant fixes in 4.5, I doubt they are relevant 
to what you want to do.

> I suppose that "raw/real" UTF-8 will not work ;)
> So how do I express UCN in the code?

By using the \u or \U syntax.  For example, pipe your code 
through

perl -pe 'BEGIN { binmode STDIN, ":utf8"; } s/(.)/ord($1) < 128 ? $1 : 
sprintf("\\U%08x", ord($1))/ge;'

or similar to convert extended characters to UCNs.

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

Re: PowerPC suboptimal "add with carry" optimization

[Ian Lance Taylor]

Joakim Tjernlund  writes:

> Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>>
>> Joakim Tjernlund  writes:
>>
>> > Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:
>
> BTW, I can see in gcc src:
> (define_insn ""
>   [(set (match_operand:CC 0 "cc_reg_operand" "=x,?y")
>   (compare:CC
>(plus:SI (gt:SI (match_operand:SI 1 "gpc_reg_operand" "r,r")
>(const_int 0))
> (match_operand:SI 2 "gpc_reg_operand" "r,r"))
>(const_int 0)))
>(clobber (match_scratch:SI 3 "=&r,&r"))]
>   "TARGET_32BIT"
>   "@
>{a|addc} %3,%1,%1\;{sfe|subfe} %3,%1,%3\;{aze.|addze.} %3,%2
>#"
>   [(set_attr "type" "compare")
>(set_attr "length" "12,16")])
> so there seems to be possible for gcc to emit them but how do
> I make gcc do that?

That unfortunately does not do what you want.  That instruction
sequence uses a scratch register to set a condition register to
whether (a + b) > 0.

Ian

Re: PowerPC suboptimal "add with carry" optimization

[Ian Lance Taylor]

Joakim Tjernlund  writes:

> Anyway, I *looked* at the page and it said something about gccbug so I tried
> that, not obvious either but I let me fire off a report an back came
> bug ID 43892

Thanks for filing the report.

Ian

Re: PowerPC suboptimal "add with carry" optimization

[David Edelsohn]

On Mon, Apr 26, 2010 at 9:22 AM, Joakim Tjernlund
 wrote:
>
> David Edelsohn  wrote on 2010/04/26 14:54:55:
>>
>> On Mon, Apr 26, 2010 at 8:21 AM, Joakim Tjernlund
>>  wrote:
>> > Manuel López-Ibáñez  wrote on 2010/04/26 13:59:04:
>> >> On 26 April 2010 09:13, Joakim Tjernlund  
>> >> wrote:
>> >> > Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>> >> >> 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.
>> >> >
>> >> > I rather not, going through all that just for one odd report. I was 
>> >> > hoping
>> >> > an interested part would pick it up from my email.
>> >>
>> >> What is to be done besides what you have done here but in a more
>> >> useful, structured manner? I am asking because we want to make things
>> >> simple but not simpler than they become more complex for us.
>> >
>> > Lots of stuff to read on that page, lots of info to supply,
>> > registering an account, specify all that system info and so on.
>>
>> You do not need to register an account to report a bug or request a
>
> Just tried that and don't see that.

Sorry, I was mistaken.  I thought that one could submit bug reports
without registering an account.

Thanks for opening a PR for the enhancement request.

Thanks, David

Re: vectorization, scheduling and aliasing

[roy rosen]

Hi Richard,

Here is the relevant block from the dump:

:
  __vect_var__26_6 = *__vect_p_14_19;
  *__vect_p_18_25 = __vect_var__26_6;
  # PT = nonlocal { __PARM_RESTRICT_2 } (restr)
  __vect_p_22_11 = __vect_p_14_19 + 8;
  # PT = nonlocal { __PARM_RESTRICT_1 } (restr)
  __vect_p_27_12 = __vect_p_18_25 + 8;
  __vect_var__26_45 = *__vect_p_22_11;
  *__vect_p_27_12 = __vect_var__26_45;

I guess that it recognizes the restrict pointer so I don't understand
why later it creates a dependency between the insns.
Do you see here something relevant?

Thanks, Roy.

Re: PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

Manuel López-Ibáñez  wrote on 2010/04/26 15:29:54:
>
> On 26 April 2010 15:22, Joakim Tjernlund  
> wrote:
> >
> >> feature enhancement.  Some of the information can be left blank, but
> >> if we do not have information about the system and an example, we may
> >> not understand the request or may not be able to reproduce the problem
> >> and fix it.
> >
> > Just go look at that page, it is so much info that if the bug isn't very 
> > importat
> > you quickly decide it is not worth it. How I am supposed to know what is 
> > need
> > or not without reading all that?
>
> You are totally right here. But this is not because we do not want to
> improve that page. Again, it is a lack of people contributing to
> improve that page. OK. I will stop fixing bugs and try to work on
> improving that page. Do you want to help me? It would be great to have
> some user-feedback when doing it.

You do what you want, it is not for me to say. And no I am not into fixing
that page either.

Anyway, I *looked* at the page and it said something about gccbug so I tried
that, not obvious either but I let me fire off a report an back came
bug ID 43892

  Jocke

Re: PowerPC suboptimal "add with carry" optimization

[Manuel López-Ibáñez]

On 26 April 2010 15:22, Joakim Tjernlund  wrote:
>
>> feature enhancement.  Some of the information can be left blank, but
>> if we do not have information about the system and an example, we may
>> not understand the request or may not be able to reproduce the problem
>> and fix it.
>
> Just go look at that page, it is so much info that if the bug isn't very 
> importat
> you quickly decide it is not worth it. How I am supposed to know what is need
> or not without reading all that?

You are totally right here. But this is not because we do not want to
improve that page. Again, it is a lack of people contributing to
improve that page. OK. I will stop fixing bugs and try to work on
improving that page. Do you want to help me? It would be great to have
some user-feedback when doing it.

Cheers,

Manuel.

Re: PowerPC suboptimal "add with carry" optimization

[Manuel López-Ibáñez]

On 26 April 2010 14:42, Pekka Enberg  wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Manuel López-Ibáñez
>  wrote:
 What is to be done besides what you have done here but in a more
 useful, structured manner? I am asking because we want to make things
 simple but not simpler than they become more complex for us.
>>>
>>> Lots of stuff to read on that page, lots of info to supply,
>>> registering an account, specify all that system info and so on.
>>
>> I don't think it will take you much more than 15 minutes.
>
> There's been a long "why not contribute to GCC thread" so to point out
> the obvious...

I know. I started it. ;-)

> I guess that's the point, really. 15 minutes for what exactly? All the
> information is right there in the email Joakim sent. You are trying to
> make life easier for developers, not users or testers.

I think you misunderstood the thread then. More users and more testers
would be nice but we really need more developers (or people
contributing documentation, infrastructure support, etc). So making
life easier for developers is contributing. Making life harder for
developers is not.

You mention "reality" below. If you really want a particular bug
fixed, then you should try to help the developers to fix it. Reality
is that bugs that are not in bugzilla do not get fixed because
developers prefer to spend their time efficiently on well-structured
reports and on high impact bugs. So my comment is trying to help you
to increase the chances that your bug gets fixed. But if yourself
don't care, then why do you expect others do?

Cheers,

Manuel.

Re: PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

David Edelsohn  wrote on 2010/04/26 14:54:55:
>
> On Mon, Apr 26, 2010 at 8:21 AM, Joakim Tjernlund
>  wrote:
> > Manuel López-Ibáñez  wrote on 2010/04/26 13:59:04:
> >> On 26 April 2010 09:13, Joakim Tjernlund  
> >> wrote:
> >> > Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
> >> >> 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.
> >> >
> >> > I rather not, going through all that just for one odd report. I was 
> >> > hoping
> >> > an interested part would pick it up from my email.
> >>
> >> What is to be done besides what you have done here but in a more
> >> useful, structured manner? I am asking because we want to make things
> >> simple but not simpler than they become more complex for us.
> >
> > Lots of stuff to read on that page, lots of info to supply,
> > registering an account, specify all that system info and so on.
>
> You do not need to register an account to report a bug or request a

Just tried that and don't see that.

> feature enhancement.  Some of the information can be left blank, but
> if we do not have information about the system and an example, we may
> not understand the request or may not be able to reproduce the problem
> and fix it.

Just go look at that page, it is so much info that if the bug isn't very 
importat
you quickly decide it is not worth it. How I am supposed to know what is need
or not without reading all that?

>
> >> Aren't you interested in someone fixing the bug?
> >
> > Sure or better yet, show me some way to restructure the C code so proper
> > asm code is generated.
>
> You referred to PowerPC patterns in GCC that use the carry
> instructions.  Those patterns are optimizations for materializing a
> truthvalue in a GPR or performance a 64 bit arithmetic operation in 32
> bit mode.  The PowerPC port of GCC does not recognize general carry
> arithmetic operations yet and track the carry bit.

OK, thanks. I know x86 do I had hope there was some way to do that i
PowerPC too.

Re: cpplib utf8, status?

[Janek Kozicki]

Joseph S. Myers said: (by the date of Mon, 26 Apr 2010 12:35:49 + (UTC))

> If you wish to experiment with extended identifiers, use 
> -fextended-identifiers.  This only supports UCNs in identifiers, not 
> extended characters represented other than with UCNs.  Point 14 out of 15 
> on my list is support for actual UTF-8 in identifiers.

Thank you,

Currently I have gcc version 4.4.3 20100108 (prerelease)
(Debian 4.4.2-9), should use a newer version?

I suppose that "raw/real" UTF-8 will not work ;)
So how do I express UCN in the code?

Shorter question: how do I modify this code, to get it to work, and
actually use the -fextended-identifiers option:

// g++ -fextended-identifiers -o z z.cpp
#include

int main()
{
double Δ_velocity(0);
std::cout << "Δ_velocity= " << Δ_velocity << "\n";
}

best regards
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: PowerPC suboptimal "add with carry" optimization

[David Edelsohn]

On Mon, Apr 26, 2010 at 8:21 AM, Joakim Tjernlund
 wrote:
> Manuel López-Ibáñez  wrote on 2010/04/26 13:59:04:
>> On 26 April 2010 09:13, Joakim Tjernlund  
>> wrote:
>> > Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>> >> 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.
>> >
>> > I rather not, going through all that just for one odd report. I was hoping
>> > an interested part would pick it up from my email.
>>
>> What is to be done besides what you have done here but in a more
>> useful, structured manner? I am asking because we want to make things
>> simple but not simpler than they become more complex for us.
>
> Lots of stuff to read on that page, lots of info to supply,
> registering an account, specify all that system info and so on.

You do not need to register an account to report a bug or request a
feature enhancement.  Some of the information can be left blank, but
if we do not have information about the system and an example, we may
not understand the request or may not be able to reproduce the problem
and fix it.

>> Aren't you interested in someone fixing the bug?
>
> Sure or better yet, show me some way to restructure the C code so proper
> asm code is generated.

You referred to PowerPC patterns in GCC that use the carry
instructions.  Those patterns are optimizations for materializing a
truthvalue in a GPR or performance a 64 bit arithmetic operation in 32
bit mode.  The PowerPC port of GCC does not recognize general carry
arithmetic operations yet and track the carry bit.

Thanks, David

Re: PowerPC suboptimal "add with carry" optimization

[Pekka Enberg]

Hi David,

On Mon, Apr 26, 2010 at 3:45 PM, David Edelsohn  wrote:
> There are a large number of users and a small number of developers.
> Why is it so large a burden to ask users to provide the information in
> a standard format in a centralized, trackable location, like GCC
> Bugzilla?

I'm not sure I understand the question. If you're arguing that it's
_not_ a burden, we have Joakim's reaction as proof that it's a burden
for *some* people. And if you're arguing that people shouldn't
consider it as a burden, then well, all I can say that you're arguing
with reality. Whether or not that represents a significant portion of
your user and tester-base is unknown to me.

Pekka

Re: PowerPC suboptimal "add with carry" optimization

[David Edelsohn]

In Mon, Apr 26, 2010 at 8:42 AM, Pekka Enberg  wrote:
> On Mon, Apr 26, 2010 at 3:36 PM, Manuel López-Ibáñez
>  wrote:
 What is to be done besides what you have done here but in a more
 useful, structured manner? I am asking because we want to make things
 simple but not simpler than they become more complex for us.
>>>
>>> Lots of stuff to read on that page, lots of info to supply,
>>> registering an account, specify all that system info and so on.
>>
>> I don't think it will take you much more than 15 minutes.
>
> There's been a long "why not contribute to GCC thread" so to point out
> the obvious...
>
> I guess that's the point, really. 15 minutes for what exactly? All the
> information is right there in the email Joakim sent. You are trying to
> make life easier for developers, not users or testers.

There are a large number of users and a small number of developers.
Why is it so large a burden to ask users to provide the information in
a standard format in a centralized, trackable location, like GCC
Bugzilla?

Thanks, David

Re: PowerPC suboptimal "add with carry" optimization

[Pekka Enberg]

On Mon, Apr 26, 2010 at 3:36 PM, Manuel López-Ibáñez
 wrote:
>>> What is to be done besides what you have done here but in a more
>>> useful, structured manner? I am asking because we want to make things
>>> simple but not simpler than they become more complex for us.
>>
>> Lots of stuff to read on that page, lots of info to supply,
>> registering an account, specify all that system info and so on.
>
> I don't think it will take you much more than 15 minutes.

There's been a long "why not contribute to GCC thread" so to point out
the obvious...

I guess that's the point, really. 15 minutes for what exactly? All the
information is right there in the email Joakim sent. You are trying to
make life easier for developers, not users or testers.

Pekka

Re: PowerPC suboptimal "add with carry" optimization

[Manuel López-Ibáñez]

On 26 April 2010 14:21, Joakim Tjernlund  wrote:
> Manuel López-Ibáñez  wrote on 2010/04/26 13:59:04:
>> On 26 April 2010 09:13, Joakim Tjernlund  
>> wrote:
>> > Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>> >> 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.
>> >
>> > I rather not, going through all that just for one odd report. I was hoping
>> > an interested part would pick it up from my email.
>>
>> What is to be done besides what you have done here but in a more
>> useful, structured manner? I am asking because we want to make things
>> simple but not simpler than they become more complex for us.
>
> Lots of stuff to read on that page, lots of info to supply,
> registering an account, specify all that system info and so on.
>

I don't think it will take you much more than 15 minutes.

>> Aren't you interested in someone fixing the bug?
>
> Sure or better yet, show me some way to restructure the C code so proper
> asm code is generated.

This would perhaps help you now but not a future you, not anyone else
in the world. (On the other hand, I don't have a workaround, sorry).

Cheers,

Manuel.

Re: cpplib utf8, status?

[Joseph S. Myers]

On Mon, 26 Apr 2010, Janek Kozicki wrote:

> Hi,
> 
> I wanted to ask - perhaps you know - what is the status of adding the
> UTF-8 support for identifier names in GCC, for c++?
> 
> It is according to http://gcc.gnu.org/projects/cpplib.html that such
> support is planned.

That page generally appears very out of date; it's not been updated since 
2002.

I have a 15-point todo list for extended identifiers, the very last point 
of which is enabling -fextended-identifiers by default for C99, C1X and 
C++.  This represents the results of analysis of the current state of GCC 
against the requirements for extended identifiers I agreed with Zack (PR 
9449 comment 21).  Fixing all the various cases required is however low 
priority.

> If you know that there is some patch somewhere floating around, even
> a very experimental one, I would like to try it. (debian squeeze)

If you wish to experiment with extended identifiers, use 
-fextended-identifiers.  This only supports UCNs in identifiers, not 
extended characters represented other than with UCNs.  Point 14 out of 15 
on my list is support for actual UTF-8 in identifiers.

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

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

You are free to keep discussing this ad-infinitum. But I really think
that this discussion is not adding anything new. It seems the same old
controversy that is beyond GCC. And it is getting confusing, hard to
follow, and at the end, all your effort will be lost in the archives
and help no one.

Cheers,

Manuel.


On 26 April 2010 14:22, Richard Kenner  wrote:
>> If I have the rights to re-license software, and I re-license the
>> software, why do I not have permission to enforce these rights?
>
> Because you have the permission to re-DISTRIBUTE (not "re-LICENSE") the
> software and nothing else.  Note that I changed "right" to "permission".
> The owner of the software (the copyright holder) has given you specific
> permissions to do certain things with the software.  Re-distributing it is
> one of them.  But you're not the OWNER of the software.
>
> You're also not re-LICENSING the software.  If I write some software and
> apply the GPL to it and you get a copy, you have my permission to
> redistribute that software to a third person.  But the license that the
> third person receives is from ME, not you.  If a person you give it to
> violates the GPL (e.g., by giving somebody a binary copy and refusing to
> give them the sources), that person has violated a license with ME and only
> *I* can persue it legally.
>
>> Personally, this whole issue is problematic to me. I really can't see
>> why I would ever sue somebody for using software that I had declared
>> free.
>
> If they made it NON-FREE!  See above.
>

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Years ago, I was asked to sign one of these documents for some public
> domain code I wrote that I never intended to become part of a FSF project.
> Someone wanted to turn it a regular GNU project with a GPL license,
> configure scripts, a cute acronym and all that stuff.   I said no.
> It's public domain, take it or leave it.  Why I should I sign some
> legally binding document for some code I had in effect already donated
> to the public?

Because that's the only way to PUT something in the public domain!
Copyright law says that if you write something, you own the copyright to
it.  That's true whether you put a copyright notice in it or not.  If you
mean to disclaim copyright interest in it, you have to sign some document
saying you do.

> How would you feel if some charity you donated money to came back
> with a piece of paper for you to sign?

A closer analogy: a charity receives an unsolicited script for a play from
you.  There's no copyright notice on it.  They love the script and feel
they can make a lot of money producing the show.  If you were the charity's
attorney would you recommend they go ahead and produce the show under the
assumption you MEANT to assign the rights to them or should they get a
document from you STATING that you mean to assign the rights to them?

cpplib utf8, status?

[Janek Kozicki]

Hi,

I wanted to ask - perhaps you know - what is the status of adding the
UTF-8 support for identifier names in GCC, for c++?

It is according to http://gcc.gnu.org/projects/cpplib.html that such
support is planned.

If you know that there is some patch somewhere floating around, even
a very experimental one, I would like to try it. (debian squeeze)

thank you for your time to answer me,
-- 
Janek Kozicki   http://janek.kozicki.pl/  |

Re: PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

Manuel López-Ibáñez  wrote on 2010/04/26 13:59:04:
> On 26 April 2010 09:13, Joakim Tjernlund  
> wrote:
> > Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
> >> 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.
> >
> > I rather not, going through all that just for one odd report. I was hoping
> > an interested part would pick it up from my email.
>
> What is to be done besides what you have done here but in a more
> useful, structured manner? I am asking because we want to make things
> simple but not simpler than they become more complex for us.

Lots of stuff to read on that page, lots of info to supply,
registering an account, specify all that system info and so on.

>
> Aren't you interested in someone fixing the bug?

Sure or better yet, show me some way to restructure the C code so proper
asm code is generated.

V4.5 was successfully built on RedHat 2.6.18-164.15.1.el5 x86_64

[Wenqing Wang]

Version 4.5 was successfully built on RedHat 2.6.18-164.15.1.el5 x86_64 
with glibc-2.5-42.el5_4.3


srcdir/config.guess:  x86_64-unknown-linux-gnu

Configured with: ../gcc-4.5.0/configure --with-gmp=/usr --with-mpfr=/usr 
--prefix=/usr --with-mpc=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,obj-c++,fortran --disable-dssi 
--enable-plugin --with-cpu=generic

Re: Why not contribute? (to GCC)

[Richard Kenner]

> If I have the rights to re-license software, and I re-license the
> software, why do I not have permission to enforce these rights?

Because you have the permission to re-DISTRIBUTE (not "re-LICENSE") the
software and nothing else.  Note that I changed "right" to "permission".
The owner of the software (the copyright holder) has given you specific
permissions to do certain things with the software.  Re-distributing it is
one of them.  But you're not the OWNER of the software.

You're also not re-LICENSING the software.  If I write some software and
apply the GPL to it and you get a copy, you have my permission to
redistribute that software to a third person.  But the license that the
third person receives is from ME, not you.  If a person you give it to
violates the GPL (e.g., by giving somebody a binary copy and refusing to
give them the sources), that person has violated a license with ME and only
*I* can persue it legally.

> Personally, this whole issue is problematic to me. I really can't see 
> why I would ever sue somebody for using software that I had declared 
> free.

If they made it NON-FREE!  See above.

successfully built 4.5

[Wenqing Wang]

Version 4.5 was successfully built on RedHat 2.6.18-164.15.1.el5 x86_64 
with glibc-2.5-42.el5_4.3


srcdir/config.guess:  x86_64-unknown-linux-gnu

Configured with: ../gcc-4.5.0/configure --with-gmp=/usr --with-mpfr=/usr 
--prefix=/usr --with-mpc=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,obj-c++,fortran --disable-dssi 
--enable-plugin --with-cpu=generic

Re: GCC porting tutorials

[Radu Hobincu]

Hello again and thank you a lot for the quick replies! I am impressed by
the number of mails I got in such a short time. You helped us loads.

I will also try to document our work every step of the way, maybe it will
help someone else in the future.

Regards,
Radu

Re: PowerPC suboptimal "add with carry" optimization

[Manuel López-Ibáñez]

On 26 April 2010 09:13, Joakim Tjernlund  wrote:
> Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>> 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.
>
> I rather not, going through all that just for one odd report. I was hoping
> an interested part would pick it up from my email.

What is to be done besides what you have done here but in a more
useful, structured manner? I am asking because we want to make things
simple but not simpler than they become more complex for us.

Aren't you interested in someone fixing the bug?

Manuel.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 07:06, Chris Lattner  wrote:
>
> 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?
>

Well, I agree that the discussion is going a bit off-topic. As it
commonly happens when the legal issues are raised. But it has been
raised that it is easier to contribute to LLVM than to GCC because the
former does not require a copyright assignment/disclaimer. The
question then is whether the copyright assignment/disclaimer is needed
at all, or its benefits outweighs its costs. It is a pointless
discussion for GCC because the FSF strongly feels that it is
necessary. I guess you have noticed that I am not in the LLVM mailing
list raising this "uncomfortable" questions.

In fact, I agree that those are (real, not perceived) problems in GCC.
But to address those problems we need more help. And I feel the
feedback from would-be-contributors has been interesting, but we
probably are not going to get anything more useful from this thread.
Can I close it?

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

From the things we have heard in this thread, this is a pretty
sensible question. Is the answer yes or no? You could actually ask the
lawyers of the U. of Illinois. But yes, until I start contributing to
LLVM (which may happen someday, there is nothing wrong with it) I
don't care much, that is, unless someone raises again the point that
it is easier to contribute to LLVM because they don't ask for a
copyright disclaimer. If you get an answer, I am honestly interested.
:-)

Manuel.

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/26/2010 11:23 AM, Mark Mielke wrote:

Personally, this whole issue is problematic to me. I really can't see
why I would ever sue somebody for using software that I had declared
free.


Because (a derivative of) it is being made nonfree?


It wouldn't be worth my time and I have trouble understanding how
I could demonstrate personal loss making the law suit worth persuing in
the first place.


Perhaps because you know the code better than anyone else, so you could 
provide paid support on that derivative as well.


Or maybe because you have to.  There was a case of a free software 
project (JMRI) being sued for patent infringement by a proprietary 
software company.  It turned out that the proprietary software included 
source code from the free software project without attribution (copyleft 
was not even necessary, as the project was under the Artistic License!). 
 In this case, the possibility to counter-sue saved the free software 
programmer from having to pay millions of dollars.


Paolo

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/26/2010 07:20 AM, Richard Kenner wrote:

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


I would not be surprised if these things were better defined in
Europe. I would not be surprised if they weren't better defined either,
but it's worth trying because in my experience the disclaimer is a much
higher barrier-to-entry than the assignment.

In particular, it is not common to find lawyers that are fluent in US
law in European institutions (if they are fluent in English at all).  In
fact, the FSF would do this half of the world a great favor by making a
list of countries where a disclaimer from the employer is not needed (if
any).  Alternatively, ask the FSF Europe to work on a version in at
least French, German, Italian and Spanish.

And even in the US we lost a patch for 4.5 due to a problem with the
disclaimer.  I read this recently on gcc-patches:

   The FSF has a personal copyright assignment for me, but I could not
   get one from my employer at the time, Stanford (according to
   Stanford's policies they would not claim copyright on this patch).

I suppose that this referred to http://rph.stanford.edu/5-2.html which
shows that the matter is not black-and-white:

   BOOKS, ARTICLES, AND SIMILAR WORKS, INCLUDING UNPATENTABLE SOFTWARE
   In accord with academic tradition, except to the extent set forth in
   this policy, Stanford does not claim ownership to pedagogical,
   scholarly, or artistic works, regardless of their form of
   expression. Such works include those of students created in the
   course of their education, such as dissertations, papers and
   articles. The University claims no ownership of popular nonfiction,
   novels, textbooks, poems, musical compositions, unpatentable
   software, or other works of artistic imagination which are not
   institutional works and did not make significant use of University
   resources or the services of University non-faculty employees
   working within the scope of their employment.

Yet copyright.list has:
- 3 disclaimers from Stanford dating back to 1989
- 10 contributors with a Stanford email, all without a disclaimer

So?

Paolo

Re: vectorization, scheduling and aliasing

[Richard Guenther]

On Mon, Apr 26, 2010 at 9:43 AM, roy rosen  wrote:
> Hi Richard,
>
> 2010/4/23, Richard Guenther :
>> On Thu, Apr 22, 2010 at 6:04 PM, roy rosen  wrote:
>> > Hi Richard,
>> >
>> > 2010/4/14, Richard Guenther :
>> >> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen  wrote:
>> >> > Hi All,
>> >> >
>> >> > I have implemented some vectorization features in my gcc port.
>> >> >
>> >> > In the generated code for this function I can see a scheduling problem:
>> >> >
>> >> > int xxx(int* __restrict__ a, int* __restrict__ b)
>> >> > {
>> >> >    int __restrict__ i;
>> >> >    for (i = 0; i < 8; i++)
>> >> >    {
>> >> >        a[i] = b[i];
>> >> >    }
>> >> >    return 0;
>> >> > }
>> >> >
>> >> > from asmcons:
>> >> >
>> >> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
>> >> >        (mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 
>> >> > {*movv4hi_load} (nil))
>> >> >
>> >> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
>> >> >        (reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD 
>> >> > (reg:V4HI 105)
>> >> >        (nil)))
>> >> >
>> >> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
>> >> >        (mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
>> >> >                (const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
>> >> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
>> >> >        (nil)))
>> >> >
>> >> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
>> >> >                (const_int 8 [0x8])) [2 S8 A64])
>> >> >        (reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD 
>> >> > (reg:V4HI 106)
>> >> >        (expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
>> >> >            (nil
>> >> >
>> >> >  from sched1 - dependecies list:
>> >> >   --- Region Dependences --- b 3 bb 0
>> >> > ;;      insn  code    bb   dep  prio  cost   reservation
>> >> > ;;            --   ---       ---
>> >> > ;;       17   115     3     0     4     1   (2_slots+lsu)       : 58 20 
>> >> > 18
>> >> > ;;       18   116     3     1     3     1   (2_slots+lsu)       : 58 19
>> >> > ;;       19   115     3     1     2     1   (2_slots+lsu)       : 58 20
>> >> > ;;       20   116     3     2     1     1   (2_slots+lsu)       : 58
>> >> > ;;       58   101     3     4     1     1   (3_slots+pcu)       :
>> >> >
>> >> > As you can see, insn 19 is dependant on 18.
>> >> > I think that this should not happen since the arrays has __restrict__.
>> >> > It might have something to do with aliasing.
>> >> >
>> >> > Are you aware of any kind of problems regarding aliasing and vectors?
>> >> > Can you think of anything else that might be wrong in my code that
>> >> > leads gcc to think that there is a dependency between insn 18 and 19?
>> >>
>> >> It completely depends on the GCC version you are using.  The
>> >> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based?  Because
>> >> they are not existant.  Try recent trunk which should work fine.
>> >>
>> >> Richard.
>> >>
>> >> > Thanks, Roy.
>> >> >
>> >>
>> >
>> > I have taken 4.5.0 and I still get the same problem.
>> > Do you have any ideas? Shouldn't the restrict tell the compiler that
>> > there is no dependency between these insns?
>>
>> It doesn't work for 4.5.0 due to PR42617.
>>
>> Richard.
>>
>> > Thanks, Roy.
>> >
>>
>
> I took snapshot 4.6-20100424 (is this version ok?) and the problem
> still occurs when I am looking at the vectorized version of the code.
> It seems ok in the nonvectorized version.
>
> What might be the problem?

Look at the -fdump-tree-optimized-alias dump, likely the defs
of the pointer SSA names that are used in the loads/stores
have their alias information dropped.  Or the vectorizer emits
ALIGN_INDIRECT_REFs on your target which we still drop.

Richard.

> Thanks, Roy.
>

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

[Richard Guenther]

On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn
 wrote:
> 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.

That's correct.  Now I delayed hacking this all into collect2
(because I don't think that's the correct place to do it).  I first
wanted to cleanup the driver <-> lto1 interface so we do _not_
rely on collect2 to identify LTO objects but instead have lto1
do that work and communicate final link objects to the driver
back via a response file (same for -fwhopr WPA / LTRANS
stage - do not exec lto1 from lto1 but rather tell the driver
the set of LTRANS files).

That's also the only easy way to get rid of the .comm __gnu_lto_v2
marker and simply check the availability of one of the always
present LTO sections.  For ar archieves it is easy to iterate
through them and we need to re-write them anyway if we want
to support partly LTO / non-LTO objects inside an archive.

Now of course if ar support ends up to look easy and sane in
the collect2 framework then we can choose to not wait for
somebody doing the above suggested cleanups ...

Richard.

>    cheers,
>      DaveK
>
>

Re: Why not contribute? (to GCC)

[Ross Ridge]

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

That's irrlevent.  By signing the FSF's document I'd be doing nothing
to reduce anyone's ability to sue me, I could only be increasing them.
And please don't try to argue that's not true, because I have no reason
to believe you.  Only a lawyer working for myself would be in a position
to convince me otherwise, but if I have to go that far, it's clearly
not worth it.

The debate over legalities has already derailed this thread, so let me
try to put it another way.

Years ago, I was asked to sign one of these documents for some public
domain code I wrote that I never intended to become part of a FSF project.
Someone wanted to turn it a regular GNU project with a GPL license,
configure scripts, a cute acronym and all that stuff.   I said no.
It's public domain, take it or leave it.  Why I should I sign some
legally binding document for some code I had in effect already donated
to the public?  How would you feel if some charity you donated money to
came back with a piece of paper for you to sign?

Submitting a hypothetical patch to GCC isn't much different to me.  For
some people having their code in the GCC distribution is worth something.
For me it's not.  For them it's a fair trade.  For me it's a donation.

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

As I said, I was just listing the reasons why I don't contribute.
I'm not arguing that anything should be changed or can be changed.
However, what I do know is that excuses won't make me or anyone else
more likely to contribute to GCC.

>Please refer to GCC as a free software project, it was written by the
>GNU project and the free software community. 

Oh, yah, forgot about that one.  Political stuff like this another reason
not to get involved with GCC. 

Ross Ridge

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 12:31 AM, Ian Lance Taylor wrote:

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.


They aren't truly independent if you use the patch as a model to work 
from. Demonstrating to a judge that your work is unique might be a lot 
more difficult if you confess to reading the original before writing the 
new.


What are clean room implementations for if not for avoiding copyright 
violation? At my company, we took things seriously to the point of 
dividing the GPL designers from the non-GPL designers to prevent code 
fragments from being leaked to one side or the other, even if just a 
faint memory that ends up resulting in code that looks just about 
exactly like the original, even if the author cannot identify what the 
original was.


Cheers,
mark

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:44 PM, Dave Korn wrote:

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.


"... they can only license the bits they do own" isn't quite right. The 
can only license the bits they have permission to license. Under the 
GPL, anybody with a legally obtained copy can re-license the software 
the same version of the GPL or a later version of the GPL.


Perhaps you mean they can only sue the bits they do own - but even that 
sounds suspect. If I have the rights to re-license software, and I 
re-license the software, why do I not have permission to enforce these 
rights? It doesn't make sense to me. But, I'm willing to assume the FSF 
lawyers know something I don't about copyright law, probably something 
about how only the actual owner (either due to being the original author 
or due to implicit copyright assignment to an employer or due to 
explicit copyright assignment to a third party such as the FSF?) can 
raise the law suit. If so, then yes, it would seem to, unfortunately, 
mean that you would need to get the author of the code that you want to 
sue about involved in the process.


Personally, this whole issue is problematic to me. I really can't see 
why I would ever sue somebody for using software that I had declared 
free. It wouldn't be worth my time and I have trouble understanding how 
I could demonstrate personal loss making the law suit worth persuing in 
the first place. Perhaps I do not run an organization such as the FSF or 
own a company that makes money off dual-licensing GPL/Commercial, so I 
don't have the same perspective as they do...


Cheers,
mark

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:27 PM, Dave Korn wrote:

On 26/04/2010 01:12, Mark Mielke wrote:
   

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.
   


If the software was truly free - and not limited use - there would be no 
need to enforce it. It would be free.



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.
   


This presumes that the benefits of truly free software are not 
sufficient on their own to result in benefits for the users. There are 
many non-GPL "free" software projects, that continue to be distributed 
for free, without the heavy handed "enforcement" defined by the GPL. The 
GPL is just one model for free software. It is not the only model, nor 
it is the most "free" model.



   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.
   


I think that other licenses exist which are both more free (less limited 
use), and would provide the same sorts of value in creating a commons. I 
think the creation of a commons should be about practical merit, and not 
some weird copyright protection that acts like a virus in that it 
infiltrates every derived software of the original software. I think 
people should do the right thing because it makes sense, not because the 
FSF crafted a clever way to lock people in to a certain model and never 
escape from it.



   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.
   


I have no fear of hoarding, because I believe that the merits of free 
software extend beyond a legal requirement to honour a copyright 
license. I believe companies generally discover that it is cheaper to 
contribute back to the project than to maintain patches off stream for 
extended periods of time. I believe that the users have power in 
requesting that the companies provide the software under an open source 
or free software license. I believe that free software has a significant 
place in this world which is compelling and self evident even to greedy 
self-interests. And if somebody doesn't get it, and hoards their own 
copy? I don't care. I as a user, can choose to not buy their solution. I 
as a user, can choose to contribute to an alternative to their solution. 
So what if somebody profits from my work? Companies such as RedHat 
profit from GPL work today. The copyright assignment part only goes so 
far in terms of protection. Personally, I have no problem with companies 
profiting from work which I have chosen to give away for free.



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 t

Re: GCC porting tutorials

[Jonas Paulsson]

Hi,

I recently completed my degree project on LTH on retargeting GCC. See 
http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved to 
http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon).


Even though I was aiming for a DSP architecture, I wrote down some things 
that concluded my experiences during the project. When setting out, I was 
completely new to GCC internals. I also found the Bombay links quite useful.


Good luck,

Jonas Paulsson
LTH, Sweden


- Original Message - 
From: "Radu Hobincu" 

To: 
Cc: "Vali Codreanu" ; "Petronela Agache" 


Sent: Saturday, April 24, 2010 10:53 AM
Subject: GCC porting tutorials



Hello,

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

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

Regards,
Radu 

Re: Why not contribute? (to GCC)

[Andrew Haley]

On 04/25/2010 06:05 PM, Steven Bosscher wrote:
> 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."

This is an example of a case where an explicit copyright agreement
helps everyone.  Clarity is good.

Andrew.

Re: PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
>
> Joakim Tjernlund  writes:
>
> > Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:

BTW, I can see in gcc src:
(define_insn ""
  [(set (match_operand:CC 0 "cc_reg_operand" "=x,?y")
(compare:CC
 (plus:SI (gt:SI (match_operand:SI 1 "gpc_reg_operand" "r,r")
 (const_int 0))
  (match_operand:SI 2 "gpc_reg_operand" "r,r"))
 (const_int 0)))
   (clobber (match_scratch:SI 3 "=&r,&r"))]
  "TARGET_32BIT"
  "@
   {a|addc} %3,%1,%1\;{sfe|subfe} %3,%1,%3\;{aze.|addze.} %3,%2
   #"
  [(set_attr "type" "compare")
   (set_attr "length" "12,16")])
so there seems to be possible for gcc to emit them but how do
I make gcc do that?

   Jocke

Re: vectorization, scheduling and aliasing

[roy rosen]

Hi Richard,

2010/4/23, Richard Guenther :
> On Thu, Apr 22, 2010 at 6:04 PM, roy rosen  wrote:
> > Hi Richard,
> >
> > 2010/4/14, Richard Guenther :
> >> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen  wrote:
> >> > Hi All,
> >> >
> >> > I have implemented some vectorization features in my gcc port.
> >> >
> >> > In the generated code for this function I can see a scheduling problem:
> >> >
> >> > int xxx(int* __restrict__ a, int* __restrict__ b)
> >> > {
> >> >int __restrict__ i;
> >> >for (i = 0; i < 8; i++)
> >> >{
> >> >a[i] = b[i];
> >> >}
> >> >return 0;
> >> > }
> >> >
> >> > from asmcons:
> >> >
> >> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> >> >(mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load} 
> >> > (nil))
> >> >
> >> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> >> >(reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD 
> >> > (reg:V4HI 105)
> >> >(nil)))
> >> >
> >> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> >> >(mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> >> >(const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> >> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> >> >(nil)))
> >> >
> >> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> >> >(const_int 8 [0x8])) [2 S8 A64])
> >> >(reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD 
> >> > (reg:V4HI 106)
> >> >(expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> >> >(nil
> >> >
> >> >  from sched1 - dependecies list:
> >> >   --- Region Dependences --- b 3 bb 0
> >> > ;;  insn  codebb   dep  prio  cost   reservation
> >> > ;;    --   ---       ---
> >> > ;;   17   115 3 0 4 1   (2_slots+lsu)   : 58 20 
> >> > 18
> >> > ;;   18   116 3 1 3 1   (2_slots+lsu)   : 58 19
> >> > ;;   19   115 3 1 2 1   (2_slots+lsu)   : 58 20
> >> > ;;   20   116 3 2 1 1   (2_slots+lsu)   : 58
> >> > ;;   58   101 3 4 1 1   (3_slots+pcu)   :
> >> >
> >> > As you can see, insn 19 is dependant on 18.
> >> > I think that this should not happen since the arrays has __restrict__.
> >> > It might have something to do with aliasing.
> >> >
> >> > Are you aware of any kind of problems regarding aliasing and vectors?
> >> > Can you think of anything else that might be wrong in my code that
> >> > leads gcc to think that there is a dependency between insn 18 and 19?
> >>
> >> It completely depends on the GCC version you are using.  The
> >> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based?  Because
> >> they are not existant.  Try recent trunk which should work fine.
> >>
> >> Richard.
> >>
> >> > Thanks, Roy.
> >> >
> >>
> >
> > I have taken 4.5.0 and I still get the same problem.
> > Do you have any ideas? Shouldn't the restrict tell the compiler that
> > there is no dependency between these insns?
>
> It doesn't work for 4.5.0 due to PR42617.
>
> Richard.
>
> > Thanks, Roy.
> >
>

I took snapshot 4.6-20100424 (is this version ok?) and the problem
still occurs when I am looking at the vectorized version of the code.
It seems ok in the nonvectorized version.

What might be the problem?

Thanks, Roy.

Re: PowerPC suboptimal "add with carry" optimization

[Joakim Tjernlund]

Ian Lance Taylor  wrote on 2010/04/25 20:07:03:
> 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.

I rather not, going through all that just for one odd report. I was hoping
an interested part would pick it up from my email.

 Jocke