Re: Can realloc be marked as a mallloc-like function?

[Janne Blomqvist]

On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:

On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:
> H.J. Lu wrote:
> >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> >return an address which can alias something else. But it isn't true
> >for realloc. Now, the qestions are
> >
> >1. Can gcc make such an assumption?
> >2. Can realloc be marked as DECL_IS_MALLOC.
> >
> >BTW, glibc also marks realloc with __attribute_malloc__.
>
> There was an absurdely long thread on this topic starting at
> .  I didn't dig through
> it to find the answer.

Now, we have a real testcase to show the problem. How do we solve
it?


I assigned the bug to myself, since I caused it. However, as the
regression is not seen on x86, I suppose there is only so much I can
do.  HJL, can you confirm that indeed removing only the DECL_IS_MALLOC
of internal_realloc fixes the issue on IA-64?

When I get back home tonight I'll take a look at the trees created by
array_constructor_6 and see if we do something obviously stupid, i.e.
can the frontend be fixed in some other way so that we can still keep
internal_realloc marked with DECL_IS_MALLOC.

--
Janne Blomqvist

Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7

[Dominique Dhumieres]

> Btw, is this a compiler with checking enabled?  

As fas as I can tell, yes.

> If so try comparing numbers with --enable-checking=release.

I am more interested to compare times rather than get the lowest possible 
number.

The following update of the timings shows that the compile time is 
worsening without positive impact on the execution time:

   compile   execute
  
 07/13 06/15 06/08 04/13   07/13 06/15 
06/08 04/13
 
ac   6.101 6.098 4.169 3.754 141.067   141.335   
141.271   140.479
aermod 280.850   266.403   205.639   196.447  93.91492.756
93.58390.632
air 15.82314.77311.92511.541  41.59840.149
41.53339.399
capacita 7.545 7.332 5.542 5.154 177.666   175.615   
176.229   177.222
channel  4.224 4.289 2.519 2.279  15.71315.664
15.94715.732
doduc   38.83437.70028.04026.679  68.60468.599
68.89568.195
fatigue 14.89712.843 8.733 8.293  24.45923.766
24.79523.061
gas_dyn 11.89311.856 8.168 7.598  54.01853.942
53.92952.100
induct  37.13136.87823.67122.445  71.68072.247
73.03169.283
linpk2.389 2.419 1.979 1.910  33.43533.489
33.84433.446
mdbx 9.428 9.052 7.036 6.716  32.56632.542
32.54332.985
nf   5.409 5.412 3.629 3.357  57.32851.424
51.40458.494
protein 20.16720.09713.16213.063  72.80970.825
70.11370.896
rnflow  19.95819.81214.37014.196  77.14976.936
77.41976.371
test_fpu17.48317.09812.03411.396  37.14637.336
37.32437.697
tfft 2.513 2.530 1.938 1.779  16.60216.653
16.83116.581

total  494.645   474.592   352.554   336.6071015.754  1003.278  
1008.691  1002.573

I have done the following comparison of the compile time for induct.f90 
with -ftime-report.  

Half of the ~15s is coming from 'loop analysis' (7s) and 'expand' account for 
1s.
Assuming that the lines starting by 'df' were introduced by the 
'dataflow' patch, it can explain directly at most a few seconds.
Does anybody understand why 'loop analysis' takes so much time on Darwin7?

TIA

Dominique


gcc version 4.3.0 20070713 (experimental)

[karma] lin/source% time gfortran -ftime-report -O3 -ffast-math -funroll-loops 
induct.f90

Execution times (seconds)
 loop analysis :   7.56 (21%) usr   0.19 ( 6%) sys   7.80 (19%) wall
1192 kB ( 2%) ggc
 tree STMT verifier:   4.80 (13%) usr   0.62 (19%) sys   5.34 (13%) wall
   2 kB ( 0%) ggc
 tree SSA verifier :   3.70 (10%) usr   0.07 ( 2%) sys   3.87 (10%) wall
  26 kB ( 0%) ggc
 expand:   1.99 ( 6%) usr   0.18 ( 6%) sys   2.21 ( 5%) wall
4996 kB (10%) ggc
 tree operand scan :   0.96 ( 3%) usr   0.56 (17%) sys   1.50 ( 4%) wall
2180 kB ( 4%) ggc
 global alloc  :   0.79 ( 2%) usr   0.08 ( 2%) sys   0.85 ( 2%) wall
1065 kB ( 2%) ggc
 scheduling:   0.73 ( 2%) usr   0.06 ( 2%) sys   0.81 ( 2%) wall
 285 kB ( 1%) ggc
 tree PRE  :   0.72 ( 2%) usr   0.04 ( 1%) sys   0.78 ( 2%) wall
2445 kB ( 5%) ggc
 rename registers  :   0.69 ( 2%) usr   0.02 ( 1%) sys   0.73 ( 2%) wall
 257 kB ( 1%) ggc
 CSE   :   0.66 ( 2%) usr   0.06 ( 2%) sys   0.67 ( 2%) wall
 264 kB ( 1%) ggc
 scheduling 2  :   0.62 ( 2%) usr   0.01 ( 0%) sys   0.63 ( 2%) wall
  60 kB ( 0%) ggc
 CFG verifier  :   0.62 ( 2%) usr   0.04 ( 1%) sys   0.48 ( 1%) wall
   0 kB ( 0%) ggc
 df live regs  :   0.61 ( 2%) usr   0.00 ( 0%) sys   0.68 ( 2%) wall
   0 kB ( 0%) ggc
 parser:   0.54 ( 2%) usr   0.08 ( 2%) sys   0.86 ( 2%) wall
3631 kB ( 7%) ggc
 garbage collection:   0.49 ( 1%) usr   0.05 ( 2%) sys   0.56 ( 1%) wall
   0 kB ( 0%) ggc
 if-conversion :   0.44 ( 1%) usr   0.00 ( 0%) sys   0.45 ( 1%) wall
  61 kB ( 0%) ggc
 combiner  :   0.43 ( 1%) usr   0.00 ( 0%) sys   0.49 ( 1%) wall
 912 kB ( 2%) ggc
 local alloc   :   0.41 ( 1%) usr   0.01 ( 0%) sys   0.44 ( 1%) wall
 752 kB ( 2%) ggc
 tree iv optimization  :   0.40 ( 1%) usr   0.07 ( 2%) sys   0.43 ( 1%) wall
7302 kB (15%) ggc
 reload CSE regs   :   0.32 ( 1%) usr   0.00 ( 0%) sys   0.33 ( 1%) wall
 941 kB ( 2%) ggc
 forward prop  :   0.32 ( 1%) usr   0.03 ( 1%) sys   0.37 ( 1%) wall
 550 kB ( 1%) ggc
 alias analysis:   0.31 ( 1%) usr   0.00 ( 0%) sys   0.40 ( 1%) wall
1398 kB ( 3%) ggc
 dead code elimination :   0.30 ( 1%) usr   0.01 ( 0%) sys   0.30 ( 1%) wall
   1 kB ( 0%) ggc
 tree VRP  :   0.29 ( 

Re: RFH: GPLv3

[Robert Dewar]

Brooks Moses wrote:

Robert Dewar wrote:

One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).


I'm going to pull a Wikipedia and call "citation needed" on that 
parenthetical claim.


Well the obvious citation is the copyright statutes themselves,
probably not a bad idea to read them!

At the very least, the file headers are a clear representation as to 
what license the file is under, and IMO a reasonable person would expect 
to be able to rely on such a representation.


Well certainly it is good policy for headers to reflect the copyright
and licensing situation, and of course we aim at that, that goes without
saying. But no you cannot rely on this information, and a blanket
copyright statement is a way of making sure that no possible case can
arise in which someone says "but I thought this was still under the
v2 GPL". Then you work hard to make ALL headers reflect the new status.


Thus, I think there's a reasonable argument to be made that distributing 
a GCC with some file headers saying "GPLv2 or later" and some saying 
"GPLv3 or later" is violating the license.


No, the position of the FSF (and it is a perfectly reasonable one) is
that if a file header says GPLv2 or later, it is essentially a multiple
distribution under all versions, so redistributing it as GPLv3 only
is fine. it is nice if you do this to change the header, but there is
nothing anywhere that requires this.

The FSF is allowed to 
violate their own license


That's a nonsense concept, there is no such thing as a license between
party A and party A, so the notion of violating it is meaningless.
Actually the whole notion of violating a license is a confused one.
The violation is of the copyright, the license merely gives some
cases in which copying is allowed. If you copy outside the license
you have not "violated" the license, you have simply infringed the
copyright, and the license is irrelevant.

And, regardless of whether one accepts that argument, if I were to pull 
a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an 
exact copy of it to my friend, I would have to remember to tell her that 
the file isn't licensed under what it says it's licensed under.  That's 
also not good.


Thus, I think it's reasonably critical that _all_ file headers be 
updated, quickly, to match the state of intended license for the files 
that include them.


I don't think anyone disagreed with this, so no need to argue against
non-existent disagreement!


- Brooks

Re: RFH: GPLv3

[Richard Kenner]

> Unfortunately, as I understand it, this is not the case.  If you
> apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
> this entire branch, and all files in it, magically and silently
> becomes GPLv3.

This is the key point, I think: what, PRECISELY, is a "GPLv3 patch".

I think everybody has assignments that predate GPLv3.  The assignment I
signed (and I think the current assignments) don't even mention the GPL at
all, let alone a particular version of it!

So one of us writes a patch and posts it on that list.  The copyright
status of that patch is that it's assigned to the FSF, which then can
"decide" what license agreement to apply to it.  But, as a matter of
practice, no FSF individual is involved in the process of having that patch
be applied to the sources: it's checked in by the person who wrote it
(after possible approval, but not change, by some other person).

At what point in this process, and by what mechanism, does a patch become a
"GPLv2 patch" or a "GPLv3 patch".  I'd argue that the patch itself has no
such status at all: as of the time it's posted, its copyright is owned by
the FSF, but that's all that's happened.  The assignment agreement
obligates the FSF that all "distribution" of the patch should be under
GPL-like terms, but it's completely unclear as to at what point those terms
apply.  For one thing, there are multiple possible licenses even ignoring
the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc.

So if you see a patch posted on an FSF mailing list, what copyright license
status does that patch have?  My feeling is that as a practical matter, it's
irrelevant since the patch is a derived work from some file and the license
that applies to that file trumps any that might be viewed by some mechanism
as applying to the patch in isolation.  If I'm patching an LGPLv3 file,
then my patch is a derived work from that file and so is also LGPLv3.
End of story.

So I think the discussion of a GPLv3 patch being applied to a GPLv2 file and
affecting the license of that file is somewhat backwards: the file's license
affects the patch and not vice-versa.

Where this gets tricky is indeed in a backport.  Let's suppose I have two
files that differ only into which license applies.  Suppose I start with
the GPLv3 version and develop a patch for it.  That patch is a derived work
from GPLv3.  When I apply it to the GPLv3 version of the file, nothing
changes.

Now, suppose I apply it to the GPLv2 version of the file. One could argue
that such file is now GPLv3 and I think that'd be correct.  But since the
parts of the file being patched are identical, the patch is indistinguishable
from one that's derived from GPLv2 text.  This strikes me as a VERY murky
legal areas.

Re: RFH: GPLv3

[Richard Kenner]

> Come on, if the FSF (the copyright holder) distributes a program,
> and if the included licence says GPLv2+, then the licence is GPLv2+
> and you'll have a really hard time trying to convince anyone that
> it's different.

The problem isn't convincing somebody it's *different*, but to convince
them that there's a reason the license is what it supposedly says it is!
It's critical to understand that copyright and license agreements in files
have *no legal significance whatsoever* except *possibly* to try to
establish what was in the mind of the author.

It's likely true that if they FSF were to "distribute" software in the
sense of mailing somebody a CD and there was no license on paper, you could
*probably* indeed rely on the license within the CD as being definitive.

But if there's some random file floating around that somebody claims was
copied from a site that somebody else claimed was maintained by the FSF and
you start relying on a notice in *that* file as definitively saying what
the license is, you're on *much* shakier legal grounds and most attorneys
would not be comfortable with it.

> BTW: the copyright holder is free to take a GPLv3 patch and
> release it under GPLv2 (and any other licence).

True, but irrelevant, as I said in my previous email: a patch is a derived
work of the file it patches, so there's not much real meaning in talking
about the license status of a patch in isolation.

Re: RFH: GPLv3

[Robert Dewar]

Richard Kenner wrote:


At what point in this process, and by what mechanism, does a patch become a
"GPLv2 patch" or a "GPLv3 patch".  I'd argue that the patch itself has no
such status at all: as of the time it's posted, its copyright is owned by
the FSF, but that's all that's happened.  The assignment agreement
obligates the FSF that all "distribution" of the patch should be under
GPL-like terms, but it's completely unclear as to at what point those terms
apply.  For one thing, there are multiple possible licenses even ignoring
the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc.


Yes, I think that this analysis is exactly correct


So if you see a patch posted on an FSF mailing list, what copyright license
status does that patch have?  My feeling is that as a practical matter, it's
irrelevant since the patch is a derived work from some file and the license
that applies to that file trumps any that might be viewed by some mechanism
as applying to the patch in isolation.  If I'm patching an LGPLv3 file,
then my patch is a derived work from that file and so is also LGPLv3.
End of story.


Seems like the right approach


Now, suppose I apply it to the GPLv2 version of the file. One could argue
that such file is now GPLv3 and I think that'd be correct.  But since the
parts of the file being patched are identical, the patch is indistinguishable
from one that's derived from GPLv2 text.  This strikes me as a VERY murky
legal areas.


Right, that does seem murky, which is why I suggested the blanket 
statement, that removes any possible murk.

Re: RFH: GPLv3

[Richard Kenner]

> >You asked if COPYING would be updated.  The answer is not necessarily.
> >The COPYING text may say GPLv2+, but if there has been a GPLv3 patch
> >applied to the branch, then the entire branch is GPLv3.
> 
> I struggle to believe this. Afaik a bunch of code is released under a
> license, and nothing has the power to magically change that license. If
> someone applies a GPLv3 patch to some GPLv2 code and releases the whole
> under the GPLv2, then that person has broken copyright law and the release
> is invalid (because the GPLv3 code has been released without a license),
> but the rest of the GPLv2 code is still GPLv2. Or have I missed something
> here? It sounds to me like the syntactic mischief Microsoft is playing when
> it calls the GPL "viral" (note, I'm not suggesting that you are making
> mischief, just that the implication is similar)!

No, you're correct, but what's meant by "the entire branch is GPLv3" doesn't
mean that somehow the license status of the code changed, but that "the
entire branch can now only be distributed under GPLv3".

> I think this misses a point: FSF is a copyright assignee, and I don't know
> how that relates to "holding", but the person who wrote the patch is free
> to dual-license without reference to the FSF. So as a completely fabricated
> example: say in 6 months Richard Kenner makes a patch to (GPLv3) mainline
> for a bug, and you want that patch to improve a GPLv2 product that you're
> maintaining for one of your customers. You are free to ask Richard to
> release that patch to you under GPLv2, and Richard is free to grant that
> request.

It's actually not that simple.  First of all, under the assignment, I don't
*automatically* have the right to distribute the patch under any license
I choose, but have to request it.  From an ancient version of assign.changes:

Upon thirty days' prior written notice, the Foundation agrees to grant
me non-exclusive rights to use the Work (i.e. my changes and
enhancements, not the program which I enhanced) as I see fit; (and the
Foundation's rights shall otherwise continue unchanged).

Secondly, the patch is usually not just a standalone entity, but a derived
work from the file that was patched.  I don't have authority to change
*that* license.

Re: RFH: GPLv3

[David Edelsohn]

> Richard Kenner writes:

Richard> Now, suppose I apply it to the GPLv2 version of the file. One could 
argue
Richard> that such file is now GPLv3 and I think that'd be correct.  But since 
the
Richard> parts of the file being patched are identical, the patch is 
indistinguishable
Richard> from one that's derived from GPLv2 text.  This strikes me as a VERY 
murky
Richard> legal areas.

I believe this scenario is exactly RMS's expectation if someone
other than the original author copies / backports a patch from a GPLv3
file.

David

Re: Can realloc be marked as a mallloc-like function?

[H.J. Lu]

On Sun, Jul 15, 2007 at 10:17:56AM +0300, Janne Blomqvist wrote:
> On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:
> >On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:
> >> H.J. Lu wrote:
> >> >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> >> >return an address which can alias something else. But it isn't true
> >> >for realloc. Now, the qestions are
> >> >
> >> >1. Can gcc make such an assumption?
> >> >2. Can realloc be marked as DECL_IS_MALLOC.
> >> >
> >> >BTW, glibc also marks realloc with __attribute_malloc__.
> >>
> >> There was an absurdely long thread on this topic starting at
> >> .  I didn't dig through
> >> it to find the answer.
> >
> >Now, we have a real testcase to show the problem. How do we solve
> >it?
> 
> I assigned the bug to myself, since I caused it. However, as the
> regression is not seen on x86, I suppose there is only so much I can
> do.  HJL, can you confirm that indeed removing only the DECL_IS_MALLOC
> of internal_realloc fixes the issue on IA-64?

Yes.

> 
> When I get back home tonight I'll take a look at the trees created by
> array_constructor_6 and see if we do something obviously stupid, i.e.
> can the frontend be fixed in some other way so that we can still keep
> internal_realloc marked with DECL_IS_MALLOC.
> 

You can compare the ia64 alias dumps to see the difference between
before and after the DECL_IS_MALLOC change.


H.J.

Re: RFH: GPLv3

[Richard Kenner]

> At the very least, the file headers are a clear representation as to 
> what license the file is under, and IMO a reasonable person would expect 
> to be able to rely on such a representation.

Well, all I can say to this is that (with my AdaCore hat on) I had a discussion
with somebody in the purchasing department of a major US defense contractor
last week who seemed like a quite reasonable person to me and quite rightly
was *not* willing to rely on any such "representation" in the file.  I think
I was, however, able to point her to something that she *could* rely on.
These sorts of discussions happen quite often and are one of the main
barriers towards commercial acceptance of GPL software.

> And, regardless of whether one accepts that argument, if I were to pull 
> a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an 
> exact copy of it to my friend, I would have to remember to tell her that 
> the file isn't licensed under what it says it's licensed under.  That's 
> also not good.

Yes, but it's precisely because you might have done that that people are not
willing to just rely on statements in files.

> Thus, I think it's reasonably critical that _all_ file headers be 
> updated, quickly, to match the state of intended license for the files 
> that include them.

I don't think you'll get any disagreement on that statement, but that doesn't
mean that such an update has any *legal* significance.

Re: RFH: GPLv3

[Richard Kenner]

> Actually the whole notion of violating a license is a confused one.  The
> violation is of the copyright, the license merely gives some cases in
> which copying is allowed. If you copy outside the license you have not
> "violated" the license, you have simply infringed the copyright, and the
> license is irrelevant.

Well, yes and no.  In the current situation where the "license" usually
isn't a signed agreement between the parties, that's correct.  However, if
two companies sign a license agreement for some software, that agreement is
a contract between the companies and is enforceable as a contract.  What
you (correctly) point out is that the more usual enforcement is as a
copyright infringement because that has statutory damages and the license
violation would have actual damages.  However, it's not at all hard to come
up with scenarios where the license contained limitations that would not be
permitted by copyright law and violation of such would produce provable
damages that would exceed statutory copyright damages and such would be
enforceable.

Re: RFH: GPLv3

[Robert Dewar]

Richard Kenner wrote:

Actually the whole notion of violating a license is a confused one.  The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
"violated" the license, you have simply infringed the copyright, and the
license is irrelevant.


Well, yes and no.  In the current situation where the "license" usually
isn't a signed agreement between the parties, that's correct.  However, if
two companies sign a license agreement for some software, that agreement is
a contract between the companies and is enforceable as a contract.  What
you (correctly) point out is that the more usual enforcement is as a
copyright infringement because that has statutory damages and the license
violation would have actual damages. 


Not the right analogy, the right analogy is a shrink wrapped license
e.g. from Microsoft, such licenses just

Re: RFH: GPLv3

[Robert Dewar]

Richard Kenner wrote:

Actually the whole notion of violating a license is a confused one.  The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
"violated" the license, you have simply infringed the copyright, and the
license is irrelevant.


Well, yes and no


Well I disagree with your analysis, but anyway neither of us are
attorneys (though I am a legal expert in copyright and license
matters), and it is pointless to argue such issues here, since they
are really not germane in any case to the fundamental issue of how
to handle the transition.

Re: RFH: GPLv3

[Richard Kenner]

> Richard> Now, suppose I apply it to the GPLv2 version of the file. One could
> Richard> argue that such file is now GPLv3 and I think that'd be correct. 
> Richard> But since the parts of the file being patched are identical, the
> Richard> patch is indistinguishable from one that's derived from GPLv2 text.
> Richard> This strikes me as a VERY murky legal areas.
>
> I believe this scenario is exactly RMS's expectation if someone other
> than the original author copies / backports a patch from a GPLv3 file.

But I'm even worried about the case where the *original* author does it.
So I developed a patch from a GPLv3 file.  I now go back and "develop" the
same patch from the GPLv2 file, which has all relevant parts identical.
The resulting patches are identical. Making the claim that these two
identical things done by the same person in the same way have different
copyright statuses might be legally correct, but as a practical matter
seems absurd since there's no way to tell them apart as they're identical.
This is a very bizarre situation!

Re: RFH: GPLv3

[Brooks Moses]

At 06:33 AM 7/15/2007, Robert Dewar wrote:

Richard Kenner wrote:

Actually the whole notion of violating a license is a confused one.  The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
"violated" the license, you have simply infringed the copyright, and the
license is irrelevant.

Well, yes and no


Well I disagree with your analysis, but anyway neither of us are
attorneys (though I am a legal expert in copyright and license
matters), and it is pointless to argue such issues here, since they
are really not germane in any case to the fundamental issue of how
to handle the transition.


Agreed -- especially since, on reflection, what I said and what I intended 
to say were not quite the same thing.


Apologies to all for the noise.

- Brooks

Re: RFH: GPLv3 and release version numbers

[Laurent GUERBY]

On Thu, 2007-07-12 at 10:21 -0700, Mark Mitchell wrote:
> David Edelsohn wrote:
> 
> > Let me try to stop some confusion and accusations right here.  RMS
> > *did not* request or specify GCC 4.3.3 following GCC 4.2.2.  That was a
> > proposal from a member of the GCC SC.  The numbering of the first GPLv3
> > release was not a requirement from RMS or the FSF.
> 
> I don't particularly have a dog in the version number fight.
> 
> I think it's potentially surprising to have a "bug fix release" contain
> a major licensing change -- whether or not it particularly affects
> users, it's certainly a big deal, as witnessed by the fact that it's at
> the top of the FSF's priority list!  But, if there's a clear consensus
> here, I'm fine with that.

I think it's useful to look at what other members of the free software
world are doing and if we take SAMBA they're bumping the version number:

http://news.samba.org/announcements/samba_gplv3/
"[...] To allow people to distinguish which Samba version is released
with the new GPLv3 license, we are updating our next version release
number. The next planned version release was to be 3.0.26, this will now
be renumbered so the GPLv3 version release will be 3.2.0.

To be clear, all versions of Samba numbered 3.2 and later will be under
the GPLv3, all versions of Samba numbered 3.0.x and before remain under
the GPLv2. [...]"

I don't know about other "big" projects (many projects don't have
branches), but there's some value for free software users about being
consistent across projects on this point.

Laurent

Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7

[Andrew Pinski]

On 7/15/07, Dominique Dhumieres <[EMAIL PROTECTED]> wrote:

> Btw, is this a compiler with checking enabled?

As fas as I can tell, yes.

> If so try comparing numbers with --enable-checking=release.

I am more interested to compare times rather than get the lowest possible
number.


Except the extra checking which was added by the Dataflow merge is
known to be slow which is why you see the jump.  This jump is not seen
with --enable-checking=release which is the default for official
releases of GCC.

Thanks,
Andrew Pinski

Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7

[Diego Novillo]

On 7/15/07 8:24 AM, Dominique Dhumieres wrote:

> I am more interested to compare times rather than get the lowest possible 
> number.

With checking enabled, you are comparing apples to oranges.  Different
compilers will do different checks, some of which can easily take double
digit percentages of compile time.

Re: RFH: GPLv3

[Michael Eager]

Richard Kenner wrote:

Unfortunately, as I understand it, this is not the case.  If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.


This is the key point, I think: what, PRECISELY, is a "GPLv3 patch".

I think everybody has assignments that predate GPLv3.  The assignment I
signed (and I think the current assignments) don't even mention the GPL at
all, let alone a particular version of it!

So one of us writes a patch and posts it on that list.  The copyright
status of that patch is that it's assigned to the FSF, which then can
"decide" what license agreement to apply to it.  But, as a matter of
practice, no FSF individual is involved in the process of having that patch
be applied to the sources: it's checked in by the person who wrote it
(after possible approval, but not change, by some other person).

At what point in this process, and by what mechanism, does a patch become a
"GPLv2 patch" or a "GPLv3 patch".  I'd argue that the patch itself has no
such status at all: as of the time it's posted, its copyright is owned by
the FSF, but that's all that's happened.  The assignment agreement
obligates the FSF that all "distribution" of the patch should be under
GPL-like terms, but it's completely unclear as to at what point those terms
apply.  For one thing, there are multiple possible licenses even ignoring
the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc.


When you post a patch to the mailing list, or apply it to a branch, you are
acting as an agent of FSF.  You previously assigned your rights to the patch
to the FSF.  (If you have not assigned your rights, then your patch will
not be applied to the branch, so it doesn't matter.)

The FSF decides what licenses to apply to a patch.  It's not at all unclear
what point the license applies:  at the moment FSF has said that all patches
applied after August 1 are covered by GPLv3.


So if you see a patch posted on an FSF mailing list, what copyright license
status does that patch have?  My feeling is that as a practical matter, it's
irrelevant since the patch is a derived work from some file and the license
that applies to that file trumps any that might be viewed by some mechanism
as applying to the patch in isolation.  If I'm patching an LGPLv3 file,
then my patch is a derived work from that file and so is also LGPLv3.
End of story.


If you signed an assignment of copyright, the copyright to the patch
belongs to FSF.  The status is clear and the license is whatever FSF says
it is.

You have it backward:  the base source doesn't determine the license status
of the patch; the patch determines the license status of the source.  The
most restrictive license applies.  Read the GPLv3.

This is the "GPL taint" provision.  Otherwise I could take the eager-cc
compiler (currently consisting of only main()) and patch it with all of
gcc, and poof, all that patched code takes on the license of the original
source.  Not what you want and, coincidently, not what the GPL requires.


So I think the discussion of a GPLv3 patch being applied to a GPLv2 file and
affecting the license of that file is somewhat backwards: the file's license
affects the patch and not vice-versa.


Nope.  Read the GPL.


Where this gets tricky is indeed in a backport.  Let's suppose I have two
files that differ only into which license applies.  Suppose I start with
the GPLv3 version and develop a patch for it.  That patch is a derived work
from GPLv3.  When I apply it to the GPLv3 version of the file, nothing
changes.

Now, suppose I apply it to the GPLv2 version of the file. One could argue
that such file is now GPLv3 and I think that'd be correct.  But since the
parts of the file being patched are identical, the patch is indistinguishable
from one that's derived from GPLv2 text.  This strikes me as a VERY murky
legal areas.


Sorry, it isn't at all murky.  If the original patch was covered under GPLv3,
no matter how similar it might be to one which hypothetically might have
been created under a different license, it remains GPLv3.  It's not whether
the patch is indistinguishable, its that it was not independently developed.


--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

[Michael Eager]

Brooks Moses wrote:

Robert Dewar wrote:

One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).


I'm going to pull a Wikipedia and call "citation needed" on that 
parenthetical claim.


At the very least, the file headers are a clear representation as to 
what license the file is under, and IMO a reasonable person would expect 
to be able to rely on such a representation.


Actually, this is a good point.  While the FSF may declare that all
patches after Aug 1 are GPLv3, unless they take affirmative action
to assert the copyright and license, courts may determine that they
waive rights under these.  Especially if a reasonable person would
expect copyright statements to be correct.

Thus, I think there's a reasonable argument to be made that distributing 
a GCC with some file headers saying "GPLv2 or later" and some saying 
"GPLv3 or later" is violating the license.  The FSF is allowed to 
violate their own license, since they hold the copyrights, but nobody 
else is -- thus, a corrolary to that argument is that an exact copy of 
such a GCC is not redistributable unless the redistributor fixes the 
file headers.  That would be bad.


And, regardless of whether one accepts that argument, if I were to pull 
a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an 
exact copy of it to my friend, I would have to remember to tell her that 
the file isn't licensed under what it says it's licensed under.  That's 
also not good.


Yes, the situation seems chaotic and confusing.  Not a good thing.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

[Florian Weimer]

* Robert Dewar:

> One could of course just take a blanket view that everything
> on the site is, as of a certain moment, licensed under GPLv3
> (note you don't have to change file headers to achieve this,
> the file headers have no particular legal significance in
> any case).

In Germany, they are significant in some contexts.  For instance, if
you distribute software with GPL headers to someone, and the receiver
uses them in accordance with the GPL, you will face a very tough time
in court when you try to claim copyright infringement by the receiver
because--surprise, surprise--the files weren't actually licensed under
the GPL.  This is called "venire contra factum proprium" in German
legalese, and I'm sure similar no-nonsense provisions exist in many
jurisdictions.

(Of course, a third party can still successfully claim copyright
infringement.)

Re: Can realloc be marked as a mallloc-like function?

[Richard Guenther]

On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:

This patch

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html

causes the regression:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748

The only relevant change is

Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 126214)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -2276,6 +2276,7 @@ gfc_build_builtin_function_decls (void)
 (PREFIX("internal_realloc")),
 pvoid_type_node, 2, pvoid_type_node,
 gfc_index_int_type_node);
+  DECL_IS_MALLOC (gfor_fndecl_internal_realloc) = 1;

   gfor_fndecl_allocate =
 gfc_build_library_function_decl (get_identifier (PREFIX("allocate")),

In calls.c, there are comments:

  /* The return value from a malloc-like function can not alias
 anything else.  */

It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are

1. Can gcc make such an assumption?


No, it can't.  The returned memory may alias the original memory.


2. Can realloc be marked as DECL_IS_MALLOC.


... with DECL_IS_MALLOC the following

int *p;
p = malloc (4);
*p = 0;
p = realloc (p, 4);
*p = 1;

will have VOPs that do not prevent re-ordering of the two stores.


BTW, glibc also marks realloc with __attribute_malloc__.


Which is wrong as well.

Richard.

Re: Re[2]: [GSoC: DDG export][RFC] Current status

[Zdenek Dvorak]

Hello,

> Testing on tree-vectorizer testsuite and some of the GCC source files
> showed that frequent source of apparent loss of exported information
> were passes that performed basic block reordering or jump threading.
> The verifier asserted that number of loops was constant and the order
> they are visited by FOR_EACH_LOOP remained the same throughout the
> compilation.

you definitely cannot rely on that, the number and order of loops may
change due to many different optimizations (for example those you
mention, but also others).

> Zdenek, could you please clarify whether and how your LoopPreserving
> project is going to influence the mentioned problems?

Once the patches for the project are merged, the information about loops
will be preserved across most of the gimple optimizations; i.e., the
loops may still be removed or their order may be changed by different
optimizations, but any info attached to "struct loop" corresponding to
any given loop will survive (some amount of work may still be needed to
keep it correct through some transformations, but in particular for ddg
this should not be an issue, as it should stay conservatively correct
after almost all optimizations)

However, I do not preserve loops on RTL, in particular during tree->rtl
expansion; this would need some more work.

> That said, I do not see the mentioned concerns as serious problems,
> because the verifier can be made more permissive, and one can search
> exported data references in all loops.  Even if order and count of
> loop changes, if we are able to find data dependency relation for two
> given MEMs later, it will still make sense, with this notable
> exception: if RTL loop unrolling (or reversal) is performed,

We do not do loop reversal on RTL.

> then the
> found ddr will contain incorrect distance (because the increment of
> the index changed).  Is that correct?  What would be the preferred
> approach: fixing up the exported data, or discarding the irrelevant
> information?

Loop optimizations definitely need to know about ddg; it should be
fairly easy to keep it up-to-date (invalidating the affected
part is also a possibility, however the loops we unroll are most likely
exactly the loops for that we later need a better ddg in scheduling, so
this would be a bit counterproductive).

> I mentioned before that I would need to take care of basic block
> duplication on tree level, but I have seen no example of that
> happening after iv-opts so far.  Does anyone know offhand whether it
> is possible?

Some code duplication may happen in jump threading, performed in dom and
vrp, both are run also after ivopts; they probably do not have that many
opportunities to do so at that time, but you cannot rely on that.

Zdenek

Re: RFH: GPLv3

[Michael Eager]

Richard Kenner wrote:

Richard> Now, suppose I apply it to the GPLv2 version of the file. One could
Richard> argue that such file is now GPLv3 and I think that'd be correct. 
Richard> But since the parts of the file being patched are identical, the

Richard> patch is indistinguishable from one that's derived from GPLv2 text.
Richard> This strikes me as a VERY murky legal areas.

I believe this scenario is exactly RMS's expectation if someone other
than the original author copies / backports a patch from a GPLv3 file.


But I'm even worried about the case where the *original* author does it.
So I developed a patch from a GPLv3 file.  I now go back and "develop" the
same patch from the GPLv2 file, which has all relevant parts identical.
The resulting patches are identical. Making the claim that these two
identical things done by the same person in the same way have different
copyright statuses might be legally correct, but as a practical matter
seems absurd since there's no way to tell them apart as they're identical.
This is a very bizarre situation!


Actually, the two patches don't have different copyright or licenses,
given your description.  It's really not possible to "un-know" the
original GPLv3 patch and create an identical GPLv2 from scratch.  The
second patch is clearly and directly derived from the first.

There might be a claim that someone else could develop the GPLv2
patch based on the GPLv2 sources, not looking at your patch or any
GPLv3 sources, in which case it would be either coincidence if they
happened to be identical, or a requirement of the context.

But this second patch is really irrelevant to the discussion at hand.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Can realloc be marked as a mallloc-like function?

[Janne Blomqvist]

H.J. Lu wrote:

On Sun, Jul 15, 2007 at 10:17:56AM +0300, Janne Blomqvist wrote:

On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:

On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:

H.J. Lu wrote:

It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are

1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.

BTW, glibc also marks realloc with __attribute_malloc__.

There was an absurdely long thread on this topic starting at
.  I didn't dig through
it to find the answer.

Now, we have a real testcase to show the problem. How do we solve
it?

I assigned the bug to myself, since I caused it. However, as the
regression is not seen on x86, I suppose there is only so much I can
do.  HJL, can you confirm that indeed removing only the DECL_IS_MALLOC
of internal_realloc fixes the issue on IA-64?


Yes.


When I get back home tonight I'll take a look at the trees created by
array_constructor_6 and see if we do something obviously stupid, i.e.
can the frontend be fixed in some other way so that we can still keep
internal_realloc marked with DECL_IS_MALLOC.



You can compare the ia64 alias dumps to see the difference between
before and after the DECL_IS_MALLOC change.


I removed DECL_IS_MALLOC from internal_realloc, committed 126662 as 
obvious, and closed PR 32748.



--
Janne Blomqvist

Re: RFH: GPLv3

[Laurent GUERBY]

On Thu, 2007-07-12 at 17:11 +0200, Basile STARYNKEVITCH wrote:
> [...] Still, I do believe that almost all my distant colleagues from
> CEA http://www.cea.fr/ (notably compiling their numerical 
> code for e.g. nuclear, astronomical or thermodynamical numerical
> computations) will find funny a version number change 
> from 4.2 to 4.2 only for the compiler license change. Most of them
> don't care about GPLv2 vs GPLv3 for the compiler, 
> they just want to compile their (sadly proprietary) numerical code (in
> Fortran or C++).
> 
> IMHO the only persons who really care about GPLv2 vs GPLv3 are
> open-source enthusiasts (and active open-source 
> contributors).  [...]

I hope your employer follows industry standard practice of caring *a
lot* about licensing issues for all the software they use. You're
greatly mistaken if you think only compiler hackers look at software
licences, lawyers and management have they say here (at least
in the organisations I know).

Laurent

Re: Can realloc be marked as a mallloc-like function?

[H.J. Lu]

On Sun, Jul 15, 2007 at 09:52:02PM +0200, Richard Guenther wrote:
> On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:
> >This patch
> >
> >http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html
> >
> >causes the regression:
> >
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
> >
> >The only relevant change is
> >
> >Index: gcc/fortran/trans-decl.c
> >===
> >--- gcc/fortran/trans-decl.c(revision 126214)
> >+++ gcc/fortran/trans-decl.c(working copy)
> >@@ -2276,6 +2276,7 @@ gfc_build_builtin_function_decls (void)
> > (PREFIX("internal_realloc")),
> > pvoid_type_node, 2, pvoid_type_node,
> > gfc_index_int_type_node);
> >+  DECL_IS_MALLOC (gfor_fndecl_internal_realloc) = 1;
> >
> >   gfor_fndecl_allocate =
> > gfc_build_library_function_decl (get_identifier (PREFIX("allocate")),
> >
> >In calls.c, there are comments:
> >
> >  /* The return value from a malloc-like function can not alias
> > anything else.  */
> >
> >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> >return an address which can alias something else. But it isn't true
> >for realloc. Now, the qestions are
> >
> >1. Can gcc make such an assumption?
> 
> No, it can't.  The returned memory may alias the original memory.
> 
> >2. Can realloc be marked as DECL_IS_MALLOC.
> 
> ... with DECL_IS_MALLOC the following
> 
> int *p;
> p = malloc (4);
> *p = 0;
> p = realloc (p, 4);
> *p = 1;
> 
> will have VOPs that do not prevent re-ordering of the two stores.
> 
> >BTW, glibc also marks realloc with __attribute_malloc__.
> 
> Which is wrong as well.

I opened 2 bugs:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32771
http://sourceware.org/bugzilla/show_bug.cgi?id=4792


H.J.

Re: valid_gimple_expression_p claims validity of invalid gimple

[Daniel Berlin]

On 7/14/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:

> First is_gimple_min_invariant in try_to_simplify where it chooses
> DECL_INITIAL should be valid_gimple_expression_p instead.

That's a known problem, see tree-ssa-ccp.c:


I had forgotten about this because i hadn't done IPA in a while.  At
some point, we should just create special initializer functions and
gimplify these into them.


/* The regular is_gimple_min_invariant does a shallow test of the object.
   It assumes that full gimplification has happened, or will happen on the
   object.  For a value coming from DECL_INITIAL, this is not true, so we
   have to be more strict ourselves.  */

static bool
ccp_decl_initial_min_invariant (tree t)
{
  if (!is_gimple_min_invariant (t))
return false;
  if (TREE_CODE (t) == ADDR_EXPR)
{
  /* Inline and unroll is_gimple_addressable.  */
  while (1)
{
  t = TREE_OPERAND (t, 0);
  if (is_gimple_id (t))
return true;
  if (!handled_component_p (t))
return false;
}
}
  return true;
}

static tree
get_symbol_constant_value (tree sym)
{
  if (TREE_STATIC (sym)
  && TREE_READONLY (sym)
  && !MTAG_P (sym))
{
  tree val = DECL_INITIAL (sym);
  if (val
  && ccp_decl_initial_min_invariant (val))
return val;
}

  return NULL_TREE;
}

You could turn ccp_decl_initial_min_invariant into a global predicate and
invoke it from tree-ssa-sccvn.c on the DECL_INITIAL.

> However, even if i fix this, the testcase still fails because
> valid_gimple_expression says something that is clearly invalid is
> valid.
>
> (gdb) p valid_gimple_expression_p ($2)
> $3 = 1 '\001'
> (gdb) p debug_generic_stmt ($2)
> &((struct RegisterLayout *) (char *) &SimulatedRegisters)->intmask;
>
> This is not valid gimple by a longshot :)

Almost. :-)  The function was extracted unchanged from set_rhs but it looks
like it needs to be beefed up a bit if it is to become of general use.

> If you fix this part, i'll happily fix the bug report with the first part.

The problem is again the ADDR_EXPR case, because it drags lvalues into the
game.  This would be something like:


I'll try this and submit it as part of my patch if it works.

Thanks a ton!

Re: RFH: GPLv3

[Basile STARYNKEVITCH]

Laurent GUERBY wrote:

On Thu, 2007-07-12 at 17:11 +0200, Basile STARYNKEVITCH wrote:

[...] Still, I do believe that almost all my distant colleagues from
CEA http://www.cea.fr/ (notably compiling their numerical 
code for e.g. nuclear, astronomical or thermodynamical numerical
computations) will find funny a version number change 
from 4.2 to 4.2 only for the compiler license change. Most of them
don't care about GPLv2 vs GPLv3 for the compiler, 
they just want to compile their (sadly proprietary) numerical code (in

Fortran or C++).

IMHO the only persons who really care about GPLv2 vs GPLv3 are
open-source enthusiasts (and active open-source 
contributors).  [...]


I hope your employer follows industry standard practice of caring *a
lot* about licensing issues for all the software they use. You're
greatly mistaken if you think only compiler hackers look at software
licences, lawyers and management have they say here (at least
in the organisations I know).


Of course CEA's lawyers do care about GPL and know it quite well (the CECILL license http://cecill.info/ which in my 
limited understanding is an adaptation of GPL to french law originated at CEA & INRIA & CNRS).


But the developer use a compiler (perhaps GCC) to produce a binary (which might 
be the object of a commercial contract).

Unless there is a new point in GPLv3 which affects (i.e. changes) the legal status of a binary produced by GCC (I 
understood and hope that not, and this would be against the spirit of free software, and might perhaps even be illegal - 
e.g. Microsoft don't have any rights on the documents written with Word) I don't see the point.



Most of my distant collegues probably don't even compile GCC but uses it (in a binary form) from some distribution. This 
is probably the case for most GCC users.


Very few compilers (even proprietary) have strange licenses affecting the legal status of the produced binary (and I am 
not sure the license of the compiler matters here). The only exceptions I heard of are some (eg prolog or lisp) 
compilers with an explicit runtime license (usually per binary sold or transfered) for their runtime library.


AFAIK the only equivalent in GCC is libgcc (and perhaps libstdc++) which is not under GPL (ie has an exception clause 
which covers the common case of a proprietary binary).


My point is still that most GCC users don't compile the compiler and don't seem touched by the GPLv2 -> GPLv3 license 
change, provided they can do whatever they (or their management) wants with the binary produced by GCC.


Of course if the GPLv3 said clearly that the user have limited rights on the binary produced by GCC that would be very 
different (and GCC user base would almost vanish!).


So I still think that a version number change from 4.2.x to 4.3.y for only GPLv2 -> GPLv3 license transition in the 
compiler itself (not in the produced binaries) would be an annoyance.


What most GCC users care most is the legal right to use the produced binaries by the GCC compiler. It is not about the 
compiler's license, provided this license is compatible with the practice of compiling proprietary software.



--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***