passing arguments to gcc build in eclipse
I have build gcc and imported it on eclipse and started to debug it from main but after a few steps it stops and sends "malloc.c" not found error and asks to give a source path to it. I believe the problem is because of the arguments that it requires to proceed for example "" as gcc takes some arguments to work on in terminal. Can someone please tell me the error I am facing and it i am correct can u tell me how to pass arguments to the built code that it can recognize it as a .C file. Thanks ! -- View this message in context: http://old.nabble.com/passing-arguments-to-gcc-build-in-eclipse-tp32477948p32477948.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: IRA misses register range overlap
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote:
> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>
>> In the msp430 back end, hard registers 4 through 15 are HImode, with
>> adjacent register sequences used for SImode and DImode. In preparation
>> for
>> a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
>>
>> Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
>> for a pseudo-register for a preceding assignment, and does nothing to
>> preserve the value over the span where the register is part of an SI
>> value.
>> The subsequence:
>>
>> (insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
>> (reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
>> (expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
>> (nil)))
>>
>> (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
>>
>> (note 6 3 10 2 NOTE_INSN_DELETED)
>>
>> (insn 10 6 11 2 (set (reg:SI 8 r8)
>> (mem/c/i:SI (symbol_ref:HI ("seed") [flags 0x2]> 0x7f032064f960 seed>) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> (insn 11 10 12 2 (set (reg:SI 4 r4)
>> (const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> with:
>>
>> insn=2, live_throughout: 1, dead_or_set: 15, 38
>> insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
>> insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
>> insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
>> 11, 12, 13, 14, 15
>>
>> becomes:
>>
>> (insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
>> (reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
>> (nil))
>>
>> (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
>>
>> (note 6 3 10 2 NOTE_INSN_DELETED)
>>
>> (insn 10 6 11 2 (set (reg:SI 8 r8)
>> (mem/c/i:SI (symbol_ref:HI ("seed") [flags 0x2]> 0x7f032064f960 seed>) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> (insn 11 10 12 2 (set (reg:SI 4 r4)
>> (const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
>> 33614 instead of the user's parameter.
>>
>> Could somebody suggest where should I look to understand why this is
>> happening and how should it be fixed?
>>
> The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You should
> submit the test (the smaller the test, the better) and how to reproduce it:
> how to build gcc (configure options) and how to call the built gcc to
> reproduce results.
>
> I think you could look at ira dump file and check that allocno for p38
> conflicting with hard reg 4 *and* 5. If it is not, the problem is in
> conflict calculation. Otherwise, it might be IRA hard register assignment
> or in reload (the worst case).
My investigation leads me to believe that IRA does fail to detect the
conflicts, as you suggested. I'm generating RTL that uses specific general
registers that are not distinguished by register classes or marked in the
insn constraints. This is to prepare for calls to support routines that
don't follow the standard ABI. (Perhaps this is the wrong way to solve
that problem, though I believe AVR and perhaps other platforms do this
as well.)
I've attached to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 a patch
that augments ira-lives.c (process_single_reg_class_operands) to detect this
and mark the corresponding registers as conflicts. It works on this case, and
doesn't create any problems that are obvious to me.
I'd appreciate a review of whether this approach is right, or if the conflicts
should be recorded somewhere else.
Peter
>
> But having only info you provided it is very hard to say what is wrong.
>
>
Re: passing arguments to gcc build in eclipse
On 09/16/2011 11:30 AM, pankajsejwal wrote: > > I have build gcc and imported it on eclipse and started to debug it from main > but after a few steps it stops and sends "malloc.c" not found error and asks > to give a source path to it. > I believe the problem is because of the arguments that it requires to > proceed for example "" as gcc takes some arguments to work on in > terminal. > > Can someone please tell me the error I am facing and it i am correct can u > tell me how to pass arguments to the built code that it can recognize it as > a .C file. This is not an appropriate message for gcc@gcc.gnu.org, which is only about the development of gcc itself. Most of us don't use Eclipse. I think you'd be much better advised to direct this to an Eclipse-specific list, where the experts will be. Andrew.
original tree for folded expressions
I'm working on a plugin to report dependencies of a .c file to its headers, i.e. what information from the headers is referenced from the .c file. This works pretty well for most stuff, but I really have a hard time for anything that gets folded to a constant. The AST does no longer have the original types/functions/constants but transforms them to const ints in an early stage already. I am looking at the AST from a plugin and a tree walking function called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I could hook into? If not, would it be acceptable to add the original tree to a folded tree for analyzing tools like mine? If so, any hint about how this can be implemented? From looking at it, it seems that everything (?) is passed through fold_convert_loc. Thanks
Derive more alias information from named address space
Hi,
I am trying to implement named address space for our target.
In alias.c, I found the following piece of code several times.
/* If we have MEMs refering to different address spaces (which can
potentially overlap), we cannot easily tell from the addresses
whether the references overlap. */
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
return 1;
I think we can do better with the existing target hook:
- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t superset,
addr_space_t subset)
If A is not subset of B and B is not subset of A, we can conclude
they are either disjoint or overlapped. According to standard draft
(section 3.1.3),
"For any two address spaces, either the address spaces must be
disjoint, they must be equivalent, or one must be a subset of
the other. Other forms of overlapping are not permitted."
Therefore, A & B could only be disjoint, i.e., not aliased to each other.
We should be able to write:
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
{
if (!targetm.addr_space.subset_p (MEM_ADDR_SPACE (mem), MEM_ADDR_SPACE (x))
&& !targetm.addr_space.subset_p (MEM_ADDR_SPACE (x), MEM_ADDR_SPACE
(mem)))
return 0;
else
return 1;
}
Is this correct?
Thanks,
Bingfeng Mei
Re: original tree for folded expressions
On 11-09-16 12:05 , Joachim Wieland wrote: I am looking at the AST from a plugin and a tree walking function called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I could hook into? If not, would it be acceptable to add the original tree to a folded tree for analyzing tools like mine? Not really. Memory consumption would go through the roof. However, you could try an approach similar to what Le-Chun implemented for -Wself-assign (which only exists in the google/main branch for now). See EXPR_FOLDED in http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01898.html. Diego.
More int128 tests?
Hi All, I see only 3 tests (shown below) for testing int128 feature in gcc 4.6.0 (testsuite/c-c++-common). int128-1.c int128-2.c int128-types-1.c Do you know if there are more int128 tests in any version of gcc? Thanks a lot! Rohini
Re: original tree for folded expressions
On Fri, Sep 16, 2011 at 1:37 PM, Diego Novillo wrote: > However, you could try an approach similar to what Le-Chun implemented for > -Wself-assign (which only exists in the google/main branch for now). See > EXPR_FOLDED in http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01898.html. Hm, I don't see how exactly this would solve my problem... The issue I am facing is that references to necessary header files are optimized away. Just knowing that an expression has been folded doesn't help me... :-( What I had in mind was to only keep additional copies of the original subtrees if the node has been replaced completely by folding. I don't see why memory consumption would go through the roof that way, this would mean that a very high percentage of the code can be folded and shrinked significantly which shouldn't be true in the general case. Of course I see that it can be difficult to implement this, it might require changes to every folding function. Is there any function that I could create a hook for which still sees an unfolded expression? Thanks, Joachim
Re: original tree for folded expressions
On 11-09-16 16:25 , Joachim Wieland wrote: Hm, I don't see how exactly this would solve my problem... The issue I am facing is that references to necessary header files are optimized away. Just knowing that an expression has been folded doesn't help me... :-( Sorry, I was too cryptic. The setting of EXPR_FOLDED would be the places where you want to capture the unfolded trees. What I had in mind was to only keep additional copies of the original subtrees if the node has been replaced completely by folding. I don't see why memory consumption would go through the roof that way, this would mean that a very high percentage of the code can be folded and shrinked significantly which shouldn't be true in the general case. Of course I see that it can be difficult to implement this, it might require changes to every folding function. IIUC, for every folded tree you want to keep the original form, right? That causes increased memory consumption. Is there any function that I could create a hook for which still sees an unfolded expression? Not really. At least, not using plugins. You'll need to modify the compiler for that. If you are doing analysis this close to the original source, however, you may want to consider clang. GCC does not try to keep its ASTs close to the original source. Diego.
gcc-4.6-20110916 is now available
Snapshot gcc-4.6-20110916 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110916/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 178919 You'll find: gcc-4.6-20110916.tar.bz2 Complete GCC MD5=b0cd68f508146763e66c2f416b2a81c6 SHA1=ea97ce622d7a6fda1dfe09297e6ebcab7cf25e92 Diffs from 4.6-20110909 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
