"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Looking at a .md file of a backend it there a way to know whether a
> target supports long long
gcc always supports "long long" for all targets.
Can you ask a more precise question?
Ian
On Mon, Nov 06, 2006 at 10:52:00AM +0530, Mohamed Shafi wrote:
> Hello all,
>
> Looking at a .md file of a backend it there a way to know whether a
> target supports long long
> Should i look for patterns with machine mode DI?
No. For example, 8-bit, 16-bit and 32-bit targets should normally n
Thanks for the reply
My target (non gcc/private one) fails for long long testcases and
there are cases (with long long) which gets through, but not with the
right output. When i replace long long with long the testcases runs
fine, even those giving wrong output.
The target is not able to compile
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> So when i looked into the .md file i saw no patterns with DI machine
> mode ,used for long long(am i right?), execpt
>
> define_insn "adddi3" and define_insn "subdi3"
>
> The .md file says that this is to prevent gcc from synthesising it,
> though
On Nov 6, 2006, at 9:30 PM, Mohamed Shafi wrote:
My target (non gcc/private one) fails for long long testcases
Does it work flawlessly otherwise, if not, fix all those problems
first. After those are all fixed, then you can see if it then just
works. In particular, you will want to ensur
On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 6, 2006, at 9:30 PM, Mohamed Shafi wrote:
> My target (non gcc/private one) fails for long long testcases
Does it work flawlessly otherwise, if not, fix all those problems
first. After those are all fixed, then you can see if it then jus
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
When i diff the rtl dumps for programs passing negative value with and
without frame pointer i find changes from file.greg .
And, is that change bad? We do expect changes in codegen, you didn't
say if those changes are invalid, or what was in
Thanks for the input and the questions
Did you examine:
long long l, k;
l = -k;
for correctness by itself? Was it valid or invalid?
Yes this is working.
[ read ahead for spoilers, I'd rather you pull this information out
of the dump and present it to us... ]
A quick glance at th
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> and one more thing. In the dumps i noticed that before using a
> register in DI mode they are all clobbred first, like
>
> (insn 30 54 28 6 (clobber (reg:DI 34)) -1 (nil)
> (nil))
>
> What is the use of this insns ... Why do we need to clobber th
On 11/10/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
> When i diff the rtl dumps for programs passing negative value with and
> without frame pointer i find changes from file.greg .
A quick glance at the rtl shows that insn 95 tries to use [a4+4] b
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> (insn 94 91 95 6 (set (reg:SI 12 a4)
> (mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
> (nil))
>
> (insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
> (mem/c:SI (plus:SI (reg:SI 12 a4)
> (
On Thu, Nov 09, 2006 at 11:52:02AM -0800, Mike Stump wrote:
> The way the instructions are numbered suggests that the code went
> wrong before this point. You have to read and understand all the
> dumps, whether they are right or wrong and why, track down the code
> in the compiler that is
On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
> > 1. What could be the reason for this behavior?
>
> I'm really shooting in the dark here, but my guess is that you have a
> define_expand for movdi that is not reload safe.
And
On 10 November 2006 17:55, Rask Ingemann Lambertsen wrote:
> On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
>> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>>
>>> 1. What could be the reason for this behavior?
>>
>> I'm really shooting in the dark here, but my guess is that you
On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
> No, surely you don't want to do that! You really need a movdi pattern -
> even more so if there are no natural DImode-sized registers, as gcse can get
> terribly confused by bad reg_equal notes if you don't. See e.g.:
>
> http://gcc
First thanks very much for your thoughts
If those two instructions appear for the first time in the .greg dump
file, then they have been created by reload.
Yes they appear for the first time in .greg dump file.
> 1. What could be the reason for this behavior?
I'm really shooting in the da
On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote:
> On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
>
>> No, surely you don't want to do that! You really need a movdi pattern -
>> even more so if there are no natural DImode-sized registers, as gcse can
>> get terribly con
I'm really shooting in the dark here, but my guess is that you have a
define_expand for movdi that is not reload safe. You can do this
operation correctly, you just have to reverse the instructions: load
a5 from (a4 + 4) before you load a4 from (a4). See, e.g.,
mips_split_64bit_move in mips.c an
On 13 November 2006 12:27, Mohamed Shafi wrote:
> (insn 94 91 95 6 (set (reg:SI 12 a4)
> (mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
> (nil))
>
> (insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
> (mem/c:SI (plus:SI (reg:SI 12 a4)
>
On 13 November 2006 12:37, Dave Korn wrote:
> You *must* implement a movdi expander, and it has to be clever enough to
> notice when one of the output registers is going to clobber one of the input
> operands and emit the two SImode halves of the move in the opposite order.
Take a look at, e
On Mon, 6 Nov 2006, Ian Lance Taylor wrote:
> gcc always supports "long long" for all targets.
I just noticed that while the base compiler may support "long long", this
extension fails to interact well with at least one other extension: hash_map<>
in libstdc++.
Specifically, the following exampl
21 matches
Mail list logo