Re: Who owns config.rpath?
On Sun, 3 Oct 2010, Ralf Wildenhues wrote: > * Dave Korn wrote on Sun, Oct 03, 2010 at 01:42:15PM CEST: >> I can't find any mention of it at the usual place for external sources >> (http://gcc.gnu.org/codingconventions.html#upstream), so is our version >> forked, or is that just an oversight? > It comes originally from gettext, but for all practical matters I think > you can consider gnulib to be upstream. > > Contents should be kept in sync with relevant parts of libtool.m4 from > Libtool though. Could I convince you to propose language for addition to http://gcc.gnu.org/codingconventions.html#upstream ? If you send me the text, I'll can take care of HTML-ification (or just go ahead an update the patch if you prefer, of course ;-). Gerald
Re: LTO symtabs inconsistency
> On 16/10/2010 21:20, Dave Korn wrote: > > >> U _libintl_bindtextdomain > >> U _libintl_gettext > >> U _libintl_textdomain > > >> 0070 9600 5f6c 6962696e 746c5f74 .._libintl_t > >> 0080 65787464 6f6d6169 6e02 extdomain... > >> 0090 00a6 005f6c69 62696e74 ._libint > >> 00a0 6c5f6269 6e647465 7874646f 6d61696e l_bindtextdomain > >> 00b0 0200 a900 > > > For some reason, the two libintl symbols have underscores. gettext is > > missing altogether because we have a builtin for it, but I don't think we do > > for (bind)textdomain. > > Ah. It's because those functions have assembler names defined for them > already: > > > (gdb) call debug_tree ($5) > > > > Can someone clarify the purpose of the LTO symtab: is it there for anything > that LTO itself does, or is it solely to get the linker to pick up > kind-of-more-or-less the right dependencies? IOW, would it make sense for the It is for LTO plugin to pick up symbol table. > LTO symtab entries to be transformed by ASM_OUTPUT_LABELREF, are they intended > to be assembler-level symbols, or are they supposed to be C-level symbols? Hmm, yes, whatever mangling happens in real symbol output should happen when producing the symtab entry too. Honza > > cheers, > DaveK > >
Re: LTO symtabs inconsistency
On 17/10/2010 19:21, Jan Hubicka wrote: >> On 16/10/2010 21:20, Dave Korn wrote: > >> LTO symtab entries to be transformed by ASM_OUTPUT_LABELREF, are they >> intended to be assembler-level symbols, or are they supposed to be >> C-level symbols? > > Hmm, yes, whatever mangling happens in real symbol output should happen > when producing the symtab entry too. Ouch. Bashing ASM_OUTPUT_LABELREF into a shape where it can be used in a sprintf-style fashion rather than just outputting to a FILE* stream will be a big job. cheers, DaveK
gcc-4.3-20101017 is now available
Snapshot gcc-4.3-20101017 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101017/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 165594 You'll find: gcc-4.3-20101017.tar.bz2 Complete GCC (includes all of below) MD5=6b34104a0edcde643f7f0a9acf69a0d0 SHA1=d609ec654ab0612cd6c252a9e0d969b249101946 gcc-core-4.3-20101017.tar.bz2C front end and core compiler MD5=35c71f26a55dc814171226bb903c36b7 SHA1=d8c32a86a22bd989b7795886f5f7b97537170300 gcc-ada-4.3-20101017.tar.bz2 Ada front end and runtime MD5=93c917418f893fa031716c67ddd8369b SHA1=d7bfa0a377e9375eff1c0ab7f606e11658a28a75 gcc-fortran-4.3-20101017.tar.bz2 Fortran front end and runtime MD5=3f272e1ff3d4f7b148b6ea32eead66d4 SHA1=ee7d7b346a72355073a6704c83484849e15e79bc gcc-g++-4.3-20101017.tar.bz2 C++ front end and runtime MD5=76a06406bfeee3ffe3f4e89f69931fae SHA1=1ca4d3c8bb25939e75b819f41d2d424d16da14a9 gcc-java-4.3-20101017.tar.bz2Java front end and runtime MD5=33a8fe8422a9fb3571778511fc0fbc40 SHA1=5a5e014f03cbecc6ef960e760a6d9d9434275dc1 gcc-objc-4.3-20101017.tar.bz2Objective-C front end and runtime MD5=1d5e5c9f6d851a932e4f31417f2b25da SHA1=b1aaa310681bf70f66db6d607ab5fec1e50c1203 gcc-testsuite-4.3-20101017.tar.bz2 The GCC testsuite MD5=a26c5bf47f498356061596a7b5562086 SHA1=e45ad9ff00b5bc09b4de7cf321214064d14aec64 Diffs from 4.3-20101010 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
please help on makefile bug in MELT (plugin, not branch)
Hello All,
I apparently have a makefile bug (the bug is mine, not of make!) in
the GCC MELT branch, only when using it for plugin.
In case you want to help me, here are the gory details
First, read http://gcc-melt.org/ & http://gcc-melt.org/leaflet.html &
http://gcc.gnu.org/wiki/MELT for the context.
To reproduce the bug, assuming you have a gcc-4.5 enabled for plugins
installed somewhere:
Retrieve the entire GCC MELT branch, eg. rev 165598 (actually, you'll
need very few files from it). I call $GCCMELTSOURCE the source tree from SVN
You don't have to build the GCC MELT branch (in a seperate build tree) to
reproduce the bug, but just
cd $GCCMELTSOURCE
./contrib/make-melt-source-tar.sh $GCCMELTSOURCE /tmp/gccmeltplugin
## this have created a /tmp/gccmeltplugin directory & its tar archive
/tmp/gccmeltplugin.tgz
cd /tmp/gccmeltplugin
## now try to build MELT as a plugin to gcc-4.5, this is a shell script which
eventually run make
env GCC=gcc-4.5 ./build-melt-plugin.sh -M /tmp/gccmeltplugin -Y
gt-melt-runtime-plugin-4.5.h
#
More simply, I don't master every detail of make.
In the gcc/melt-make.mk file of the GCC MELT branch (which gets copied into
/tmp/gccmeltplugin) I have things like
warmelt-%.so: warmelt-%.c $(melt_make_module_makefile) melt-predef.h
cc1$(exeext)
$(MELT_MAKE_MODULE) melt_module \
GCCMELT_CFLAGS="$(melt_cflags) $(MELT_FINAL_CFLAGS)" \
GCCMELT_MODULE_SOURCE=$< GCCMELT_MODULE_BINARY=$@
and I believed that just having the above rule is enough to get it triggered
when makeing warmelt-first.1.so, but apparently not, with make -d I am getting
Trying pattern rule with stem `first.1'.
Rejecting impossible implicit prerequisite `warmelt-first.1.c'.
What does stem means in the context of make?
###
The funny thing is that the same melt-make.mk Makefile is used (perhaps in a
slightly different context) when building GCC MELT branch and it works. Perhaps
I have a vpath issue somewhere.
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 mine, sont seulement les miennes} ***
some questions to GCC steering commitee (at GCC Summit) related to documentation from code
Hello All,
I will attend the GCC Summit (unless some strikes in France will cancel
all flights to Canada; I hope not, but I don't know...) and I am busy
preparing my GCC MELT tutorial slides. [See
http://gcc-melt.org/leaflet.html for more]
There are a few questions I will definitely ask to the Steering
Commitee, most of them related to generating documentation from source
code.
As I explained in many long threads like
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00460.html and
http://gcc.gnu.org/ml/gcc/2010-05/msg00539.html
& many others
the MELT technical documentation meltgendoc.texi is built by a MELT
specific mode -i.e. by a MELT specific software tool- from MELT source
code files *.melt
I really want to generate documentation from code, because it is the
only documentation I've got. Not being able to do that means losing
documentation and a lot of work... I don't understand what is permitted
or not... (I got too much contradicting advices).
Several people gave me contradictory advices (potential GFDL vs GPL
license conflict?!), and when meeting FSF persons (e.g. at
OpenWorldForum in Paris a few weeks ago) I am also getting other
advices.
So I will ask face to face practical advices on these issues, in
particular I need to understand who is able to give me constructive &
"definitive" advices (apparently I asked on licens...@fsf.org and Karl
Berry replied, but probably his opinion is not powerful enough).
Perhaps a solution could be for GCC MELT to package the generated
meltgendoc.texi in a document independent of gcc.texi or gccint.texi
and licensed under GPLv3.
But I really want to meet at the GCC Summit someone who is able to take
decisions and has power to give good advices on these... I am very
confused.
If you are a member of the GCC "politburo" [that is the highest
decision taking authority & decision about GCC, I don't understand what
it is, who is there, and what it is called (SC or FSF?)] please give me
a few minutes of your precious time at the GCC Summit. If possible,
give me (perhaps by private email) your name & quality and most
importantly fix a time to meet there. I need to explain things in a
dozen of minutes with a laptop & face to face. I tried to explain by
email to gcc@gcc.gnu.org & gcc-patc...@gcc.gnu.org & licens...@fsf.org
but failed.
What I want to avoid is to get advice from the "wrong" persons, or
being told "do this" by person X and later by person Y "don't do this,
X told you wrongly". What I hope is concrete enough advices telling put
such & such licensing comments and such & such make rules to produce
such & such MELT documentation which could be "freely" redistributed
under such & such conditions (e.g. could be packaged in Debian).
>From France, understanding the decision making inside GCC is next to
impossible -very probably, as impossible it is for US people to
understand why planes might not take off from Paris Charles de Gaulle
airport... :-) :-) :-) [and even I cannot explain the details of
transportation strikes in France]
Cheers.
BTW I strongly believe that such documentation issues are not specific
to GCC MELT. They will & should happen, especially when going C++ &
doxygen etc... So the question is of general interest... and should get
a broad answer
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: some questions to GCC steering commitee (at GCC Summit) related to documentation from code
On 17 October 2010 22:16, Basile Starynkevitch wrote: > > So I will ask face to face practical advices on these issues, in > particular I need to understand who is able to give me constructive & > "definitive" advices (apparently I asked on licens...@fsf.org and Karl > Berry replied, but probably his opinion is not powerful enough). Really? I think with GNU licensing questions the best answer you'll get is from licens...@gnu.org - why do you think otherwise?
Re: some questions to GCC steering commitee (at GCC Summit) related to documentation from code
On 17 October 2010 22:34, Jonathan Wakely wrote: > On 17 October 2010 22:16, Basile Starynkevitch wrote: >> >> So I will ask face to face practical advices on these issues, in >> particular I need to understand who is able to give me constructive & >> "definitive" advices (apparently I asked on licens...@fsf.org and Karl >> Berry replied, but probably his opinion is not powerful enough). > > Really? I think with GNU licensing questions the best answer you'll > get is from licens...@gnu.org - why do you think otherwise? ^ sorry, I meant fsf.org not gnu.org
Re: some questions to GCC steering commitee (at GCC Summit) related to documentation from code
On Sun, 17 Oct 2010, Jonathan Wakely wrote: >>> So I will ask face to face practical advices on these issues, in >>> particular I need to understand who is able to give me constructive & >>> "definitive" advices (apparently I asked on licens...@fsf.org and Karl >>> Berry replied, but probably his opinion is not powerful enough). >> >> Really? I think with GNU licensing questions the best answer you'll >> get is from licens...@gnu.org - why do you think otherwise? > ^ sorry, I meant fsf.org not gnu.org Either way, this is something the Steering Committee is working to get addressed where we want to get the ability to extract (aspects of) documentation from code, but the combination of GPL and GFDL throws us a wrench. Gerald
Laurynas Biveinis now gengtype reviewer
Laurynas -- The GCC SC has appointed you as a reviewer for the gengtype/GTY machinery in GCC. You now have the authority to review and approve patches to the gengtype programs, to use of GTY markers, and other related topics. Please update MAINTAINERS to reflect your appointment. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
how to initialize a pointer using data page mode
Hi all, When compiling a C code containing a global declaration like: char *s = "abc"; The assembly code will be .section .rodata .LC0: .ascii "abc\0" .section .data .align 1 _s: .long .LC0 where the real address of string constant is kept in _s. However, in the processor I am porting GCC to, there is a memory mode, data page mode, which combines 14 LSB of the first word with 10LSB of the second word to make a read address. So, how to make GCC generates for _s like: _s: .int POF:.LCO .int PAG:.LCO and how to make assembler or linker accepts such an initialization. The assembler can accept the prefix POF and PAG now if they are in the assembly code like mov r2, PAG:_s mov r3,POF:_s but it cannot accept such a prefix in the initialization. Best regards, Phung
Re: GCSE problem on a gcc testsuite
Well,then I am not quite sure about the usage of this testsuite.Most testsuites seem to be used to test whether or not a kind of optimization works,and according to your view,this testsuite seems to be useless. So do you think it is proper if we remove this testsuite from the GCC testsuites? Thanks again. On Wed, Oct 13, 2010 at 3:12 PM, Eric Botcazou wrote: >> But now I am facing with a new instruction which will put the result >> in a single register,and thus GCC want to do GCSE on this >> instruction.GCC will treat si1%si2 as a loop invariant.So si1%si2 was >> moved out of the loop,just before the execution of function foo();as >> si2 is equal 0,there occurs a trap which shouldn't have occurred >> according to the original semantic. > > This happens for other targets as well, see the audit trail of the PR. > >> I am considering a solution:in a certain basic block,if there >> exists a function call rtx(which might exit or even trap in >> advance),then we shall not do GCSE optimization on the following rtx >> which might trap(see rtlanal.c:may_trap_p()).But it seems the cost is >> expensive,and I am not quite sure whether or not it works. > > Any attempt along these lines would most likely pessimize the common case. > > This PR is a pathological case that doesn't come from real life and fixing it > properly is hard, so I wouldn't bother about it. > > -- > Eric Botcazou >
Re: Laurynas Biveinis now gengtype reviewer
2010/10/18 Mark Mitchell : > The GCC SC has appointed you as a reviewer for the gengtype/GTY > machinery in GCC. You now have the authority to review and approve > patches to the gengtype programs, to use of GTY markers, and other > related topics. Thanks! > Please update MAINTAINERS to reflect your appointment. I've just committed the following: Index: ChangeLog === --- ChangeLog (revision 165606) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2010-10-18 Laurynas Biveinis + + * MAINTAINERS (Reviewers): Add myself for gengtype/GTY. + (Write After Approval): Remove myself. + 2010-10-15 Tristan Gingold * MAINTAINERS (OS Port Maintainers): Add myself for VMS. Index: MAINTAINERS === --- MAINTAINERS (revision 165606) +++ MAINTAINERS (working copy) @@ -266,6 +266,7 @@ FortranTobias Schlüter tobias.schlue...@physik.uni-muenchen.de FortranPaul Thomas pa...@gcc.gnu.org FortranJanus Weil ja...@gcc.gnu.org +gengtype/GTY Laurynas Biveinis laurynas.bivei...@gmail.com Graphite Daniel Berlin dber...@dberlin.org Graphite Tobias Grosser gros...@fim.uni-passau.de Graphite Sebastian Pop sebastian@amd.com @@ -300,7 +301,6 @@ Jan Beulichjbeul...@novell.com David Billinghurst david.billinghu...@riotinto.com Tomas Bily tb...@suse.cz -Laurynas Biveinis laurynas.bivei...@gmail.com Eric Blake er...@gcc.gnu.org Phil Blundell p...@futuretv.com Hans Boehm hbo...@gcc.gnu.org -- Laurynas
Re: GCSE problem on a gcc testsuite
> Well,then I am not quite sure about the usage of this testsuite.Most > testsuites seem to be used to test whether or not a kind of > optimization works,and according to your view,this testsuite seems to > be useless. The testcase only, not the testsuite. > So do you think it is proper if we remove this testsuite from the > GCC testsuites? Marking it as XFAIL is the usual way of dealing with such issues. -- Eric Botcazou
Re: some questions to GCC steering commitee (at GCC Summit) related to documentation from code
On Sun, 17 Oct 2010 22:34:47 +0100
Jonathan Wakely wrote:
> On 17 October 2010 22:16, Basile Starynkevitch wrote:
> >
> > So I will ask face to face practical advices on these issues, in
> > particular I need to understand who is able to give me constructive &
> > "definitive" advices (apparently I asked on licens...@fsf.org and Karl
> > Berry replied, but probably his opinion is not powerful enough).
>
> Really? I think with GNU licensing questions the best answer you'll
> get is from licens...@gnu.org - why do you think otherwise?
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00688.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01034.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00790.html
So I do hope that some people might understand that I am confused and
lost.
This is why I strongly hope to meet at the GCC Summit next week face to
face & discuss, with a laptop showing code & generated documentation,
with people having autority.
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 mine, sont seulement les miennes} ***
Questions about selective scheduler and PowerPC
Hi,
I'm investigating a GCC testsuite FAIL of PowerPC with e500 multilib.
The test is pr42245.c, which sets options to "-O2 -fselective-scheduling
-fsel-sched-pipelining".
$ ./cc1 -quiet pr42245.c -mcpu=8540 -mfloat-gprs=single -O2
-fselective-scheduling
pr42245.c: In function ‘build_DIS_CON_tree’:
pr42245.c:29:1: internal compiler error: in advance_state_on_fence, at
sel-sched.c:5288
The code around sel-sched.c:5288 looks like:
5265 static bool
5266 advance_state_on_fence (fence_t fence, insn_t insn)
5267 {
5268 bool asm_p;
5269
5270 if (recog_memoized (insn) >= 0)
5271 {
5272 int res;
5273 state_t temp_state = alloca (dfa_state_size);
5274
5275 gcc_assert (!INSN_ASM_P (insn));
5276 asm_p = false;
5277
5278 memcpy (temp_state, FENCE_STATE (fence), dfa_state_size);
5279 res = state_transition (FENCE_STATE (fence), insn);
5280 gcc_assert (res < 0);
5281
5282 if (memcmp (temp_state, FENCE_STATE (fence), dfa_state_size))
5283 {
5284 FENCE_ISSUED_INSNS (fence)++;
5285
5286 /* We should never issue more than issue_rate insns. */
5287 if (FENCE_ISSUED_INSNS (fence) > issue_rate)
5288 gcc_unreachable ();
5289 }
5290 }
5291 else
When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate
is 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but
rs6000_issue_rate lies to scheduler that it can only issue 1 instruction
before register relocation is done. See the following code:
23205 static int
23206 rs6000_issue_rate (void)
23207 {
23208 /* Unless scheduling for register pressure, use issue rate of 1 for
23209 first scheduling pass to decrease degradation. */
23210 if (!reload_completed && !flag_sched_pressure)
23211 return 1;
23212
23213 switch (rs6000_cpu_attr) {
[snip]
23223 case CPU_PPC8540:
[snip]
23230 return 2;
This issue could be traced down to haifa-sched.c:max_issue (), which
returns 2 even issue_rate is 1. So my questions and possible ways to fix
it are:
1. Should we restrict max_issue to only return value less than or equal
to issue_rate?
2. Should we do the same as what SMS does? See
static void
sms_schedule (void)
{
[snip]
/* Initialize issue_rate. */
if (targetm.sched.issue_rate)
{
int temp = reload_completed;
reload_completed = 1;
issue_rate = targetm.sched.issue_rate ();
reload_completed = temp;
}
else
issue_rate = 1;
[snip]
}
I suspect this piece code in sms_schedule was written for rs6000, but it
comes as the first commit of SMS merge and there is no patch email
explaining it.
3. The aforementioned rs6000 hack rs6000_issue_rate was added by
2003-03-03 David Edelsohn
* config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.
(TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
(rs6000_variable_issue): Do not return negative value.
(rs6000_issue_rate): Uniformly set issue rate to 1 for first
scheduling pass.
, which was more than 7 years ago. Is this still needed now?
Any one of the above three ways can fix the FAIL. But I'm not sure which
way is best, or maybe we should do 1 and 3 and remove the hack in 2?
Thoughts?
Regards,
--
Jie Zhang
CodeSourcery
