Hello,
I think I have found a bug in G++ . Please submit it to the bug tracker
(I do not want to open an account there) if you think it is a bug - I am
not sure about it.
While I worked with "search+replace" I accidently had following in my
source code:
const char* DUMMY = DUMMY;
It is am
Qun-Ying writes:
> No warning at all. Should gcc warn about the *next pointer points to
> an unknown structure? I know it is allow by the standard, but most of
> the case, it indicates some error in the code.
Hmm? Where do you expect to warn?
You never dereference the pointer, so there's no e
For the simple program, forward.c:
#include
typedef struct _item_st {
int data;
struct item_st *next;
} item_t;
int
main (int argc, char *argv[])
{
item_t head = {0, NULL};
head.data = 1;
printf ("head.data: %d ptr: %p\n", head.data, (void *)head.next);
return 0;
}
I
Snapshot gcc-4.7-20120428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120428/
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
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If gcc supports this, it's not obvious how.
I get partway there with FUNC
On 04/27/2012 11:31 PM, Greg McGary wrote:
I'm working on a port that does loads& stores in two phases.
Every load/store is funneled through the intermediate registers "ld" and "st"
standing between memory and the rest of the register file.
Example:
ld=4(rB)
...
...
> The instruction is generated according to cstoresi4/addsi_addgeu
> pattern during expanding.
>
> ;; Used as part of the expansion of thumb les sequence.
> (define_insn "thumb1_addsi3_addgeu"
> [(set (match_operand:SI 0 "s_register_operand" "=l")
> (plus:SI (plus:SI (match_operand:SI 1 "
On Sat, Apr 28, 2012 at 6:13 PM, Eric Botcazou wrote:
>> Yes, the reason here should be the pattern for insn 79 has predicates on
>> its operands and does not allow constant here.
>
> And there is no way to get rid of the 2 pluses and thus change the pattern?
>
> --
> Eric Botcazou
The instructio
> Yes, the reason here should be the pattern for insn 79 has predicates on
> its operands and does not allow constant here.
And there is no way to get rid of the 2 pluses and thus change the pattern?
--
Eric Botcazou
On Sat, Apr 28, 2012 at 5:15 PM, Eric Botcazou wrote:
>> I am sorry for misleading description. By "propagate register 172 in
>> insn79 and delete insn78"
>> I was meaning that gcc replaces reg 172 in insn79 with another
>> register contains ZERO and
>> that register(saying reg X) is defined in ot
> I am sorry for misleading description. By "propagate register 172 in
> insn79 and delete insn78"
> I was meaning that gcc replaces reg 172 in insn79 with another
> register contains ZERO and
> that register(saying reg X) is defined in other basic blocks.
OK, in this case I think you need to find
On Sat, Apr 28, 2012 at 4:55 PM, Eric Botcazou wrote:
>> I noticed that global passes before combine, like loop-invariant/cprop/cse2
>> some time have conflicts with combine.
>> The combine pass can only operates with basic block, while these global
>> passes move insns across basic block and left
> I noticed that global passes before combine, like loop-invariant/cprop/cse2
> some time have conflicts with combine.
> The combine pass can only operates with basic block, while these global
> passes move insns across basic block and left no description info.
>
> For example, a case I encountered
13 matches
Mail list logo
