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
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
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
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
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
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 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:
> 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 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
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
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 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
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 05/04/12 07:07, Camm Maguire wrote:
> Nothing here should affect any kfreebsd_amd64 machine, right?
Correct.
r~
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
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
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! 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
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
Quoting BELBACHIR Selim :
Any ideas on how to get around this problem?
You can look at the name of library functions.
"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
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
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
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 "
> 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
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
26 matches
Mail list logo
