"eric lin" writes:
> eric@eric-laptop:~/practicalCpp$ g++ fixed_pt.cpp fixed_test.cpp
> In file included from fixed_pt.cpp:3:
> fixed_pt.h:211: error: ‘fixed_pt::fixed_pt
> fixed_pt::fixed_pt::operator+(const fixed_pt::fixed_pt&, const
> fixed_pt::fixed_pt&)’ must take either zero or one argume
eric@eric-laptop:~/practicalCpp$ g++ fixed_pt.cpp fixed_test.cpp
In file included from fixed_pt.cpp:3:
fixed_pt.h:211: error: fixed_pt::fixed_pt fixed_pt::fixed_pt::operator+(const
fixed_pt::fixed_pt&, const fixed_pt::fixed_pt&) must take either zero or one
argument
fixed_pt.h:216: error: fixe
On May 13, 2011, at 8:56 PM, Andrew Pinski wrote:
> On Fri, May 13, 2011 at 5:51 PM, Paul Koning wrote:
>> I was using 4.5.1 which has the bug. I thought later ones have it too, but
>> it looks like I misread the assembly output. (The fix makes a subtle
>> change: beq becomes beql.)
>
> A g
On Fri, May 13, 2011 at 5:51 PM, Paul Koning wrote:
> I was using 4.5.1 which has the bug. I thought later ones have it too, but
> it looks like I misread the assembly output. (The fix makes a subtle change:
> beq becomes beql.)
A good question is why does XLR have branch linkely enabled anyw
On May 13, 2011, at 5:29 PM, Eric Botcazou wrote:
>> rest_of_pass_free_cfg calls df_analyze but it doesn't call
>> df_note_add_problem. Is that the issue? I see that some other passes
>> (like regrename) do a sequence of df_xyz calls.
>
> It does now, you have outdated sources.
I was using 4.
Snapshot gcc-4.6-20110513 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110513/
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
> rest_of_pass_free_cfg calls df_analyze but it doesn't call
> df_note_add_problem. Is that the issue? I see that some other passes
> (like regrename) do a sequence of df_xyz calls.
It does now, you have outdated sources.
--
Eric Botcazou
On May 13, 2011, at 5:30 PM, Paul Koning wrote:
>
> On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>
>>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>>> right? From the definition of REG_DEAD, it seems that rewriting a later
>>> insns to use register x means
> A later pass (machdep) relies on the notes, so the fact that the actual
> register liveness no longer matches what the REG_DEAD notes imply seems to
> be a problem.
Again, if a pass consumes these notes, it must df_note_add_problem() on entry.
For machine_reorg, this is too late because the CFG
On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>> right? From the definition of REG_DEAD, it seems that rewriting a later
>> insns to use register x means that a preceding (REG_DEAD x) needs to be
>> deleted. Or m
On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>> right? From the definition of REG_DEAD, it seems that rewriting a later
>> insns to use register x means that a preceding (REG_DEAD x) needs to be
>> deleted. Or m
> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
> right? From the definition of REG_DEAD, it seems that rewriting a later
> insns to use register x means that a preceding (REG_DEAD x) needs to be
> deleted. Or moved to the later insn, perhaps.
If the pass doesn't co
In attempting to find out what's wrong in PR 48990 (wrong code for MIPS N32
-O1) it looks to me like the issue is that a register is marked dead, then
still used afterwards. This causes the delay slot fill logic to make a wrong
decision (it brings a load instruction that overwrites the "dead" r
On 05/10/2011 06:51 PM, Joseph S. Myers wrote:
> * If you are volunteering to be maintainer of the port, make that explicit
> (and probably post to gcc@ for the attention of the SC; maintainership
> needs approving by the SC, separately from the technical review of the
> patches).
Patch append
Jakub Jelinek wrote:
> And that's the right thing to do.
I concur. But the exchange case remains open.
> Please file an enhancement request in gcc bugzilla.
Done, 48986. I have also noticed several other missing
optimizations in this area, so I'm about to report them too.
Best regards,
On 12/05/2011 17:24, fanqifei wrote:
I am using gcc4.3.2.
In our microcontroller, move instruction(mov reg, imm) can accept
16bits and 32bits immediate operand.
The data memory size is less than 64KB, however, code memory size is
larger than 64KB.
The immediate operand may be addresses of variabl
16 matches
Mail list logo
