Re: Help needed: banishing RTL from the front ends

[Steven Bosscher]

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.
>
> Interesting, this simpler testcase worked:
>
> test-a/b = $(warning ok)
>
> all: a/b
>        : $(test-$<) above line from '$$(test-$$<)' should say ok
> a/b:
>        : $(test-$@) above line from '$$(test-$$@)' should say ok
>
> Can you add $(warning $@ -> $(CFLAGS-$@)) to the .c.o rule to see if that
> gives a clue?

Well, gives me at least one clue so far: the implicit rule .c.o is
over-ruled by t-i386, which explains why the extra CFLAGS-$file are
not passed to config/i386/i386-c.c.  I'm now restarting the build with
extra front ends included again, to see if there is something equally
obvious "wrong" there.

Ciao!
Steven

Re: GFDL/GPL issues

[Paolo Bonzini]

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 parts of the internals manual were copied into 
config/*/*.h files pre-GFDL?  Certainly it would reduce the number of 
people that will have to be contacted to relicense under the GPL their 
contribution to the internals manual.


Paolo

Re: Help needed: banishing RTL from the front ends

[Paolo Bonzini]

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: a/b
: $(test-$<) above line from '$$(test-$$<)' should say ok
a/b:
: $(test-$@) above line from '$$(test-$$@)' should say ok

Can you add $(warning $@ -> $(CFLAGS-$@)) to the .c.o rule to see if 
that gives a clue?


Paolo

Re: GFDL/GPL issues

[Basile Starynkevitch]

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.

However, could you (or some other well informed person) elaborate on
that incompatibility. What exactly is incompatible? Is it some paragraph
of GPLv3 versus another paragraph of GFDL1.2 - which ones? Or why is it
incompatible?

My feeling is that the main thing affected is perhaps the right to
redistribute a modification of such generated documentation. But very
sincerely, I don't understand the issue, except that the generated
documentation will be both GPL & GFDL licensed.

Apparently, it should be either specific to GPL (not to LGPL), to GFDL,
or should be an *interpretation* of the FSF. (A contrario, GTK headers
do contain comments which produce documentation, and these GTK headers
seems to be stricto LGPLv2+. At least, file  only
mentions LGPLv2 and does not mention any exception and that same file is
used to generate the
http://library.gnome.org/devel/gtk/2.21/GtkWidget.html page).

Assuming it won't be solved in a few weeks, do you imagine that it could
be solved by : a change of the GPL (so we have to wait for an
hypothetical GPLv4), a change of the GCC runtime license, something
else?

This matters practically for timescale reasons. Waiting for GPLv4 means
waiting probably nearly twenty years (and by that time, GCC will
probably cease to be relevant, and perhaps even to be actively be
developed). Waiting for a change of the GCC runtime might mean waiting
for 2 or 4 years.

Cheers.
-- 
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 mines, sont seulement les miennes} ***

Re: Help needed: banishing RTL from the front ends

[Steven Bosscher]

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 cp/tree.o to have different flags
> from tree.o.

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.


>> and define CFLAGS-foo for each foo
>> in $(ALL_HOST_FRONTEND_OBJS).  Though the latter is a bit tricky if you
>> want to do it automatically.
>
> That would be something like
>
> $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += ...))

Same here.

Maybe I should sed away the slashes? Or is there a better way?

Ciao!
Steven

Re: GFDL/GPL issues

[Russ Allbery]

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 any involvement in
> Debian.

This is not the place to discuss this in any further detail, obviously,
but just to clarify for those watching this part of the discussion: Debian
is not horribly happy with the GFDL, but does consider it to be a free
license provided that there are no Front Cover or Back Cover texts and no
Invariant Sections.  Debian judges all licenses for all material by the
same DFSG standards as software licenses and considers the presence of
texts covered by those three provisions of the GFDL to be unmodifiable
sections, hence non-free, and not permitted in the Debian distribution.
But as long as that aspect of the license is not used, the GFDL is a
DFSG-free license.

Provided that the software does not conflict with the terms of the GPL or
GFDL by combining things with conflicting terms in such a way as to make
them unredistributable (and dual-licensing would resolve that, obviously),
I don't believe Debian would have a problem with the situation that you
describe.

-- 
Russ Allbery (r...@stanford.edu) 

Re: Help needed: banishing RTL from the front ends

[Ian Lance Taylor]

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 rather that a build system
maintainer take a look also.

Thanks.

Ian

Re: Help needed: banishing RTL from the front ends

[Steven Bosscher]

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 cp/tree.o to have different flags
> from tree.o.
>
>> and define CFLAGS-foo for each foo
>> in $(ALL_HOST_FRONTEND_OBJS).  Though the latter is a bit tricky if you
>> want to do it automatically.
>
> That would be something like
>
> $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += ...))
>
> (All on one line, no spaces after commas!)

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?

Ciao!
Steven


Index: Makefile.in
===
--- Makefile.in (revision 159900)
+++ Makefile.in (working copy)
@@ -1048,7 +1048,7 @@
   $(PPLINC) $(CLOOGINC) $(LIBELFINC)

 .c.o:
-   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION)
+   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(CFLAGS-$@)
$(ALL_CPPFLAGS) $< $(OUTPUT_OPTION)

 #
 # Support for additional languages (other than C).
@@ -1445,15 +1445,26 @@

 OBJS-onestep = libbackend.o $(OBJS-archive)

-# This lists all host object files, whether they are included in this
-# compilation or not.
-ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \
+# This lists all host objects for the front ends.
+ALL_HOST_FRONTEND_OBJS = $(C_OBJS) \
+  $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
+
+# Signal that these files are front-end objects.  This causes extra symbols
+# to be poisoned: Things no front end should ever look at, like RTL.
+$(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) +=
-DIN_GCC_FRONTEND))
+
+# FIXME: c-common.c still includes expr.h
+CFLAGS-c-common.o =
+
+ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) libbackend.o \
   @TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \
-  $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \
-  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
-  mips-tfile.o mips-tdump.o \
+  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) mips-tfile.o mips-tdump.o \
   $(GCOV_OBJS) $(GCOV_DUMP_OBJS)

+# This lists all host object files, whether they are included in this
+# compilation or not.
+ALL_HOST_OBJS = $(ALL_HOST_FRONTEND_OBJS) $(ALL_HOST_BACKEND_OBJS)
+
 BACKEND = main.o @TREEBROWSER@ libbackend.a $(CPPLIB) $(LIBDECNUMBER)

 MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \
Index: system.h
===
--- system.h(revision 159900)
+++ system.h(working copy)
@@ -789,6 +789,10 @@
   VA_FIXEDARG VA_CLOSE VA_START
 #endif /* IN_GCC */

+#if defined(IN_GCC_FRONTEND)
+#pragma GCC poison GCC_RTL_H
+#endif
+
 /* Note: not all uses of the `index' token (e.g. variable names and
structure members) have been eliminated.  */
 #undef bcopy

Re: GFDL/GPL issues

[Hans-Peter Nilsson]

> 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 to extract documentation from code and take bits
> of what is currently in GCC manuals and put that into comments in code
> and so forth and so on.

FWIW, there's some hope, as licens...@gnu.org recommended
solving the similar issue regarding doxygenerated documentation
for a (to-be-released) non-FSF LGPLv3 w/GFDL docs library, by
dual-licensing the comments and mentioning the dual-licensing in
the licensing info.  Right, preaching is not the same as
practicing, but still.

brgds, H-P

Re: GFDL/GPL issues

[Alfred M. Szmidt]

I suggest you raise this with lice...@gnu.org.

Re: GFDL/GPL issues

[Mark Mitchell]

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 manuals
(e.g., target hooks) and the user manual (e.g., command-line options).

I've not raised any of the Debian issues with RMS and don't intend to do
so; I will not convince the FSF by making this into an argument about
whether the GFDL is a good license.  I'm trying to focus on use of the
GPL'd code in GFDL manuals and vice versa, particularly in the context
of GCC's manuals, as a way of reducing developer effort and improving
the documentation.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Steven Bosscher]

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 doesn't look like that such a policy is forthcoming in
>> a timeframe relevant to current GCC development.
>
> I did get a response from RMS today, within about 24 hours of the mail I
> sent him yesterday.  But, the response was a request for more
> information, not a commitment to doing anything.

Still good news.

Would it help to include in this "more information" to emphasize that
the issue is especially urgent for internals documentation?  IMHO the
problems Debian has with GFDL are important too, but for the FSF I
think the "internals documentation" argument carries more weight.

Ciao!
Steven

Re: GFDL/GPL issues

[Mark Mitchell]

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 documentation in Debian as well.

I could ask that question, but I don't know how to do so in a way that
is likely to get the desired answer.  The FSF considers the GFDL
meritorious, and, as far as I can tell, doesn't care whether that
inconveniences Debian.  So, I don't know how to make the argument that
this change helps the FSF.

I've argued that allowing GFDL documentation to be extracted from GPL'd
code, and allowing the current GFDL text in the manuals to be placed
into comments in GPL'd code, is a win in that it reduces developer
effort and improves the quality of the product -- but I can't argue that
this is true for the manual pages.

But, if we could get the documentation for command-line options into
GPL'd code in a structured way, then I think you could probably generate
 GPL'd manual pages from that.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Joseph S. Myers]

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 the manual pages in its non-free section.  The issue was
> raised with the FSF some years ago, but issues with the GFDL seem to be low
> priority within the FSF (Mako may correct me).  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 documentation in Debian as well.

Just as Joern has worked on putting target hook information in one place, 
if we can get suitable permission from the FSF it should allow putting the 
Texinfo descriptions of individual options in the GPL (plus whatever GFDL 
permission wording the FSF approves) .opt files (which I think would be 
good for similar reasons - making it more likely that people write and 
update the documentation).  This is not all the documentation that goes in 
the manpages, but a large proportion of it.  I would hope that the 
permission will not require us to go back to the FSF for each individual 
case where we wish to do something like that.

I have no plans to work on that, but do intend to make it so that all the 
options are actually in the .opt files in the first place - at present 
options that are purely handled by the gcc.c driver do not appear there 
(and many such options are undocumented).

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

Re: GFDL/GPL issues

[Joern Rennecke]

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 documentation that has been previously released under the GFDL.
Or if the only portions not covered by the above are generated from content
for which the user of the autogeneration machinery has full authorship
rights.


You could
generate GPL'd documentation, though.


But then it must not rely on GFDL files; the GCC documentation generally
uses some texinfo infrastructure.

Re: GFDL/GPL issues

[Joseph S. Myers]

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 then the question is what permissions the 
copyright holders of the code grant and what wording they permit to be 
used in license notices (subject of course to the FSF not accepting e.g. 
non-free licenses for anything in GNU projects).  Of course, if a project 
does not have copyright assignments and wishes to start using existing GPL 
code in GFDL manuals, or vice versa, they may then need to get permission 
for this from many different copyright holders, which could be at least as 
hard as getting permission from the FSF.

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

Re: GFDL/GPL issues

[Mark Mitchell]

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 timeframe relevant to current GCC development.

I did get a response from RMS today, within about 24 hours of the mail I
sent him yesterday.  But, the response was a request for more
information, not a commitment to doing anything.

> I'm also at a loss why the GNU package maintainers

...

> cannot authorize to put pieces of GPLed code/documentation under the GFDL,
> or pieces of GFDLed code under the GPL, as long this is done in order to
> pursue the goals set out in the above documents.

AFAIK, as a GNU maintainer, I don't have the right to bind the FSF in
any legal manner.  I don't think I have the right to dual-license GPL'd
code under the GFDL any more than I have the right to license it under
the BSD license or the CodeSourcery Super-Sekrit Proprietary License o'
Doom.

Allowing dual-license of GPL'd code under GFDL might further the
interests of the FSF (and, in fact, I've argued to RMS that at least in
the context of GCC it would do so), but I don't think any of us have the
right to do that without the FSF's permission.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Joern Rennecke]

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 processes.  If
I knew how to do it faster, I certainly would.  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 to my Robert&Collins
english<->french dictionnary applied twice, "to further" means "to
favour" in that context; is that understanding the right one?].


To a first order of approximation.  Pedantically speaking, you could be said
to favour the goals of the FSF over the goals of some other organization if
do less damage to the  goals of the FSF than to that of that other
organization.  OTOH 'further' in the context above does not allow such
a nefarious interpretation, it means that you are actually helping to
archieve/promote the goals of the FSF.


First, I have no idea of who the FSF really means (except RMS). Who
should I contact by email? What should I tell? What do I risk? What are
the *technical* background I can assume? Do FSF people know what coding
is about? (RMS certainly does, but is he most of FSF?).


There is some information on the fsf.org site.  You could also try
that question on gnu.misc.discuss .


Second, I believe I tried hard to explain what MELT is doing w.r.t.
documentation in an email (dated May 07th)
http://gcc.gnu.org/ml/gcc/2010-05/msg00125.html to which *nobody*
responded. Or was gcc@ the wrong list to ask?

Are there any reason for which I should expect more attention now? I
don't understand why a question nobody cared about on May 7th should
become interesting on May 27th of the same year (2010).


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 timeframe relevant to current GCC development.


And all this is not really MELT related, and perhaps even not even GCC
related. Several GNU projects (notably GTK) generates documentation from
code. Not understanding at all any internal (& personal) factors from my
far continent (I am European, and I am not a lawyer!), I cannot imagine
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
GTK is not an FSF project, (this implying that GNU software is not FSF
software)? Or are there still no FSF copyrighted software generating
some small documentation from code! (we are in 2010, and it is common
practice; I could imagine that bash or binutils have similar issues.).
And for GTK at least, the header files only mention LGPL license, and
apparently not any additional exception related to documentation...


I'm also at a loss why the GNU package maintainers, who are charged with
selecting which contributions to accept or reject, making sure each
relevant file has a license notice and that the program is properly documented
(http://www.gnu.org/prep/maintain/maintain.html,
 http://www.gnu.org/prep/standards/standards.html),
cannot authorize to put pieces of GPLed code/documentation under the GFDL,
or pieces of GFDLed code under the GPL, as long this is done in order to
pursue the goals set out in the above documents.


And there is one even more basic thing I don't understand. Why are GFDL
& GPL incompatible?


That one is easy.  The GPL, unlike the  GFDL, has a concept of source code,
which is relevant for the operation of the license.
I.e. I can auto-generate GFDL documentation from differently licensed source,
and distribute the result under the GFDL, and am free to mix it with other
GFDL documentation.  The same is not true for GPLed code.
The GPL does only grant redistribution rights under the GPL.  Since the
GFDL does not have a source code concept, it is not the GPL, so redistribution
rights under the GFDL are not granted by the GPL.
Likewise, the GFDL only grants redistribution rights under
'precisely this License', thus no redistribution rights under the GPL
are granted.


Also, some official GCC documentation contains substantial chunks of
code (e.g. plugins.texi). Does that mere fact legally invalidate
something?


Ask a lawyer.  Or maybe more than one... the answer probably varies
with the jurisdiction.
Prima facie, it is unsafe to use any GFDLed documentation to write
GPLed code; see PR other/44032.


In practice, should I have to erase all the :doc annotations in MELT
source code?


I don't see how the annotations would be a problem; the problem only
arises when you have auto-generating scripts that use these annotations
and trans

Re: RFH: gen_rtx_MEM / gen_rtx_CONST in ada front-end code

[Eric Botcazou]

> 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_decl (input_location,
>VAR_DECL, gnu_entity_name, gnu_type);
> /* The (MEM (CONST (0))) pattern is prescribed by STABS.  */
> if (global_bindings_p ())
>   addr = gen_rtx_CONST (VOIDmode, const0_rtx);
> else
>   addr = stack_pointer_rtx;
> SET_DECL_RTL (gnu_decl, gen_rtx_MEM (Pmode, addr));
> gnat_pushdecl (gnu_decl, gnat_entity);
> break;
>   }

It's a gigi hack to support a front-end kludge. :-)

> I would like to remove this code from ada, but I am not sure what the
> purpose of this code is. What should I do with this code?

The goal is to build a pure debugging variable, i.e. a variable that will be 
present only in the debug info.  GDB is supposed to magically recognize its 
name and deduce something from its presence in the scope.

This was done this way to prevent debug stuff from altering code generation 
and avoid wasting space.  Yes, the whole design is questionable, give me a 
few days to investigate whether it can be modified.

-- 
Eric Botcazou

Re: GFDL/GPL issues

[Matthias Klose]

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 from code and take bits
of what is currently in GCC manuals and put that into comments in code
and so forth and so on.


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 the manual pages in its non-free section.  The issue was 
raised with the FSF some years ago, but issues with the GFDL seem to be low 
priority within the FSF (Mako may correct me).  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 documentation in Debian as well.


  Matthias

Re: GFDL/GPL issues

[Mark Mitchell]

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 to my Robert&Collins
> english<->french dictionnary applied twice, "to further" means "to
> favour" in that context; is that understanding the right one?].

I would that "to further" in this context means "to advance".  If you
show the FSF how some change will help the FSF achieve its goals, then
they will generally consider it.

> First, I have no idea of who the FSF really means (except RMS). 

Me neither.  I usually contact RMS directly because ultimately he seems
to make most of the decisions about these things, often after getting
input from the SFLC and probably other people I don't know about.

> Are there any reason for which I should expect more attention now? I
> don't understand why a question nobody cared about on May 7th should
> become interesting on May 27th of the same year (2010).

If you can't explain to the FSF why a license change will help the FSF
achieve its goals, I'd expect that your request will be ignored.  The
discussion I started with RMS at Joseph's behest was not about MELT.  It
was about the general issue of generating documentation from code.  I
wasn't aware it had anything to do with MELT.

> And there is one even more basic thing I don't understand. Why are GFDL
> & GPL incompatible? 

I suggest you search the internet for the answer; there's a lot of
discussion about this out there.

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.  You could
generate GPL'd documentation, though.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[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 processes.  If
> I knew how to do it faster, I certainly would.  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 to my Robert&Collins
english<->french dictionnary applied twice, "to further" means "to
favour" in that context; is that understanding the right one?].

First, I have no idea of who the FSF really means (except RMS). Who
should I contact by email? What should I tell? What do I risk? What are
the *technical* background I can assume? Do FSF people know what coding
is about? (RMS certainly does, but is he most of FSF?).

Second, I believe I tried hard to explain what MELT is doing w.r.t.
documentation in an email (dated May 07th)
http://gcc.gnu.org/ml/gcc/2010-05/msg00125.html to which *nobody*
responded. Or was gcc@ the wrong list to ask?

Are there any reason for which I should expect more attention now? I
don't understand why a question nobody cared about on May 7th should
become interesting on May 27th of the same year (2010).

And all this is not really MELT related, and perhaps even not even GCC
related. Several GNU projects (notably GTK) generates documentation from
code. Not understanding at all any internal (& personal) factors from my
far continent (I am European, and I am not a lawyer!), I cannot imagine
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
GTK is not an FSF project, (this implying that GNU software is not FSF
software)? Or are there still no FSF copyrighted software generating
some small documentation from code! (we are in 2010, and it is common
practice; I could imagine that bash or binutils have similar issues.).
And for GTK at least, the header files only mention LGPL license, and
apparently not any additional exception related to documentation...

And there is one even more basic thing I don't understand. Why are GFDL
& GPL incompatible? Apparently, both allow at least redistribution,
under the same license, of human written textual material -documentation
for GFDL, & source code for GPL- (the GPL probably allows more, like
compilation of a source code & some use of the resultant binary). Why
the probably non-empty intersection of rights (probably the right to
read textual material & to redistribute it verbatim at least) is not
usable?

Also, some official GCC documentation contains substantial chunks of
code (e.g. plugins.texi). Does that mere fact legally invalidate
something?

In practice, should I have to erase all the :doc annotations in MELT
source code? I would be very sad to do that. And even if I did that, I
am not sure to be able to claim that these :doc annotations never
existed (they did). I am not willing to falsely (= lyingly) claim that I
never wrote these :doc annotations. I did wrote them and I don't want to
deny that I did wrote them.

The most important for me is that MELT continues to be a GCC branch. If
I have to reduce or remove the documentation & comments inside the MELT
code for that, I probably would accept that (with great sadness). But
removing explanations -addressed to human readers- from inside source
code is in my naive technical view against the goals of free software.

Cheers.

Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro

[Michael Meissner]

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 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 eliminate macros.
> > > 
> > > Yes, the (informally agreed) policy is to have hooks, not macros.  There
> > > may be situations where that is technically impossible, but I'd expect
> > > those to be very rare.
> > 
> > For the target address space stuff, it is to the __ea keyword.  You don't 
> > want
> > a target hook that is called on every identifier, but instead you want a 
> > target
> > hook that is called in c_parse_init (in c-parser.c) and init_reswords (in
> > cp/lex.c) to set up the keywords.  The target hook would have to duplicate 
> > the
> > functionality of all of the setup that c_parse_init and init_reswords do,
> > particularly if they have different semantics.
> 
> It looks like this may be simpler than I thought.  The following patch
> introduces a "c_register_addr_space" routine that the back-end may call
> to register a named address space qualifier keyword.  (This could be done
> either statically at start-up, or even dynamically e.g. in respose to a
> target-specific #pragma.)
> 
> In the current patch, the SPU back-end uses somewhat of a hack to actually
> perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
> Note that this macro is already being used by the SPU and several other
> back-end for similar hacks.  It seems that it might be a good idea to
> replace this by something like a "register_target_extensions" callback
> in targetcm, but that can probably be done in a separate patch.

Note, many of the things done by REGISTER_TARGET_PRAGMAS deal with the
preprocessor and keywords, which are used by the C-like front ends, but not
used for Ada, Fortran, etc.  Those front ends don't link in libcpp.  So, you
need something in -c.c that sets the hook, rather than moving it to
.c.

-- 
Michael Meissner, IBM
Until June 14: 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
After June 14: 5 Technology Place Drive, MS 2757, Westford, MA 01886, USA
meiss...@linux.vnet.ibm.com

Re: GFDL/GPL issues

[Joern Rennecke]

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

Does that means that the only time when such a file could be
redistributed is in a couple of years (2012, 2015?) [*] when at long
last the FSF will have make an official change in some license or
exception?


IIRC, when you do a Copyright Assignment to the FSF, you get the right
granted back to use the code you contributed in other projects, subject
to some notice  period (3 weeks?).
You best check your assignment confirmation papers.

So I would suggest that you inform the FSF that you want to use the
MELT code that you contributed previously (to the GCC project)
for the project 'MELT documentation';
wait for the notice period to pass, and then AFAIU you are free to
use your MELT code under a different License, like the GFDL.
(Ask a lawyer if there is any doubt.)
To assure users that they may use the documentation, you then have to
actually grant a GFDL license to the documentation.
E.g. you could include the auto-generated documentation with GFDL
license in your branchand/or release.  Of course you'd have to make
sure that you don't drag in copyrightable material for which you
don't have GFDL rights (e.g. pieces of GPL-only code from GCC proper).

Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro

[Mark Mitchell]

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.
> 
>   * config/spu/spu.h (TARGET_ADDR_SPACE_KEYWORDS): Remove.
>   (REGISTER_TARGET_PRAGMAS): Call c_register_addr_space.
> 
>   * doc/tm.texi (Named Address Spaces): Mention c_register_addr_space.
>   Remove TARGET_ADDR_SPACE_KEYWORDS.

OK.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Mark Mitchell]

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 wants, other than
what it's said in public.

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

I don't know.  I don't know enough about Melt to give an answer, even an
informal one.  (And I'm not a lawyer, so I certainly couldn't give you
good legal advice.)

> 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 any involvement in
Debian.

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 it faster, I certainly would.  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.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Richard Kenner]

> 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 Asterisk system: it makes many of the advantages of it being
Free Software go away.

Minor technical advantages shouldn't have been enough to create that
situation.  I hope it never happens to GCC, but I'm not optimistic.

[patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro

[Ulrich Weigand]

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?
> > > 
> > > I don't know to which extent this is a formal goal these days, but I
> > > personally agree that it would be nice to eliminate macros.
> > 
> > Yes, the (informally agreed) policy is to have hooks, not macros.  There
> > may be situations where that is technically impossible, but I'd expect
> > those to be very rare.
> 
> For the target address space stuff, it is to the __ea keyword.  You don't want
> a target hook that is called on every identifier, but instead you want a 
> target
> hook that is called in c_parse_init (in c-parser.c) and init_reswords (in
> cp/lex.c) to set up the keywords.  The target hook would have to duplicate the
> functionality of all of the setup that c_parse_init and init_reswords do,
> particularly if they have different semantics.

It looks like this may be simpler than I thought.  The following patch
introduces a "c_register_addr_space" routine that the back-end may call
to register a named address space qualifier keyword.  (This could be done
either statically at start-up, or even dynamically e.g. in respose to a
target-specific #pragma.)

In the current patch, the SPU back-end uses somewhat of a hack to actually
perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
Note that this macro is already being used by the SPU and several other
back-end for similar hacks.  It seems that it might be a good idea to
replace this by something like a "register_target_extensions" callback
in targetcm, but that can probably be done in a separate patch.

The patch below passes all the "__ea" related tests on SPU; a full test
suite run is ongoing.  OK if it passes?

Bye,
Ulrich

ChangeLog:

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

* config/spu/spu.h (TARGET_ADDR_SPACE_KEYWORDS): Remove.
(REGISTER_TARGET_PRAGMAS): Call c_register_addr_space.

* doc/tm.texi (Named Address Spaces): Mention c_register_addr_space.
Remove TARGET_ADDR_SPACE_KEYWORDS.

Index: gcc/doc/tm.texi
===
*** gcc/doc/tm.texi (revision 159889)
--- gcc/doc/tm.texi (working copy)
*** Internally, address spaces are represent
*** 9966,9982 
  range 0 to 15 with address space 0 being reserved for the generic
  address space.
  
! @defmac TARGET_ADDR_SPACE_KEYWORDS
! A list of @code{ADDR_SPACE_KEYWORD} macros to define each named
! address keyword.  The @code{ADDR_SPACE_KEYWORD} macro takes two
! arguments, the keyword string and the number of the named address
! space.  For example, the SPU port uses the following to declare
! @code{__ea} as the keyword for named address space #1:
  @smallexample
  #define ADDR_SPACE_EA 1
! #define TARGET_ADDR_SPACE_KEYWORDS ADDR_SPACE_KEYWORD ("__ea", ADDR_SPACE_EA)
  @end smallexample
- @end defmac
  
  @deftypefn {Target Hook} {enum machine_mode} TARGET_ADDR_SPACE_POINTER_MODE 
(addr_space_t @var{address_space})
  Define this to return the machine mode to use for pointers to
--- 9966,9979 
  range 0 to 15 with address space 0 being reserved for the generic
  address space.
  
! To register a named address space qualifier keyword with the C front end,
! the target may call the @code{c_register_addr_space} routine.  For example,
! the SPU port uses the following to declare @code{__ea} as the keyword for
! named address space #1:
  @smallexample
  #define ADDR_SPACE_EA 1
! c_register_addr_space ("__ea", ADDR_SPACE_EA);
  @end smallexample
  
  @deftypefn {Target Hook} {enum machine_mode} TARGET_ADDR_SPACE_POINTER_MODE 
(addr_space_t @var{address_space})
  Define this to return the machine mode to use for pointers to
Index: gcc/c-common.c
===
*** gcc/c-common.c  (revision 159889)
--- gcc/c-common.c  (working copy)
*** const struct c_common_resword c_common_r
*** 718,728 
{ "inout",  RID_INOUT,  D_OBJC },
{ "oneway", RID_ONEWAY, D_OBJC },
{ "out",RID_OUT,D_OBJC },
- 
- #ifdef TARGET_ADDR_SPACE_KEYWORDS
-   /* Any address space keywords recognized by the target.  */
-   TARGET_ADDR_SPACE_KEYWORDS,
- #endif
  };
  
  const unsigned int num_c_common_reswords =
--- 718,723 
*** const struct attribute_spec c_common_for
*** 857,873 
{ NULL, 0, 0, false, false, false, NULL }
  };
  
  /* Return identifier for address space AS.  */
  const

Re: GFDL/GPL issues

[Mark Mitchell]

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 that in the context of FSF GCC, and, of course, the SC
has no control of any other GCC.  This is the downside of copyright
assignment; it gives the FSF a lot control over licensing issues.  If
you don't want to give the FSF that control, you can't assign copyright
to the FSF.  But, that also means you can't contribute to FSF GCC.

Of course, in the context of plug-ins, you'd have more options, in that
you could develop and independently distribute a plug-in where you had
more control of licensing.  The plug-in would have to be
GPLv3-compatible, but you'd be able to dual-license the code in the
plug-in if you chose to do that.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: GFDL/GPL issues

[Basile Starynkevitch]

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 wanted by the FSF. It was only wanted by the GCC
community (and probably the FSF was reluctant to any changes). 

> That last consideration, of course, does not apply to not-FSF GCC, e.g.,
>  to a release that Basile does himself.

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

Does that means that the only time when such a file could be
redistributed is in a couple of years (2012, 2015?) [*] when at long
last the FSF will have make an official change in some license or
exception?

Does that mean that even if a MELT plugin package appears in Debian, it
could not contain any documentation? Or is there a mean (e.g. splitting
the chapters of the documentation...) to avoid such trouble...


Note [*]: I am quite pessimistic in the actual delay for an FSF official
decision. I remember too well how long it took to have a runtime license
compatible with plugins (even after it was drafted, it took much more
time than anyone expected). And no, I cannot fund American lawyers to
help (except at most by a *personal* donation of a few dozens euros,
which won't help at all; I imagine that american lawyers cost nearly a
million euros; any amount I could personally give is totally
insignificant.).


Any concrete & practical advice is welcome.

Cheers.
-- 
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 mines, sont seulement les miennes} ***

Re: GFDL/GPL issues

[Basile Starynkevitch]

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 am the only contributor to these files might help.
> 
> Would dual-licensing the .texi files (GFDL + GPL3) solve these problems?


Maybe (but one of them is generated from *.melt source files), but I
have absolutely no idea of who can permit me to change the licenses of
the files. In my understanding, their copyright belongs to FSF (not to
my employer CEA or me), and I would imagine that getting the FSF to
accept such a license change might be as difficult and as long-lasting
as having FSF solve the "global" issue.

Besides, GCC MELT is a branch that I would imagine is not the prime
interest of the FSF. To be more rude, I am probably the only one who
really cares about that branch, and I have no influence on the FSF.

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.

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?

[Michael Meissner]

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 a formal goal these days, but I
> > personally agree that it would be nice to eliminate macros.
> 
> Yes, the (informally agreed) policy is to have hooks, not macros.  There
> may be situations where that is technically impossible, but I'd expect
> those to be very rare.

For the target address space stuff, it is to the __ea keyword.  You don't want
a target hook that is called on every identifier, but instead you want a target
hook that is called in c_parse_init (in c-parser.c) and init_reswords (in
cp/lex.c) to set up the keywords.  The target hook would have to duplicate the
functionality of all of the setup that c_parse_init and init_reswords do,
particularly if they have different semantics.

-- 
Michael Meissner, IBM
Until June 14: 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
After June 14: 5 Technology Place Drive, MS 2757, Westford, MA 01886, USA
meiss...@linux.vnet.ibm.com

Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?

[Mark Mitchell]

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 eliminate macros.

Yes, the (informally agreed) policy is to have hooks, not macros.  There
may be situations where that is technically impossible, but I'd expect
those to be very rare.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: stack slot reuse

[Easwaran Raman]

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, 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, Steven Bosscher 
 >>  wrote:
 >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li 
 >>>  wrote:
  stack variable overlay and stack slot assignments is here too.
 >>>
 >>> Yes, and for these I would like to add a separate timevar. Agree?
 >>
 >> Yes.  (By the way, we are rewriting this pass to eliminate the code
 >> motion/aliasing problem -- but that is a different topic).
 >
 > Btw, we want to address the same problem by representing the
 > points where (big) variables go out-of scope in the IL, also to
 > help DSE.  The original idea was to simply drop in an aggregate
 > assignment from an undefined value at the end of the scope
 > during lowering, like
 >
 >  var = {undefined};
 >

>>>
>>> Is there something that prevents store sinking (or similar passes)
>>> from moving this 'var = {undefined};' statement outside the scope? Or
>>> should store sinking be taught to treat this as a barrier?
>>
>> Not at the moment (if indeed that assignment looks as a regular one).
>> Passes should be taught that it's not worthwhile to sink a
>> no-op.  IIRC no pass currently would sink aggregate copies anyway.
>
> Other issues to consider: 1) how does it affect SRA decisions? 2)
> inline summary also needs to be taught to not include size of those
> fake instructions; 3) why only aggregates? For scalars that live in
> stack, they also need barriers if slot sharing pick them as
> candidates, etc.
>
>
>>
 This looks like a very interesting approach.  Do you see any downside
 of this approach?  What is the problem of handling (nullifying) the
 dummy statement in expansion pass?

 The approach we took is different --- we move this overlay/packing
 earlier (after ipa-inlining).
>>>
>>> To elaborate further, we use the current stack-slot sharing heuristics
>>> in cfgexpand.c to decide what variables can share stack slots,
>>> synthesize union variables with those variables as fields and replace
>>> references to those variables with field references. We have an
>>> initial implementation and are evaluating the performance impact of
>>> making the sharing decisions early.
>>
>> Note that using union variables will pessimize alias analysis
>> as we allow type-punning with unions.  How do you address
>> the issue of debug information?
>>
>
> Debug information is handled. Easwaran can fill in the details.

We retain the original VAR_DECL even after synthesizing the union
variables and keep a map between the synthesized union variable to the
set of original variables corresponding to the synthesized union. In
cfgexpand.c, when RTL is generated for the synthesized variable, we
set the RTL to all of the original variables using SET_DECL_RTL
instead of setting the RTL to the synthesized union variable.


thanks,
Easwaran

>
> Thanks,
>
> David
>
>> Some time ago I had the very simple idea to merge identically
>> typed variables that do not have overlapping life-ranges into
>> a single variable (avoiding the union issue).  That would not
>> catch all cases cfgexpand catches but may even re-use
>> common initializations.  Of course the debug information
>> issues would be the same.
>>
>> I think we want the clobbering stores anyway, for optimization
>> purposes, even if we do not end up using them for the
>> stack slot sharing problem.
>>
>> Richard.
>>
>

Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?

[Ulrich Weigand]

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 eliminate macros.

However, there are (or at least, used to be) some areas where using
hooks is a bit difficult, in particular where interactions between
the back-end and one particular front-end (as opposed to common code)
are concerned.  This is the reason why we implemented 
TARGET_ADDR_SPACE_KEYWORDS as macro (note that all the other
address-space related back-end callbacks were already implemented
as hooks to begin with).

> Kai already said on IRC last night that he can hookize
> TARGET_ENUM_VA_LIST. Could the folks who introduced
> TARGET_ADDR_SPACE_KEYWORDS please do the same?

I'll have a look.  What is the preferred solution these days for
hooks between the C front-end and a back-end?  targetcm?
(Why is there both targetcm and targetm.c ?)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Ada LTO failures (2x)

[Richard Guenther]

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 which you can't (well,
>> you could by name).
>
> Can't we simply record the first personality routine encountered when reading
> in the GIMPLE IL and assign it to all FDEs that don't have one?  That would
> at least solve the problem in the homogeneous case.

Hm, we could arrange dwarf2out.c:current_unit_personality to be
set to that of the first DECL_FUNCTION_PERSONALITY we
stream in and in expr.c:get_personality_function use that
for the eh_personality_any case.  Sort of ugly as current_unit_personality
is not exported, but ...

For multi-language LTO it's probably still prefered to use the
C personality for eh_personality_any, so conditionalizing this
on !CFI assembler would be needed.

Richard.

Re: Ada LTO failures (2x)

[Eric Botcazou]

> 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 record the first personality routine encountered when reading 
in the GIMPLE IL and assign it to all FDEs that don't have one?  That would 
at least solve the problem in the homogeneous case.

-- 
Eric Botcazou

Re: externally_visible and resoultion file

[Richard Guenther]

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.  We do not parse the complete resolution file but only the
entries we'll end up reading .o files with LTO information for.

> In theory, it shouldn't be needed since LTO has all information. But what
> about current implementation. I checked relevant source files and can't
> get immediate clue.

The current implementation has no idea of the external references
(though it's probably not too hard to implement).

Richard.

Re: stack slot reuse

[Richard Guenther]

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, 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, Steven Bosscher 
 >>  wrote:
 >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li 
 >>>  wrote:
  stack variable overlay and stack slot assignments is here too.
 >>>
 >>> Yes, and for these I would like to add a separate timevar. Agree?
 >>
 >> Yes.  (By the way, we are rewriting this pass to eliminate the code
 >> motion/aliasing problem -- but that is a different topic).
 >
 > Btw, we want to address the same problem by representing the
 > points where (big) variables go out-of scope in the IL, also to
 > help DSE.  The original idea was to simply drop in an aggregate
 > assignment from an undefined value at the end of the scope
 > during lowering, like
 >
 >  var = {undefined};
 >

>>>
>>> Is there something that prevents store sinking (or similar passes)
>>> from moving this 'var = {undefined};' statement outside the scope? Or
>>> should store sinking be taught to treat this as a barrier?
>>
>> Not at the moment (if indeed that assignment looks as a regular one).
>> Passes should be taught that it's not worthwhile to sink a
>> no-op.  IIRC no pass currently would sink aggregate copies anyway.
>
> Other issues to consider: 1) how does it affect SRA decisions?

It shouldn't.  But SRA needs to be adjusted for sure.

> 2) inline summary also needs to be taught to not include size of those
> fake instructions;

That's simple.  The inliner also needs to be taught to emit the
fake assignments into the caller.

> 3) why only aggregates? For scalars that live in
> stack, they also need barriers if slot sharing pick them as
> candidates, etc.

Sure.

Richard.

Re: GFDL/GPL issues

[Joern Rennecke]

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.


Would dual-licensing the .texi files (GFDL + GPL3) solve these problems?


Are you talking about the melt .texi files or the general GCC and texinfo
infrastructure texi files?  Unless you dual-license the latter, all
.texi files that use them must be GFDL.  I.e. if you autogenerate .texi files
from melt source files, these source files would have to have a
GFDL-compatible license, or you have to distribute & check-in the generated
.texi files under the GFDL together with the GPLed sources.

Re: Ada LTO failures (2x)

[Richard Guenther]

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 personality routine without any real
> reasons.  You don't need several personality routines to compile an all-Ada
> program.  This can presumably happen for an all-C++ program as well, but is
> masked if you have recent enough binutils (2.20 and above).

I say it's a middle-end bug that it doesn't support multiple personalities
without cfi asm.

LTO does it the way it does it to allow cross-language inlining for
more functions (we can't inline functions with different personalities,
but we can inline to/from a function that only requires _some_
personality).  So we make this distinction and thus end up
with the basic C personality for some functions.

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

Richard.

> --
> Eric Botcazou
>

Re: GFDL/GPL issues

[Mark Mitchell]

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

Presumably so, but we cannot unilaterally do that with source code that
has been assigned to the FSF.  The FSF assignment agreement generally
allows the original contributor to relicense his/her own work under
different terms, so Basile could (if he is the sole contributor)
dual-license the MELT .texi documentation -- but it's not clear to me
that this permits us to then take advantage of that in the context of
FSF GCC.

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?
That last consideration, of course, does not apply to not-FSF GCC, e.g.,
 to a release that Basile does himself.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

externally_visible and resoultion file

[Bingfeng Mei]

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 
about current implementation. I checked relevant source files and can't 
get immediate clue. 

Thanks,
Bingfeng

Re: stack slot reuse

[Xinliang David Li]

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, Xinliang David Li  
>>> > wrote:
>>> >> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher  
>>> >> wrote:
>>> >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li 
>>> >>>  wrote:
>>>  stack variable overlay and stack slot assignments is here too.
>>> >>>
>>> >>> Yes, and for these I would like to add a separate timevar. Agree?
>>> >>
>>> >> Yes.  (By the way, we are rewriting this pass to eliminate the code
>>> >> motion/aliasing problem -- but that is a different topic).
>>> >
>>> > Btw, we want to address the same problem by representing the
>>> > points where (big) variables go out-of scope in the IL, also to
>>> > help DSE.  The original idea was to simply drop in an aggregate
>>> > assignment from an undefined value at the end of the scope
>>> > during lowering, like
>>> >
>>> >  var = {undefined};
>>> >
>>>
>>
>> Is there something that prevents store sinking (or similar passes)
>> from moving this 'var = {undefined};' statement outside the scope? Or
>> should store sinking be taught to treat this as a barrier?
>
> Not at the moment (if indeed that assignment looks as a regular one).
> Passes should be taught that it's not worthwhile to sink a
> no-op.  IIRC no pass currently would sink aggregate copies anyway.

Other issues to consider: 1) how does it affect SRA decisions? 2)
inline summary also needs to be taught to not include size of those
fake instructions; 3) why only aggregates? For scalars that live in
stack, they also need barriers if slot sharing pick them as
candidates, etc.


>
>>> This looks like a very interesting approach.  Do you see any downside
>>> of this approach?  What is the problem of handling (nullifying) the
>>> dummy statement in expansion pass?
>>>
>>> The approach we took is different --- we move this overlay/packing
>>> earlier (after ipa-inlining).
>>
>> To elaborate further, we use the current stack-slot sharing heuristics
>> in cfgexpand.c to decide what variables can share stack slots,
>> synthesize union variables with those variables as fields and replace
>> references to those variables with field references. We have an
>> initial implementation and are evaluating the performance impact of
>> making the sharing decisions early.
>
> Note that using union variables will pessimize alias analysis
> as we allow type-punning with unions.  How do you address
> the issue of debug information?
>

Debug information is handled. Easwaran can fill in the details.


Thanks,

David

> Some time ago I had the very simple idea to merge identically
> typed variables that do not have overlapping life-ranges into
> a single variable (avoiding the union issue).  That would not
> catch all cases cfgexpand catches but may even re-use
> common initializations.  Of course the debug information
> issues would be the same.
>
> I think we want the clobbering stores anyway, for optimization
> purposes, even if we do not end up using them for the
> stack slot sharing problem.
>
> Richard.
>

Re: Ada LTO failures (2x)

[Eric Botcazou]

> 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 personality routines to compile an all-Ada 
program.  This can presumably happen for an all-C++ program as well, but is 
masked if you have recent enough binutils (2.20 and above).

-- 
Eric Botcazou

Re: GFDL/GPL issues

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

Would dual-licensing the .texi files (GFDL + GPL3) solve these problems?


- FChE

Re: Performance optimizations for Intel Core 2 and Core i7 processors

[Maxim Kuvyrkov]

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

http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01272.html

The biggest complaint was on mdbx (about 16%).


Thank you for the pointers and analysis!

...

Also I think it is important to have a pipeline description for
Core2/Core i7 or at least to use it from generic.


Right.  We will be adding a pipeline description for Core 2/i7.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331-3385 x724

Re: vectorization issue

[Richard Guenther]

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__ x)
> {
>    int i;
>    for (i=0;i<1024;i++)
>        x[i] = a[i] + b[i];
> }
>
> the loop is vectorized.
> But if I define ts as follows: #define ts short
> then the loop is not vectorized. The message I get is:
>
> ./a.c:21: note: no optab.
> ./a.c:21: note: not vectorized: relevant stmt not supported: D.1279_12
> = (short unsigned int) D.1278_11;
>
> I have tried to look a bit in the vectorizer code and it seems that
> for this stmt I get to vectorizable_operation with code==NOP_EXPR
> which is not handled.
>
> Does anyone knows anything about this problem?

The addition is done in type int (according to promotion rules),
but we fold it to an unsigned short addition.  You probably
lack a vector unsigned short -> vector short conversion
operation (which the middle-end should handle transparently).

Please file a bugreport.

Richard.

>
> Thanks, Roy.
>

vectorization issue

[roy rosen]

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[i];
}

the loop is vectorized.
But if I define ts as follows: #define ts short
then the loop is not vectorized. The message I get is:

./a.c:21: note: no optab.
./a.c:21: note: not vectorized: relevant stmt not supported: D.1279_12
= (short unsigned int) D.1278_11;

I have tried to look a bit in the vectorizer code and it seems that
for this stmt I get to vectorizable_operation with code==NOP_EXPR
which is not handled.

Does anyone knows anything about this problem?

Thanks, Roy.

Re: i370 port - status

[Paul Edwards]

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 that reliably
crashed on the 3rd identical run.

However, when I attempted to debug at a level above, ie in
the emulator, the bug would disappear also.

My working hypothesis now is that it is a bug in the
Hercules emulator to do with paging.  Which means I am
at the mercy of the operating system as to when it pages.
That operating system is MUSIC/SP, and it doesn't come
with source code, and I'm not really familiar with it anyway,
and the author is dead (a couple of years ago).

I did succeed in finding a configuration option to stop the
huge amount of paging in MUSIC/SP.  That then allowed my
compiles to go through cleanly, so I am now able to
get GCC to reproduce itself under MUSIC/SP.

The underlying presumed paging bug in either Hercules or
MUSIC/SP I decided to just package up and leave for another
day, as neither thing was my main or even important focus.

Closer to my main focus - after getting GCC working on MUSIC/SP,
the final real ("real" = "commercially used operating system,
which people use to develop code, and which doesn't have a
free C compiler already") target that I knew of that remained
was DOS/VS (z/VSE).

In April 2010 I finally got this last environment to have a hosted
C compiler that was good enough to compile a "hello world".
The C runtime library is only bare bones, so it can't handle
#include yet, only reading from stdin, but that's enough to get
the right code for a "hello world" to be generated.  Getting GCC
on that environment found a bug in the DOS/VS operating
system, and other limitations, but these problems were
worked around.

As we speak, Michel et al over here:

http://tech.groups.yahoo.com/group/H390-DOSVS/

is battling to try to get the DOS/VS environment to process a 
PARM string (in a way compatible with z/VSE).  Previously

the parameter was kludged to read it from stdin.  The old
DOS/VS doesn't have parameters basically.  Then the rest
of the library can be dealt with (reading from private source
statement libraries is the main thing).

Meanwhile, I have released GCC 3.2.3 MVS 8.0, which
can be found here:

http://gccmvs.sourceforge.net

which includes a much nicer MVS environment (with default
DCB information) for GCC et al.  It also includes the afore
mentioned MUSIC/SP and DOS/VS ports, even if the latter
is bare-bones.

Perhaps a link to that site could be put here:

http://gcc.gnu.org/extensions.html

So in the short term, the sort of things I am likely to be involved in are:

1. MVS source code management (10 million lines of code).
2. Improve VSE/380 port.
3. GCC 3.4.6 upgrade (from 3.2.3).

Although I managed to get 3.4.6 working on MVS many months ago,
I haven't formally released that port because I was trying to get the
potentially last 3.2.3 out the door.  But that happened a couple of
days ago.  So now, as long as I can bring all 4 environments along,
I should be able to upgrade.

GCC 3.4.6 has the advantage that the Unix build tools are able to
generate all the required files for MVS etc.  Before I used to
handcraft them.  I could probably backport that to 3.2.3 but haven't
tried, as my plan was to go forward.

One problem with going foward though is that I will lose the ability
to generate the generated files from i370.md.  The reason for that
is that one of the generator programs opens lots of files by name,
and those names are not appropriate for MVS usage.  I can
probably work around that, but rather than spending the effort
doing that, I was planning on revisiting that in GCC 4, and in the
meantime, just do that part of the build on Unix instead.  If people
truly need a self-contained MVS (EBCDIC) C compiler, then 3.2.3
will always be available.

Hopefully I'll have more positive news on GCC on the EBCDIC
platfoms in the months ahead.  :-)  Thanks to everyone who
helped in getting it so far already.

BFN.  Paul.






- Original Message - 
From: "Richard Guenther" 

To: "Paul Edwards" 
Cc: 
Sent: Sunday, November 29, 2009 2:02 AM
Subject: Re: i370 port - music/sp - possible generic gcc problem


On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards  wrote:

I think I have found a bug in gcc, that still exists in gcc 4.4

I found the problem on 3.2.3 though.

While MVS and VM have basically been working fine, when I did
the port to MUSIC/SP I started getting strange compilation failures.

Initializing the stack to NULs made the problem go away, but I
persisted, and instead initialized the stack to x'01' to try to get
consistent failures.

Even with that, and the malloced memory initialized to consistent
garbage, I still didn't get the desired consistency in failures.
But it was consistent enough that I could just run it 6 times and
see if there were any f

Re: Ada LTO failures (2x)

[Rainer Orth]

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:

http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01279.html

HTH.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Melt-building problem

[Basile Starynkevitch]

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.5.
> 
> Thanks for your feedback.
> 
> [my guess is that you have been hit by a bug that has been corrected a
> few weeks ago]


No, unfortunately, the bug is still here, and appears when configuring
GCC MELT with --enable-bootstrap and when compiling it with a gcc which
is not 4.5. (I confess I rarely test that).

I will investigate that later...

Thanks.

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Ada LTO failures (2x)

[Steven Bosscher]

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/testsuite/gnat.dg/lto6_pkg.ads: In
function 'lto6_pkg__f_stringSI':^M
/home/stevenb/devel/trunk/gcc/testsuite/gnat.dg/lto6_pkg.ads:4:8:
sorry, unimplemented: Multiple EH personalities are supported only
with assemblers supporting .cfi.personality directive.^M
lto-wrapper: /home/stevenb/devel/build/gcc/xgcc returned 1 exit status^M
collect2: lto-wrapper returned 1 exit status^M
gnatlink: error when calling /home/stevenb/devel/build/gcc/xgcc^M
gnatmake: *** link failed.^M

FAIL: gnat.dg/lto6.adb (test for excess errors)
Excess errors:
In file included from :44:0:
/home/stevenb/devel/trunk/gcc/testsuite/gnat.dg/lto6_pkg.ads:4:8:
sorry, unimplemented: Multiple EH personalities are supported only
with assemblers supporting .cfi.personality directive.
lto-wrapper: /home/stevenb/devel/build/gcc/xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status
gnatlink: error when calling /home/stevenb/devel/build/gcc/xgcc

UNRESOLVED: gnat.dg/lto6.adb compilation failed to produce executable

RFH: gen_rtx_MEM / gen_rtx_CONST in ada front-end code

[Steven Bosscher]

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_decl (input_location,
   VAR_DECL, gnu_entity_name, gnu_type);
/* The (MEM (CONST (0))) pattern is prescribed by STABS.  */
if (global_bindings_p ())
  addr = gen_rtx_CONST (VOIDmode, const0_rtx);
else
  addr = stack_pointer_rtx;
SET_DECL_RTL (gnu_decl, gen_rtx_MEM (Pmode, addr));
gnat_pushdecl (gnu_decl, gnat_entity);
break;
  }

Setting DECL_RTL here is a problem. Front ends should not have to set
DECL_RTL, and it breaks with LTO (which does not stream DECL_RTL). Ada
is the last front end to set DECL_RTL to something non-NULL:

$ grep SET_DECL_RTL c-*.[ch] cp/*.[ch] objc/*.[ch] objcp/*.[ch]
fortran/*.[ch] java/*.[ch] ada/gcc-interface/*.[ch]
cp/class.c:  SET_DECL_RTL (clone, NULL);
cp/method.c:  SET_DECL_RTL (x, NULL);
cp/pt.c:  SET_DECL_RTL (new_friend, NULL);
cp/pt.c:SET_DECL_RTL (r, NULL);
cp/pt.c:  SET_DECL_RTL (r, NULL);
cp/pt.c:  SET_DECL_RTL (r, NULL);
cp/pt.c:  SET_DECL_RTL (d, NULL);
java/decl.c:  SET_DECL_RTL (decl, 0);
ada/gcc-interface/decl.c:   SET_DECL_RTL (gnu_decl,
gen_rtx_MEM (Pmode, addr));


I would like to remove this code from ada, but I am not sure what the
purpose of this code is. What should I do with this code?

Thanks for any help/advice you can give,

Ciao!
Steven

Re: Melt-building problem

[Basile Starynkevitch]

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 that has been corrected a
few weeks ago]

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Target macros vs. target hooks - policy/goal is hooks, isn't it?

[Steven Bosscher]

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.
(TARGET_ENUM_VA_LIST): New.

and TARGET_ADDR_SPACE_KEYWORDS, introduced by:

2009-10-26  Ben Elliston  
Michael Meissner  
Ulrich Weigand  

* doc/tm.texi (TARGET_ADDR_SPACE_KEYWORDS): Document.


These patches were all reviewed and approved by maintainers who should
know if there is (or not) a goal of the GCC community to have target
hooks instead of target macros. And yet, there you are: two new target
macros. Pool Anatoly Sokolov will have a life time job turning macros
into hooks if new macros are allowed to appear.

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?

Kai already said on IRC last night that he can hookize
TARGET_ENUM_VA_LIST. Could the folks who introduced
TARGET_ADDR_SPACE_KEYWORDS please do the same?

Ciao!
Steven

Re: stack slot reuse

[Richard Guenther]

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, Steven Bosscher  
>> >> wrote:
>> >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li  
>> >>> wrote:
>>  stack variable overlay and stack slot assignments is here too.
>> >>>
>> >>> Yes, and for these I would like to add a separate timevar. Agree?
>> >>
>> >> Yes.  (By the way, we are rewriting this pass to eliminate the code
>> >> motion/aliasing problem -- but that is a different topic).
>> >
>> > Btw, we want to address the same problem by representing the
>> > points where (big) variables go out-of scope in the IL, also to
>> > help DSE.  The original idea was to simply drop in an aggregate
>> > assignment from an undefined value at the end of the scope
>> > during lowering, like
>> >
>> >  var = {undefined};
>> >
>>
>
> Is there something that prevents store sinking (or similar passes)
> from moving this 'var = {undefined};' statement outside the scope? Or
> should store sinking be taught to treat this as a barrier?

Not at the moment (if indeed that assignment looks as a regular one).
Passes should be taught that it's not worthwhile to sink a
no-op.  IIRC no pass currently would sink aggregate copies anyway.

>> This looks like a very interesting approach.  Do you see any downside
>> of this approach?  What is the problem of handling (nullifying) the
>> dummy statement in expansion pass?
>>
>> The approach we took is different --- we move this overlay/packing
>> earlier (after ipa-inlining).
>
> To elaborate further, we use the current stack-slot sharing heuristics
> in cfgexpand.c to decide what variables can share stack slots,
> synthesize union variables with those variables as fields and replace
> references to those variables with field references. We have an
> initial implementation and are evaluating the performance impact of
> making the sharing decisions early.

Note that using union variables will pessimize alias analysis
as we allow type-punning with unions.  How do you address
the issue of debug information?

Some time ago I had the very simple idea to merge identically
typed variables that do not have overlapping life-ranges into
a single variable (avoiding the union issue).  That would not
catch all cases cfgexpand catches but may even re-use
common initializations.  Of course the debug information
issues would be the same.

I think we want the clobbering stores anyway, for optimization
purposes, even if we do not end up using them for the
stack slot sharing problem.

Richard.

Re: Melt-building problem

[Wolfgang]

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: Verzeichnis
Plan: normal
Letzter Autor: bstarynk
Letzte geänderte Rev: 159667
Letztes Änderungsdatum: 2010-05-21 16:44:05 +0200 (Fr, 21. Mai 2010)

The configuration of melt ist:
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/usr/lib/test/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../melt-branch/configure --enable-languages=c,c++ 
--enable-shared --enable-threads=posix --enable-nls --enable-objc-gc 
--enable-mpfr --prefix=/usr/lib/test --enable-plugin --enable-lto 
--enable-checking --enable-tree-browse --enable-tree-checking --with-ppl 
--disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100406 (experimental) (GCC)

Now i can not reproduce the error any more

Thanks a lot for your help

Wolfgang


> > > 
> > > > but i get the following error:
> > > > 
> > > > 
> > > > make warmelt1
> > > > make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > > > date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
> > > > /bin/bash ../../melt-branch/gcc/../move-if-change
> > > empty-file-for-melt.c-tmp empty-file-for-melt.c
> > > > make -f ../../melt-branch/gcc/melt-module.mk 
> > > VPATH=../../melt-branch/gcc:. meltmodule \
> > > >   GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2
> > > -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I
> melt-private-build-include
> > > -I." \
> > > >  
> > >
> GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c 
> GCCMELT_MODULE_BINARY=warmelt-first.0.so
> > > > make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > > > gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer
> -gtoggle
> > > -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> > > warmelt-first.0.pic.o
> ../../melt-branch/gcc/melt/generated//warmelt-first.0.c
> > > > cc1: error: unrecognised debug output level "toggle"
> 
> 
> Perhaps re-merging the current MELT branch into your private branch
> (assuming you have a private MELT variant) might help, because on my
> side with GCCMELT_CC set to gcc-4.5 the make log contains
> 
> 
> make warmelt1
> make[4]: Entering directory `/usr/src/Lang/_MeltBoot/Obj/gcc'
> date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
> /bin/bash ../../melt-branch/gcc/../move-if-change
> empty-file-for-melt.c-tmp empty-file-for-melt.c
> make -f ../../melt-branch/gcc/melt-module.mk
> VPATH=../../melt-branch/gcc:. meltmodule \
> GCCMELT_CFLAGS="-g -fkeep-inline-functions -g
> -fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -I
> melt-private-build-include -I." \
> 
> GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> GCCMELT_MODULE_BINARY=warmelt-first.0.so
> make[5]: Entering directory `/usr/src/Lang/_MeltBoot/Obj/gcc'
> gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC
> -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> warmelt-first.0.pic.o
> ../../melt-branch/gcc/melt/generated//warmelt-first.0.c
> gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC
> -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> warmelt-first.0
> +01.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0+01.c
> echo '/*' generated file ./warmelt-first.0-stamp.c '*/' >
> warmelt-first.0-stamp.c-tmp
> date "+const char melt_compiled_timestamp[]=\"%c \";" >>
> warmelt-first.0-stamp.c-tmp
> echo "const char melt_md5[]=\"\\" >> warmelt-first.0-stamp.c-tmp
> for f
> in ../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> ../../melt-branch/gcc/melt/generated/warmelt-first.0+01.c; do \
> md5line=`md5sum $f` ; \
> printf "%s\\\n" $md5line >> warmelt-first.0-stamp.c-tmp; \
>   done
> echo "\";" >> warmelt-first.0-stamp.c-tmp
> echo "const char melt_csource[]=
> \"../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> ../../melt-branch/gcc/melt/generated/warmelt-first.0+01.c\";" >> 
> warmelt-first.0-stamp.c-tmp
> mv warmelt-first.0-stamp.c-tmp warmelt-first.0-stamp.c
> gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC
> -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -shared \
>./warmelt-first.0.pic.o  ./warmelt-first.0
> +01.pic.o ./warmelt-first.0-stamp.c -o warmelt-first.0.so
> rm -f ./warmelt-first.0-stamp.c
> 
> As you can see, the inner make -f ../../melt-branch/gcc/melt-module.mk
> has no -gtoggle inside the GCCMELT_CFLAGS. I see no reason it won't work
> with gcc-4.4 as GCCMELT_CC
> 
> The GCC MELT was svn checkout cleanly, the svn info is
> 
> Tue May 25 17:06:44 MEST 2010
> Path: melt-branch
> URL: svn://gcc.gnu.org/svn/gcc/branches/mel

Re: Help needed: banishing RTL from the front ends

[Andreas Schwab]

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 completely different."

Re: Testing GCC on Cygwin made substantially easier [was Re: dragonegg in FSF gcc?]

[Laurynas Biveinis]

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 modified version of the Cygwin DLL that will
> happily run make check at significant -j levels (I think I tried 12 at most;
> I've only got a dual-core cpu so it wasn't exactly efficient, but it proved
> that the patch holds up under substantial load).

I do not test on Cygwin these days, but previously I did and I wish I
knew this back then. I have added a note to
http://gcc.gnu.org/wiki/Testing_GCC . Thanks for the info!

-- 
Laurynas

Re: [PATCH, committed] Re: toplevel out of sync

[Paolo Bonzini]

> 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 elf_getshdrstrndx or elf_getshstrndx
>       separately.
>       * configure: Regenerate.
>
>
> 2010-04-13  Steve Ellcey  
>
>       * configure: Regenerate after change to elf.m4.
>
> config/
> 2010-04-13  Steve Ellcey  
>
>       * elf.m4: Add hppa[12]*-*-hpux* to list of non-elf platforms.
>
>
> 2010-04-02  Sebastian Pop  
>
>       * configure.ac: Add brackets around AC_TRY_COMPILE alternative.
>       * configure: Regenerated.
>
>
> 2010-04-02  Sebastian Pop  
>
>       * configure.ac: Print "buggy but acceptable" when CLooG
>       revision is less than 9.
>       * configure: Regenerated.
>
>
> config/
> 2010-01-05  Rainer Orth  
>
>       * stdint.m4 (GCC_HEADER_STDINT): Don't typedef uint8_t etc. if
>       corresponding macros already exist.

Re: GFDL/GPL issues

[Joern Rennecke]

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
source code is GPL (generating GPLed code from GFDL source is not
compatible with the GPL provision of distributing the source under
the GPL), and that all patches include GPLed source and GFDLed
documentation from the start.
I.e. the original contributor grants GPL license to the source and
GFDL license to the generated documentation, and then with the
contribution the assignment to the FSF somes into effect.
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.
Which should be even more motivation to get the initial licenses
right.

In this spirit, my patch:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00788.html
should help to keep target hook code and documentation in
lock-step and properly licensed in the future, even though it
can't fix any of the pre-existing issues.

It's slightly out-of-date because three more changes have been
made to the target hooks in the meantime, two of which have introduced
new code/documentation inconsistencies; I'll post an updated patch
shortly after verifying regression test results.  However, it's
just mechanical changes where the new code / documentation bits
are added into the appropriate places.