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
> 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
wors
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'
> 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 thin
> 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
th
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 assi
> >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 noth
> 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
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 addres
> 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 pu
> 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
> li
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 copyrig
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 copyrig
> 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
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 li
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 f
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 ex
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 o
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 "GPLv
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'
* 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 ar
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
=
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
> the
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 tha
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
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 ver
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 rele
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
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
29 matches
Mail list logo
