Inquireries
Hello, My name is Alangi Derick Ndimnain and i have been contributing to the GCC organisation for some time now and i even got a message from one of gcc admins that i am in one the top 50 gcc contributors and that i should submit a proposal. I am a Computer Engineering student in Cameroon, University of Buea. I saw a project in the gcc idea list and i want to work on it. But my main problem now is that i don't know my mentor and i need him so as to talk with him about the project. The project name is: Converting different program representation levels of GCC back to the source code. It's not a trivial task but I saw substantial interest to that recently and it is found in the http://gcc.gnu.org/wiki/SummerOfCode page. This project really interests me because i want to be able to get my source codes back if i lost them and i still have my executable files up and running. My main aim of writing to the mailing list is to tell the other members informing them about the project i am working on and i need to know my mentor on the project so that i can start working with him/her her Thanks for your Understanding Your Contributor Alangi Derick Ndimnain Cheers!!!
Re: Inquireries
Hello Alangi Derick & the GCC list
[your subject "Inquireries" is mispelled and not very explicit; probably
should be Gimple conversion to source code]
On Sat, 2014-03-15 at 13:30 +0100, Alangi Derick wrote:
>The project name is: Converting different program
> representation levels of GCC back to the source code. It's not a
> trivial task but I saw substantial interest to that recently and it is
> found in the http://gcc.gnu.org/wiki/SummerOfCode page.
If you want to convert some Gimple back to C code, it is an interesting
project (but somehow difficult or even impossible, notably because of
of exceptions and Gimple code like GIMPLE_EH_FILTER, GIMPLE_CATCH
etc...). Plugins are probably a good way to make that. And the MELT
meta-plugin http://gcc-melt.org/ used to have some (incomplete) code -by
Jeremie Salvucci- which you could resurrect from
http://gcc.gnu.org/viewcvs/gcc/branches/melt-branch/gcc/obsolete-melt/xtramelt-c-generator.melt
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 mine, sont seulement les miennes} ***
Re: Legitimize address after reload
Thanks for the information.
So far I'm still facing problems regarding memory addresses even with
the most restrictive conditions. The non-recognized instruction is:
../../../libgcc/libgcc2.c: In function '__muldi3':
../../../libgcc/libgcc2.c:559:1: error: insn not satisfying its restrictions:
(insn 130 164 134 4 (set:SI (mem/c:SI (plus:SI (mem/f/c:SI (plus:SI
(reg/f:SI 6 %ebp)
(const_int 8 [0x8])) [6 .result_ptr+0 S4 A32])
(const_int 4 [0x4])) [2 +4 S4 A32])
(reg:SI 1 %edx [84])) ../../../libgcc/libgcc2.c:558 9 {*movsi}
(nil))
../../../libgcc/libgcc2.c:559:1: internal compiler error
reload_cse_simplify_operands, at postreload.c:403
I'm using this as TARGET_LEGITIMATE_ADDRESS_P:
bool valid_address (enum machine_mode mode, rtx x, bool strict_p) {
switch (GET_CODE (x)) {
case REG:
case SUBREG:
return REG_P(x);
case PLUS:
return ( REG_P( XEXP(x,0) ) && CONST_INT_P( XEXP(x,1) ) );
case CONST_INT:
case CONST:
case LABEL_REF:
case SYMBOL_REF:
return true;
default:
return false;
}
}
So I don't get why the reload pass doesn't force the address to be in
a register.
Any ideas?
And, anyone can give me a hint on how to debug this issues? I'd like
to discover where in the gcc source this memory RTX expression is
created and why it is not expanded to be a valid address.
Thanks a lot!
David
2014-03-14 18:56 GMT+01:00 DJ Delorie :
>
> David Guillen writes:
>> In any case I'm not using the restrict variable and I'm assuming
>> strict is zero, this is, not checking the hard regsiters themselves.
>> This is because any reg is OK for base reg. I'm pretty sure I'm
>> behaving similarly to arm, cris or x86 backends.
>
> "strict" doesn't mean which hard register it is, "strict" means whether
> or not it's a hard register at all.
>
> If "strict" is true, you must assume any REG which isn't a real hard
> register (i.e. REGNO >= FIRST_PSEUDO_REGISTER) does NOT match.
gcc-4.7-20140315 is now available
Snapshot gcc-4.7-20140315 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140315/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 208598 You'll find: gcc-4.7-20140315.tar.bz2 Complete GCC MD5=320cd18033b1730436190cd55637d2a8 SHA1=4e211658a1ac9f97e2989fab02c3acfd83e0e016 Diffs from 4.7-20140308 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
debug strings output order is arbitrary
Hi list, the strings in the ".debug_str" section are output in an arbitrary order. Could this be changed? The function 'output_indirect_strings' in 'gcc/dwarf2out.c' uses htab_traverse which then outputs the string in the order they appear in the hash table. Instead, it would be nicer to output them based on their labels (which are assigned based on the order of creation). This would minimize differences between builds with slightly different build environments, e.g. directory. Martin
