define_split should be the correct way to handle this.
You should first use define_split to break your 256bit pattern and
generate legitimized 128bit rtl pattern sequence for you processor
mips_output_move should only be used to handle those legitimized one.
256 bit rtl pattern > define
On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> > ok, took long enough, but that answers most things. your usage of "x32-"
> > prefixed binaries in the documentation seems to imply a lot more than the
> > fact you just picked those lo
On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
>> > so we get back to my original e-mail:
>> > are you getting a unique host tuple for this ? or are you
>> > extending
hi all
Our processor have a outrageous load insn, so I have to make gcc
support it. But when I tried some way, I failed.
When we suppose a load should be:
load_256 $z1, 16($fp) ;load 256bits to a 256bits-wide register.
we have to split it into:
load_low_128 $z1, 16($fp)
On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> > so we get back to my original e-mail:
> >are you getting a unique host tuple for this ? or are you
> > extending x86_64-linux-gnu ? so the only way of knowing which ABI is to
Jovi Zhang writes:
> I encounter a problem about several .so library linked by a
> problem, when a library A executing call function which source at same
> .so, but strangly it jump to another library B address with same
> function name, then program crash.
>
> Why library A don't find func
Hi,
I encounter a problem about several .so library linked by a
problem, when a library A executing call function which source at same
.so, but strangly it jump to another library B address with same
function name, then program crash.
Why library A don't find function name in itself address
There was some discussion earlier of defaulting FSF gcc to
--enable-build-with-cxx
for the stage2 compiler (with the stage 1 bootstrap retaining the use of the
system c compiler).
Is this change planned for gcc 4.7? On x86_64-apple-darwin10, I have had few
problems
routinely bootstrapping x86
On Tue, Mar 15, 2011 at 7:54 PM, Jack Howarth wrote:
> On Tue, Mar 15, 2011 at 08:37:38PM -0400, Robert Dewar wrote:
>> On 3/15/2011 8:11 PM, Jack Howarth wrote:
>>
>>> FSF legal could solve these problems in a minute. Don't shove a blanket
>>> dislaimer for all employees at the employer. Give
Hi,
I have touched this subject before:
http://thread.gmane.org/gmane.comp.gcc.devel/116198/focus=116200
Now, at the time I didn't pursue this issue but now with 4.4.4 this
keeps happening and I traced it to the cprop_hardreg replacing a
register which makes the set insn having the same source
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> Ian Lance Taylor writes:
>
>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>
> extern tree xref_tag (enum tree_code code, tree name);
>
> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
> tag.
>
Ian Lance Taylor writes:
> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
extern tree xref_tag (enum tree_code code, tree name);
AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
tag.
Unfortunately, declares a different ‘xref_tag’ func
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>> extern tree xref_tag (enum tree_code code, tree name);
>>>
>>> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
>>> tag.
>>>
>>> Unfortunately, declares a different ‘xref_tag’ function,
>>> so it seems that the above
Hi,
Ian Lance Taylor writes:
> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> ‘c-common.h’ lacks this declaration:
>>
>> extern tree xref_tag (enum tree_code code, tree name);
>>
>> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
>> tag.
>>
>> Unfortunately,
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> ‘c-common.h’ lacks this declaration:
>
> extern tree xref_tag (enum tree_code code, tree name);
>
> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
> tag.
>
> Unfortunately, declares a different ‘xref_tag’ function,
>
Mike Frysinger writes:
> but it doesnt say what to do for binutils or gcc itself. obviously you cant
> use the -mx32 flag when building the cross gcc for the first time since the
> current native gcc wont support it.
Of course, for a compiler tool the only thing that matters is the
target.
A
On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
>> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> >> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> >> > On
Hello,
‘c-common.h’ lacks this declaration:
extern tree xref_tag (enum tree_code code, tree name);
AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
tag.
Unfortunately, declares a different ‘xref_tag’ function,
so it seems that the above declaration cannot just be adde
18 matches
Mail list logo
