assigning hard regs to pseudo regs
For certain instructions, I am trying to do my own register assignments before IRA runs. I call df_analyze to find all register references and after my manipulations I call df_scan_blocks to reparse the insns. A typical replacement that I want to handle is a register reference of the form (subreg:REGQ (reg/v: TI 195 [x2] 4) If I replace the entire subreg expression by genRTX the compilation works but I lose the reference to X2 (plus I have to update every reference to reg expressions referencing reg 195). If I call SET_REGNO on the inner expression, it automatically updates all of the comparable expressions, and register 195 only appears as original reg in any insn. The insn dumps look correct to me. But reload will complain that register 195 didn't get a hard register assignment. What do I need to do to make reload happy? Thanks shmeel
i386.md missing a mode
Hi On the head, I see this: ../../gcc/gcc/config/i386/i386.md:11448: warning: source missing a mode? ../../gcc/gcc/config/i386/i386.md:11460: warning: source missing a mode? / Since it is in the middle of a big log and doesn't include the word warning in the message, I wondered if someone was aware of it. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: Gcc plugin for modification of source code ?
Thanks Basile Starynkevitch for the useful reply.
On 6/15/14, Basile Starynkevitch wrote:
> On Sun, 2014-06-15 at 02:40 +0530, Mohsin Khan wrote:
>> Hi,
>> I'm working on a gcc plugin project. I had a doubt, can somebody help
>> me on this.
>
> [no need to ask on gcc-help@; plugins are definitely gcc internals
> related and should better be discussed on gcc@gcc.gnu.org]
>
>> Can we write a plugin (which works after a pass like cfg or any other)
>> which can modify the source code of .C file, for example insert
>> comments before function definitions or insert a new IF Block in the
>> .C file. And after modification it writes the entire modified code to
>> a new .C file. Is this type of plugin possible in GCC. If yes, please
>> tell me how and if No, please tell me why.
>
> If your source file does not contain any #line directive, a GCC plugin
> (or a MELT extension, see http://gcc-melt.org/ for more) is able to get
> the source code position of every Gimple instruction. (But did you think
> about instruction obtained by some macro expansions?).
>
> With that information, you can indeed transform the C source as you
> wish. It might not be simple (you need to build an editor-like internal
> represention of each line of the source code).
>
> However, modifying the Gimple representation (without modifying any C++
> source file) is probably simpler.
>
> What exactly do you want to achieve? Are you sure that a source to
> source transformation is worthwhile -given that you can transform
> internal GCC representations like Gimples-?
>
> 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} ***
>
>
>
Repost of Gcc plugin for modification of source code ?
Hi, I'm working on a gcc plugin project. I had a doubt, can somebody help me on this. Can we write a plugin (which works after a pass like cfg or any other) which can modify the source code of .C file, for example insert comments before function definitions or insert a new IF Block in the .C file. And after modification it writes the entire modified code to a new .C file. Is this type of plugin possible in GCC. If yes, please tell me how and if No, please tell me why. Any help is much appreciated. Note : This question was also answered by Basile Starynkevitch, thanks to him. I want thoughts from other developers also from GCC. So can a Gcc developer help me with this, and share there point of view. Any help is appreciated. Thanks
gcc-4.10-20140615 is now available
Snapshot gcc-4.10-20140615 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140615/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 211688 You'll find: gcc-4.10-20140615.tar.bz2Complete GCC MD5=7f595d549d28321eff60d7bfc93d4b1f SHA1=4c85879088a18d3e256d25367de41a20b5cfed4f Diffs from 4.10-20140608 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 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: [PATCH] gcc/dwarf2asm.c: Add static_output_delta() with var_list for dw2_asm_output_delta()
On Sat, Jun 14, 2014 at 5:50 PM, Chen Gang wrote:
> On 06/14/2014 05:45 PM, Chen Gang wrote:
>> dw2_asm_output_vms_delta() calls dw2_asm_output_delta() in an abnormal
>> way, so need add a new function just like vprintf() for printf(), and
>> then the related call will be in normal way.
>>
>> The related warning:
>>
>> ../../gcc/gcc/dwarf2asm.c: In function 'void dw2_asm_output_vms_delta(int,
>> const char*, const char*, const char*, ...)':
>> ../../gcc/gcc/dwarf2asm.c:167:50: warning: format not a string literal and
>> no format arguments [-Wformat-security]
>>
>>
>> Signed-off-by: Chen Gang
>> ---
>> gcc/ChangeLog | 6 ++
>> gcc/dwarf2asm.c | 23 +++
>> 2 files changed, 21 insertions(+), 8 deletions(-)
>>
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index edb3fc0..0e1df0e 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2014-06-14 Chen Gang
>> +
>> + * dwarf2asm.c (dw2_asm_output_delta): Add static_output_delta() for
>> + dw2_asm_output_delta(), just like vprintf() for printf(), so that
>> + dw2_asm_output_vms_delta() can use it in normal way.
>> +
>> 2014-06-13 Vladimir Makarov
>>
>> * lra-assign.c (assign_by_spills): Add code to assign vector regs
>> diff --git a/gcc/dwarf2asm.c b/gcc/dwarf2asm.c
>> index 1372b23..69733b3 100644
>> --- a/gcc/dwarf2asm.c
>> +++ b/gcc/dwarf2asm.c
>> @@ -123,14 +123,10 @@ dw2_asm_output_data (int size, unsigned HOST_WIDE_INT
>> value,
>> impossible to do here, since the ASM_SET_OP for the difference
>> symbol must appear after both symbols are defined. */
>>
>> -void
>> -dw2_asm_output_delta (int size, const char *lab1, const char *lab2,
>> - const char *comment, ...)
>> +static void
>> +static_output_delta (int size, const char *lab1, const char *lab2,
>> + const char *comment, va_list ap)
>> {
>> - va_list ap;
>> -
>> - va_start (ap, comment);
>> -
>> #ifdef ASM_OUTPUT_DWARF_DELTA
>>ASM_OUTPUT_DWARF_DELTA (asm_out_file, size, lab1, lab2);
>> #else
>> @@ -145,7 +141,18 @@ dw2_asm_output_delta (int size, const char *lab1, const
>> char *lab2,
>>vfprintf (asm_out_file, comment, ap);
>> }
>>fputc ('\n', asm_out_file);
>> +}
>> +
>>
>> +
>
> Oh, sorry, it contents 2 new redundant '\n', if necessary to send patch
> v2 for it, please let me know.
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
Hi,
Please send patches to gcc-patches mailing list.
Thanks,
bin
--
Best Regards.
Re: [PATCH] gcc/dwarf2asm.c: Add static_output_delta() with var_list for dw2_asm_output_delta()
On 06/16/2014 09:36 AM, Bin.Cheng wrote: > On Sat, Jun 14, 2014 at 5:50 PM, Chen Gang wrote: [...] > > Hi, > > Please send patches to gcc-patches mailing list. > OK, thanks, and excuse me as a newbie to send a patch to the incorrect mailing list. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Regarding concrete inlined and out-of-line inlined instances
Hi, I have the below debug information (dwarf4) generated by the GCC compiler v4.8.2 for an inlined function. Please help me with the following queries. In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc value (0xc01b49d0) is overlapping with the address range i.e. DW_AT_low_pc (0xc01b4980) and DW_AT_high_pc (0xc01b4a60) of the out-of-line instance root entry. Is this overlapping legitimate and how? Also, if we closely look at the debug information tables, the DW_AT_location attribute is not generated either for all formal parameters in the concrete inlined instance tree OR for all function local variables in the out-of-line inlined instance tree. Isn't that something abnormal? If it is legitimate, how the debugger is supposed to get the DW_AT_location details of the formal parameters of the concrete inlined instance tree? <1><1038302>: Abbrev Number: 51 (DW_TAG_subprogram) <1038303> DW_AT_name: (indirect string, offset: 0x7a615): ext2_lookup <1038307> DW_AT_decl_file : 1 <1038308> DW_AT_decl_line : 58 <1038309> DW_AT_prototyped : 1 <103830a> DW_AT_type: <0x10330af> <103830e> DW_AT_inline : 1 (inlined) <103830f> DW_AT_sibling : <0x1038359> <2><1038313>: Abbrev Number: 52 (DW_TAG_formal_parameter) <1038314> DW_AT_name: dir <1038318> DW_AT_decl_file : 1 <1038319> DW_AT_decl_line : 58 <103831a> DW_AT_type: <0x103331d> <2><103831e>: Abbrev Number: 56 (DW_TAG_formal_parameter) <103831f> DW_AT_name: (indirect string, offset: 0x4fb14): dentry <1038323> DW_AT_decl_file : 1 <1038324> DW_AT_decl_line : 58 <1038325> DW_AT_type: <0x10330af> <2><1038329>: Abbrev Number: 56 (DW_TAG_formal_parameter) <103832a> DW_AT_name: (indirect string, offset: 0x1a72d5): flags <103832e> DW_AT_decl_file : 1 <103832f> DW_AT_decl_line : 58 <1038330> DW_AT_type: <0x1030083> <2><1038334>: Abbrev Number: 61 (DW_TAG_variable) <1038335> DW_AT_name: (indirect string, offset: 0x7a533): inode <1038339> DW_AT_decl_file : 1 <103833a> DW_AT_decl_line : 60 <103833b> DW_AT_type: <0x103331d> <2><103833f>: Abbrev Number: 57 (DW_TAG_variable) <1038340> DW_AT_name: ino <1038344> DW_AT_decl_file : 1 <1038345> DW_AT_decl_line : 61 <1038346> DW_AT_type: <0x1030243> <2><103834a>: Abbrev Number: 62 (DW_TAG_variable) <103834b> DW_AT_name: (indirect string, offset: 0xdd81): __func__ <103834f> DW_AT_type: <0x1038369> <1038353> DW_AT_artificial : 1 <1038354> DW_AT_const_value : (indirect string, offset: 0x7a615): ext2_lookup <1><1038359>: Abbrev Number: 8 (DW_TAG_array_type) <103835a> DW_AT_type: <0x1030168> <103835e> DW_AT_sibling : <0x1038369> <2><1038362>: Abbrev Number: 9 (DW_TAG_subrange_type) <1038363> DW_AT_type: <0x1030129> <1038367> DW_AT_upper_bound : 11 <1><1038369>: Abbrev Number: 11 (DW_TAG_const_type) <103836a> DW_AT_type: <0x1038359> . . (some intermediate DIE entries) . <1><10397ce>: Abbrev Number: 92 (DW_TAG_subprogram) <10397cf> DW_AT_abstract_origin: <0x1038302> <10397d3> DW_AT_low_pc : 0xc01b4980 <10397db> DW_AT_high_pc : 0xc01b4a60 <10397e3> DW_AT_frame_base : 0x53243a(location list) <10397e7> DW_AT_GNU_all_call_sites: 1 <10397e8> DW_AT_sibling : <0x10398eb> <2><10397ec>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397ed> DW_AT_abstract_origin: <0x1038313> <10397f1> DW_AT_location: 0x5324c5(location list) <2><10397f5>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397f6> DW_AT_abstract_origin: <0x103831e> <10397fa> DW_AT_location: 0x53254d(location list) <2><10397fe>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397ff> DW_AT_abstract_origin: <0x1038329> <1039803> DW_AT_location: 0x5325e8(location list) <2><1039807>: Abbrev Number: 93 (DW_TAG_variable) <1039808> DW_AT_abstract_origin: <0x1038334> <2><103980c>: Abbrev Number: 93 (DW_TAG_variable) <103980d> DW_AT_abstract_origin: <0x103833f> <2><1039811>: Abbrev Number: 94 (DW_TAG_variable) <1039812> DW_AT_abstract_origin: <0x103834a> <1039816> DW_AT_location: 9 byte block: 3 c0 0 0 0 0 79 3ea0 (DW_OP_addr: c0793ea0) <2><1039820>: Abbrev Number: 95 (DW_TAG_inlined_subroutine) <1039821> DW_AT_abstract_origin: <0x1038302> <1039825> DW_AT_entry_pc: 0xc01b49d0 <103982d> DW_AT_ranges : 0x14a0c0 <1039831> DW_AT_call_file : 1 <1039832> DW_AT_call_line : 58 <3><1039833>: Abbrev Number: 96 (DW_TAG_formal_parameter) <1039834>
