Andrew Stubbs wrote:
I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
Given the following command:
cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
-auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
-ftree-vectorize -o pr34330.s -fsched
On 07/14/2009 09:17 PM, Benjamin Kosnik wrote:
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the
On 07/14/2009 10:31 PM, Jean Christophe Beyler wrote:
Ok, so actually, my cpu.h file had some of those included. I've
removed them and am now filling in the constraints.md file with what
is needed. I also so that they were obsolete in the GCC internals,
I'll be moving everything to the constraint
As you can see, the compiler uses r9 to store data and then uses that
for data[0] but also loads in r7 data+8 instead of directly using r9.
If I remove the loop then it does not do this.
This optimization is done by CSE only, currently. That's why it cannot
look through loops.
Paolo
> At the risk of being naive: implement it. I'm not quite sure what
> you're looking for here?
I'd rather have some confidence that the way I choose to implement it
would be acceptable to those who would be reviewing it ;-)
I'll give it a shot at the same point in the code where we call the
tar
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
> I finally got the last of the feedback I needed from our customers,
> and they agree that the AAPCS functionality is suitable for their
> ports as well.
Great!
> What's
Snapshot gcc-4.4-20090714 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090714/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>>> Why do you need alias-set numbers?
>>
>> We want to represent the alias set information as an extra subscript
>> on memory accesses: for example,
>>
>> if we have A[10] and supposing that
Ok, so actually, my cpu.h file had some of those included. I've
removed them and am now filling in the constraints.md file with what
is needed. I also so that they were obsolete in the GCC internals,
I'll be moving everything to the constraints then.
Thank you for your help,
Jc
On Tue, Jul 14, 20
> >> I think the ARM specification is pretty sensible, and would make a
> >> good cross-platform approach.
> >
> > Could you distill it for us?
>
> The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
I finally got the last of the feedback I needed from our customers,
and they agree
Dear all,
As some might know, I've been concentrating on optimizing the handling
of loads for my port of GCC. I'm now considering this code:
uint64_t data[107];
uint64_t foo (void)
{
uint64_t x0, x1, x2, x3, x4, x5,x6,x7;
uint64_t i;
for(i=0;i<107;i++) {
data[i] = i;
}
Jean Christophe Beyler writes:
> In file included from ./tm_p.h:5,
> from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35:
> ./tm-preds.h:40:1: warning: "CONSTRAINT_LEN" redefined
> In file included from ./tm.h:6,
> from /home/toto/gcc-4.3.2/gcc/c-pragma.c:24:
> /home/tot
On Wed, 8 Jul 2009, Diego Novillo wrote:
> > http://gcc.gnu.org/gcc-4.5/criteria.html
>
> Thanks. I've filtered the non-ELF platforms from both lists to get this:
You should test LTO-enabled cross tools from a non-ELF primary or
secondary host to an ELF primary or secondary target, as well as
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the only open
issues standing in the way of the conv
Dear all,
I'm continuing this port and have run into something strange, if I add
a constraints.md file with only this:
(define_constraint "I"
"A signed 16-bit constant (for arithmetic instructions)."
(and (match_code "const_int")
(match_test "SMALL_OPERAND (ival)")))
(Like one of the c
On 07/14/2009 07:35 PM, Janis Johnson wrote:
What's the forum for discussions about the C++ ABI?
cxx-abi-...@codesourcery.com
Jason
Tested on x86_64. Needed a bit of tweaking due to the removal of %J
from mainline.
Diego.
Mainline merge @149625.
* configure.ac (ACX_PKGVERSION): Update revision merge string.
* configure: Regenerate.
* lto-symtab.c (lto_symtab_compatible): Replace uses of
On Tue, 2009-07-14 at 17:16 +0200, Jason Merrill wrote:
> On 07/09/2009 12:32 AM, Janis Johnson wrote:
> > Given that libstdc++ is used with compilers other than G++, is it
> > allowable to depend on non-standard C++ compiler support?
>
> Seems reasonable to me, but we may want to standardize the
On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>> Why do you need alias-set numbers?
>
> We want to represent the alias set information as an extra subscript
> on memory accesses: for example,
>
> if we have A[10] and supposing that A is in alias set 6, this would be
> represented as "memory_a
On Tue, Jul 14, 2009 at 10:26, Richard
Guenther wrote:
> What do you mean by 'different number for each alias set'?
An alias set numbering maps alias sets to integer numbers,
and that map is one-to-one.
> If you want to have a number that is the same for all conflicting
> memory references then
On Tue, Jul 14, 2009 at 5:14 PM, Sebastian Pop wrote:
> Hi Richi,
>
> On Tue, Jul 14, 2009 at 04:40, Richard
> Guenther wrote:
>> You misunderstood what alias-set numbers represent. Alias-set
>> numbers encode type-based alias information only - which in
>> your case cannot disambiguate a or Q.
>>
On 07/09/2009 12:32 AM, Janis Johnson wrote:
Given that libstdc++ is used with compilers other than G++, is it
allowable to depend on non-standard C++ compiler support?
Seems reasonable to me, but we may want to standardize the support in
the ABI.
Jason
Hi Richi,
On Tue, Jul 14, 2009 at 04:40, Richard
Guenther wrote:
> You misunderstood what alias-set numbers represent. Alias-set
> numbers encode type-based alias information only - which in
> your case cannot disambiguate a or Q.
>
I also have misunderstood this.
> For dependency checking you
Stefan Lampe writes:
> Here's some code that produced a surprising result with GCC 4.3.3 on
> linux 64. I'd have expected all addresses output to be the same.
This message should have gone to gcc-h...@gcc.gnu.org rather than
g...@gcc.gnu.org. Please take any followups to gcc-help. Thanks.
You
Eric Botcazou wrote:
> Patch attached. I'll give it a whirl on SPARC but not immediately so, Kaz,
> if
> you can test it on SH in the meantime, you can apply it on all branches.
>
>
> 2009-07-14 Eric Botcazou
>
> PR rtl-optimization/40710
> * resource.c (mark_target_live_regs)
> > Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?
>
> The same question arises to me.
That's explained in the head comment of find_basic_block: the CFG is destroyed
by the DBR pass in some controlled way so the strategy is to recompute the
liveness info starting from data that ar
On Tue, Jul 14, 2009 at 11:12 AM, Li Feng wrote:
> Hi Richard,
> On Tue, Jul 14, 2009 at 4:54 PM, Richard
> Guenther wrote:
>> On Tue, Jul 14, 2009 at 8:01 AM, Li Feng wrote:
>>> Hi,
>>>
>>> I'm now working on Graphite branch and need to know
>>> the alias set information for each data_reference_p,
Hi Richard,
On Tue, Jul 14, 2009 at 4:54 PM, Richard
Guenther wrote:
> On Tue, Jul 14, 2009 at 8:01 AM, Li Feng wrote:
>> Hi,
>>
>> I'm now working on Graphite branch and need to know
>> the alias set information for each data_reference_p, which
>> would be an integer (or alias_set_type) stands for
On Tue, Jul 14, 2009 at 8:01 AM, Li Feng wrote:
> Hi,
>
> I'm now working on Graphite branch and need to know
> the alias set information for each data_reference_p, which
> would be an integer (or alias_set_type) stands for which
> alias set it is in.
>
> I tried to get the alias set information wi
Hi,
Here's some code that produced a surprising result with GCC 4.3.3 on linux 64.
I'd have expected all addresses output to be the same.
I guess the reason for this is that when merging the templates instantiated in
one.cpp and two.cpp, the linker doesn't perform a complete merge, but only
m
30 matches
Mail list logo
