Le 03/05/2012 14:14, Aurelien Buhrig a écrit :
> 02/05/2012 21:36, Eric Botcazou :
>>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>>> this insn:
>>> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
>>> (lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f]))
>>>
>>> The
> I modified CANNOT_CHANGE_MODE_CLASS as you suggested. But strange as it
> may seem, it has no effect on such a reload, and I can't find a way to
> make it work...
The macro is mainly used by the RA, not clear for reload.
> BTW, has this bug already been filed?
In its general form, I'm not sure
Hi,
I was just trying to understand exactly what constraint modifiers + and
= mean. I have read the manual but I am uncertain about their meaning in
the context of the following rule (without any modifiers):
Expand generates:
(define_insn_and_split "movmem_long"
[(set (match_operand:QI 2 "
Hi,
I'm working on an architecture where the calling convention depends on the type
of the parameter (i.e. pointers are passed into $C regs and non-pointers are
passed into $R regs). I've implemented this difference by using the
POINTER_TYPE_P() macro on the 'type' argument of the FUNCTION_ARG
Greetings, and thanks for this very helpful synopsis.
I'm wondering if there is a simple configure time test to detect when
this has been fixed. If I just aborted using __builtin___clear_cache if
it is in fact a noop on alpha, ppc, ppc64, and ia64, would this suffice?
Take care,
Richard Henders
"Paulo J. Matos" writes:
> Expand generates:
>
> (define_insn_and_split "movmem_long"
> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>(set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
> (mem:BLK (match_operand:QI 1 "register_operand" "x,c")))
>(s
Quoting BELBACHIR Selim :
Any ideas on how to get around this problem?
You can look at the name of library functions.
That's the only option ? Is there a more general method to do this ?
-Message d'origine-
De : amyl...@spamcop.net [mailto:amyl...@spamcop.net]
Envoyé : vendredi 4 mai 2012 15:48
À : BELBACHIR Selim
Cc : gcc@gcc.gnu.org
Objet : Re: type argument in FUNCTION_ARG macro
Quoting BELBACHIR S
Greetings! As a followup, I should note that sh4 and hppa are also
broken. I currently have this in configure.in
case $use in
sh4*) ;; #FIXME
hppa*) ;; #FIXME
*)
AC_MSG_CHECKING(__builtin___clear_cache)
AC_TRY_COMPILE([],
[void
BELBACHIR Selim writes:
> I'm working on an architecture where the calling convention depends on the
> type of the parameter (i.e. pointers are passed into $C regs and non-pointers
> are passed into $R regs). I've implemented this difference by using the
> POINTER_TYPE_P() macro on the 'type'
Greetings! Last followup:
Nothing here should affect any kfreebsd_amd64 machine, right? My
understanding is that these do not require cache flushing. Thus the
failure:
https://buildd.debian.org/status/fetch.php?pkg=acl2&arch=kfreebsd-amd64&ver=4.3-1&stamp=1326315213
mv *saved_acl2.gcl saved_a
Ok thanks, I'll keep on with plan B (INIT_CUMULATIVE_LIBCALL_ARGS with special
libcall handling)
Selim
-Message d'origine-
De : Ian Lance Taylor [mailto:i...@google.com]
Envoyé : vendredi 4 mai 2012 15:58
À : BELBACHIR Selim
Cc : gcc@gcc.gnu.org
Objet : Re: type argument in FUNCTION_ARG
On 05/04/12 07:07, Camm Maguire wrote:
> Nothing here should affect any kfreebsd_amd64 machine, right?
Correct.
r~
On 04/05/12 14:44, Ian Lance Taylor wrote:
I agree that there is something wrong here. I agree that as written
the constraints for operands 0, 1, and 2 should have a '+'.
That said, a '+' constraint is most useful for a pattern that expands
into multiple instructions. I think this would be bet
On May 4, 2012, at 9:44 AM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> Expand generates:
>>
>> (define_insn_and_split "movmem_long"
>> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>> (set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
>>(m
writes:
> I thought that the "operand" in a mem:BLK is the pointer to the block,
> not the block itself. So if the instruction(s) generated don't touch
> the pointer -- a likely answer for a block-move instruction -- then
> the operand would be read-only. Is that the right interpretation?
Yes.
On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
> writes:
>
>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>> not the block itself. So if the instruction(s) generated don't touch
>> the pointer -- a likely answer for a block-move instruction -- then
>> the opera
On 05/04/12 06:39, Camm Maguire wrote:
> I'm wondering if there is a simple configure time test to detect when
> this has been fixed. If I just aborted using __builtin___clear_cache if
> it is in fact a noop on alpha, ppc, ppc64, and ia64, would this suffice?
I can't think of any simple, portable
writes:
> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>
>> writes:
>>
>>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>>> not the block itself. So if the instruction(s) generated don't touch
>>> the pointer -- a likely answer for a block-move instruction --
On May 4, 2012, at 1:52 PM, Ian Lance Taylor wrote:
> writes:
>
>> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>>
>>> writes:
>>>
I thought that the "operand" in a mem:BLK is the pointer to the block,
not the block itself. So if the instruction(s) generated don't touch
>>
writes:
> What I was trying to describe is the handling of a memcpy operation in the
> .md file, where the operands are the memory pointers and (in my case) I want
> to tell the machinery that the registers it's using to pass in the addresses
> no longer have those addresses in them on complet
On 19/04/12 17:36, Andrew Stubbs wrote:
On 18/04/12 21:47, Richard Sandiford wrote:
I still prefer the idea of disabling in the first pass. It'll need to
be tested on something like non-NEON ARM to see whether it makes things
worse or better there. (I think size testing would be fine.)
I'll ha
On Tue, Oct 25, 2011 at 4:28 AM, Bingfeng Mei wrote:
> Thanks, Andrew. I also implemented a quick patch on our port (based on GCC
> 4.5).
> I noticed it produced better code now for our applications. Maybe eliminating
> control flow in earlier stage helps other optimizing passes. Currently, tree
Snapshot gcc-4.6-20120504 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120504/
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
Hello, please consider the little program below which was compiled on GCC 4.7.0.
At the line containing the comment /* auto */, when using auto instead of
vector, the expected result which would be [3][6][9][12][15] is computed
as [6][12][15][15][15] for some reason. Despite the high chance of t
On 5 May 2012 00:04, Amit Markel wrote:
> Hello, please consider the little program below which was compiled on GCC
> 4.7.0.
Your question is inappropriate on this list which is for discussing
development of GCC not with GCC. Your question would be appropriate
on the gcc-help list, please take a
26 matches
Mail list logo
