Rationale for an old TRUNCATE patch
I am trying to understand the checkin by Jeff Law from about 11 years ago: r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines * combine.c (simplify_rtx, case TRUNCATE): Respect value of TRULY_NOOP_TRUNCATION. Index: combine.c === --- combine.c(revision 19018) +++ combine.c(revision 19204) @@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) break; - if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) + if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT + && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), +GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0) SUBST (XEXP (x, 0), force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), GET_MODE_MASK (mode), NULL_RTX, 0)); This optimization simplifies the input to a truncate by only computing bits that won't be eliminated by the truncation. Normally these are the bits in the output mode mask. Note that the optimization does not change the truncate into a low-part subreg, which would pretty automatically warrant the TRULY_NOOP_TRUNCATION check. Specifically I am curious if this was prompted by MIPS (or SH) or maybe some other target that have a notion of truncate different from MIPS. force_to_mode was broken WRT truncate before my patch in 2006: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00553.html so maybe the Jeff's patch was just trying to avoid the call to force_to_mode. Anyhow, I don't think that the above transformation is illegal for MIPS64. When truncating to SI mode the bits outside the resulting SI mode will all be copies of the SI mode sign bit so their input values are obviously irrelevant. For QI and HI modes the representation requires the upper 32 bits in the 64-bit word to be copies of the 31st bit. The transformation might change the 31 bits so it can affect the the resulting bits in the 64-bit word. This however should have no visible effect. Operations on QI- and HI-mode values are performed in SI mode with proper extensions before the operation if bits outside the mode would affect the result. I also tried a few things after removing the above check. Boostrapping and regtesting on mips64octeon-linux was successful so was regtesting on mipsisa64r2-elf. The assembly output of gcc.c-torture/execute/*.c improved as: 13 files changed, 73 insertions(+), 99 deletions(-) The changes typically remove zero and sign-extensions before a subsequent truncation. Any further information on this subject would be very much appreciated. Adam
Re: uint64_t alignof odditity on x86
Jan Engelhardt writes:
> I noticed that __alignof__(uint64_t) will return 8, while
> __alignof__(struct { uint64_t x; }) will give only 4. This
> run on a typical 32-bit x86 CPU (GCC config below).
>
> What I am wondering about is why GCC was coded to give different
> alignments here. If aligning a single uint64_t to a boundary of 8 for
> whatever reason there may be (performance?), not doing so when it is
> inside a struct appears to be a discrepancy.
This question would have been more appropriate for the mailing list
gcc-h...@gcc.gnu.org rather than g...@gcc.gnu.org. Please take any
followups to gcc-help. Thanks.
The x86 ABI specifies the aligment of fields within a struct. gcc can
not change that alignment without breaking the ABI. This does not
matter much when the only field has type uint64_t, but it matters for a
case like "struct { int f1; uint64_t f2; };". For a variable of type
uint64_t, it's OK for gcc to increase the alignment, since it does not
affec the ABI (although the required alignment is only 4, any program
must work if all uint64_t variables happen to be aligned on an 8-byte
boundary).
Ian
instructions for compiling plugins?
Hello All,
I am very glad that plugins are now inside the trunk.
I have configured the trunk as suggested in
http://gcc.gnu.org/ml/gcc/2009-06/msg00173.html so I invoke it as gcc-trunk
Apparently, the goal is to be able to compile (at least some) plugins
without having the GCC source tree or build tree.
However, I believe we don't have any documentation stating that. At
least not in http://gcc.gnu.org/onlinedocs/gccint/Plugins.html and not
in http://gcc.gnu.org/wiki/plugins
My feeling is that, at least on Linux machines, a plugin might be
compiled with e.g. a Makefile containing
GCC=gcc-trunk
GCCPLUGINS_DIR:=$(shell $(GCC) -print-file-name=plugin)
CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC
plugin.so: plugin.pic.o
$(GCC) -shared $^ -o $@
plugin.pic.o: plugin.c
Should we add a section "Building plugins" in the Plugin chapter of the
documentation http://gcc.gnu.org/onlinedocs/gccint/Plugins.html ?
By the way, are we sure that install-plugin target in gcc/Makefile is
invoked from a toplevel sudo make install in the build dir? I feel it
might not be the case, but I am not sure..
Regards.
--
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} ***
AVR C++ - how to move vtables into FLASH memory
I would like to change gcc so AVR C++ port will use FLASH memory instead of SRAM to store virtual function pointers. Does anyone try to do it? I have no experience as gcc developer, so can you head me to appropriate files/literature about this particular problem? TIA.
Re: Address mode offset spill
Hi, your guys:
Here is the cc1 the notation cc1 crashed:
mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
spill in class 'R0_REG'
mvx_audio_dec_mp3_test.c:112: error: this is the insn:
(insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
(const_int 2076 [0x81c])) 4 {load_imm_low_si} (nil)
(expr_list:REG_EQUIV (const_int 2076 [0x81c])
(nil)))
PS: there are 16 general registers in my RISC chip, from R0 to R15.
R14, and R15 are used for FP,SP. R0 register is special.
Every large immediate, larger than 512, must be moved into R0
register, which means that R0 is the only register to load large
immediate.
This is a thorny problem.
I have traced the rtl code, and RTL code was combined from two rtl
instructions(R14 is Frame pointer register):
(insn 129 127 168 6 (set (reg:SI 88)
(const_int 2064 [0x810])) 4 {load_imm_low_si} (nil)
(nil))
(insn 168 129 131 6 (set (reg/f:SI 101)
(plus:SI (reg/f:SI 14 R14)
(const_int 12 [0xc]))) 45 {rice_addsi3} (nil)
(nil))
(insn 133 131 134 6 (set (reg:SI 4 R4)
(plus:SI (reg/f:SI 101)
(reg:SI 88))) 45 {rice_addsi3} (nil)
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 14 R14)
(const_int 2076 [0x81c]))
(nil)))
So before cc1 crashed, the unrecognized insn doesn't go through the
LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro.
Is there any solution I can handle the similar problems?
And the following code is what I wrote in macro
LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS:
#define LEGITIMIZE_RELOAD_ADDRESS(X,MODE,OPNUM,TYPE,IND_LEVELS,WIN)
\
{ \
if(rice_legitimize_reload_address(&X,MODE,OPNUM,TYPE,IND_LEVELS))
\
goto WIN; \
}
/*constant value like immediate larger than 512,
*symbol_ref, label_ref, should be moved into R0 register*/
#define PREFERRED_RELOAD_CLASS(X, CLASS) rice_preferred_reload_class(X, CLASS)
enum reg_class rice_preferred_reload_class (rtx x, enum reg_class class)
{
if((GET_CODE(x) == SYMBOL_REF) ||
(GET_CODE(x) == LABEL_REF) ||
(GET_CODE(x) == CONST) ||
((GET_CODE(x) == CONST_INT) && (!Bit10_constant_operand(x,
GET_MODE(x)
{
return R0_REG;
}
return class;
}
bool rice_legitimize_reload_address(rtx* x,
enum machine_mode mode ATTRIBUTE_UNUSED,
int opnum, int type,
int ind_levels ATTRIBUTE_UNUSED)
{
printf("Come to rice_legitimize_reload_address! \n");
if((GET_CODE(*x) == SYMBOL_REF) ||
(GET_CODE(*x) == LABEL_REF) ||
(GET_CODE(*x) == CONST) ||
((GET_CODE(*x) == CONST_INT) && (!Bit10_constant_operand(*x,
GET_MODE(*x)
{
#ifdef DEBUG_RICE_GCC
printf("Come to rice_legitimize_reload_address: R0 Reload! \n");
#endif
push_reload (*x, NULL_RTX, x, NULL,
R0_REG, GET_MODE (*x), GET_MODE (*x), 0, 0,
opnum, type);
return RICE_YES;
}
// We must re-recognize what we created before.
if (GET_CODE (*x) == PLUS
&& (GET_MODE_SIZE (mode) == 4)
&& GET_CODE (XEXP (*x, 0)) == PLUS
&& GET_CODE (XEXP (XEXP (*x, 0), 1)) == CONST_INT
&& rice_reg_ok_for_base (XEXP (XEXP (*x, 0), 0), 1)
&& GET_CODE (XEXP (*x, 1)) == CONST_INT)
{
rtx sum;
#ifdef DEBUG_RICE_GCC
printf("Come to rice_legitimize_reload_address: Offset
re-recognize! \n");
#endif
push_reload (XEXP ((*x), 0), NULL_RTX, &XEXP ((*x), 0), NULL,
BASE_REG_CLASS, GET_MODE (*x),
VOIDmode, 0, 0,
(opnum), (type));
sum = XEXP (*x, 0);
sum = XEXP (*x, 1);
sum = XEXP(XEXP (*x, 0), 0);
sum = XEXP(XEXP (*x, 0), 1);
return RICE_YES;
}
//Offset >= 256
if (GET_CODE (*x) == PLUS
&& GET_MODE_SIZE (mode) == 4
&& (GET_CODE (XEXP (*x, 1)) == CONST_INT && INTVAL(XEXP (*x,
1)) > 255)
&& rice_reg_ok_for_base (XEXP (*x, 0), 0))
{
rtx index_rtx = XEXP (*x, 1);
HOST_WIDE_INT high_part, low_part, offset = INTVAL (index_rtx);
rtx sum;
Re: diagnostics-branch merged into mainline
2009/6/15 Aldy Hernandez : >> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?: >> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to >> function ?make_decl_one_only? > > make_decl_one_only expects one argument, and that's what's being fed. > Could you please debug this and find out what's going on? > At revision 148493 decl_one_only was changed to take 2 arguments. Looks like I missed winnt.c. Will send a patch. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: diagnostics-branch merged into mainline
2009/6/16 Rafael Espindola :
> 2009/6/15 Aldy Hernandez :
>>> ../../gcc/gcc/config/i386/winnt.c: In function
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only?
>>
>> make_decl_one_only expects one argument, and that's what's being fed.
>> Could you please debug this and find out what's going on?
>>
>
> At revision 148493 decl_one_only was changed to take 2 arguments.
> Looks like I missed winnt.c.
>
> Will send a patch.
>
> Cheers,
> --
> Rafael Avila de Espindola
>
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047
>
Yes, I have prepared a patch for it already. I am just doing a
regression test for it and will apply it.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: diagnostics-branch merged into mainline
> At revision 148493 decl_one_only was changed to take 2 arguments. > Looks like I missed winnt.c. 148492 actually. Fixed in revision 148523: 2009-06-16 Rafael Avila de Espindola * config/i386/winnt.c (i386_pe_encode_section_info): Update call to make_decl_one_only. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: diagnostics-branch merged into mainline
2009/6/16 Rafael Espindola :
>> At revision 148493 decl_one_only was changed to take 2 arguments.
>> Looks like I missed winnt.c.
>
> 148492 actually. Fixed in revision 148523:
>
>
> 2009-06-16 Rafael Avila de Espindola
>
> * config/i386/winnt.c (i386_pe_encode_section_info): Update call to
> make_decl_one_only.
>
> Cheers,
> --
> Rafael Avila de Espindola
>
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047
>
This is ok, too. I assume you have done a regression test? ;)
My test was successful with following patch.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Index: gcc/gcc/config/i386/winnt.c
===
--- gcc.orig/gcc/config/i386/winnt.c2009-05-28 16:15:41.0 +0200
+++ gcc/gcc/config/i386/winnt.c 2009-06-16 11:34:48.460772000 +0200
@@ -285,7 +285,7 @@
ctor is protected by a link-once guard variable, so that
the object still has link-once semantics, */
|| TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl)))
- make_decl_one_only (decl);
+ make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
else
error ("%q+D:'selectany' attribute applies only to "
"initialized objects", decl);
Re: "plugin"-ifying the MELT branch.
Basile STARYNKEVITCH wrote:
Can a branch be simply a plugin, or should I close (soon) the
melt-branch and start a melt-plugin-branch on the SVN. If I do that,
do I need some authorization? from whom?
Apparently, nothing very special is required to start a new branch. So I
intend to create a new melt-plugin-branch in a few hours (or days),
unless there is some objections to it;I will progressively move code
from the current MELT branch melt-branch into this melt-plugin-branch to
make MELT a big plugin.
Also, does such a thing should be called a branch. After all, it is not
a derivative of an existing trunk! Maybe it should be called something
different!
This also brings interesting questions: how should plugins in general be
structured? Do they need some autoconf hackery?
My goal is of course to make MELT a big (meta) plugin suitable to work
with the standard trunk (ie future 4.5).
Regards.
--
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: "plugin"-ifying the MELT branch.
On Tue, Jun 16, 2009 at 1:13 PM, Basile
STARYNKEVITCH wrote:
> Basile STARYNKEVITCH wrote:
>>
>>
>> Can a branch be simply a plugin, or should I close (soon) the melt-branch
>> and start a melt-plugin-branch on the SVN. If I do that, do I need some
>> authorization? from whom?
>
>
> Apparently, nothing very special is required to start a new branch. So I
> intend to create a new melt-plugin-branch in a few hours (or days), unless
> there is some objections to it;I will progressively move code from the
> current MELT branch melt-branch into this melt-plugin-branch to make MELT a
> big plugin.
>
> Also, does such a thing should be called a branch. After all, it is not a
> derivative of an existing trunk! Maybe it should be called something
> different!
I do not think that plugins should be branches of trunk, nor should
they live in the FSF repository.
Richard.
>
> This also brings interesting questions: how should plugins in general be
> structured? Do they need some autoconf hackery?
>
> My goal is of course to make MELT a big (meta) plugin suitable to work with
> the standard trunk (ie future 4.5).
>
> Regards.
>
> --
> 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: "plugin"-ifying the MELT branch.
Richard Guenther wrote:
On Tue, Jun 16, 2009 at 1:13 PM, Basile
STARYNKEVITCH wrote:
Basile STARYNKEVITCH wrote:
Can a branch be simply a plugin, or should I close (soon) the melt-branch
and start a melt-plugin-branch on the SVN. If I do that, do I need some
authorization? from whom?
Apparently, nothing very special is required to start a new branch. So I
intend to create a new melt-plugin-branch in a few hours (or days), unless
there is some objections to it;I will progressively move code from the
current MELT branch melt-branch into this melt-plugin-branch to make MELT a
big plugin.
Also, does such a thing should be called a branch. After all, it is not a
derivative of an existing trunk! Maybe it should be called something
different!
I do not think that plugins should be branches of trunk, nor should
they live in the FSF repository.
I thought on the contrary that is was expected that some code would
become FSF owned plugins?
BTW, since MELT is a branch, its code is FSF owned. So to become a
plugin, it should be an FSF owned plugin!
In other words, are plugins only for code outside of GCC?
Regards.
--
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: "plugin"-ifying the MELT branch.
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote: > I thought on the contrary that is was expected that some code would become FSF > owned plugins? Not without a mechanism for linking plugins in statically on hosts for which we don't support dynamic loading of plugins, and even then it's doubtful. Rather, we should watch out for things being implemented as plugins that are generally useful for GCC and seek to build them into GCC (unconditionally) where appropriate, while leaving cases such as checking project-specific coding rules as separate plugins. -- Joseph S. Myers jos...@codesourcery.com
Re: diagnostics-branch merged into mainline
Rafael Espindola wrote: > 2009/6/15 Aldy Hernandez : >>> ../../gcc/gcc/config/i386/winnt.c: In function >>> ?i386_pe_encode_section_info?: >>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to >>> function ?make_decl_one_only? >> make_decl_one_only expects one argument, and that's what's being fed. >> Could you please debug this and find out what's going on? >> > > At revision 148493 decl_one_only was changed to take 2 arguments. > Looks like I missed winnt.c. > > Will send a patch. Oops! Please ignore my last message Rafael, I only searched the -patches list for related threads so far! Thanks for having fixed this so fast! cheers, DaveK
Re: instructions for compiling plugins?
> Apparently, the goal is to be able to compile (at least some) plugins > without having the GCC source tree or build tree. Correct. > However, I believe we don't have any documentation stating that. At least > not in http://gcc.gnu.org/onlinedocs/gccint/Plugins.html and not in > http://gcc.gnu.org/wiki/plugins > > My feeling is that, at least on Linux machines, a plugin might be compiled > with e.g. a Makefile containing > > GCC=gcc-trunk > GCCPLUGINS_DIR:=$(shell $(GCC) -print-file-name=plugin) > CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC > > plugin.so: plugin.pic.o > $(GCC) -shared $^ -o $@ > > plugin.pic.o: plugin.c Something like that :-) > Should we add a section "Building plugins" in the Plugin chapter of the > documentation http://gcc.gnu.org/onlinedocs/gccint/Plugins.html ? > > > By the way, are we sure that install-plugin target in gcc/Makefile is > invoked from a toplevel sudo make install in the build dir? I feel it might > not be the case, but I am not sure.. I tried a "make install" from the top level builddir and the headers were installed correctly. > Regards. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Help with BLOCK vs BIND_EXPR trees
(trying again) Hi, all. I have a basic question about GENERIC trees. I'm playing with writing a front end, and find the distinction between BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying to get a handle on how to represent a function in GENERIC form. On the surface the texi docs and code comments don't seem to agree: Section on function trees say FUNCTION_DECL represents a function, and that DECL_INITIAL is not empty. But it doesn't say what should be contained there. It says DECL_SAVED_TREE should contain the body of the function. The comments in tree.h say that DECL_INITIAL holds the body of a function, with a BLOCK tree at the root. BLOCK nodes are described under TREE_SSA->GIMPLE, though these nodes are part of GENERIC if I understand correctly. At least, the docs say that any tree code found in tree.def is part of GENERIC. In this section, it says that block scopes and variables are declared in BIND_EXPR nodes. Can someone please clarify how these things are supposed to fit together in GENERIC form, assuming the default conversion to GIMPLE will be used? Thanks, Jerry Quinn
Questions about VAR_DECL and DECL_EXPR
Hi, again, I am a little unclear on VAR_DECL and DECL_EXPR. The impression I get from reading the docs is that when a variable is first declared in a function, a VAR_DECL should be created, possibly with DECL_INITIAL() set. What's less clearly stated is what you use for variable references later in the code. I think you also use VAR_DECL for this purpose, but I'm not sure. Could someone clarify? If so, must it be the same tree node or does it just have to be another VAR_DECL with the same variable name? There is also DECL_EXPR representing local declarations, which appears to be related. How do these get used and would it even be used in a C-like language? Thanks, Jerry Quinn
Re: diagnostics-branch merged into mainline
> This is ok, too. I assume you have done a regression test? ;) On the fix patch? The file would not build without it I did test the original patch, but missed the winnt file. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: "plugin"-ifying the MELT branch.
I (Basile) very probably misunderstood what Joseph Myers or Richard
Guenther meant. What I might have [mis]understood scares me. This is a
request for clarification.
Joseph S. Myers wrote:
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote:
I thought on the contrary that is was expected that some code would become FSF
owned plugins?
Not without a mechanism for linking plugins in statically on hosts for
which we don't support dynamic loading of plugins, and even then it's
doubtful.
That mechanism already exists in libltdl (the libtool wrapper of dlopen).
However, I am not sure to understand the logic here. Plugins are by
definition optional stuff, and I understood from the beginning that
plugins are considered only on machines which have a way of dynamically
loading code (currently, the documented constraint is even stronger:
dlopen & -rdynamic).
Rather, we should watch out for things being implemented as
plugins that are generally useful for GCC and seek to build them into GCC
(unconditionally) where appropriate, while leaving cases such as checking
project-specific coding rules as separate plugins.
Again, I don't understand the rationale here.
My broad feeling was that plugin feature is for code which could
interest some people, but does not interest every GCC user. (and MELT,
or even ICI or TreeHydra, fits the definition).
In particular, there would probably be several plugins which give some
extra feedback to the developers using them, but do not modify the code
generation behavior of GCC.
Did I understood that in your view no branch hosted on GCC SubVersion
should provide plugins? Why? Is it only your view, or some decision by
some powerful guys (e.g. the Steering Committee)? Did the MELT branch
[*] suddenly become illegal without me knowing about that? That would be
ironical for a branch which happened -with other branches & people- to
have pushed the idea of plugins!
Is there some [political?] impossibility for FSF copyrighted GPLv3 code
(like those sitting in branches, e.g. the MELT one) to become plugins? I
thought that becoming GPLv3/FSF plugins is an additional natural path
for code sitting in branched to become accepted in the trunk!
I suppose these things has been discussed at the GCC summit a few days
ago? What has been discussed & decided?
This surprises me a big lot. I thought on the contrary that specialized
plugins would be used inside GCC in the future (for GCC development). To
be more concrete, one could imagine a plugin to check all the error &
warning messages inside GCC for validity (attribute printf is not fully
adequate for that purpose). And my interpretation of GTY as attribute
discussion was that someone is dreaming to replace gengtype, in a
distant future, by some plugin providing the same behavior as gengtype
(there is a bootstrap chicken&egg issue in that case, but one could
easily store the generated gt-*.h file in the source tree, as it is
already done for autoconf stuff today).
Is there some new prohibition on FSF copyrighted GPLv3 licenced code
(inside branches) providing plugins? Or did I (hopefully) misunderstood?
Can a branch only (or mostly) provide a plugin? If not, why? If a branch
cannot provide a plugin, who, when was decided such a major decision? I
feel such a decision fully in contradiction with the idea of accepting
plugins in GCC.
Please take time to explain, and remember that I am not an English
native speaker, that I am not familiar with the US law system or the
American corporate culture, and that MELT branch was always designed
with meta-programming & dlopening generated code in mind. MELT has
absolutely no sense on system without dlopen (or an equivalent
functionality. So far, MELT is using ltdl).
Regards.
Note *: the MELT branch always provided a plugin mechanism. It is
essential to MELT to generate C code and run it. I always said that
dlopen is essential to MELT
PS. My understanding of the runtime license exception discussion last
year was that the FSF & the SC wanted to promote the idea of GPLv3
licencsd plugins [and of course restrain proprietary plugins] not to
discourage them (and rejecting the idea of FSF copyrighted GPLv3
licenced plugins might not be perceived as encouraging GPLv3 plugins).
--
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: diagnostics-branch merged into mainline
Rafael Espindola wrote: >> This is ok, too. I assume you have done a regression test? ;) > > On the fix patch? The file would not build without it > > I did test the original patch, but missed the winnt file. > > Cheers, I did look at the file myself, but couldn't tell (without studying your original patch in much more depth first) whether DECL_ASSEMBLER_NAME or something else was right for the second arg - I saw some places where you'd used cxx_comdat_group, and couldn't immediately know whether to worry about C++ in the encode_section_info hook, or whether the DECL_ASSEMBLER_NAME would be definitively right at that point. cheers, DaveK
Re: instructions for compiling plugins?
Rafael Espindola wrote: (citing me Basile)
Apparently, the goal is to be able to compile (at least some) plugins
without having the GCC source tree or build tree.
Correct.
However, I believe we don't have any documentation stating that. At least
not in http://gcc.gnu.org/onlinedocs/gccint/Plugins.html and not in
http://gcc.gnu.org/wiki/plugins
I did submit a documentation patch. See
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01169.html
(yes, my English language is poor. I would expect some improvements).
regards.
--
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 with BLOCK vs BIND_EXPR trees
On Tue, Jun 16, 2009 at 1:50 PM, Jerry Quinn wrote: > (trying again) > Hi, all. I have a basic question about GENERIC trees. > > I'm playing with writing a front end, and find the distinction between > BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying > to get a handle on how to represent a function in GENERIC form. > > On the surface the texi docs and code comments don't seem to agree: > > Section on function trees say FUNCTION_DECL represents a function, and > that DECL_INITIAL is not empty. But it doesn't say what should be > contained there. It says DECL_SAVED_TREE should contain the body of the > function. > > The comments in tree.h say that DECL_INITIAL holds the body of a > function, with a BLOCK tree at the root. > > BLOCK nodes are described under TREE_SSA->GIMPLE, though these nodes are > part of GENERIC if I understand correctly. At least, the docs say that > any tree code found in tree.def is part of GENERIC. In this section, it says > that block scopes and variables are declared in BIND_EXPR nodes. > > Can someone please clarify how these things are supposed to fit together in > GENERIC form, assuming the default conversion to GIMPLE will be used? BIND_EXPRs are containers for local variables in the GENERIC function body (they persist until GIMPLE is lowered). BLOCKs represent the scope tree of the function (which also refers to local variables). The BLOCK tree is kept live throughout the compilation and is used to generate proper debug information for example. Richard.
Re: Questions about VAR_DECL and DECL_EXPR
On Tue, Jun 16, 2009 at 2:14 PM, Jerry Quinn wrote: > Hi, again, > > I am a little unclear on VAR_DECL and DECL_EXPR. The impression I get > from reading the docs is that when a variable is first declared in a > function, a VAR_DECL should be created, possibly with DECL_INITIAL() > set. > > What's less clearly stated is what you use for variable references later > in the code. I think you also use VAR_DECL for this purpose, but I'm > not sure. Could someone clarify? If so, must it be the same tree node > or does it just have to be another VAR_DECL with the same variable name? The same VAR_DECL. > > There is also DECL_EXPR representing local declarations, which appears > to be related. How do these get used and would it even be used in a > C-like language? Looking at how the gimplifier treats them may answer your question. I don't know off-hand. Richard. > Thanks, > Jerry Quinn > > >
Re: "plugin"-ifying the MELT branch.
On Tue, Jun 16, 2009 at 2:22 PM, Basile STARYNKEVITCH wrote: > > I (Basile) very probably misunderstood what Joseph Myers or Richard Guenther > meant. What I might have [mis]understood scares me. This is a request for > clarification. > > > Joseph S. Myers wrote: > > >> On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote: >> >> >>> >>> I thought on the contrary that is was expected that some code would >>> become FSF >>> owned plugins? >>> >> >> Not without a mechanism for linking plugins in statically on hosts for >> which we don't support dynamic loading of plugins, and even then it's >> doubtful. > > That mechanism already exists in libltdl (the libtool wrapper of dlopen). > > However, I am not sure to understand the logic here. Plugins are by > definition optional stuff, and I understood from the beginning that plugins > are considered only on machines which have a way of dynamically loading code > (currently, the documented constraint is even stronger: dlopen & -rdynamic). > >> Rather, we should watch out for things being implemented as plugins that >> are generally useful for GCC and seek to build them into GCC >> (unconditionally) where appropriate, while leaving cases such as checking >> project-specific coding rules as separate plugins. > > Again, I don't understand the rationale here. > > My broad feeling was that plugin feature is for code which could interest > some people, but does not interest every GCC user. (and MELT, or even ICI or > TreeHydra, fits the definition). > > In particular, there would probably be several plugins which give some extra > feedback to the developers using them, but do not modify the code generation > behavior of GCC. > > Did I understood that in your view no branch hosted on GCC SubVersion should > provide plugins? Why? Is it only your view, or some decision by some > powerful guys (e.g. the Steering Committee)? Did the MELT branch [*] > suddenly become illegal without me knowing about that? That would be > ironical for a branch which happened -with other branches & people- to have > pushed the idea of plugins! As you already said, a plugin is not a branch of trunk and so it should not be a branch of trunk. There is no way a user with usual SVN write access can (or should) add a new repository to host a plugin on gcc.gnu.org. Instead I suggest that plugins be hosted at whatever convenient public repository hosting site. Just because it does not make technical sense. No "powerful" entities are involved here. Richard.
Re: Questionable function renaming
On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng Mei wrote:
> Hello,
>
> I came across a function renaming issue in GCC 4.4.
>
> ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g -D_FILE_OFFSET_BITS=64
> -save-temps -c bzip2.c -fdump-tree-all
>
>
> Function saveInputFileMetaInfo is renamed to T.251 after ipa passes, which
> are not dumped into intermediate files. So compare bzip2.c.038t.release_ssa
> and bzip2.c.049t.copyrename2 file,
>
> ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
>
> Released 3 names, 50.00%
> saveInputFileMetaInfo (Char * srcName)
> {
> IntNative retVal;
>
> :
> retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
> if (retVal_4 != 0)
> goto ;
> else
> goto ;
>
> :
> ioError ();
>
> :
> return;
>
> }
>
> becomes
>
> ;; Function T.251 (T.251)
>
> T.251 ()
> {
> IntNative retVal;
>
> :
> retVal_1 = __xstat (1, &inName, &fileMetaInfo);
> if (retVal_1 != 0)
> goto ;
> else
> goto ;
>
> :
> ioError ();
>
> :
> return;
>
> }
>
> The renamed function stays afterwards. My understanding is that ipa-cp pass
> did copy-propagation of the original function but still somehow create a
> clone as suggested bzip2.c.203t.statistics.
>
> bzip2.c.203t.statistics:35 copyprop "Copies propagated"
> "saveInputFileMetaInfo" 1
> bzip2.c.203t.statistics:35 copyprop "Statements deleted"
> "saveInputFileMetaInfo" 3
>
> This seems unnecessary and causes trouble in our profiling/debugging tools. I
> could diable this by using -fno-ipa-cp. But is there any better way? Thanks
> in advance
It constant propagated &inName here (probably not very profitable
as no further optimization is performed on the body) and removed
the then unused parameter.
Any better way to do what?
Richard.
> Cheers,
> Bingfeng Mei
>
> Boradcom UK
RE: Questionable function renaming
Is it possible to restore the original name if the copy propagation is not
profitable and doesn't go ahead?
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 16 June 2009 13:56
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Questionable function renaming
>
> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng
> Mei wrote:
> > Hello,
> >
> > I came across a function renaming issue in GCC 4.4.
> >
> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g
> -D_FILE_OFFSET_BITS=64 -save-temps -c bzip2.c -fdump-tree-all
> >
> >
> > Function saveInputFileMetaInfo is renamed to T.251 after
> ipa passes, which are not dumped into intermediate files. So
> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file,
> >
> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
> >
> > Released 3 names, 50.00%
> > saveInputFileMetaInfo (Char * srcName)
> > {
> > IntNative retVal;
> >
> > :
> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
> > if (retVal_4 != 0)
> > goto ;
> > else
> > goto ;
> >
> > :
> > ioError ();
> >
> > :
> > return;
> >
> > }
> >
> > becomes
> >
> > ;; Function T.251 (T.251)
> >
> > T.251 ()
> > {
> > IntNative retVal;
> >
> > :
> > retVal_1 = __xstat (1, &inName, &fileMetaInfo);
> > if (retVal_1 != 0)
> > goto ;
> > else
> > goto ;
> >
> > :
> > ioError ();
> >
> > :
> > return;
> >
> > }
> >
> > The renamed function stays afterwards. My understanding is
> that ipa-cp pass did copy-propagation of the original
> function but still somehow create a clone as suggested
> bzip2.c.203t.statistics.
> >
> > bzip2.c.203t.statistics:35 copyprop "Copies propagated"
> "saveInputFileMetaInfo" 1
> > bzip2.c.203t.statistics:35 copyprop "Statements deleted"
> "saveInputFileMetaInfo" 3
> >
> > This seems unnecessary and causes trouble in our
> profiling/debugging tools. I could diable this by using
> -fno-ipa-cp. But is there any better way? Thanks in advance
>
> It constant propagated &inName here (probably not very profitable
> as no further optimization is performed on the body) and removed
> the then unused parameter.
>
> Any better way to do what?
>
> Richard.
>
> > Cheers,
> > Bingfeng Mei
> >
> > Boradcom UK
>
>
Re: Questionable function renaming
On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng Mei wrote:
> Is it possible to restore the original name if the copy propagation is not
> profitable and doesn't go ahead?
The calling convention is changed, so I don't see how this is
easily possible.
Richard.
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 16 June 2009 13:56
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Questionable function renaming
>>
>> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng
>> Mei wrote:
>> > Hello,
>> >
>> > I came across a function renaming issue in GCC 4.4.
>> >
>> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g
>> -D_FILE_OFFSET_BITS=64 -save-temps -c bzip2.c -fdump-tree-all
>> >
>> >
>> > Function saveInputFileMetaInfo is renamed to T.251 after
>> ipa passes, which are not dumped into intermediate files. So
>> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file,
>> >
>> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
>> >
>> > Released 3 names, 50.00%
>> > saveInputFileMetaInfo (Char * srcName)
>> > {
>> > IntNative retVal;
>> >
>> > :
>> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
>> > if (retVal_4 != 0)
>> > goto ;
>> > else
>> > goto ;
>> >
>> > :
>> > ioError ();
>> >
>> > :
>> > return;
>> >
>> > }
>> >
>> > becomes
>> >
>> > ;; Function T.251 (T.251)
>> >
>> > T.251 ()
>> > {
>> > IntNative retVal;
>> >
>> > :
>> > retVal_1 = __xstat (1, &inName, &fileMetaInfo);
>> > if (retVal_1 != 0)
>> > goto ;
>> > else
>> > goto ;
>> >
>> > :
>> > ioError ();
>> >
>> > :
>> > return;
>> >
>> > }
>> >
>> > The renamed function stays afterwards. My understanding is
>> that ipa-cp pass did copy-propagation of the original
>> function but still somehow create a clone as suggested
>> bzip2.c.203t.statistics.
>> >
>> > bzip2.c.203t.statistics:35 copyprop "Copies propagated"
>> "saveInputFileMetaInfo" 1
>> > bzip2.c.203t.statistics:35 copyprop "Statements deleted"
>> "saveInputFileMetaInfo" 3
>> >
>> > This seems unnecessary and causes trouble in our
>> profiling/debugging tools. I could diable this by using
>> -fno-ipa-cp. But is there any better way? Thanks in advance
>>
>> It constant propagated &inName here (probably not very profitable
>> as no further optimization is performed on the body) and removed
>> the then unused parameter.
>>
>> Any better way to do what?
>>
>> Richard.
>>
>> > Cheers,
>> > Bingfeng Mei
>> >
>> > Boradcom UK
>>
>>
>
Re: "plugin"-ifying the MELT branch.
On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote: > > > I thought on the contrary that is was expected that some code would become > > > FSF > > > owned plugins? > > > > > > > Not without a mechanism for linking plugins in statically on hosts for which > > we don't support dynamic loading of plugins, and even then it's doubtful. > That mechanism already exists in libltdl (the libtool wrapper of dlopen). As already discussed at length, libltdl is liable to make building GCC and making effectively redistributable binaries without problematic dependencies much harder and so using it would be a bad idea. > However, I am not sure to understand the logic here. Plugins are by definition > optional stuff, and I understood from the beginning that plugins are > considered only on machines which have a way of dynamically loading code > (currently, the documented constraint is even stronger: dlopen & -rdynamic). Making features presently supported by GCC optional and completely unavailable on many host platforms would be a clear regression. > > Rather, we should watch out for things being implemented as plugins that are > > generally useful for GCC and seek to build them into GCC (unconditionally) > > where appropriate, while leaving cases such as checking project-specific > > coding rules as separate plugins. > Again, I don't understand the rationale here. > > My broad feeling was that plugin feature is for code which could interest some > people, but does not interest every GCC user. (and MELT, or even ICI or > TreeHydra, fits the definition). The criterion for being appropriate to include in GCC is different from interesting every GCC user. Nothing interests every GCC user. > In particular, there would probably be several plugins which give some extra > feedback to the developers using them, but do not modify the code generation > behavior of GCC. If the feedback relates to the use of a particular library not provided by GCC, for example, that is probably an appropriate case for a plugin provided by that library rather than by GCC. If it is generally relevant to users of a particular language feature or feature in a language's standard library, like existing warnings in GCC, it is probably an appropriate case for code in GCC proper. > Did I understood that in your view no branch hosted on GCC SubVersion should > provide plugins? Why? Is it only your view, or some decision by some powerful I did not say anything about what branches should provide. My comments are about the question of whether feature X should go in trunk or in a separate plugin, given that there is an implementation that is or can be assigned to the FSF and that is technically ready to go in trunk. > This surprises me a big lot. I thought on the contrary that specialized > plugins would be used inside GCC in the future (for GCC development). To be > more concrete, one could imagine a plugin to check all the error & warning > messages inside GCC for validity (attribute printf is not fully adequate for > that purpose). And my interpretation of GTY as attribute discussion was that I could indeed imagine that those warnings that are present in GCC only for use when building GCC might usefully become plugins - but not without being able to build them in statically when bootstrapping on a platform on which plugins are not supported. This would be most useful if the plugins supported multiple host GCC versions so that the host GCC 4.5 building a 4.6 cross compiler could load the plugin for the version of checking relevant for building GCC 4.6. This is the special case above of code only useful for compiling one particular piece of software (where that one piece of software just happens to be GCC). > someone is dreaming to replace gengtype, in a distant future, by some plugin > providing the same behavior as gengtype (there is a bootstrap chicken&egg > issue in that case, but one could easily store the generated gt-*.h file in > the source tree, as it is already done for autoconf stuff today). It would be better to have fewer generated files in the source tree and fewer bootstrap dependencies or dependencies for modifying GCC and building a modified version, not more. (I also don't know what host and target dependencies those files might have.) Portable tools that can be built using any ISO C compiler are far better than depending on complicated host-specific features of a particular version of GCC. If we move to C++ as implementation language I believe we should keep the ability to build with non-GCC ISO C++ compilers and with a wide range of GCC versions. -- Joseph S. Myers jos...@codesourcery.com
Re: Help with BLOCK vs BIND_EXPR trees
On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
> BIND_EXPRs are containers for local variables in the GENERIC
> function body (they persist until GIMPLE is lowered). BLOCKs
> represent the scope tree of the function (which also refers to
> local variables). The BLOCK tree is kept live throughout the
> compilation and is used to generate proper debug information
> for example.
So let me see if I understand with an example from C. If we have the
following C function:
void foo() {
int a;
{ int b; }
{ int c; }
}
then starting with FUNCTION_DECL, we should have pseudocode for the
GENERIC something like the following?
tree foo = FUNCTION_DECL
tree int_a = VAR_DECL
tree int_b = VAR_DECL
tree int_c = VAR_DECL
tree scope_b = BIND_EXPR
BIND_EXPR_VARS(scope_b) = int_b
BIND_EXPR_BODY(scope_b) = int_b
tree scope_c = BIND_EXPR
BIND_EXPR_VARS(scope_c) = int_b
BIND_EXPR_BODY(scope_c) = int_b
tree foo_body = STATEMENT_LIST
// I know this is actually a tree-iterator
foo_body = { int_a, scope_b, scope_c }
tree scope_foo = BIND_EXPR
BIND_EXPR_VARS(scope_foo) = int_a
BIND_EXPR_BODY(scope_foo) = foo_body
DECL_SAVED_FUNCTION(foo) = scope_foo
tree block_foo = BLOCK
tree block_b = BLOCK
tree block_c = BLOCK
BLOCK_VARS(block_b) = int_b
BLOCK_SUPERCONTEXT(block_b) = block_foo
BLOCK_CHAIN(block_b) = block_c
BLOCK_VARS(block_c) = int_c
BLOCK_SUPERCONTEXT(block_c) = block_foo
BLOCK_CHAIN(block_c) = null
BLOCK_VARS(block_foo) = int_a
BLOCK_SUPERCONTEXT(block_foo) = foo
BLOCK_CHAIN(block_foo) = null
BLOCK_SUBBLOCKS(block_foo) = block_b, block_c
DECL_INITIAL(foo) = block_foo
Thanks for taking the time to clarify things for me,
Jerry
Re: Address mode offset spill
daniel tian writes:
> mvx_audio_dec_mp3_test.c:112: error: unable to find a register to
> spill in class 'R0_REG'
> mvx_audio_dec_mp3_test.c:112: error: this is the insn:
> (insn 185 134 133 6 (set (reg/f:SI 4 R4 [101])
> (const_int 2076 [0x81c])) 4 {load_imm_low_si} (nil)
> (expr_list:REG_EQUIV (const_int 2076 [0x81c])
> (nil)))
>
> PS: there are 16 general registers in my RISC chip, from R0 to R15.
> R14, and R15 are used for FP,SP. R0 register is special.
> Every large immediate, larger than 512, must be moved into R0
> register, which means that R0 is the only register to load large
> immediate.
One thing you certainly need to do is set REG_ALLOC_ORDER so that r0 is
the last register allocated.
> I have traced the rtl code, and RTL code was combined from two rtl
> instructions(R14 is Frame pointer register):
>
> (insn 129 127 168 6 (set (reg:SI 88)
> (const_int 2064 [0x810])) 4 {load_imm_low_si} (nil)
> (nil))
>
> (insn 168 129 131 6 (set (reg/f:SI 101)
> (plus:SI (reg/f:SI 14 R14)
> (const_int 12 [0xc]))) 45 {rice_addsi3} (nil)
> (nil))
>
> (insn 133 131 134 6 (set (reg:SI 4 R4)
> (plus:SI (reg/f:SI 101)
> (reg:SI 88))) 45 {rice_addsi3} (nil)
> (expr_list:REG_EQUAL (plus:SI (reg/f:SI 14 R14)
> (const_int 2076 [0x81c]))
> (nil)))
You need to set TARGET_RTX_COSTS so that constants larger than 512 are
more expensive than registers. That should prevent the constant from
being propagated into the insn.
> So before cc1 crashed, the unrecognized insn doesn't go through the
> LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro.
> Is there any solution I can handle the similar problems?
You're right, for a pure load like this, you will need a secondary
reload.
Ian
Re: git mirror at gcc.gnu.org
On 06/15/2009 01:22 PM, Bernie Innocenti wrote: On 06/15/09 16:28, Rafael Espindola wrote: It fails with $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' $ git fetch fatal: refs/remotes/origin/gcc-4_0-branch tracks both refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch Perhaps I should remove those "friendly" refs pointing at the remote branches? Or can we find a better alternative? Their use was to make a few frequently used branches readily visible in gitweb and with a simple clone. It makes sense to me to have the friendly refs so that the simple case (clone, don't try to use svn directly) works easily. What I'm doing doesn't have any problem with them. Rafael was following older instructions written by someone else. When I started editing that page, I put my suggestions at the bottom because I was fairly new to git. Now I feel more confident that what I'm doing is right (or at least better) so I think I'll remove the old instructions. But what are oldmaster/pre-globals-git/restrict-git? And why have both "master" and "trunk" as heads? Perhaps git-svn could be configured to map svn branches directly to the local namespace instead of remotes/ ? It could, but it seems unnecessary. Jason
Re: git mirror at gcc.gnu.org
On Tue, Jun 16, 2009 at 10:17 AM, Jason Merrill wrote: > On 06/15/2009 01:22 PM, Bernie Innocenti wrote: >> >> On 06/15/09 16:28, Rafael Espindola wrote: >>> >>> It fails with >>> >>> $ git config --add remote.origin.fetch >>> '+refs/remotes/*:refs/remotes/origin/*' >>> $ git fetch >>> fatal: refs/remotes/origin/gcc-4_0-branch tracks both >>> refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch >> >> Perhaps I should remove those "friendly" refs pointing at the remote >> branches? Or can we find a better alternative? Their use was to make a >> few frequently used branches readily visible in gitweb and with a simple >> clone. > > It makes sense to me to have the friendly refs so that the simple case > (clone, don't try to use svn directly) works easily. > > What I'm doing doesn't have any problem with them. Rafael was following > older instructions written by someone else. When I started editing that > page, I put my suggestions at the bottom because I was fairly new to git. > Now I feel more confident that what I'm doing is right (or at least better) > so I think I'll remove the old instructions. > > But what are oldmaster/pre-globals-git/restrict-git? pre-globals-git and restrict-git were test branches from an old mostly broken version. ;) They are dead and if someone wants to manually remove the refs, go for it. No idea what oldmaster is. > And why have both > "master" and "trunk" as heads? > See "broken" ;) >> Perhaps git-svn could be configured to map svn branches directly to the >> local namespace instead of remotes/ ? > > It could, but it seems unnecessary. > > Jason >
RE: Questionable function renaming
Thanks, I didn't notice both functions have different arguments after
transformation.
However, gprof produces T.251 in its statistics, completely unknown
to user. Could GCC use more informative name here, e.g.,
saveInputFileMetaInfo.251?
50.01 0.01 0.01 24 0.42 0.42 BZ2_hbMakeCodeLengths
50.01 0.02 0.01110.0010.00 mainSort
0.00 0.02 0.00 58 0.00 0.34 BZ2_bzCompress
0.00 0.02 0.00 58 0.00 0.34 handle_compress
0.00 0.02 0.00 43 0.00 0.34 BZ2_bzWrite
0.00 0.02 0.006 0.00 0.00 BZ2_hbAssignCodes
0.00 0.02 0.004 0.00 0.00 default_bzalloc
0.00 0.02 0.004 0.00 0.00 default_bzfree
0.00 0.02 0.002 0.00 0.00 addFlagsFromEnvVar
0.00 0.02 0.002 0.00 0.00 myMalloc
0.00 0.02 0.001 0.0010.00 BZ2_blockSort
0.00 0.02 0.001 0.00 0.00 BZ2_bzCompressInit
0.00 0.02 0.001 0.00 5.17 BZ2_bzWriteClose64
0.00 0.02 0.001 0.00 0.00 BZ2_bzWriteOpen
0.00 0.02 0.001 0.0020.00 BZ2_compressBlock
0.00 0.02 0.001 0.00 0.00 T.251
0.00 0.02 0.001 0.0020.00 compress
0.00 0.02 0.001 0.0020.00 compressStream
0.00 0.02 0.001 0.00 0.00 snocString
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 16 June 2009 14:02
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Questionable function renaming
>
> On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng
> Mei wrote:
> > Is it possible to restore the original name if the copy
> propagation is not profitable and doesn't go ahead?
>
> The calling convention is changed, so I don't see how this is
> easily possible.
>
> Richard.
>
> >> -Original Message-
> >> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> >> Sent: 16 June 2009 13:56
> >> To: Bingfeng Mei
> >> Cc: gcc@gcc.gnu.org
> >> Subject: Re: Questionable function renaming
> >>
> >> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng
> >> Mei wrote:
> >> > Hello,
> >> >
> >> > I came across a function renaming issue in GCC 4.4.
> >> >
> >> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g
> >> -D_FILE_OFFSET_BITS=64 -save-temps -c bzip2.c -fdump-tree-all
> >> >
> >> >
> >> > Function saveInputFileMetaInfo is renamed to T.251 after
> >> ipa passes, which are not dumped into intermediate files. So
> >> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file,
> >> >
> >> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
> >> >
> >> > Released 3 names, 50.00%
> >> > saveInputFileMetaInfo (Char * srcName)
> >> > {
> >> > IntNative retVal;
> >> >
> >> > :
> >> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
> >> > if (retVal_4 != 0)
> >> > goto ;
> >> > else
> >> > goto ;
> >> >
> >> > :
> >> > ioError ();
> >> >
> >> > :
> >> > return;
> >> >
> >> > }
> >> >
> >> > becomes
> >> >
> >> > ;; Function T.251 (T.251)
> >> >
> >> > T.251 ()
> >> > {
> >> > IntNative retVal;
> >> >
> >> > :
> >> > retVal_1 = __xstat (1, &inName, &fileMetaInfo);
> >> > if (retVal_1 != 0)
> >> > goto ;
> >> > else
> >> > goto ;
> >> >
> >> > :
> >> > ioError ();
> >> >
> >> > :
> >> > return;
> >> >
> >> > }
> >> >
> >> > The renamed function stays afterwards. My understanding is
> >> that ipa-cp pass did copy-propagation of the original
> >> function but still somehow create a clone as suggested
> >> bzip2.c.203t.statistics.
> >> >
> >> > bzip2.c.203t.statistics:35 copyprop "Copies propagated"
> >> "saveInputFileMetaInfo" 1
> >> > bzip2.c.203t.statistics:35 copyprop "Statements deleted"
> >> "saveInputFileMetaInfo" 3
> >> >
> >> > This seems unnecessary and causes trouble in our
> >> profiling/debugging tools. I could diable this by using
> >> -fno-ipa-cp. But is there any better way? Thanks in advance
> >>
> >> It constant propagated &inName here (probably not very profitable
> >> as no further optimization is performed on the body) and removed
> >> the then unused parameter.
> >>
> >> Any better way to do what?
> >>
> >> Richard.
> >>
> >> > Cheers,
> >> > Bingfeng Mei
> >> >
> >> > Boradcom UK
> >>
> >>
> >
>
>
Re: Help with BLOCK vs BIND_EXPR trees
On Tue, Jun 16, 2009 at 3:19 PM, Jerry Quinn wrote:
> On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote:
>> BIND_EXPRs are containers for local variables in the GENERIC
>> function body (they persist until GIMPLE is lowered). BLOCKs
>> represent the scope tree of the function (which also refers to
>> local variables). The BLOCK tree is kept live throughout the
>> compilation and is used to generate proper debug information
>> for example.
>
> So let me see if I understand with an example from C. If we have the
> following C function:
>
> void foo() {
> int a;
> { int b; }
> { int c; }
> }
>
>
> then starting with FUNCTION_DECL, we should have pseudocode for the
> GENERIC something like the following?
>
>
> tree foo = FUNCTION_DECL
>
> tree int_a = VAR_DECL
> tree int_b = VAR_DECL
> tree int_c = VAR_DECL
>
> tree scope_b = BIND_EXPR
> BIND_EXPR_VARS(scope_b) = int_b
> BIND_EXPR_BODY(scope_b) = int_b
>
> tree scope_c = BIND_EXPR
> BIND_EXPR_VARS(scope_c) = int_b
> BIND_EXPR_BODY(scope_c) = int_b
>
> tree foo_body = STATEMENT_LIST
> // I know this is actually a tree-iterator
> foo_body = { int_a, scope_b, scope_c }
>
> tree scope_foo = BIND_EXPR
> BIND_EXPR_VARS(scope_foo) = int_a
> BIND_EXPR_BODY(scope_foo) = foo_body
>
> DECL_SAVED_FUNCTION(foo) = scope_foo
>
> tree block_foo = BLOCK
> tree block_b = BLOCK
> tree block_c = BLOCK
>
> BLOCK_VARS(block_b) = int_b
> BLOCK_SUPERCONTEXT(block_b) = block_foo
> BLOCK_CHAIN(block_b) = block_c
>
> BLOCK_VARS(block_c) = int_c
> BLOCK_SUPERCONTEXT(block_c) = block_foo
> BLOCK_CHAIN(block_c) = null
>
> BLOCK_VARS(block_foo) = int_a
> BLOCK_SUPERCONTEXT(block_foo) = foo
> BLOCK_CHAIN(block_foo) = null
> BLOCK_SUBBLOCKS(block_foo) = block_b, block_c
>
>
> DECL_INITIAL(foo) = block_foo
>
>
Yes, that is about right.
Richard.
>
> Thanks for taking the time to clarify things for me,
> Jerry
>
>
>
>
>
>
>
>
>
Re: Questionable function renaming
On Tue, Jun 16, 2009 at 3:49 PM, Bingfeng Mei wrote:
> Thanks, I didn't notice both functions have different arguments after
> transformation.
> However, gprof produces T.251 in its statistics, completely unknown
> to user. Could GCC use more informative name here, e.g.,
> saveInputFileMetaInfo.251?
Probably we should set the clones abstract origin appropriately
and gprof should use debug information to show that instead ...
Richard.
> 50.01 0.01 0.01 24 0.42 0.42 BZ2_hbMakeCodeLengths
> 50.01 0.02 0.01 1 10.00 10.00 mainSort
> 0.00 0.02 0.00 58 0.00 0.34 BZ2_bzCompress
> 0.00 0.02 0.00 58 0.00 0.34 handle_compress
> 0.00 0.02 0.00 43 0.00 0.34 BZ2_bzWrite
> 0.00 0.02 0.00 6 0.00 0.00 BZ2_hbAssignCodes
> 0.00 0.02 0.00 4 0.00 0.00 default_bzalloc
> 0.00 0.02 0.00 4 0.00 0.00 default_bzfree
> 0.00 0.02 0.00 2 0.00 0.00 addFlagsFromEnvVar
> 0.00 0.02 0.00 2 0.00 0.00 myMalloc
> 0.00 0.02 0.00 1 0.00 10.00 BZ2_blockSort
> 0.00 0.02 0.00 1 0.00 0.00 BZ2_bzCompressInit
> 0.00 0.02 0.00 1 0.00 5.17 BZ2_bzWriteClose64
> 0.00 0.02 0.00 1 0.00 0.00 BZ2_bzWriteOpen
> 0.00 0.02 0.00 1 0.00 20.00 BZ2_compressBlock
> 0.00 0.02 0.00 1 0.00 0.00 T.251
> 0.00 0.02 0.00 1 0.00 20.00 compress
> 0.00 0.02 0.00 1 0.00 20.00 compressStream
> 0.00 0.02 0.00 1 0.00 0.00 snocString
>
> Bingfeng
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 16 June 2009 14:02
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Questionable function renaming
>>
>> On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng
>> Mei wrote:
>> > Is it possible to restore the original name if the copy
>> propagation is not profitable and doesn't go ahead?
>>
>> The calling convention is changed, so I don't see how this is
>> easily possible.
>>
>> Richard.
>>
>> >> -Original Message-
>> >> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> >> Sent: 16 June 2009 13:56
>> >> To: Bingfeng Mei
>> >> Cc: gcc@gcc.gnu.org
>> >> Subject: Re: Questionable function renaming
>> >>
>> >> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng
>> >> Mei wrote:
>> >> > Hello,
>> >> >
>> >> > I came across a function renaming issue in GCC 4.4.
>> >> >
>> >> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g
>> >> -D_FILE_OFFSET_BITS=64 -save-temps -c bzip2.c -fdump-tree-all
>> >> >
>> >> >
>> >> > Function saveInputFileMetaInfo is renamed to T.251 after
>> >> ipa passes, which are not dumped into intermediate files. So
>> >> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file,
>> >> >
>> >> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
>> >> >
>> >> > Released 3 names, 50.00%
>> >> > saveInputFileMetaInfo (Char * srcName)
>> >> > {
>> >> > IntNative retVal;
>> >> >
>> >> > :
>> >> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
>> >> > if (retVal_4 != 0)
>> >> > goto ;
>> >> > else
>> >> > goto ;
>> >> >
>> >> > :
>> >> > ioError ();
>> >> >
>> >> > :
>> >> > return;
>> >> >
>> >> > }
>> >> >
>> >> > becomes
>> >> >
>> >> > ;; Function T.251 (T.251)
>> >> >
>> >> > T.251 ()
>> >> > {
>> >> > IntNative retVal;
>> >> >
>> >> > :
>> >> > retVal_1 = __xstat (1, &inName, &fileMetaInfo);
>> >> > if (retVal_1 != 0)
>> >> > goto ;
>> >> > else
>> >> > goto ;
>> >> >
>> >> > :
>> >> > ioError ();
>> >> >
>> >> > :
>> >> > return;
>> >> >
>> >> > }
>> >> >
>> >> > The renamed function stays afterwards. My understanding is
>> >> that ipa-cp pass did copy-propagation of the original
>> >> function but still somehow create a clone as suggested
>> >> bzip2.c.203t.statistics.
>> >> >
>> >> > bzip2.c.203t.statistics:35 copyprop "Copies propagated"
>> >> "saveInputFileMetaInfo" 1
>> >> > bzip2.c.203t.statistics:35 copyprop "Statements deleted"
>> >> "saveInputFileMetaInfo" 3
>> >> >
>> >> > This seems unnecessary and causes trouble in our
>> >> profiling/debugging tools. I could diable this by using
>> >> -fno-ipa-cp. But is there any better way? Thanks in advance
>> >>
>> >> It constant propagated &inName here (probably not very profitable
>> >> as no further optimization is performed on the body) and removed
>> >> the then unused parameter.
>> >>
>> >> Any better way to do what?
>> >>
>> >> Richard.
>> >>
>> >> > Cheers,
>> >> > Bingfeng Mei
>> >> >
>> >> > Boradcom UK
>> >>
>> >>
>> >
>>
>>
>
Re: Questionable function renaming
Hi,
On Tue, Jun 16, 2009 at 06:49:58AM -0700, Bingfeng Mei wrote:
> Thanks, I didn't notice both functions have different arguments after
> transformation.
> However, gprof produces T.251 in its statistics, completely unknown
> to user. Could GCC use more informative name here, e.g.,
> saveInputFileMetaInfo.251?
The current trunk (what is to become gcc 4.5) already gives clones a
more sensible name, in your example it would be
saveInputFileMetaInfo.clone.0 (IIRC).
By the way, I work on allowing ipa-cp to produce multiple clones of a
single function. Their names will differ in the number after the last
dot.
Martin
>
> 50.01 0.01 0.01 24 0.42 0.42 BZ2_hbMakeCodeLengths
> 50.01 0.02 0.01110.0010.00 mainSort
> 0.00 0.02 0.00 58 0.00 0.34 BZ2_bzCompress
> 0.00 0.02 0.00 58 0.00 0.34 handle_compress
> 0.00 0.02 0.00 43 0.00 0.34 BZ2_bzWrite
> 0.00 0.02 0.006 0.00 0.00 BZ2_hbAssignCodes
> 0.00 0.02 0.004 0.00 0.00 default_bzalloc
> 0.00 0.02 0.004 0.00 0.00 default_bzfree
> 0.00 0.02 0.002 0.00 0.00 addFlagsFromEnvVar
> 0.00 0.02 0.002 0.00 0.00 myMalloc
> 0.00 0.02 0.001 0.0010.00 BZ2_blockSort
> 0.00 0.02 0.001 0.00 0.00 BZ2_bzCompressInit
> 0.00 0.02 0.001 0.00 5.17 BZ2_bzWriteClose64
> 0.00 0.02 0.001 0.00 0.00 BZ2_bzWriteOpen
> 0.00 0.02 0.001 0.0020.00 BZ2_compressBlock
> 0.00 0.02 0.001 0.00 0.00 T.251
> 0.00 0.02 0.001 0.0020.00 compress
> 0.00 0.02 0.001 0.0020.00 compressStream
> 0.00 0.02 0.001 0.00 0.00 snocString
>
> Bingfeng
>
> > -Original Message-
> > From: Richard Guenther [mailto:richard.guent...@gmail.com]
> > Sent: 16 June 2009 14:02
> > To: Bingfeng Mei
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: Questionable function renaming
> >
> > On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng
> > Mei wrote:
> > > Is it possible to restore the original name if the copy
> > propagation is not profitable and doesn't go ahead?
> >
> > The calling convention is changed, so I don't see how this is
> > easily possible.
> >
> > Richard.
> >
> > >> -Original Message-
> > >> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> > >> Sent: 16 June 2009 13:56
> > >> To: Bingfeng Mei
> > >> Cc: gcc@gcc.gnu.org
> > >> Subject: Re: Questionable function renaming
> > >>
> > >> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng
> > >> Mei wrote:
> > >> > Hello,
> > >> >
> > >> > I came across a function renaming issue in GCC 4.4.
> > >> >
> > >> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g
> > >> -D_FILE_OFFSET_BITS=64 -save-temps -c bzip2.c -fdump-tree-all
> > >> >
> > >> >
> > >> > Function saveInputFileMetaInfo is renamed to T.251 after
> > >> ipa passes, which are not dumped into intermediate files. So
> > >> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file,
> > >> >
> > >> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo)
> > >> >
> > >> > Released 3 names, 50.00%
> > >> > saveInputFileMetaInfo (Char * srcName)
> > >> > {
> > >> > IntNative retVal;
> > >> >
> > >> > :
> > >> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo);
> > >> > if (retVal_4 != 0)
> > >> > goto ;
> > >> > else
> > >> > goto ;
> > >> >
> > >> > :
> > >> > ioError ();
> > >> >
> > >> > :
> > >> > return;
> > >> >
> > >> > }
> > >> >
> > >> > becomes
> > >> >
> > >> > ;; Function T.251 (T.251)
> > >> >
> > >> > T.251 ()
> > >> > {
> > >> > IntNative retVal;
> > >> >
> > >> > :
> > >> > retVal_1 = __xstat (1, &inName, &fileMetaInfo);
> > >> > if (retVal_1 != 0)
> > >> > goto ;
> > >> > else
> > >> > goto ;
> > >> >
> > >> > :
> > >> > ioError ();
> > >> >
> > >> > :
> > >> > return;
> > >> >
> > >> > }
> > >> >
> > >> > The renamed function stays afterwards. My understanding is
> > >> that ipa-cp pass did copy-propagation of the original
> > >> function but still somehow create a clone as suggested
> > >> bzip2.c.203t.statistics.
> > >> >
> > >> > bzip2.c.203t.statistics:35 copyprop "Copies propagated"
> > >> "saveInputFileMetaInfo" 1
> > >> > bzip2.c.203t.statistics:35 copyprop "Statements deleted"
> > >> "saveInputFileMetaInfo" 3
> > >> >
> > >> > This seems unnecessary and causes trouble in our
> > >> profiling/debugging tools. I could diable this by using
> > >> -fno-ipa-cp. But is there any better way? Thanks in advance
> > >>
> > >> It constant propagated &inName here (probably not very profitable
> > >> as no further optimization is performed on the body) and removed
> > >> the then unused parameter.
> > >>
> > >> Any better way to do what?
>
Re: Rationale for an old TRUNCATE patch
Adam Nemet writes: > I am trying to understand the checkin by Jeff Law from about 11 years ago: > >r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines > > >* combine.c (simplify_rtx, case TRUNCATE): Respect value of >TRULY_NOOP_TRUNCATION. > > >Index: combine.c >=== >--- combine.c (revision 19018) >+++ combine.c (revision 19204) >@@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest > if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) > break; > >- if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) >+ if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT >+&& TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), >+ GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0) > SUBST (XEXP (x, 0), > force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), > GET_MODE_MASK (mode), NULL_RTX, 0)); > > This optimization simplifies the input to a truncate by only computing bits > that won't be eliminated by the truncation. Normally these are the bits in > the output mode mask. Note that the optimization does not change the truncate > into a low-part subreg, which would pretty automatically warrant the > TRULY_NOOP_TRUNCATION check. I agree that this patch looks wrong in todays compiler. There should be no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. > Specifically I am curious if this was prompted by MIPS (or SH) or maybe some > other target that have a notion of truncate different from MIPS. It pretty much has to have been MIPS or SH since I don't think any other target back then defined TRULY_NOOP_TRUNCATION as anything other than 1. Ian
Re: AVR C++ - how to move vtables into FLASH memory
Tomasz Francuz writes: > I would like to change gcc so AVR C++ port will use FLASH memory > instead of SRAM to store virtual function pointers. Does anyone try to > do it? I have no experience as gcc developer, so can you head me to > appropriate files/literature about this particular problem? This question would be more appropriate for the mailing list gcc-h...@gcc.gnu.org than for g...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. Virtual tables will normally be placed in the .rodata section which holds read-only data. All you should need to do it arrange for the .rodata section to be placed in FLASH rather than SRAM. This would normally be done in your linker script. Ian
Re: Questionable function renaming
On Tue, Jun 16, 2009 at 04:34:01PM +0200, Martin Jambor wrote: > Hi, > > On Tue, Jun 16, 2009 at 06:49:58AM -0700, Bingfeng Mei wrote: > > Thanks, I didn't notice both functions have different arguments after > > transformation. > > However, gprof produces T.251 in its statistics, completely unknown > > to user. Could GCC use more informative name here, e.g., > > saveInputFileMetaInfo.251? > > The current trunk (what is to become gcc 4.5) already gives clones a > more sensible name, in your example it would be > saveInputFileMetaInfo.clone.0 (IIRC). Yeah, see http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01186.html Jakub
Re: Questions about VAR_DECL and DECL_EXPR
Jerry Quinn writes: > There is also DECL_EXPR representing local declarations, which appears > to be related. How do these get used and would it even be used in a > C-like language? The VAR_DECL is simply stored in the BLOCK, but in C++, C99, and GNU89, not all variables are declared at the start of a block. DECL_EXPR is used to mark the point in the instruction sequence where the variable is actually declared. The gimplifier turns this into an initialization of the variable. Ian
Re: git mirror at gcc.gnu.org
Incidentally, I notice that branches in subdirectories of branches/ are still broken; i.e. ARM apple redhat suse ubuntu, maybe others. I give instructions on the GitMirror page for how to deal with that, but I wonder if it's possible to set it up properly on the mirror instead. Jason
Re: diagnostics-branch merged into mainline
On Mon, Jun 15, 2009 at 2:18 PM, NightStrike wrote: > On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote: >>> ../../gcc/gcc/config/i386/winnt.c: In function >>> ?i386_pe_encode_section_info?: >>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to >>> function ?make_decl_one_only? >> >> make_decl_one_only expects one argument, and that's what's being fed. >> Could you please debug this and find out what's going on? >> > > I don't really know how to. Hopefully, Kai can help (I have him on the CC > list) > With the decl fix, everything builds again. Thanks, all!
Re: "plugin"-ifying the MELT branch.
On Tue, 2009-06-16 at 14:22 +0200, Basile STARYNKEVITCH wrote: > I (Basile) very probably misunderstood what Joseph Myers or Richard > Guenther meant. What I might have [mis]understood scares me. This is a > request for clarification. > Did I understood that in your view no branch hosted on GCC SubVersion > should provide plugins? Why? Is it only your view, or some decision by > some powerful guys (e.g. the Steering Committee)? Did the MELT branch > [*] suddenly become illegal without me knowing about that? That would be > ironical for a branch which happened -with other branches & people- to > have pushed the idea of plugins! > > Is there some [political?] impossibility for FSF copyrighted GPLv3 code > (like those sitting in branches, e.g. the MELT one) to become plugins? I > thought that becoming GPLv3/FSF plugins is an additional natural path > for code sitting in branched to become accepted in the trunk! I don't think that the responses have answered Basile's concerns. Basile, people are saying that MELT no longer belongs in a branch of the GCC repository because now that plug-ins are supported, MELT no longer needs to modify GCC itself and can be maintained independently. That does not mean that MELT cannot be assignd to the FSF (you should probably talk to the FSF about that) and certainly doesn't mean that it can't use GPLv3. It also doesn't mean that you should stop being part of the GCC community. All it means is that the MELT sources should now be hosted elsewhere as a separate project. Richi and Joseph, do you agree with that? Janis
Re: "plugin"-ifying the MELT branch.
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote: > Basile, people are saying that MELT no longer belongs in a branch of > the GCC repository because now that plug-ins are supported, MELT no > longer needs to modify GCC itself and can be maintained independently. > That does not mean that MELT cannot be assignd to the FSF (you should > probably talk to the FSF about that) and certainly doesn't mean that > it can't use GPLv3. It also doesn't mean that you should stop being > part of the GCC community. All it means is that the MELT sources > should now be hosted elsewhere as a separate project. Agreed. Additionally, I chatted with Taras last week at the summit about the various plugins that people have developed. I will be creating a landing wiki page where people can add links to plugins they have found or developed. This could be a good place where to add links to MELT. Diego.
Re: "plugin"-ifying the MELT branch.
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the GCC repository because now that plug-ins are supported, MELT no
longer needs to modify GCC itself and can be maintained independently.
MELT is not pluginified yet. So it will stay some time as a branch,
because today it cannot be a plugin (for various small technical details).
--
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: "plugin"-ifying the MELT branch.
On Tue, 16 Jun 2009, Janis Johnson wrote: > Basile, people are saying that MELT no longer belongs in a branch of > the GCC repository because now that plug-ins are supported, MELT no > longer needs to modify GCC itself and can be maintained independently. > That does not mean that MELT cannot be assignd to the FSF (you should > probably talk to the FSF about that) and certainly doesn't mean that > it can't use GPLv3. It also doesn't mean that you should stop being > part of the GCC community. All it means is that the MELT sources > should now be hosted elsewhere as a separate project. > > Richi and Joseph, do you agree with that? I have not been saying anything about whether or not MELT belongs in a branch of the GCC repository or where plugins should be hosted. My comments have been about general questions of what should or should not be a plugin rather than about what should be hosted where. -- Joseph S. Myers jos...@codesourcery.com
Re: AVR C++ - how to move vtables into FLASH memory
2009/6/16 Ian Lance Taylor : > Tomasz Francuz writes: > >> I would like to change gcc so AVR C++ port will use FLASH memory >> instead of SRAM to store virtual function pointers. Does anyone try to >> do it? I have no experience as gcc developer, so can you head me to >> appropriate files/literature about this particular problem? > > This question would be more appropriate for the mailing list > gcc-h...@gcc.gnu.org than for g...@gcc.gnu.org. Please take any > followups to gcc-help. Thanks. > > Virtual tables will normally be placed in the .rodata section which > holds read-only data. All you should need to do it arrange for the > .rodata section to be placed in FLASH rather than SRAM. This would > normally be done in your linker script. No, no. movMODE insns for AVR don't support FLASH (PROGMEM), only SRAM. Denis.
Re: git mirror at gcc.gnu.org
Daniel Berlin wrote: > pre-globals-git and restrict-git were test branches from an old mostly > broken version. ;) > > They are dead and if someone wants to manually remove the refs, go for it. > No idea what oldmaster is. Done. >> And why have both >> "master" and "trunk" as heads? > > See "broken" ;) Yes, but which one should die? Will cloners get confused by a repository where the master branch is missing? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Re: AVR C++ - how to move vtables into FLASH memory
> This question would be more appropriate for the mailing list > gcc-h...@gcc.gnu.org than for g...@gcc.gnu.org. Please take any > followups to gcc-help. Thanks. > > Virtual tables will normally be placed in the .rodata section which > holds read-only data. All you should need to do it arrange for the > .rodata section to be placed in FLASH rather than SRAM. This would > normally be done in your linker script. No, it won't work. The AVR is a Harvard architecture and the FLASH is not mapped into the data address space. You need to use special instructions to fetch FLASH data into registers. You load the FLASH address in a register pair, possibly set a peripheral register to select which 64K block of the FLASH you want to address, since the register pair is only 16 bit wide and there can be up to 128K FLASH, then do a byte or word load into a register or register pair. The compiler *must* be aware of where the data is, because it needs to generate completely different code to access data in the FLASH. I haven't used the AVR for a while, but as far as I know, gcc does not provide any support for constants to be stored in FLASH, let it be const data, gcc generated tables or anything. It was a pain in the neck, because there's precious little amount of RAM on these processors, and all your strings and gcc generated internal data were wasting RAM (without you having any control over that) and even placing your own data into FLASH required a fairly convoluted use of the section attribute and inline asm routines to access it. So it is indeed a valid compiler issue, not an incompetent user issue. Probably an improvement request would be the best. Zoltan
Re: Rationale for an old TRUNCATE patch
Ian Lance Taylor writes: > I agree that this patch looks wrong in todays compiler. There should be > no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. Thanks. Do you think we can assume this for TRUNCATEs in general or only for MIPS-like TRUNCATEs? I can't think of why it would be useful to represent a mode so that bits outside the mode mask don't either depent on bits inside the mask or are don't-care bits. IOW, can we assume that for any TRUNCATE from wider mode W to narrower mode N the following holds: (truncate:N expr:W) == (truncate:N (and:W expr:W GET_MODE_MASK(Nmode))) ? Where == is not necessarily identical bit representation of the object holding the value (e.g. QI HI values in MIPS) but that they are indistinguishable in the operations that are defined on them. Adam
gcc-4.4-20090616 is now available
Snapshot gcc-4.4-20090616 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 148556 You'll find: gcc-4.4-20090616.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090616.tar.bz2 C front end and core compiler gcc-ada-4.4-20090616.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090616.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090616.tar.bz2 C++ front end and runtime gcc-java-4.4-20090616.tar.bz2 Java front end and runtime gcc-objc-4.4-20090616.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090616.tar.bz2The GCC testsuite Diffs from 4.4-20090609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: AVR C++ - how to move vtables into FLASH memory
Zoltán Kócsi writes: > So it is indeed a valid compiler issue, not an incompetent user issue. > Probably an improvement request would be the best. Thanks for the details on the AVR. The question of gcc vs. gcc-help is not one of compiler issues vs. incompetent user issues. Many highly competent users post on gcc-help. The question is one of using gcc vs. modifying gcc. A discussion of how to modify gcc's AVR backend to support putting the virtual table in FLASH would be appropriate for g...@. A message like yours is appropriate for gcc-h...@. Thanks. Ian
Re: Rationale for an old TRUNCATE patch
Adam Nemet writes: > Ian Lance Taylor writes: >> I agree that this patch looks wrong in todays compiler. There should be >> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. > > Thanks. > > Do you think we can assume this for TRUNCATEs in general or only for MIPS-like > TRUNCATEs? truncate has a machine independent meaning. > I can't think of why it would be useful to represent a mode so that bits > outside the mode mask don't either depent on bits inside the mask or are > don't-care bits. IOW, can we assume that for any TRUNCATE from wider mode W > to narrower mode N the following holds: > > (truncate:N expr:W) == (truncate:N (and:W expr:W GET_MODE_MASK(Nmode))) > > ? Where == is not necessarily identical bit representation of the object > holding the value (e.g. QI HI values in MIPS) but that they are > indistinguishable in the operations that are defined on them. Yes. The bits in Nmode's mask are determined by the truncate. The other bits are don't-care. If the result of the truncate happens to wind up in a register, then in some cases PROMOTE_MODE will apply. Ian
Re: Address mode offset spill
> > One thing you certainly need to do is set REG_ALLOC_ORDER so that r0 is > the last register allocated. > > You need to set TARGET_RTX_COSTS so that constants larger than 512 are > more expensive than registers. That should prevent the constant from > being propagated into the insn. Yeah. I 've already done it in macro REG_ALLOC_ORDER and TARGET_RTX_COSTS . > > > > So before cc1 crashed, the unrecognized insn doesn't go through the > > LEGITIMIZE_RELOAD_ADDRESS and PREFERRED_RELOAD_CLASS macro. > > Is there any solution I can handle the similar problems? > > You're right, for a pure load like this, you will need a secondary > reload. > > Ian you mean in Target hook "TARGET_SECONDARY_RELOAD"? This is what I haven't done yet. I will write it and try again. Thank you very much. daniel
Re: Rationale for an old TRUNCATE patch
Adam Nemet wrote:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NOOP_TRUNCATION.
Index: combine.c
===
--- combine.c(revision 19018)
+++ combine.c(revision 19204)
@@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest
if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT)
break;
- if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT)
+ if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT
+ && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
+GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0)
SUBST (XEXP (x, 0),
force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)),
GET_MODE_MASK (mode), NULL_RTX, 0));
This optimization simplifies the input to a truncate by only computing bits
that won't be eliminated by the truncation. Normally these are the bits in
the output mode mask. Note that the optimization does not change the truncate
into a low-part subreg, which would pretty automatically warrant the
TRULY_NOOP_TRUNCATION check.
Specifically I am curious if this was prompted by MIPS (or SH) or maybe some
other target that have a notion of truncate different from MIPS.
force_to_mode was broken WRT truncate before my patch in 2006:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00553.html
so maybe the Jeff's patch was just trying to avoid the call to force_to_mode.
Anyhow, I don't think that the above transformation is illegal for MIPS64.
When truncating to SI mode the bits outside the resulting SI mode will all be
copies of the SI mode sign bit so their input values are obviously irrelevant.
For QI and HI modes the representation requires the upper 32 bits in the
64-bit word to be copies of the 31st bit. The transformation might change the
31 bits so it can affect the the resulting bits in the 64-bit word. This
however should have no visible effect. Operations on QI- and HI-mode values
are performed in SI mode with proper extensions before the operation if bits
outside the mode would affect the result.
I also tried a few things after removing the above check. Boostrapping and
regtesting on mips64octeon-linux was successful so was regtesting on
mipsisa64r2-elf. The assembly output of gcc.c-torture/execute/*.c improved
as:
13 files changed, 73 insertions(+), 99 deletions(-)
The changes typically remove zero and sign-extensions before a subsequent
truncation.
Any further information on this subject would be very much appreciated.
I can't be 100% sure, but I believe this was installed to deal with
problems related to a 64bit mips chip.
Assuming I've found the right thread in my personal mail archives (I've
extracted the most relevant parts of the conversation)
I wrote (in 1998):
Imagine a 64bit mips part (like that's hard :-)
Integer comparisons in the hardware are always done with 64bits
of precision.
Consider this code:
(insn 21 18 22 (set (reg:DI 86)
(ashiftrt:DI (reg/v:DI 83)
(const_int 32))) 222 {ashrdi3_internal4} (insn_list 15 (nil))
(nil))
(insn 22 21 24 (set (reg:SI 87)
(truncate:SI (reg:DI 86))) 112 {truncdisi2} (insn_list 21 (nil))
(expr_list:REG_DEAD (reg:DI 86)
(nil)))
(jump_insn 24 22 26 (set (pc)
(if_then_else (ge:SI (reg:SI 87)
(const_int 0))
(label_ref 36)
(pc))) 241 {branch_zero} (insn_list 22 (nil))
(expr_list:REG_DEAD (reg:SI 87)
Combine will turn that into (and I believe this is a valid
tranformation): [ we now know this was invalid... ]
(insn 22 21 24 (set (subreg:DI (reg:SI 87) 0)
(lshiftrt:DI (reg/v:DI 83)
(const_int 32))) 232 {lshrdi3_internal4} (insn_list 15 (nil))
(nil))
(jump_insn 24 22 26 (set (pc)
(if_then_else (ge:SI (reg:SI 87)
(const_int 0))
(label_ref 36)
(pc))) 241 {branch_zero} (insn_list 22 (nil))
(expr_list:REG_DEAD (reg:SI 87)
(nil)))
(nil)))
;; End of basic block 0
Note that insn 22 uses a logical shift -- the net result will
be that the value placed into reg87 is no longer sign extended
from 32 to 64 bits.
This causes serious grief when we try to perform a signed comparison
with zero. I suspect it would cause major headaches for arithmetic
operations too.
Ian wrote (in 1998):
> For the MIPS port, it is not valid to examine a reg:DI in reg:SI mode
> without using truncate. I don't know why that is happening. Perhaps
> something is failing to check TRULY_NOOP_TRUNCATION, which I believe
> is intended to prohibit this type of operation.
And a later message from Jim:
Truncate converts a value from a larger to a smaller mode in a machin
Re: Rationale for an old TRUNCATE patch
Ian Lance Taylor wrote: Adam Nemet writes: I am trying to understand the checkin by Jeff Law from about 11 years ago: r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines * combine.c (simplify_rtx, case TRUNCATE): Respect value of TRULY_NOOP_TRUNCATION. Index: combine.c === --- combine.c(revision 19018) +++ combine.c(revision 19204) @@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) break; - if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) + if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT + && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), +GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0) SUBST (XEXP (x, 0), force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), GET_MODE_MASK (mode), NULL_RTX, 0)); This optimization simplifies the input to a truncate by only computing bits that won't be eliminated by the truncation. Normally these are the bits in the output mode mask. Note that the optimization does not change the truncate into a low-part subreg, which would pretty automatically warrant the TRULY_NOOP_TRUNCATION check. I agree that this patch looks wrong in todays compiler. There should be no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. Based on reviewing my old notes, we do have to ensure that combine doesn't replace a TRUNCATE with a SUBREG as that can result in having a 32bit value that isn't sign-extended, which clearly causes MIPS64 ports grief. Jeff
gcc for i386-solaris doesn't expand builtin functions for atomic memory access
Hi all, As we see from gcc doc, the builtins are intended to be compatible with those described in the Intel Itanium Processor-specific Application Binary Interface, section 7.4. Why did gcc for x86 miss expanding such built-ins, just generating a call to an external function? Is it on purpose or TODO work? # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: /import/iropt5/lijuan/plain-gcc/gcc-git/configure --prefix=/import/dr3/i386/gcc-4.4.0 --enable-shared --disable-static --disable-libtool-lock --disable-libada --enable-libssp --enable-languages=c,c++,objc,fortran --enable-threads=posix --enable-tls=yes --with-system-zlib --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-as=/usr/sfw/bin/gas --enable-c99 --enable-nls --enable-wchar_t --enable-libstdcxx-allocator=mt --with-pic --disable-bootstrap Thread model: posix gcc version 4.4.0 20090421 (prerelease) (GCC) Thanks, -- Lijuan
Re: gcc for i386-solaris doesn't expand builtin functions for atomic memory access
Lijuan Hai writes: > As we see from gcc doc, the builtins are intended to be compatible > with those described in the Intel Itanium Processor-specific > Application Binary Interface, section 7.4. Why did gcc for x86 miss > expanding such built-ins, just generating a call to an external > function? Is it on purpose or TODO work? As written, this question would be better suited for the gcc-h...@gcc.gnu.org mailing list rather than the gcc@gcc.gnu.org mailing list. You neglected to mention which builtin you were using. As the gcc documentation describes, the builtins are only open coded on processors which support them. The i386 does not support many atomic operations. Try using -march=i686 or some other -march option. Ian
Re: [gnat] reuse of ASTs already constructed
I got my first main program built in multi-source mode running. The ALI file and debug-info generation isn't perfect yet; also I'm using raw gnat1 as gnatmake is not yet adapted to multi-source mode. Oliver gnat1_multi_demo.tgz Description: application/compressed-tar
genrecog: ran out of alphabet
genrecog uses strings to keep track of where it is, specifically, digits and letters. I've got an insn that writes to more than 26 registers. Would switching to something bigger than [A-Z] be difficult? Perhaps using Japanese letters instead of English? ;-)
Ping: New Toshiba Media Processor (mep-elf) port and maintainer
> Pending initial (technical) approval Ping? Still waiting for technical approval from a global maintainer. http://people.redhat.com/dj/mep/
Re: Rationale for an old TRUNCATE patch
Jeff Law writes: > Ian Lance Taylor wrote: > > Adam Nemet writes: > > > > > >> I am trying to understand the checkin by Jeff Law from about 11 years ago: > >> > >>r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines > >> > >> > >>* combine.c (simplify_rtx, case TRUNCATE): Respect value of > >>TRULY_NOOP_TRUNCATION. > >> > >> > >>Index: combine.c > >>=== > >>--- combine.c (revision 19018) > >>+++ combine.c (revision 19204) > >>@@ -3736,7 +3736,9 @@ simplify_rtx (x, op0_mode, last, in_dest > >> if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) > >>break; > >> > >>- if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT) > >>+ if (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT > >>+ && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode), > >>+ GET_MODE_BITSIZE (GET_MODE (XEXP > >> (x, 0) > >>SUBST (XEXP (x, 0), > >> force_to_mode (XEXP (x, 0), GET_MODE (XEXP (x, 0)), > >> GET_MODE_MASK (mode), NULL_RTX, 0)); > >> > >> This optimization simplifies the input to a truncate by only computing bits > >> that won't be eliminated by the truncation. Normally these are the bits in > >> the output mode mask. Note that the optimization does not change the > >> truncate > >> into a low-part subreg, which would pretty automatically warrant the > >> TRULY_NOOP_TRUNCATION check. > >> > > > > I agree that this patch looks wrong in todays compiler. There should be > > no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow. > > > Based on reviewing my old notes, we do have to ensure that combine > doesn't replace a TRUNCATE with a SUBREG as that can result in having a > 32bit value that isn't sign-extended, which clearly causes MIPS64 ports > grief. Thanks for the long information in your other reply. As I said in the original email, we are not turning a TRUNCATE into a SUBREG in this transformation. We're just simplifying the input expression to truncate with the knowledge that only the truncated mode bits are relevant from the input. At the end we are still left with a truncate expression but possibly with a simpler operand. Adam
Re: Rationale for an old TRUNCATE patch
Ian Lance Taylor writes: > truncate has a machine independent meaning. Yes, I guess with your definition below it does. It's interesting though that Jim had said the opposite in the excerpts posted by Jeff: And a later message from Jim: Truncate converts a value from a larger to a smaller mode in a machine dependent way. A subreg just chops off the high bits. A truncate does not. The name might be a little confusing, but the whole point of truncate is to have something that operates differently than a subreg. Combine is clearly making an invalid transformation. > Yes. The bits in Nmode's mask are determined by the truncate. The > other bits are don't-care. If the result of the truncate happens to > wind up in a register, then in some cases PROMOTE_MODE will apply. And IIUC this don't-care nature of the other bits that allows backends to define the upper bits. For example to have sign-bit copies there in registers to enforce the MIPS64 SI mode representation. And treating the don't care bits outside SI mode in this way is true for any other SI-mode operations performed on registers not just truncate, right? Hmm, nice. Adam
