Re: Serious code generation/optimisation bug (I think)

[Andrew Haley]

Erik Trulsson wrote:
> On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote:

>> "6.3.2.3 Pointers
>>
>> If a null pointer constant is converted to a pointer type, the
>> resulting pointer, called a null pointer, is guaranteed to compare
>> unequal to a pointer to any object or function."
>>
>> This implies that a linker cannot place an object at address zero.
> 
> Wrong.  There is nothing which requires a null pointer to be all-bits-zero
> (even though that is by far the most common representation of null
> pointers.)

We're talking about gcc on ARM.  gcc on ARM uses 0 for the null pointer
constant, therefore a linker cannot place an object at address zero.
All the rest is irrelevant.

Andrew.

Re: Serious code generation/optimisation bug (I think)

[Vincent Lefevre]

On 2009-01-28 16:34:29 -0500, Robert Dewar wrote:
> If 0 is a valid address, then it is improper for the compiler to use
> 0 to represent the null pointer.

I disagree. You can represent addresses with some bit set. If in
practice (at the processor level), this bit is ignored, then this
can really be efficient. For instance, IIRC, the 68000 ignored
the top 8 bits of a register when regarding its value as an
address (a 32-bit register could address a 24-bit address space).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Serious code generation/optimisation bug (I think)

[Vincent Lefevre]

On 2009-01-29 08:53:10 +, Andrew Haley wrote:
> We're talking about gcc on ARM.  gcc on ARM uses 0 for the null pointer
> constant, therefore a linker cannot place an object at address zero.
> All the rest is irrelevant.

How about using volatile, as suggested by Robert Dewar (if the gcc
documentation implies that this will work)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Serious code generation/optimisation bug (I think)

[Zoltán Kócsi]

On Thu, 29 Jan 2009 08:53:10 +
Andrew Haley  wrote:

> Erik Trulsson wrote:
> > On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote:
> 
> >> "6.3.2.3 Pointers
> >>
> >> If a null pointer constant is converted to a pointer type, the
> >> resulting pointer, called a null pointer, is guaranteed to compare
> >> unequal to a pointer to any object or function."
> >>
> >> This implies that a linker cannot place an object at address zero.
> > 
> > Wrong.  There is nothing which requires a null pointer to be
> > all-bits-zero (even though that is by far the most common
> > representation of null pointers.)
> 
> We're talking about gcc on ARM.  gcc on ARM uses 0 for the null
> pointer constant, therefore a linker cannot place an object at
> address zero. All the rest is irrelevant.
> 
> Andrew.

Um, the linker *must* place the vector table at address zero, because
the ARM, at least the ARM7TDMI fetches all exception vectors from
there. Dictated by the HW, not the compiler.

Zoltan

Re: New GCC Runtime Library Exception

[Florian Weimer]

* Joe Buck:

> On Tue, Jan 27, 2009 at 12:51:22PM -0800, Florian Weimer wrote:
>> * David Edelsohn:
>> 
>> > We have also published a rationale document and FAQ to help users
>> > understand the exception better.  It is avaliable at:
>> >
>> >   http://www.gnu.org/licenses/gcc-exception-faq.html
>> 
>> Is it deliberate that the exception does not extend to programs
>> compiled with GCJ?
>
> There's nothing special about GCJ, it's just the Java front end of GCC and
> the rules are the same as for other language front ends.

The difference is that the front end does not work on source code, but
Java bytecode, which seems closer to intermediate representation than
to a "high-level, non-intermediate language".  If I'm not mistaken,
there is currently no usable Java-to-bytecode compiler with a license
that is GPLv3-compatible (according to the Free Software Foundation's
license interpretations).

> Perhaps you're thinking about Classpath; some issues were raised
> that haven't been worked out, so as the FAQ says:

I assume this exception is for libgcc.  A compiled Java class file
references libgcc (at least indirectly), so it is an Independent
Module.  The Eclipse compiler and jc1 take part in the Compilation
Process.  This Compilation Process is not Eligible because it is done
with GCC *and* software which is not GPL-compatible.  This means that
the exception does not come into force as far as libgcc is concerned,
meaning that GCJ-compiled programs must be licensed under a
GPLv3-compatible license (which is a problem if you want to include
GPLv2-only libraries, for instance).

Other cases are rather unclear, too.  A hypothetical QPL-licensend
compiler which links against libgcc (Objective Caml apparently
doesn't) cannot produce an Eligible Compilation Process because it is
a work based on GCC (thanks to libgcc), and not everything is
GPL-licensed.  Interpreters capable of producing ELF binaries might
also be affected by a similar issue.

Call me paranoid, but this looks like yet another example where the
Free Software Foundation tries to make things easy for proprietary
software developers, and ends up leaving projects behind which use
non-GPL free software licenses--whose status as free software licenses
is acknowledged by the FSF.

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :

I'm not sure what your point is here.  newlib is not under the GPL in
any case.  It is not affected by the gcc runtime library license.


The old runtime library exception allowed you to distribute binaries that
both include pieces of the gcc runtime and arbitrary pieces of newlib,
without requiring the distribution to be under the terms of the GPL.
I.e. your could link non-GPL code against both the gcc runtime and newlib
and distribute it.
The new license does not allow this unless all parts included from newlib
are written in a high level language AND use the gcc runtime.




Note that there is also code which is not written in a high level language
which uses gcc runtime library interfaces.  For example, look at
libgloss/m68k/crt0.S , which uses __do_global_dtors .
That the license of libgloss is GPL-compatible does not help here,
since we want to allow people to link programs containing non-GPL-compatible
code simultanously against libgloss and libgcc.


I don't see anything which prohibits them from doing so.


That would be the Berne Copyright convention.  I don't see anything
which allows them distributing the resulting binaries.

They could distribute binaries that use the gcc runtime and parts of
libgloss under the terms of the GPL, or they could distribute binaries
that use the gcc runtime and proprietary code which uses the gcc runtime
under the terms of the GCC library exception, but there is no provision
that allows them to distribute a binary which combines all three.


The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc proprietary compiler.


No, it says that you can only do that if every file of the proprietary code
is written or generated in a high level language, and uses the GCC runtime.


What the runtime library license restricts is linking libgcc with
proprietary code which was compiled by a mix of gcc and proprietary
code to produce some program, and then distributing the program
without distributing source code.


I suppose you know that, but let's state here clearly for the benefit of
any third parties reading this that just distributing source is not
sufficient to satisfy the GPL.  The program could be licensed with a
GPL-incompatible open source / free software license, source code
distributed, and you still wouldn't be allowed to distribute binaries
linked against the gcc runtime if you don't fulfill the prerequisites
of the gcc runtime library exception.

Problems with DWARF debug info and GCC 4.3.2

[Sebastian Huber]

Hi,

I use GCC cross compilers from the RTEMS project. They differ only in nuances
from the official releases.  Between GCC version 4.2.4 and 4.3.3 something
changed in the DWARF debug info. I am unsure if this is cause for trouble. I
tested it with the PowerPC and m68k architectures. Here is the test program
source (test.cpp):

#include 

extern "C" {

void _start()
{
/* VOID */
}

}

Command line:

m68k-4.3.3-g++ test.cpp test.cpp -otest-4.3.3.elf
m68k-4.2.4-g++ test.cpp test.cpp -otest-4.2.4.elf

Inspection of the resulting ELF-file with objdump (from Binutils 2.19) produces
the following warnings and errors (samples):

objdump -W test-4.3.3.elf > /dev/null

objdump: Error: Range lists in .debug_info section aren't in ascending order!

objdump: Warning: Range lists in .debug_ranges section start at 0xe8

objdump: Warning: There is an overlap [0x120 - 0x0] in .debug_ranges section.

objdump: Warning: There is a hole [0xe8 - 0x6d8] in .debug_ranges section.

objdump -W test-4.2.4.elf > /dev/null

No warnings and errors.

In the version 4.3.3 there are warnings and an error. The background is
that we have problems to debug applications compiled with the version 4.3.3 due
to invalid line number informations. I am unsure if the above warnings and
errors are connected to this.

Have a nice day!

Sebastian Huber

-- 
Sebastian Huber, Embedded Brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: New GCC Runtime Library Exception: not fit for purpose

[Manuel López-Ibáñez]

2009/1/29 Joern Rennecke :
>
>> The runtime library license says that you can link libgcc with
>> proprietary code, whether that proprietary code was compiled with gcc
>> or whether it was compiled with some non-gcc proprietary compiler.
>
> No, it says that you can only do that if every file of the proprietary code
> is written or generated in a high level language, and uses the GCC runtime.
>

Where does it say that? I don't see it, but again I am not a lawyer.
Have you contacted licens...@fsf.org ? We know the intention of the
license. There is also the FAQ:
http://www.fsf.org/licensing/licenses/gcc-exception-faq.html

If we are missing some legal technicality, then this is not the
appropriate forum to address it.

Cheers,

Manuel.

Re: New GCC Runtime Library Exception

[Joern Rennecke]

The difference is that the front end does not work on source code, but
Java bytecode, which seems closer to intermediate representation than
to a "high-level, non-intermediate language".  If I'm not mistaken,
there is currently no usable Java-to-bytecode compiler with a license
that is GPLv3-compatible (according to the Free Software Foundation's
license interpretations).



Other cases are rather unclear, too.  A hypothetical QPL-licensend
compiler which links against libgcc (Objective Caml apparently
doesn't) cannot produce an Eligible Compilation Process because it is
a work based on GCC (thanks to libgcc), and not everything is
GPL-licensed.  Interpreters capable of producing ELF binaries might
also be affected by a similar issue.


I think using non-GPL Free Software is in the spirit of what we are trying
to archive, while exposing non-high-level input languages for the use with
gcc to arbitrarily licensed optimizers is not.

Therefore, I think it would be best to amend the definition of an Eligible
Compilation Process.

I.E.:

replace definition of "GPL-compatible Software" with:

"Free Compilation Software" is software distributed under a license that
was approved as a free software license by the FSF at the time that the
code covered by the GCC Runtime Library Exception was released by the FSF,
or any later license that the FSF grants for the distribution of GCC,
and for which source code was available for the person generating Target
Code when generating the Target Code.

A Compilation Process is "Eligible" if it is done using GCC, alone or  
with other Free Compilation Software, or if it is done without using  
any work based on GCC. For example, using Software not qualifying as  
Free Compilation Software

to optimize any GCC intermediate representations would not qualify as an
Eligible Compilation Process..

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Manuel López-Ibáñez :


2009/1/29 Joern Rennecke :



The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc proprietary compiler.


No, it says that you can only do that if every file of the proprietary code
is written or generated in a high level language, and uses the GCC runtime.



Where does it say that?


Where does it grant any other permission?
It allows you to propagate a work of Target code formed by combining  
the Runtime Library with Independent Modules under certain conditions,  
but

it doesn't give you any permission to propagate a work that also includes
code that is neither part of the Runtime Library nor an Independent Module.

And a file is only an Independent Module if it either requires the Runtime
Library for execution after the Compilation Process, or makes use of an
interface provided by the Runtime library.
Hence, if a file of your code does not use the GCC runtime, it is not an
Independent Module, and thus no permission is given to include it in a link
with the runtime library.

Moreover, since the permission is specific for a work of Target Code, and
all Target Code has to be generated by Eligible Compilation Processes,
it follows that all of your code - and all of the Runtime Library code -
included in the link must be generated by an Eligible Compilation process
for the exception to apply.
An Eligible compilation process is defined such that it can only apply
to code represented in a hihg-level language, so if any you the libgcc
code, your code, or any third-party library code is written in assembler,
the exception can't apply, i.e. the only license you could possibly
propagate the resulting binary under would be GPLv3 or later.


Have you contacted licens...@fsf.org ?


I thought that there so may things wrong with this license that we should
first have a discussion on what we think it should say so as to archive
the stated purpose.


We know the intention of the license.


Indeed.  That's why we can dicusss in what ways it does not meet that
intention.

There is also the FAQ:

http://www.fsf.org/licensing/licenses/gcc-exception-faq.html


Which contains a number of false assumptions and non sequiturs.

Not every file of source code that doesn't contain any source from GCC  
libraries qualifies as an "Independent Module" as defined.  As a matter

of fact, which ones qualify depends on the target processor, but in
general the ratio is rather low.

And hardly anybody will be able to use the GCC Runtime Library Exception,
I.E. the recommendation should be to stick with a previous version of GCC.


If we are missing some legal technicality,


I don't think these are mere legal technicalities, this is a fundamental
failure to say what you mean.
The new GCC runtime library exception will hardly give anyone any rights
that they don't already have under the GPL, since we got non-highlevel
code in the runtime library, i.e. most links are not producing a work
of Target Code generated by an Eligible Compilation Process.

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> Quoting Manuel López-Ibáñez :
>
>> 2009/1/29 Joern Rennecke :
>>>
 The runtime library license says that you can link libgcc with
 proprietary code, whether that proprietary code was compiled with gcc
 or whether it was compiled with some non-gcc proprietary compiler.
>>>
>>> No, it says that you can only do that if every file of the proprietary code
>>> is written or generated in a high level language, and uses the GCC runtime.
>>>
>>
>> Where does it say that?
>
> Where does it grant any other permission?
> It allows you to propagate a work of Target code formed by combining
> the Runtime Library with Independent Modules under certain conditions,
> but
> it doesn't give you any permission to propagate a work that also includes
> code that is neither part of the Runtime Library nor an Independent Module.

I don't think it needs to.

Code that is neither Target Code nor an Independent Module is code
that has never been involved with gcc, and the license does not cover
it.  The license does not prohibit combining Target Code or
Independent Modules with other code, so it is permitted.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[amylaar]

Quoting Ian Lance Taylor :


Joern Rennecke  writes:


Quoting Manuel López-Ibáñez :


2009/1/29 Joern Rennecke :



The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc proprietary compiler.


No, it says that you can only do that if every file of the   
proprietary code
is written or generated in a high level language, and uses the   
GCC runtime.




Where does it say that?


Where does it grant any other permission?
It allows you to propagate a work of Target code formed by combining
the Runtime Library with Independent Modules under certain conditions,
but
it doesn't give you any permission to propagate a work that also includes
code that is neither part of the Runtime Library nor an Independent Module.


I don't think it needs to.

Code that is neither Target Code nor an Independent Module is code
that has never been involved with gcc, and the license does not cover
it.  The license does not prohibit combining Target Code or
Independent Modules with other code, so it is permitted.

Ian

Re: New GCC Runtime Library Exception

[Ian Lance Taylor]

Florian Weimer  writes:

> The difference is that the front end does not work on source code, but
> Java bytecode, which seems closer to intermediate representation than
> to a "high-level, non-intermediate language".

I think it is clear that Java bytecode, which can even be executed
directly by some microprocessors, is not a "compiler intermediate
representation."

I'm not super familiar with Java tools, but I think the rest of your
argument hinges on that.


> Other cases are rather unclear, too.  A hypothetical QPL-licensend
> compiler which links against libgcc (Objective Caml apparently
> doesn't) cannot produce an Eligible Compilation Process because it is
> a work based on GCC (thanks to libgcc), and not everything is
> GPL-licensed.  Interpreters capable of producing ELF binaries might
> also be affected by a similar issue.

Your argument here seems to be that linking against libgcc makes a
program be covered by the definition of "GCC" in the runtime library
license.  I don't think that argument is reasonable either on the text
or in the real world.  It would mean that every program compiled by
gcc is itself gcc.


> Call me paranoid, but this looks like yet another example where the
> Free Software Foundation tries to make things easy for proprietary
> software developers, and ends up leaving projects behind which use
> non-GPL free software licenses--whose status as free software licenses
> is acknowledged by the FSF.

While perhaps some wording needs to be changed, the intent of the
license is stated clearly.  Paranoia on this point is not appropriate.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

>>> Note that there is also code which is not written in a high level language
>>> which uses gcc runtime library interfaces.  For example, look at
>>> libgloss/m68k/crt0.S , which uses __do_global_dtors .
>>> That the license of libgloss is GPL-compatible does not help here,
>>> since we want to allow people to link programs containing non-GPL-compatible
>>> code simultanously against libgloss and libgcc.
>>
>> I don't see anything which prohibits them from doing so.
>
> That would be the Berne Copyright convention.  I don't see anything
> which allows them distributing the resulting binaries.

The license says that you have permission to propagate works when
certain conditions apply.  It does not say that you do not have
permission if certain other conditions apply.  Therefore, if certain
conditions apply, you have permission.  It is not necessary for the
license to say "oh, and if you stand on your head, you still have
permission.'


>> The runtime library license says that you can link libgcc with
>> proprietary code, whether that proprietary code was compiled with gcc
>> or whether it was compiled with some non-gcc proprietary compiler.
>
> No, it says that you can only do that if every file of the proprietary code
> is written or generated in a high level language, and uses the GCC runtime.

The word "only" is your interpolation.  It does not appear in the
runtime license.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :

Code that is neither Target Code nor an Independent Module is code
that has never been involved with gcc, and the license does not cover
it.


There is a lot of Target code that is, per definition, not an
Independent Module because it does not use the GCC runtime library.


The license does not prohibit combining Target Code or
Independent Modules with other code, so it is permitted.


No, this is not how Copyright works.  In the absence of a license you may
not distribute the resulting work.

So, if you want to combine parts of the GCC runtime library with Independent
Modules and other code, your only option (if any) is the GPL.

Likewise, if you want to combine any parts of the GCC runtime library which
are not Target Code (anything written in assembler is not Target Code, e.g.
some targets have crt*.S files) with independent modules, your only option
(if any) is the GPL.

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

[Rainer Orth]

Dennis Clarke writes:

> Would there be any way that I could invite you into the community
> build farm at Blastwave.org for this purpose ? I think it would be
> great if we could get a GCC package built ( with ada ) that passes a
> set of QC/QA steps and then release it to the Solaris world. Clearly
> I'll need a bit of help with the ada portion.

Thanks for the offer, but I fear I'll have to decline.  Apart from not
being able to accept more responsibilities (and not wanting to get into the
packaging business), I'd like to stay out of the Blastwave vs. OpenCSW
controversy and invest any spare time I might have directly in either the
GCC project (improving Solaris support in GCC) or the OpenSolaris community
(helping with the upcoming integration of GCC 4.3 into OpenSolaris).

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :


Joern Rennecke  writes:


Note that there is also code which is not written in a high level language
which uses gcc runtime library interfaces.  For example, look at
libgloss/m68k/crt0.S , which uses __do_global_dtors .
That the license of libgloss is GPL-compatible does not help here,
since we want to allow people to link programs containing   
non-GPL-compatible

code simultanously against libgloss and libgcc.


I don't see anything which prohibits them from doing so.


That would be the Berne Copyright convention.  I don't see anything
which allows them distributing the resulting binaries.


The license says that you have permission to propagate works when
certain conditions apply.  It does not say that you do not have
permission if certain other conditions apply.  Therefore, if certain
conditions apply, you have permission.  It is not necessary for the
license to say "oh, and if you stand on your head, you still have
permission.'


The permission is specific to a work of Target Code.  Assembly source files
are not Target Code, hence the permission does not apply.


The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc proprietary compiler.


No, it says that you can only do that if every file of the proprietary code
is written or generated in a high level language, and uses the GCC runtime.


The word "only" is your interpolation.  It does not appear in the
runtime license.


It is a necessary condition for all the conditions of the exception to
apply that all of the proprietary code is written or generated in a high
level language, and uses the GCC runtime.  Only the one exception is
granted.  Hence, "only" is not an interpolation, it is a corollary.

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> Quoting Ian Lance Taylor :
>> Code that is neither Target Code nor an Independent Module is code
>> that has never been involved with gcc, and the license does not cover
>> it.
>
> There is a lot of Target code that is, per definition, not an
> Independent Module because it does not use the GCC runtime library.

Yes.


>> The license does not prohibit combining Target Code or
>> Independent Modules with other code, so it is permitted.
>
> No, this is not how Copyright works.  In the absence of a license you may
> not distribute the resulting work.

By my reading, you do have permission.  It's right there in the
license.

You are arguing that the license must grant explicit permission for
combining with other code which is not covered in any way by the
license.  I don't see why that is required.  You already have
permission to do anything you like.

However, that said, I think it would be reasonable to ask the SFLC if
the definition of "Independent Module" could be clarified to make
clear that code which neither requires the runtime library, nor uses
an interface provided by the runtime library, is an independent
module.  I think that is the intent of the definition of "Independent
Module", but I agree that it is not clear from the wording.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

>> The license says that you have permission to propagate works when
>> certain conditions apply.  It does not say that you do not have
>> permission if certain other conditions apply.  Therefore, if certain
>> conditions apply, you have permission.  It is not necessary for the
>> license to say "oh, and if you stand on your head, you still have
>> permission.'
>
> The permission is specific to a work of Target Code.  Assembly source files
> are not Target Code, hence the permission does not apply.

But assembly source files, and the object code generated by the
assembler, are not covered by the license.  The license does not say
that you only have permission to link target code with independent
modules.  It says that if you link target code with independent
modules, you have permission to do anything you like with the result.

>
 The runtime library license says that you can link libgcc with
 proprietary code, whether that proprietary code was compiled with gcc
 or whether it was compiled with some non-gcc proprietary compiler.
>>>
>>> No, it says that you can only do that if every file of the proprietary code
>>> is written or generated in a high level language, and uses the GCC runtime.
>>
>> The word "only" is your interpolation.  It does not appear in the
>> runtime license.
>
> It is a necessary condition for all the conditions of the exception to
> apply that all of the proprietary code is written or generated in a high
> level language, and uses the GCC runtime.  Only the one exception is
> granted.  Hence, "only" is not an interpolation, it is a corollary.

Again, I disagree.  A grant of permission to do anything is a grant of
permission to do anything, including combining with other code that
was not compiled by gcc and does not use the gcc runtime library.  The
license only restricts code which is either compiled by gcc or uses
the runtime library.

Ian

Re: New GCC Runtime Library Exception

[Joern Rennecke]

> The difference is that the front end does not work on source code, but
> Java bytecode, which seems closer to intermediate representation than
> to a "high-level, non-intermediate language".

I think it is clear that Java bytecode, which can even be executed
directly by some microprocessors, is not a "compiler intermediate
representation."


That is beside the point.  It is not a high level language.  Hence,
when you use gcc to compile Java bytecode to Target Code, this is not
an eligible compilation process.

When you use a non-GPL-compatible java frontend to compile Java source to
bytecode and then use GCC to compile this to Target Code, it is not
an eligble compilation process either, because you used a non-GPL-compatible
frontend.


While perhaps some wording needs to be changed, the intent of the
license is stated clearly.  Paranoia on this point is not appropriate.


Yes, I would hope that the FSF agrees to change the wording to accomplish
the stated intent.
What kinds of compilation processes the license has to allow in order to
accomplish the stated goal is actual a to a large degree a technical matter,
so it is a bit disappointing that we are having this discussion so late
in the process.

Re: We should backport gcc 4.4 regression testcases to gcc 4.3 branch

[H.J. Lu]

On Mon, Jan 19, 2009 at 10:46 AM, Mark Mitchell  wrote:
> H.J. Lu wrote:
>
>> We can limit new testcases, which we backport to 4.3 branch, only
>> to those  4.4 regressions against 4.3 branch. They should always
>> pass on 4.3 branch by definition.
>
> There's nothing wrong with backporting testcases to an older release
> branch, but please make sure that they pass before committing them.
> Otherwise, we're creating noise.  Bear in mind that some tests require
> features that weren't available in older versions.
>

I will start backporting testcases of 4.4 regressions against 4.3 to 4.3 branch.


-- 
H.J.

Re: New GCC Runtime Library Exception: not fit for purpose

[Paolo Bonzini]

Joern Rennecke wrote:
> Quoting Ian Lance Taylor :
>> I'm not sure what your point is here.  newlib is not under the GPL in
>> any case.  It is not affected by the gcc runtime library license.
> 
> The old runtime library exception allowed you to distribute binaries that
> both include pieces of the gcc runtime and arbitrary pieces of newlib,
> without requiring the distribution to be under the terms of the GPL.
> I.e. your could link non-GPL code against both the gcc runtime and newlib
> and distribute it.
> The new license does not allow this unless all parts included from newlib
> are written in a high level language AND use the gcc runtime.

If they do not use the GCC runtime, why should those parts be affected
by the GCC runtime license?  If anything, the loophole in the exception
is that, if you rewrite libgcc, then you can use a non-eligible
compilation process and still distribute the result under a proprietary
license.

Paolo

Re: New GCC Runtime Library Exception

[Ian Lance Taylor]

Joern Rennecke  writes:

>> > The difference is that the front end does not work on source code, but
>> > Java bytecode, which seems closer to intermediate representation than
>> > to a "high-level, non-intermediate language".
>>
>> I think it is clear that Java bytecode, which can even be executed
>> directly by some microprocessors, is not a "compiler intermediate
>> representation."
>
> That is beside the point.  It is not a high level language.  Hence,
> when you use gcc to compile Java bytecode to Target Code, this is not
> an eligible compilation process.
>
> When you use a non-GPL-compatible java frontend to compile Java source to
> bytecode and then use GCC to compile this to Target Code, it is not
> an eligble compilation process either, because you used a non-GPL-compatible
> frontend.

I agree.  This seems like a case where the license should be
clarified.

Ian

Re: New GCC Runtime Library Exception

[Florian Weimer]

* Ian Lance Taylor:

> Florian Weimer  writes:
>
>> The difference is that the front end does not work on source code, but
>> Java bytecode, which seems closer to intermediate representation than
>> to a "high-level, non-intermediate language".
>
> I think it is clear that Java bytecode, which can even be executed
> directly by some microprocessors, is not a "compiler intermediate
> representation."

It is often used as some form of portable IR, to implement additional
functionality on the Java platform.

> I'm not super familiar with Java tools, but I think the rest of your
> argument hinges on that.

jc1 uses Java bytecode to produce GCC intermediate representation, so
Java bytecode is not Target Code according to the definition.

However, I don't think this matters for my argument, which is based on
the fact that a GCJ compilation uses the Eclipse Compiler for Java,
which is not under a GPLv3-compatible license, combined with GCC.
This compilation process does not qualify for the exception, AFAICT.

>> Other cases are rather unclear, too.  A hypothetical QPL-licensend
>> compiler which links against libgcc (Objective Caml apparently
>> doesn't) cannot produce an Eligible Compilation Process because it is
>> a work based on GCC (thanks to libgcc), and not everything is
>> GPL-licensed.  Interpreters capable of producing ELF binaries might
>> also be affected by a similar issue.
>
> Your argument here seems to be that linking against libgcc makes a
> program be covered by the definition of "GCC" in the runtime library
> license.

Right.  Why do you think this would not be the case?  libgcc is part
of GCC, so a program linking to libgcc is a derivative work of libgcc,
and therefore GCC.  That's precisely why we need an exception in the
first place because this outcome is not desired (a free operating
system could not distribute compiled binaries of C++ programs using
OpenSSL, for instance--in contrast to proprietary operating systems,
the system library exception cannot be used).

Creating imaginary inf/nan in GCC

[Kaveh R. GHAZI]

Hi,

I'm trying to create complex number expressions that contain inf or nan in
the imaginary part.  I.e. (0 + inf I) or (0 + nan I).

However when I write (_builtin_nan("") * 1.0i) I get (nan + nan I).  For
(__builtin_inf() * 1.0i) I get (nan + inf I).

I don't think these results are a bug, rather it's just an artifact of the
way complex multiplcation is done and having these special values in
there.  I had a similar problem getting negative zeros in the imaginary
part, but I solved that using conj(0.0) and conj(-0.0).  I don't think
conj helps for inf/nan though.

I know I can simply use a complex variable and set the real/imag parts
separately, but I want a constant expression which I can pass as an
argument to a builtin complex math function for writing testcases that
fold (or not) and compile-time.

Is there a way to get an imaginary inf or nan expression without having
the real part get changed?

Thanks,
--Kaveh
--
Kaveh R. Ghazi  gh...@caip.rutgers.edu

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :


Joern Rennecke  writes:

No, this is not how Copyright works.  In the absence of a license you may
not distribute the resulting work.


By my reading, you do have permission.  It's right there in the
license.

You are arguing that the license must grant explicit permission for
combining with other code which is not covered in any way by the
license.  I don't see why that is required.  You already have
permission to do anything you like.



Static linking is usually done in a single step, i.e. a derived work
is produced which incorporates pieces of the GCC runtime library,
Independent Modules, and other code.  You need a license of that,
which is not provided.

You seem to be saying that I could do incremental linking, first
linking libgcc against the Independent Modules, slapping my own
license on the partially linked work of Target Code (provided all
used pieces of libgcc are target code - that is hardly ever the
case, but lets just assume for the sake of the argument that you
have such a case).
Then a can link this partially linked work of Target Code against
anything I like.  This is quite tedious, since you now need to
identify all your Independent Modules first, and do a partial link.
Once you have motivated people to do that, it is only a simple
step (maybe even the simplest implementation of the aforesaid)
to exploit a loophole so big you can drive a truck through:
the source code is translated into Target Code that references
each used symbol that is needed by the Independent Modules.
All you need to have for that for that is a shell
or AWK script to massage nm output for which you could grant
a GPL license if you ever cared to distribute it.
Now you can incrementally link this dead piece of Target Code
with libgcc.  You can even put it into its special section so that
you can remove it later from the final link.
Now you are free to link this partially linked work of Target Code
against any kind of code - including Independent Modules compiled
with a non-eligible compilation process.


However, that said, I think it would be reasonable to ask the SFLC if
the definition of "Independent Module" could be clarified to make
clear that code which neither requires the runtime library, nor uses
an interface provided by the runtime library, is an independent
module.  I think that is the intent of the definition of "Independent
Module", but I agree that it is not clear from the wording.


Yes, that would be useful.
But we also have to address the issue of files which are neither written
nor generated in a high level language.

Re: New GCC Runtime Library Exception

[Ian Lance Taylor]

Florian Weimer  writes:

> * Ian Lance Taylor:
>
>> Florian Weimer  writes:
>>
>>> The difference is that the front end does not work on source code, but
>>> Java bytecode, which seems closer to intermediate representation than
>>> to a "high-level, non-intermediate language".
>>
>> I think it is clear that Java bytecode, which can even be executed
>> directly by some microprocessors, is not a "compiler intermediate
>> representation."
>
> It is often used as some form of portable IR, to implement additional
> functionality on the Java platform.

An IR is not the same as a "compiler intermediate representation."


>>> Other cases are rather unclear, too.  A hypothetical QPL-licensend
>>> compiler which links against libgcc (Objective Caml apparently
>>> doesn't) cannot produce an Eligible Compilation Process because it is
>>> a work based on GCC (thanks to libgcc), and not everything is
>>> GPL-licensed.  Interpreters capable of producing ELF binaries might
>>> also be affected by a similar issue.
>>
>> Your argument here seems to be that linking against libgcc makes a
>> program be covered by the definition of "GCC" in the runtime library
>> license.
>
> Right.  Why do you think this would not be the case?  libgcc is part
> of GCC, so a program linking to libgcc is a derivative work of libgcc,
> and therefore GCC.  That's precisely why we need an exception in the
> first place because this outcome is not desired (a free operating
> system could not distribute compiled binaries of C++ programs using
> OpenSSL, for instance--in contrast to proprietary operating systems,
> the system library exception cannot be used).

That is the cycle which the runtime library license is intended to
break, so now I'm just confused.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Paolo Bonzini :


Joern Rennecke wrote:

Quoting Ian Lance Taylor :

I'm not sure what your point is here.  newlib is not under the GPL in
any case.  It is not affected by the gcc runtime library license.


The old runtime library exception allowed you to distribute binaries that
both include pieces of the gcc runtime and arbitrary pieces of newlib,
without requiring the distribution to be under the terms of the GPL.
I.e. your could link non-GPL code against both the gcc runtime and newlib
and distribute it.
The new license does not allow this unless all parts included from newlib
are written in a high level language AND use the gcc runtime.


If they do not use the GCC runtime, why should those parts be affected
by the GCC runtime license?


It is not the parts of newlib that are affected, it is users that are
affected who want to link newlib which includes these parts - together
with libgcc and Independent Modules, and distribute the resulting
binaries under non-GPL terms.  They will no longer be allowed to do
this with when they are using a single link step, as they are creating
a derived work for which they have no license to distribute, except
possibly the GPL.

Re: sizeof in initializer expression not working as expected

[Paolo Bonzini]

Bruce Korb wrote:
> Hi,
> 
> I was trying to figure out how come a memory allocation was short.
> I think I've stumbled onto the issue.  "evt_t" is a 48 byte structure
> and "tpd_uptr" is a uintptr_t.  "sz" initializes to 52 (decimal).
> The value would be correct if I were not trying to multiply the
> size of the pointer by 4.  The result should be 64.

I think all you can do is the usual preprocessed testcase submission to
bugzilla.

Paolo

Re: Creating imaginary inf/nan in GCC

[Joseph S. Myers]

On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:

> I don't think these results are a bug, rather it's just an artifact of the
> way complex multiplcation is done and having these special values in

See bug 24581.  Some aspects are a bug (GCC doesn't handle mixed 
real/complex arithmetic the way it should), some are the lack of imaginary 
types (though the only use of imaginary types I know of is this one for 
building up constants, and no-one on the Power ABI working group could 
find any implementation for Power Architecture that actually supports 
imaginary types).

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

Re: Creating imaginary inf/nan in GCC

[Tobias Burnus]

Hi Kaveh,

Kaveh R. GHAZI wrote:
> I'm trying to create complex number expressions that contain inf or
> nan in the imaginary part.  I.e. (0 + inf I) or (0 + nan I).

If it does not need to be C (e.g. to try MPC in the middle end), you
could use Fortran:

! compile with gfortran -fno-range-check
complex :: z
z = cmplx(0.0, 0.0/0.0)
print *, z
end

Tobias

Re: New GCC Runtime Library Exception: not fit for purpose

[Manuel López-Ibáñez]

2009/1/29 Joern Rennecke :
> Quoting Paolo Bonzini :
>
>> Joern Rennecke wrote:
>>>
>>> Quoting Ian Lance Taylor :

 I'm not sure what your point is here.  newlib is not under the GPL in
 any case.  It is not affected by the gcc runtime library license.
>>>
>>> The old runtime library exception allowed you to distribute binaries that
>>> both include pieces of the gcc runtime and arbitrary pieces of newlib,
>>> without requiring the distribution to be under the terms of the GPL.
>>> I.e. your could link non-GPL code against both the gcc runtime and newlib
>>> and distribute it.
>>> The new license does not allow this unless all parts included from newlib
>>> are written in a high level language AND use the gcc runtime.

This doesn't make any sense to me. If a module X (including any part
of newlib) is not written in a high-level language, it doesn't need
compilation. So they are allowed to link GCC libraries. If it does not
link with GCC libraries, it is not affected by the GCC's GPL. What is
the case that I am missing?

> It is not the parts of newlib that are affected, it is users that are
> affected who want to link newlib which includes these parts - together
> with libgcc and Independent Modules, and distribute the resulting
> binaries under non-GPL terms.  They will no longer be allowed to do
> this with when they are using a single link step, as they are creating
> a derived work for which they have no license to distribute, except
> possibly the GPL.

It doesn't matter if you link incrementally or in a single step or
your code is ready for dynamic linking (the GPL does not differentiate
between static or dynamic linking for derived works), the only
important thing is what you end up propagating. If you propagate a
work that is not a derived work from GCC libraries, then it is not
covered by GCC's GPL and it doesn't need an exception. If it does,
then its "target code" must have been produced by a compiler that is
either GPL-compatible or does not use any GCC code. Anything that is
not "target code" is not covered by the license. What is unclear about
this?

Cheers,

Manuel.

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> You seem to be saying that I could do incremental linking, first
> linking libgcc against the Independent Modules, slapping my own
> license on the partially linked work of Target Code (provided all
> used pieces of libgcc are target code - that is hardly ever the
> case, but lets just assume for the sake of the argument that you
> have such a case).

The incremental linking argument is irrelevant.  Either it's OK
without that or it's not OK with that.


> Once you have motivated people to do that, it is only a simple
> step (maybe even the simplest implementation of the aforesaid)
> to exploit a loophole so big you can drive a truck through:
> the source code is translated into Target Code that references
> each used symbol that is needed by the Independent Modules.
> All you need to have for that for that is a shell
> or AWK script to massage nm output for which you could grant
> a GPL license if you ever cared to distribute it.
> Now you can incrementally link this dead piece of Target Code
> with libgcc.  You can even put it into its special section so that
> you can remove it later from the final link.
> Now you are free to link this partially linked work of Target Code
> against any kind of code - including Independent Modules compiled
> with a non-eligible compilation process.

The law is not a computer program.  Transparent dodges do not evade
the requirements of a license.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Manuel López-Ibáñez :


2009/1/29 Joern Rennecke :

Quoting Paolo Bonzini :


Joern Rennecke wrote:


Quoting Ian Lance Taylor :


I'm not sure what your point is here.  newlib is not under the GPL in
any case.  It is not affected by the gcc runtime library license.


The old runtime library exception allowed you to distribute binaries that
both include pieces of the gcc runtime and arbitrary pieces of newlib,
without requiring the distribution to be under the terms of the GPL.
I.e. your could link non-GPL code against both the gcc runtime and newlib
and distribute it.
The new license does not allow this unless all parts included from newlib
are written in a high level language AND use the gcc runtime.


This doesn't make any sense to me. If a module X (including any part
of newlib) is not written in a high-level language, it doesn't need
compilation. So they are allowed to link GCC libraries.


That does not follow.  There is no provision in the license to allow this.


If it does not
link with GCC libraries, it is not affected by the GCC's GPL. What is
the case that I am missing?


It is common to link code that requires both libgcc and newlib, where not
all used parts of newlib need libgcc.


It is not the parts of newlib that are affected, it is users that are
affected who want to link newlib which includes these parts - together
with libgcc and Independent Modules, and distribute the resulting
binaries under non-GPL terms.  They will no longer be allowed to do
this with when they are using a single link step, as they are creating
a derived work for which they have no license to distribute, except
possibly the GPL.


It doesn't matter if you link incrementally or in a single step or
your code is ready for dynamic linking (the GPL does not differentiate
between static or dynamic linking for derived works), the only
important thing is what you end up propagating.


Yes, but you could propagate the partially linked work.
Under terms that allow yourself to propagate derived works that incorporate
other code.

Re: New GCC Runtime Library Exception

[Chris Lattner]

On Jan 29, 2009, at 7:38 AM, Joern Rennecke wrote:

> The difference is that the front end does not work on source  
code, but
> Java bytecode, which seems closer to intermediate representation  
than

> to a "high-level, non-intermediate language".

I think it is clear that Java bytecode, which can even be executed
directly by some microprocessors, is not a "compiler intermediate
representation."


That is beside the point.  It is not a high level language.  Hence,
when you use gcc to compile Java bytecode to Target Code, this is not
an eligible compilation process.

When you use a non-GPL-compatible java frontend to compile Java  
source to

bytecode and then use GCC to compile this to Target Code, it is not
an eligble compilation process either, because you used a non-GPL- 
compatible

frontend.


This issue is also somewhat confusing to me.  It is a moot point,  
because LLVM is GPL compatible, but is LLVM .ll language considered a  
target code, intermediate representation, or a "high-level, non- 
intermediate language"?  It is not clear to me how LLVM .ll files are  
different from .c files that are used as intermediates between bison  
and a C compiler.


LLVM .ll files are a fully documented language and people write them  
by hand all the time.  It is quite arguably much higher level that  
machine code (having concepts like "call with arguments", a type  
system, etc), and is fully specified (http://llvm.org/docs/ 
LangRef.html).  It seems quite possible to argue that it is a "high- 
level, non-intermediate language" (at least at least as much as C is).


Is the wording intended to allow LLVM .ll files as "high-level, non- 
intermediate language", or are they considered an IR?  What is the  
dividing line?  It seems that this is a very important issue for the  
entire license.


-Chris

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :

The incremental linking argument is irrelevant.  Either it's OK
without that or it's not OK with that.


Well, if we disregard incremental linking, than the propagation
is clearly not allowed.
Combining the runtime Library with Independent Modules is certainly
more specific than combining the runtime Library with Independent Modules
and anything else you feel like.
Moreover, a typical link will contain Target Code which has not been
generated by Eligible Compilation Processes - including any object file
which has been assembled from assembly Source Code, like crt0.S or
strcmp.S, will disqualify the work for the exception.

Re: RFC: case insensitive for #include

[Chris Lattner]

On Jan 28, 2009, at 12:24 PM, H.J. Lu wrote:

On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner   
wrote:


On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:


Hi,

I got a request to try "FOO.H" if foo.h doesn't exist when dealing
with

#include "foo.h"

Any comments?


I strongly recommend against this, unless this is only a "last  
chance" fall

back.

From a performance standpoint, if you have -Idir1 -Idir2 -Idir3,  
you don't
want to stat all variants of "foo.h" in dir1 before moving on to  
dir2.  If
you do a full search for foo.h in all appropriate search paths, and  
then
redo it only on failure, then the performance issue goes away.   
However, in
that  case you get very difficult to explain behavior if you have  
multiple

files with spelling variants of foo.h in different search paths.



I won't stat all variants of "foo.h". I think scandir will work here  
and

this feature will be supported only if scandir is available.


HJ, this is a very performance sensitive part of the preprocessor.   
Just doing a scandir would be a huge cost.


-Chris

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> Combining the runtime Library with Independent Modules is certainly
> more specific than combining the runtime Library with Independent Modules
> and anything else you feel like.
> Moreover, a typical link will contain Target Code which has not been
> generated by Eligible Compilation Processes - including any object file
> which has been assembled from assembly Source Code, like crt0.S or
> strcmp.S, will disqualify the work for the exception.

We simply disagree on this point.  I won't repeat myself again.

Ian

Re: Request for testing/help for the LTO branch

[Rafael Espindola]

> Is it IO bound because the LTO files are abnormally large?  What kinds of
> file sizes are you seeing?

With the streamer debug enable we had over 40x the normal object size.
Without it, it looks to be 4 or 5 times if I remember correctly.

> -Chris

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :


Joern Rennecke  writes:


Combining the runtime Library with Independent Modules is certainly
more specific than combining the runtime Library with Independent Modules
and anything else you feel like.
Moreover, a typical link will contain Target Code which has not been
generated by Eligible Compilation Processes - including any object file
which has been assembled from assembly Source Code, like crt0.S or
strcmp.S, will disqualify the work for the exception.


We simply disagree on this point.  I won't repeat myself again.


So, assuming you may link in other stuff that is not an Independent
Module, that logically includes pieces derived from gcc itself if you
make sure that they either don't need the GCC runtime, or that they
incorporate pieces of it.  You'd only need to make sure that you
compile these with an Eligible Compilation Process.

So, you could mechanically change each gcc source file to incorporate
a bit of libgcc (using new function names so that it doesn't change
behaviour) thus rendering it not an Independent Module, bootstrap the
compiler, and convey the binary under terms of your choice.

I don't think that the FSF really intends such an interpretation.

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> So, assuming you may link in other stuff that is not an Independent
> Module, that logically includes pieces derived from gcc itself if you
> make sure that they either don't need the GCC runtime, or that they
> incorporate pieces of it.  You'd only need to make sure that you
> compile these with an Eligible Compilation Process.

No.  That would imply that the runtime library exception license
somehow releases you from all other licenses on the code, which is not
the case.  If your program is derived from code which is under the GPL
without the runtime library exception, you must obey the full GPL.

Ian

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :


Joern Rennecke  writes:


So, assuming you may link in other stuff that is not an Independent
Module, that logically includes pieces derived from gcc itself if you
make sure that they either don't need the GCC runtime, or that they
incorporate pieces of it.  You'd only need to make sure that you
compile these with an Eligible Compilation Process.


No.  That would imply that the runtime library exception license
somehow releases you from all other licenses on the code, which is not
the case.  If your program is derived from code which is under the GPL
without the runtime library exception, you must obey the full GPL.


But if code that is not an Independent Module may be added, and the  
conveying has to be consistent with the licensing of that code, what  
purpose does

the mentioning of Independent Modules in the Grant of Additional Permission
serve?  It seems you are saying that 'Independent Modules' could be read
as 'any other code you like' to give the same meaning, only more clearly.

Binary Autovectorization

[Rodrigo Dominguez]

Hi,

I am looking at binary auto-vectorization or taking a binary and rewriting
it to use SIMD instructions (either statically or dynamically). I was
wondering if anyone knew of similar work and could help me with some links.

Thank you,

Rodrigo Dominguez

Re: Binary Autovectorization

[Tim Prince]

Rodrigo Dominguez wrote:

> I am looking at binary auto-vectorization or taking a binary and rewriting
> it to use SIMD instructions (either statically or dynamically).
That's a tall order, considering how much source level dependency
information is needed.  I don't know whether proprietary binary
translation projects currently under way promise to add vectorization, or
just to translate SIMD vector code to new ISA.

Re: Binary Autovectorization

[Nathan Froyd]

On Thu, Jan 29, 2009 at 04:46:37PM -0500, Rodrigo Dominguez wrote:
> I am looking at binary auto-vectorization or taking a binary and rewriting
> it to use SIMD instructions (either statically or dynamically). I was
> wondering if anyone knew of similar work and could help me with some links.

Anshuman Dasgupta did some work at Rice University on binary
autovectorization of x86 binaries.  See:

  http://www.cs.rice.edu/~keith/pubs/LACSI02.pdf

His master's thesis might also be available online.

-Nathan

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> Quoting Ian Lance Taylor :
>
>> Joern Rennecke  writes:
>>
>>> So, assuming you may link in other stuff that is not an Independent
>>> Module, that logically includes pieces derived from gcc itself if you
>>> make sure that they either don't need the GCC runtime, or that they
>>> incorporate pieces of it.  You'd only need to make sure that you
>>> compile these with an Eligible Compilation Process.
>>
>> No.  That would imply that the runtime library exception license
>> somehow releases you from all other licenses on the code, which is not
>> the case.  If your program is derived from code which is under the GPL
>> without the runtime library exception, you must obey the full GPL.
>
> But if code that is not an Independent Module may be added, and the
> conveying has to be consistent with the licensing of that code, what
> purpose does
> the mentioning of Independent Modules in the Grant of Additional Permission
> serve?  It seems you are saying that 'Independent Modules' could be read
> as 'any other code you like' to give the same meaning, only more clearly.

Yes, I believe that "Independent Modules" is intended to mean "any
code."  However, it needs to be careful to not grant additional rights
to other parts of gcc itself.  And in any case the only code which it
can control is code which uses the runtime library--the runtime
library license can not say anything about code which does not use the
runtime library.  I expect that that is why it wound up being written
the way it was.

Ian

gcc-4.3-20090129 is now available

[gccadmin]

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

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

You'll find:

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

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

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

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

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

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

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

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

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

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

RE: Binary Autovectorization

[Rodrigo Dominguez]

Nathan,

Great! This is the kind of work I am interested in. Thank you.

Rodrigo

> -Original Message-
> From: Nathan Froyd [mailto:froy...@codesourcery.com]
> Sent: Thursday, January 29, 2009 5:04 PM
> To: Rodrigo Dominguez
> Cc: gcc@gcc.gnu.org
> Subject: Re: Binary Autovectorization
> 
> On Thu, Jan 29, 2009 at 04:46:37PM -0500, Rodrigo Dominguez wrote:
> > I am looking at binary auto-vectorization or taking a binary and
> rewriting
> > it to use SIMD instructions (either statically or dynamically). I was
> > wondering if anyone knew of similar work and could help me with some
> links.
> 
> Anshuman Dasgupta did some work at Rice University on binary
> autovectorization of x86 binaries.  See:
> 
>   http://www.cs.rice.edu/~keith/pubs/LACSI02.pdf
> 
> His master's thesis might also be available online.
> 
> -Nathan

Re: Request for testing/help for the LTO branch

[Chris Lattner]

On Jan 29, 2009, at 11:25 AM, Rafael Espindola wrote:

Is it IO bound because the LTO files are abnormally large?  What  
kinds of

file sizes are you seeing?


With the streamer debug enable we had over 40x the normal object size.
Without it, it looks to be 4 or 5 times if I remember correctly.


Thanks Rafael!

-Chris

Re: New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

Quoting Ian Lance Taylor :


Yes, I believe that "Independent Modules" is intended to mean "any
code."  However, it needs to be careful to not grant additional rights
to other parts of gcc itself.  And in any case the only code which it
can control is code which uses the runtime library--the runtime
library license can not say anything about code which does not use the
runtime library.  I expect that that is why it wound up being written
the way it was.


When you link together some object files which do not use libgcc  with
pats of libgcc, the result is still a derived work of libgcc, which can
only be distributed inasmuch as the FSF grants a license to do that.
So I don't see why you would make a distinction if the Target Code
uses any interface of libgcc or not - what matters is only if parts of
libgcc become part of the combined work.

TARGET_NARROW_VOLATILE_BITFIELD

[DJ Delorie]

The documentation doesn't match the implementation:

tm.texi:@deftypefn {Target Hook} bool TARGET_NARROW_VOLATILE_BITFIELDS (void)

target-def.h:#define TARGET_NARROW_VOLATILE_BITFIELD hook_bool_void_false
target-def.h:  TARGET_NARROW_VOLATILE_BITFIELD, \


Note the 'S' at the end in the docs.

Re: Serious code generation/optimisation bug (I think)

[Ross Smith]

Zoltán Kócsi wrote:

On Thu, 29 Jan 2009 08:53:10 +
Andrew Haley  wrote:


We're talking about gcc on ARM.  gcc on ARM uses 0 for the null
pointer constant, therefore a linker cannot place an object at
address zero. All the rest is irrelevant.


Um, the linker *must* place the vector table at address zero, because
the ARM, at least the ARM7TDMI fetches all exception vectors from
there. Dictated by the HW, not the compiler.


This sounds like a genuine bug in gcc, then. As far as I can see, Andrew 
is right -- if the ARM hardware requires a legitimate object to be 
placed at address zero, then a standard C compiler has to use some other 
value for the null pointer.


-- Ross Smith