On Thu, Oct 2, 2008 at 12:43 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> I think this is the wrong place to fix this. If you would override
>> the sizetypes precision from your target, would that fix it? That
>> is, in stor-layout.c set_sizetype make the target allow adjusting
>> the passed ty
Hi Brendon,
Thanks for reading all this :-) Comments in line.
Brendon Costa wrote:
I have notes inline below, following is my summary of libplugin from
what i understand of your posts:
* It exists as a fraemwork that works with GCC now
* It uses xml files to define plugins (Allows making ne
Hello
Is this best List to get help for GCC coding problems ?
in gcc/c-decl.c
I see in fnction finish_decl
"""
finish_decl (tree decl, tree init, tree asmspec_tree)
{
there is access possible to asmspec_tree.
but the func
push_parm_decl
have no parameter asmspec_tree.
is there a w
> (what is the current sizetype mode?)
HImode
> There are no bitfield instructions. What I suggest is that you make
> sizetype 16bits (HImode), as if I remember correctly you are not
> concerned anyway about pointer offsets larger than what fits into
> signed 16bits. If you then use the expans
I've been reading up on GCC internals so that I can begin my project.
Initial proposal: http://gcc.gnu.org/ml/gcc/2008-09/msg00383.html
(with many follow-ups).
My idea of implementing so far is: Alter the code in gcc/cp/parser.c
so that I can check strict exception specification during parsing,
si
This is what I get with your patch and not mine:
neg.w r0 ; 7neghi2/1
mov.w r0,a0; 9
zero_extendhipsi2
add.l a0,r3r1 ; 15
add
Ok, here's where it's getting expanded:
#12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450,
unsignedp=1)
at ../../gcc/gcc/expr.c:859
#13 0x0831f83a in expand_binop_directly (mode=945, binoptab=0x8824de0,
op0=0xb7f63410,
op1=0xb7f63450, target=0xb7f63440, unsign
Hello everyone,
As a proof of concept, I am trying to extend the gcc spu backend to produce
a few new assembly instructions, specifically loads and stores of the form
Load rt, s2(s18)
Store s2(s18), rc
However after searching and reading a lot of documentation, I still cannot
figure out all the
On Thu, Oct 2, 2008 at 8:50 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Ok, here's where it's getting expanded:
>
> #12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450,
> unsignedp=1)
>at ../../gcc/gcc/expr.c:859
> #13 0x0831f83a in expand_binop_directly (mode=945, bi
> Ok, I just looked for POINTER_PLUS_EXPR and tried to make sure its
> offset is always sign-extended. Can you check where on the call
> path above we miss this special treatment?
It looks like it drops past them all and gets the generic treatment,
just before the MINUS_EXPR case.
This seems to work, with a suitable extendhipsi2 pattern for m32c:
Index: expr.c
===
--- expr.c (revision 140759)
+++ expr.c (working copy)
@@ -8455,12 +8459,34 @@ expand_expr_real_1 (tree exp, rtx target
if (
> 2008-10-01 Mark Mitchell <[EMAIL PROTECTED]>
>
> * MAINTAINERS (Blanket Write Privs): Change to Global Reviewers.
This is apparently incomplete, see the Non-Algorithmic Maintainers section.
--
Eric Botcazou
Jan,
I was wondering if you could help me figure out how to fix the tests
g++.old-deja/g++.other/static14.C and g++.old-deja/g++.other/static20.C
which started failing on IA64 HP-UX at version 138150 when you checked
in the C++ inlining change. Here is a minimal test:
struct basic_string { ~b
Hi All,
Shouldn't this macro:
#define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \
real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0))
be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing
something here?
In the target I am currently working, DOUBLE_TYPE_SIZE is defined
> Load rt, s2(s18)
> Store s2(s18), rc
>
> However after searching and reading a lot of documentation, I still cannot
> figure out all the files that need to be editted in order for gcc to output
> an instruction and understand how that instruction works. Currently I have
> it detecting the 'store
Snapshot gcc-4.3-20081002 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081002/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Eric Botcazou wrote:
>> 2008-10-01 Mark Mitchell <[EMAIL PROTECTED]>
>>
>> * MAINTAINERS (Blanket Write Privs): Change to Global Reviewers.
>
> This is apparently incomplete, see the Non-Algorithmic Maintainers section.
It's a fair question.
I will raise the issue with the SC.
--
Mark M
On Thu, 2 Oct 2008, [EMAIL PROTECTED] wrote:
> I was wondering if you could help me figure out how to fix the tests
> g++.old-deja/g++.other/static14.C and g++.old-deja/g++.other/static20.C
> which started failing on IA64 HP-UX at version 138150 when you checked
> in the C++ inlining change. Here
Bernd Roesch <[EMAIL PROTECTED]> writes:
> Is this best List to get help for GCC coding problems ?
Probably.
> but the func
>
> push_parm_decl
>
> have no parameter asmspec_tree.
It shouldn't need one.
I'm not sure what the semantics of this should be. Are you trying to
change the calling
"Omar Torres" <[EMAIL PROTECTED]> writes:
> Shouldn't this macro:
> #define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \
> real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0))
>
> be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing
> something here?
That would certainly
> Thanks for tracking this down, Steve. Interesting enough, I am seeing
> exactly the same on i386-unknown-freebsd6.3, cf.
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02509.html
Likewise on Solaris.
--
Eric Botcazou
21 matches
Mail list logo
