On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
We already have the hooks, they have just been stuck in plugin.c when
they should really be in the generic backend. See register_pass.
(Sigh, every time I looked at this I said "the pass control has to be
generic" but it still wound up in plugin.c
Paolo Bonzini writes:
> On 09/24/2009 08:14 AM, Ian Lance Taylor wrote:
>> I don't agree with this. If we want this code to be x86_64 specific,
>> then it should be done by having the i386 backend add the pass to the
>> pass manager, much as plugins can add a pass. Adding stuff to
>> md-reorg i
On 09/24/2009 08:14 AM, Ian Lance Taylor wrote:
I don't agree with this. If we want this code to be x86_64 specific,
then it should be done by having the i386 backend add the pass to the
pass manager, much as plugins can add a pass. Adding stuff to
md-reorg is a step backward.
That's true. H
Paolo Bonzini writes:
> On 08/08/2009 11:59 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> Here is a patch to eliminate redundant zero-extension instructions
>> on x86_64.
>
> The code looks nice! However, since it is very specific to x86 (and
> x86 patterns), I'd rather see it in the i386 machine
On 08/08/2009 11:59 PM, Sriraman Tallam wrote:
Hi,
Here is a patch to eliminate redundant zero-extension instructions
on x86_64.
The code looks nice! However, since it is very specific to x86 (and x86
patterns), I'd rather see it in the i386 machine-dependent reorg pass.
Thanks!
Paol
On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson wrote:
> On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote:
>> On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson wrote:
>> > On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
>> >> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson
>> >>
On Wed, Sep 23, 2009 at 3:57 PM, H.J. Lu wrote:
> On Sat, Aug 8, 2009 at 2:59 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> Here is a patch to eliminate redundant zero-extension instructions
>> on x86_64.
>>
>> Tested: Ran the gcc regresssion testsuite on x86_64-linux and verified
>> that the result
On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote:
> On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson wrote:
> > On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
> >> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote:
> >> > I've been implementing ISO/IEC TR 24733, "an extensio
Sorry, it is the other way around.
Total number of zero-extension instructions before : 5814
Total number of zero-extension instructions after : 1456
Thanks for pointing it.
On Wed, Sep 23, 2009 at 4:10 PM, Ramana Radhakrishnan
wrote:
>>
>> GCC bootstrap :
>>
>> Total number of zero-extens
>
> GCC bootstrap :
>
> Total number of zero-extension instructions before : 1456
> Total number of zero-extension instructions after : 5814
> No impact on boot-strap time.
You sure you have these numbers the right way around ? Shouldn't the
number of zero-extension instructions after the pa
On Sat, Aug 8, 2009 at 2:59 PM, Sriraman Tallam wrote:
> Hi,
>
> Here is a patch to eliminate redundant zero-extension instructions
> on x86_64.
>
> Tested: Ran the gcc regresssion testsuite on x86_64-linux and verified
> that the results are the same with/without this patch.
>
>
> Problem Desc
Hi Richard,
I finally got around to getting the data you wanted. Thanks for
the response. Please
find my comments below.
On Sun, Aug 9, 2009 at 2:15 PM, Richard Guenther
wrote:
> On Sat, Aug 8, 2009 at 11:59 PM, Sriraman Tallam wrote:
>> Hi,
>>
>>Here is a patch to eliminate redundant
Eric Botcazou wrote:
>> Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that
>> has superfluous spaces (whether leading, trailing or embedded), or shall I
>> send a patch to add a $(strip) to the right-hand side of the ifeq
>> comparison? Or perhaps we should do
>>
>> LIBGNAT_T
On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson wrote:
> On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
>> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote:
>> > I've been implementing ISO/IEC TR 24733, "an extension for the
>> > programming language C++ to support decimal floating
On 09/23/2009 02:11 PM, Janis Johnson wrote:
The class types for std::decimal::decimal32 and friends do have the
proper modes. I suppose I could special-case aggregates of those modes
but the plan was to pass these particular classes (and typedefs of
them) the same as scalars, rather than _any_
On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote:
> > I've been implementing ISO/IEC TR 24733, "an extension for the
> > programming language C++ to support decimal floating-point arithmetic",
> > in GCC. It might be ready as an exp
> Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that
> has superfluous spaces (whether leading, trailing or embedded), or shall I
> send a patch to add a $(strip) to the right-hand side of the ifeq
> comparison? Or perhaps we should do
>
> LIBGNAT_TARGET_PAIRS:=$(strip $(LIBG
On 09/23/2009 11:00 AM, IainS wrote:
DW_CFA_restore (5)
Assertion failed: (reg_state_pos != cie->initial_state.regs.end()),
function ParseInstructions, file
/SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFDebugFrame.cpp,
line 353.
Abort trap
There could be some confusion in DW_CFA_r
Dave Korn wrote:
> Eric Botcazou wrote:
>> Your .diff contains this
>>
>> + EH_MECHANISM=-gcc
>>
>> so it looks as though the base compiler was SJLJ.
>
> Ah, bingo! Thanks Eric; yes, I have a recent build of an SJLJ Gnat from
> HEAD lying around my PATH ahead of my old 4.3.2-with-ZCX. Getting
Hello,
I have this scenario:
using "dwarfdump --debug-frame" in a very simple object generated
with current trunk.
I am trying to figure out (with the dwarf3 spec) wether the problem
is in the tool (dwarfdump), or what we're emitting.
Can anyone more knowledgeable comment?
Iain.
+#define PSEUDO_REG_P(X) ((X)>=FIRST_PSEUDO_REGISTER)
There's already a HARD_REGISTER_NUM_P that's the exact inverse.
+#define G_REG_P(X) ((X)<32)
I suppose you're planning to add floating point registers?
+#define CONST_OK_FOR_LETTER_P(VALUE, C) \
+( (C) == 'J' ? (VA
Rob Quigley writes:
> I am looking for some more information of the SSA Gimple syntax and
> was wondering if there was BNF available?
There is no BNF. Sorry.
> I am interested in the IR of gcc and am just looking for some further
> documentation/explanation of some of the syntax I am observin
On Wed, Sep 23, 2009 at 11:01, Rob Quigley wrote:
> Does anyone know where I might find such information? Any help and/or
> pointers in the direction of information would be most welcome. I
> tried the gcc wiki but I couldn't find much on SSA Gimple/low-Gimple
There are articles, slides and poin
On 09/23/2009 09:22 AM, Jerry Quinn wrote:
I'm not really sure how everything fits together here. Am I missing
something obvious?
I notice that you're missing the fix_string_type that tinfo_name does.
But I'd rather not duplicate the code that creates the STRING_CST;
better to delay the call
Hello,
I am looking for some more information of the SSA Gimple syntax and
was wondering if there was BNF available?
I am interested in the IR of gcc and am just looking for some further
documentation/explanation of some of the syntax I am observing such
as:
OBJ_TYPE_REF(D.103787_32;D.103784_29
With the previous patch, bootstrap failed when building libgomp: -gstrict-dwarf
was
not passed during the configure stage. So it is not sufficient to pass it to
BOOT_CFLAGS. Would repeating the trick for CFLAGS_FOR_TARGET have a chance to
work?
Dominique
Hi Dominique,
I would expect you to need -gstrict-dwarf in CFLAGS_FOR_TARGET also
but the point of my question is to find a way of having this on by
default on Darwin (which is what we currently seem to need).
(more research is need on the latter - to determine whether the
problem lies in
Iain,
I am currently bootstrapping on i686-apple-darwin9 with the current patch:
diff -uN /opt/gcc/_gcc_clean/config/mh-intel-darwin
/opt/gcc/gcc-4.5-work/config/mh-intel-darwin
--- /opt/gcc/_gcc_clean/config/mh-intel-darwin 1970-01-01 01:00:00.0
+0100
+++ /opt/gcc/gcc-4.5-work/config/
On Tue, 2009-09-22 at 09:40 -0400, Jason Merrill wrote:
> On 09/22/2009 07:04 AM, Jerry Quinn wrote:
> > On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
> >> On 09/14/2009 11:54 AM, Jason Merrill wrote:
> >>> I think the way to go with this is to revert the compiler bits of
> >>> r149964, n
daniel tian wrote:
> Hi:
>
> Do I have to write the DImode operations on my *.md target description
> file?
Yes. movMM must be implemented for all types that you want the compiler to
be able to handle at all; it's the only way it knows to move them around.
(Technically, it's supposed to b
Quoting IainS :
Hi,
In the case that a compiler flag in common.opt would best be served
with different default values on different targets.
I.E. a target-dependent Init()
Where can this be effected in the machinery ?
I can see how to make an override - but not a default.
Set the default to
Hi:
Do I have to write the DImode operations on my *.md target description file?
Now I build my gcc first, there is an error on libgcc2.c. which is
an __muldi3 function.
The error information is:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3:
../../../rice-gcc-4
Sorry, I just found and fixed the bug. the config.host file in /libgcc/.
Sorry.
Hi,
When I build gcc first time this which the configure parameter is like this:
../rice-gcc-4.3.0/configure --target=$TARGET --prefix=$PREFIX
--enable-languages=c --without-headers --with-newlib --with-gnu-as
--with-gnu-ld --disable-multilib --disable-libssp
Binutils is ok and install in the $
Thank you. I fixed the error. it caused by macro:
#define ELIMINABLE_REGS \
{\
{ARG_POINTER_REGNUM,FRAME_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM,STACK_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} \
}
because everytime when gcc check the frame_pointer_need
Hi,
In the case that a compiler flag in common.opt would best be served
with different default values on different targets.
I.E. a target-dependent Init()
Where can this be effected in the machinery ?
I can see how to make an override - but not a default.
cheers,
Iain
Hi,
> IVOpts cannot identify start_26, start_4 and ivtmp_32_7 to be copies.
> The root cause is that expression 'i + start' is identified as a common
> expression between the test in the header and the index operation in the
> latch. This is unified by copy propagation or FRE prior to loop
> opt
On Tue, Sep 22, 2009 at 11:50 PM, Vladimir Makarov wrote:
> Ian Lance Taylor wrote:
>>
>> "Amker.Cheng" writes:
>>
>>
>>>
>>> In function new_ready, it calls to min_insn_conflict_delay with
>>> "min_insn_conflict_delay (curr_state, next, next)".
>>> But the function's comments say that it retur
> Done. But if you have more cases, please report them.
Not yet. Thx!
--
Best regards,
Yuri
> Yes, it's possible that 64-bit ints are not supported by the testsuite.
> Changes to fix that are welcome.
I am not a gcc developer. Could someone verify and commit this patch
for testsuite/gcc.c-torture/execute/980526-2.c?
Best regards,
Yuri
980526-2.patch
Description: Binary data
On 09/23/2009 10:44 AM, Yuri Gribov wrote:
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
Yes, it's possible that 64-bit ints a
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
The test runs to_kdev_t(0x12345678) (see below) and verifies that
result equals 0x1
On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote:
> I've been implementing ISO/IEC TR 24733, "an extension for the
> programming language C++ to support decimal floating-point arithmetic",
> in GCC. It might be ready as an experimental feature for 4.5, but I
> would particularly like to get i
43 matches
Mail list logo
