On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>
>> Well, it looks like I do need something like @F because I now only get
>> the define on files in gcc/. Any file with a / in the full name $@
>> does not get a file specific CFLAGS.
>
> Inte
On 05/26/2010 09:25 AM, Joern Rennecke wrote:
What we can't do under this scheme is retroactively re-use code
as documentation or vice versa; we'd need the appropriate license
grant from the FSF for each bit of code/documentation that we want
to re-use in that manner.
Does it help that large pa
On 05/27/2010 06:58 AM, Steven Bosscher wrote:
Well, it looks like I do need something like @F because I now only get
the define on files in gcc/. Any file with a / in the full name $@
does not get a file specific CFLAGS.
Interesting, this simpler testcase worked:
test-a/b = $(warning ok)
all
On Tue, 2010-05-25 at 17:44 -0700, Mark Mitchell wrote:
>
> Therefore, if I don't have an update "soon" (within a week or two), I'd
> suggest that we operate under the assumption that it will not be
> possible to combine GFDL manuals and GPL code in the near future.
Thanks for the feedback.
How
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
>> Steven Bosscher writes:
>>
>>> So I guess this plan of mine is not going to work...
>>> Other ideas?
>>
>> Add $(CFLAGS-$(@F)) to the .c.o rule
>
> Actually $@ is fine, since you want
Mark Mitchell writes:
> Basile Starynkevitch wrote:
>> Does that mean that even if a MELT plugin package appears in Debian, it
>> could not contain any documentation?
> I thought Debian didn't like the GFDL at all. But, in any case, that's
> really a question for the Debian folks; I don't have
Steven Bosscher writes:
> OK, the patch at the end of this mail appears to do what I've been
> trying to achieve.
> Does it look correct, and acceptable for the trunk after proper testing?
I'll approve the patch to system.h if testing succeeds. The patch to
Makefile.in looks fine to me but I'd
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote:
>> Steven Bosscher writes:
>>
>>> So I guess this plan of mine is not going to work...
>>> Other ideas?
>>
>> Add $(CFLAGS-$(@F)) to the .c.o rule
>
> Actually $@ is fine, since you want
> Date: Tue, 25 May 2010 17:44:32 -0700
> From: Mark Mitchell
> In a biweekly call with the other GCC Release Managers, I was asked
> today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
> particular, the question of whether or not we can use "literate
> programming" techniques
I suggest you raise this with lice...@gnu.org.
Steven Bosscher wrote:
> Would it help to include in this "more information" to emphasize that
> the issue is especially urgent for internals documentation?
I think I've expressed that reasonably well, with help from Jason Merill
and Toon Moene. I gave examples involving both the internals manu
On Wed, May 26, 2010 at 11:22 PM, Mark Mitchell wrote:
> Joern Rennecke wrote:
>
>> Well, then we were still kind of hoping the FSF would come up with a
>> useful policy that allows using copyrightable elements from the code
>> to be used in its documentation, and vice versa.
>> However, now it do
Matthias Klose wrote:
> there is another issue with the manual pages.
> It would be nice to know if the files used to generate the manual
> pages (gcc/doc/invoke.texi, gcc/fortran/gfortran.texi,
> gcc/java/gcj.texi) could be dual-licensed as well, so that is possible
> to provide basic documentat
On Wed, 26 May 2010, Matthias Klose wrote:
> there is another issue with the manual pages. Debian considers GFDL licensed
> files with invariant sections and/or cover texts as non-free. You may agree
> or disagree with this, but the outcome is that Debian has to ship the gcc
> documentation and
Quoting Mark Mitchell :
I don't understand the full situation with MELT. But, you cannot
combine GPL'd and GFDL's stuff, so I don't think you can auto-generate
GFDL documentation from GPL'd code on the MELT branch.
I don't see a problem if the auto-generated GFDL documentation is
identical to
On Wed, 26 May 2010, Basile Starynkevitch wrote:
> why any "policy" defined for GTK would not be ok for GCC? Or are not all
> GNU projects equal? Is GTK less important to the FSF than GCC? Or maybe
Not all GNU projects assign their code to the FSF, and if they don't
assign their code to the FSF
Joern Rennecke wrote:
> Well, then we were still kind of hoping the FSF would come up with a
> useful policy that allows using copyrightable elements from the code
> to be used in its documentation, and vice versa.
> However, now it doesn't look like that such a policy is forthcoming in
> a timefr
Quoting Basile Starynkevitch :
On Wed, 2010-05-26 at 11:19 -0700, Mark Mitchell wrote:
As for practical advice regarding getting quicker decisions from the FSF
on licensing issues, I have none. I've worked on several such issues
with the FSF over the years, and they've all been lengthy proces
> Could you please help me with some code in
> ada/gcc-interface/decl.c::gnat_to_gnu_entity:
>
> /* For a debug renaming declaration, build a pure debug entity. */
> if (Present (Debug_Renaming_Link (gnat_entity)))
> {
> rtx addr;
> gnu_decl = buil
On 26.05.2010 02:44, Mark Mitchell wrote:
In a biweekly call with the other GCC Release Managers, I was asked
today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
particular, the question of whether or not we can use "literate
programming" techniques to extract documentation fro
Basile Starynkevitch wrote:
>> The best way to work
>> with the FSF on license issues is always to explain how whatever request
>> you are making furthers the FSF's goals.
> [not being a native english speaker, I had lots of trouble understanding
> the last sentence above; apparently, according t
On Wed, 2010-05-26 at 11:19 -0700, Mark Mitchell wrote:
>
> As for practical advice regarding getting quicker decisions from the FSF
> on licensing issues, I have none. I've worked on several such issues
> with the FSF over the years, and they've all been lengthy processes. If
> I knew how to do
On Wed, May 26, 2010 at 08:09:57PM +0200, Ulrich Weigand wrote:
> Mike Meissner wrote:
> > On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> > > Ulrich Weigand wrote:
> > >
> > > >> So the question is: The goal is to have hooks, not macros, right? If
> > > >> so, can reviewers pleas
Quoting Basile Starynkevitch :
So what should I do concretely? What is the current status of the pdf
file generated inside GCC MELT, an old version of which is on
http://gcc.gnu.org/wiki/MELT%
20tutorial?action=AttachFile&do=view&target=GCC-MELT--gcc-internals-snapshot.pdf
Is it completely illeg
Ulrich Weigand wrote:
> * c-common.h (c_register_addr_space): Add prototype.
> (ADDR_SPACE_KEYWORD): Remove.
> * c-common.c (c_register_addr_space): New function.
> (c_addr_space_name): Reimplement.
> (c_common_reswords): Do not include TARGET_ADDR_SPACE_KEYWORDS.
>
Basile Starynkevitch wrote:
> Does the FSF want anything about GCC? AFAIK, the plugin exception to the
> runtime license was not wanted by the FSF. It was only wanted by the GCC
> community (and probably the FSF was reluctant to any changes).
I don't speak for the FSF. I don't know what the FSF
> Does the FSF want anything about GCC? AFAIK, the plugin exception to the
> runtime license was not wanted by the FSF. It was only wanted by the GCC
> community (and probably the FSF was reluctant to any changes).
For good reason. Check out the mess that results from allowing plugins
in the Ast
Mike Meissner wrote:
> On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> > Ulrich Weigand wrote:
> >
> > >> So the question is: The goal is to have hooks, not macros, right? If
> > >> so, can reviewers please take care to reject patches that introduce
> > >> new macros?
> > >
> > >
Basile Starynkevitch wrote:
> My dream [I'm not sure it can happen] would be that some GCC steering
> committee member would just say here to me that dual-licensing such and
> such files is permitted and would solve any issue. If I had such a
> informal "blessing" I would be ok.
The SC cannot do
On Wed, 2010-05-26 at 08:56 -0700, Mark Mitchell wrote:
>
> In the context of FSF GCC, there is both a legal question and a policy
> question; even if we can do it legally, is that what the FSF wants?
Does the FSF want anything about GCC? AFAIK, the plugin exception to the
runtime license was not
On Wed, 2010-05-26 at 11:36 -0400, Frank Ch. Eigler wrote:
> Basile Starynkevitch writes:
>
> > [...]
> > So what should I do?
> > [...]
> > c. change the licenses of the melt*texi files [I certainly won't do that
> > without explicit approval] to something compatible. Perhaps the fact
> > that I
On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> Ulrich Weigand wrote:
>
> >> So the question is: The goal is to have hooks, not macros, right? If
> >> so, can reviewers please take care to reject patches that introduce
> >> new macros?
> >
> > I don't know to which extent this is
Ulrich Weigand wrote:
>> So the question is: The goal is to have hooks, not macros, right? If
>> so, can reviewers please take care to reject patches that introduce
>> new macros?
>
> I don't know to which extent this is a formal goal these days, but I
> personally agree that it would be nice to
On Wed, May 26, 2010 at 8:42 AM, Xinliang David Li wrote:
> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
> wrote:
>> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
>>> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
>>> wrote:
On Fri, May 21, 2010 at 2:24 AM, Richar
Steven Bosscher wrote:
> So the question is: The goal is to have hooks, not macros, right? If
> so, can reviewers please take care to reject patches that introduce
> new macros?
I don't know to which extent this is a formal goal these days, but I
personally agree that it would be nice to eliminat
On Wed, May 26, 2010 at 6:08 PM, Eric Botcazou wrote:
>> You could "fix" this by walking all functions and check if only
>> one real language personality routine remains and promote
>> the generic C personality uses to that. Of course you need then
>> to be able to identify the C personality whic
> You could "fix" this by walking all functions and check if only
> one real language personality routine remains and promote
> the generic C personality uses to that. Of course you need then
> to be able to identify the C personality which you can't (well,
> you could by name).
Can't we simply r
On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei wrote:
> Hi, Richard,
> With resolution file generated by GOLD (or I am going to hack gnu LD), is
> externally_visible attribute still needed to annotate those symbols accessed
> from non-LTO objects when compiling with -fwhole-program.
Yes it is. W
On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li wrote:
> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
> wrote:
>> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
>>> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
>>> wrote:
On Fri, May 21, 2010 at 2:24 AM, Richar
Quoting "Frank Ch. Eigler" :
Basile Starynkevitch writes:
[...]
So what should I do?
[...]
c. change the licenses of the melt*texi files [I certainly won't do that
without explicit approval] to something compatible. Perhaps the fact
that I am the only contributor to these files might help.
On Wed, May 26, 2010 at 5:38 PM, Eric Botcazou wrote:
>> When I run the test suite with Ada, I have two test suite failures,
>> for lto6.adb and lto8.adb. The failure mode is the same for both, see
>> end of this mail. Are these failures expected?
>
> That's an LTO bug: it can change the personali
Frank Ch. Eigler wrote:
>> c. change the licenses of the melt*texi files [I certainly won't do that
>> without explicit approval] to something compatible. Perhaps the fact
>> that I am the only contributor to these files might help.
>
> Would dual-licensing the .texi files (GFDL + GPL3) solve the
Hi, Richard,
With resolution file generated by GOLD (or I am going to hack gnu LD), is
externally_visible attribute still needed to annotate those symbols accessed
from non-LTO objects when compiling with -fwhole-program.
In theory, it shouldn't be needed since LTO has all information. But what
On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
wrote:
> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
>> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
>> wrote:
>>>
>>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>>> wrote:
>>> > On Thu, May 20, 2010 at 11:21 PM, Xinli
> When I run the test suite with Ada, I have two test suite failures,
> for lto6.adb and lto8.adb. The failure mode is the same for both, see
> end of this mail. Are these failures expected?
That's an LTO bug: it can change the personality routine without any real
reasons. You don't need several
Basile Starynkevitch writes:
> [...]
> So what should I do?
> [...]
> c. change the licenses of the melt*texi files [I certainly won't do that
> without explicit approval] to something compatible. Perhaps the fact
> that I am the only contributor to these files might help.
Would dual-licensing
On 5/21/10 9:06 PM, Vladimir N. Makarov wrote:
On 05/17/2010 02:44 AM, Maxim Kuvyrkov wrote:
...
If your favorite benchmark significantly under-performs on Core 2 or
Core i7 CPUs, don't hesitate asking us to take a look at it.
What I saw is people complaining about -mtune=core2 for polyhedron
On Wed, May 26, 2010 at 4:27 PM, roy rosen wrote:
> Hi,
>
> I have tried vectorization and encountered a problem which I can see
> is common to some ports (I tried ia64 and bfin).
>
> For this function:
>
> #define ts unsigned short
> void f(ts* __restrict__ a, ts* __restrict__ b, ts* __restrict__
Hi,
I have tried vectorization and encountered a problem which I can see
is common to some ports (I tried ia64 and bfin).
For this function:
#define ts unsigned short
void f(ts* __restrict__ a, ts* __restrict__ b, ts* __restrict__ x)
{
int i;
for (i=0;i<1024;i++)
x[i] = a[i] + b[
So the fix below is not a fix but papering over an
issue elswhere.
Ok, this problem nearly killed me. It took months of
effort to try to isolate the fault, delving into unfamiliar code,
trying to get something that could be reliably reproduced.
I did finally succeed in getting an executable th
Steven Bosscher writes:
> Hi,
>
> When I run the test suite with Ada, I have two test suite failures,
> for lto6.adb and lto8.adb. The failure mode is the same for both, see
> end of this mail. Are these failures expected? This is on Debian Lenny
> x86_64.
See PR middle-end/44230 and this thread
On Wed, 2010-05-26 at 12:57 +0200, Basile Starynkevitch wrote:
> On Wed, 2010-05-26 at 11:37 +0200, Wolfgang wrote:
> > Hallo,
> >
> > i built gcc-melt sucessfully with a new gcc-4.5 compiler from scratch.
>
> As far as I understand, a recent MELT can be built with another C
> compiler than gcc-4
Hi,
When I run the test suite with Ada, I have two test suite failures,
for lto6.adb and lto8.adb. The failure mode is the same for both, see
end of this mail. Are these failures expected? This is on Debian Lenny
x86_64.
Ciao!
Steven
In file included from :44:0:^M
/home/stevenb/devel/trunk/gcc/
Hello Eric,
Could you please help me with some code in
ada/gcc-interface/decl.c::gnat_to_gnu_entity:
/* For a debug renaming declaration, build a pure debug entity. */
if (Present (Debug_Renaming_Link (gnat_entity)))
{
rtx addr;
gnu_decl = build_
On Wed, 2010-05-26 at 11:37 +0200, Wolfgang wrote:
> Hallo,
>
> i built gcc-melt sucessfully with a new gcc-4.5 compiler from scratch.
As far as I understand, a recent MELT can be built with another C
compiler than gcc-4.5.
Thanks for your feedback.
[my guess is that you have been hit by a bug
Hello,
Just yesterday alone, I found two target *macros* introduced in 2008/2009:
TARGET_ENUM_VA_LIST, introduced by:
2008-07-06 Kai Tietz
* config/i386/i386.h (TARGET_ENUM_VA_LIST): New.
* doc/tm.texi (TARGET_FN_ABI_VA_LIST): New.
(TARGET_CANONICAL_VA_LIST_TYPE): New
On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li
> wrote:
>>
>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>> wrote:
>> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
>> > wrote:
>> >> On Thu, May 20, 2010 at 2:18 PM,
Hallo,
i built gcc-melt sucessfully with a new gcc-4.5 compiler from scratch.
The svn of melt is:
URL: svn://gcc.gnu.org/svn/gcc/branches/melt-branch
Basis des Projektarchivs: svn://gcc.gnu.org/svn/gcc
UUID des Projektarchivs: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 159823
Knotentyp: Verze
Steven Bosscher writes:
> +ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
> + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
You still need the backslash.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something complete
2010/4/13 Dave Korn :
> Until I find time to do a more major rewrite, anyone who wants to do testing
> on Cygwin could do worse than apply the sticking-plaster patch that I posted
> at:
>
> http://www.mail-archive.com/cygwin-patc...@cygwin.com/msg04677.html
>
> and build themselves a locally mod
> Remainders, in reverse chronological order:
Thanks Ralf. I'm CCing the people.
Paolo
> 2010-05-05 Sebastian Pop
>
> * configure.ac: Allow all the versions greater than 0.10 of PPL.
> * configure: Regenerated.
>
>
> 2010-04-16 Rainer Orth
>
> * configure.ac: Check for el
Quoting Mark Mitchell :
Therefore, if I don't have an update "soon" (within a week or two), I'd
suggest that we operate under the assumption that it will not be
possible to combine GFDL manuals and GPL code in the near future.
We still can, to some degree, as long as we make sure that the
sour
62 matches
Mail list logo
