Eric Botcazou wrote:
> So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and
> then start to post their patches on the gcc-patches@ list. I'll sponsor them
> for write access at that point.
>
Hello Eric Botcazou,
I want to once again ask for write credentials so that
I
On 21/10/11 22:41, Richard Henderson wrote:
On 10/21/2011 10:15 AM, Paulo J. Matos wrote:
So I have implemented the nadd and addc as:
(define_insn "negqi2"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_operand:QI 1 "register_operand" "0")))
(set (reg:CC_C RCC
On 23/10/11 22:21, Richard Henderson wrote:
On 10/21/2011 05:49 PM, paul_kon...@dell.com wrote:
There are lots of parts of the compiler that don't optimize well when an insn
has more than one output. For the normal insn, just clobber the flags; don't
include a second SET.
Yes, but... isn't
Hello,
I would like to implement a compiler fix for a SPARC-cpu variant
that does the following:
After each "fdivs" (SPARC single-float division) save the destination
FPU register to a stack memory location.
The sparc.md definition of fdivs is this one:
(define_insn "divsf3"
[(set (match_oper
Indeed, ptr_mode!=Pmode for my target.
I will try to figure out where such a Pmode comes from.
Thanks,
Aurélien
2011/10/23 Richard Guenther :
> On Fri, Oct 21, 2011 at 4:53 PM, Aurelien Buhrig
> wrote:
>> Hi,
>>
>> I'm trying to port gcc 4.6.1 for a new target for which Pmode=PSI.
>> I have an
Hello,
I am trying to extract the regsiter uses in instructions using note_uses
function. When encountering the following instruction I do not get r479
as a use; seemingly because of the following in note_use function:
if (GET_CODE (dest) == ZERO_EXTRACT)
{
(*fun) (&X
Hello All,
It is my pleasure to announce the release of MELT plugin 0.9.1 for GCC 4.6
MELT is a high level domain specific language to ease the development of GCC
extensions.
See http://gcc-melt.org/ for more.
The MELT plugin 0.9.1 for GCC 4.6 (dedicated to the memory of Denis M. Ritchie)
Hi All,
According to DWARF spec, a subprogram 'may' have DW_AT_return_addr
attribute. Please help me understand the following::
(1). GCC (latest) does not emit DW_AT_return_addr attributes in subprogram tags
(2). If [1] is true, then is it because of the fact that return
address can be computed
Hello,
I noticed that COND_EXPR is not expanded to conditional move
as MIN_EXPR/MAX_EXPR are (assuming movmodecc is available).
I wonder why not?
I have some loop that fails tree vectorization, but still contains
COND_EXPR from tree ifcvt pass. In the end, the generated code
is worse than if I d
> I appreciate any advise of how to resolve this -- should I add
>
> (*fun) (&XEXP (dest, 0), data); ?
Actually I don't see why not - a zero_extract on the LHS of an
expression is supposed to be a bit field insert on that register.
Isn't there an implicit read of the destination register involved
On Mon, Oct 24, 2011 at 2:55 PM, Bingfeng Mei wrote:
> Hello,
> I noticed that COND_EXPR is not expanded to conditional move
> as MIN_EXPR/MAX_EXPR are (assuming movmodecc is available).
> I wonder why not?
>
> I have some loop that fails tree vectorization, but still contains
> COND_EXPR from tre
Kai Tietz wrote:
> Hi,
>
> For trunk-version I have a tentative patch for this issue. On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
>
> But could somebody give this patch a try?
>
> Regards,
> Kai
>
> ChangeLog
>
>
2011/10/24 Bob Breuer :
> Kai Tietz wrote:
>> Hi,
>>
>> For trunk-version I have a tentative patch for this issue. On 4.6.x
>> and older branches this doesn't work, as here we can't differenciate
>> that easy between ms- and sysv-abi.
>>
>> But could somebody give this patch a try?
>>
>> Regards,
On Mon, Oct 24, 2011 at 7:00 AM, Richard Guenther
wrote:
> On Mon, Oct 24, 2011 at 2:55 PM, Bingfeng Mei wrote:
>> Hello,
>> I noticed that COND_EXPR is not expanded to conditional move
>> as MIN_EXPR/MAX_EXPR are (assuming movmodecc is available).
>> I wonder why not?
>>
>> I have some loop that
> I would like to implement a compiler fix for a SPARC-cpu variant
> that does the following:
> After each "fdivs" (SPARC single-float division) save the destination
> FPU register to a stack memory location.
Do you need to reload it afterward or just save it?
--
Eric Botcazou
On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith wrote:
> One more question on this quest (drifting a little more off topic).
> In my log files I see a lot of these errors:
>
> ld: 0711-768 WARNING: Object
> ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1,
> function .std::termin
While working on some test cases I noticed that the 'fsmuld'
instruction on sparc was not being matched by the combiner for
things like:
double fsmuld (float a, float b)
{
return a * b;
}
Combine does try to match:
(set x (float_extend:DF (mul:SF y z)))
instead of what backends (and
All,
Earlier this year libtool.m4 and friends received an update to support
the upcoming FreeBSD10.x version. Now as it seems it was not enough.
We need an additional update, especially the objformat detection needs a
fix. It is a one-liner, in libtool.m4. (around line 2273 of libtool.m4
we ha
Eric Botcazou wrote:
>> I would like to implement a compiler fix for a SPARC-cpu variant
>> that does the following:
>> After each "fdivs" (SPARC single-float division) save the destination
>> FPU register to a stack memory location.
>
> Do you need to reload it afterward or just save it?
>
I
> I just need to save it. It needs to be saved so that the FPU
> pipeline is flushed.
Then why not save it just below the stack pointer?
--
Eric Botcazou
On 2011.10.25 at 06:39 +0200, Andreas Tobler wrote:
> Is it preferred to sync libtool.m4 completely? Or do we want to shift
> this update for a later time? I'm aware of the closing stage one.
An libtool update is also needed for bootstrap-lto with slim lto object
files. So a complete sync with up
21 matches
Mail list logo
