template instantiation and anonymous namespaces
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
merges for those methods that were instantiated in each translation unit. When
using the zero argument constructor one type is used, when using the one
argument constructor, another type is used.
As I understand it, the anonymous namespace has internal linkage, so Dummy
should be considered a different type in each unit, and the template
instantiations shouldn't really be merged. Under -O3 the addresses output are
the same. Whether this is due to separate templates or a single merged
template, I'm not sure.
I really just wanted to check that my understanding is correct. For the program
I was working on I use named namespaces to provide the right semantics.
Thanks for your time,
Stefan
-- nonsingleton.hpp
#ifndef NON_SINGLETON
#define NON_SINGLETON
#include
namespace {
class Dummy {};
}
template
class Singleton {
static ObjectT* object;
public:
static ObjectT& Instance() {
if (!object)
object = new ObjectT();
return *object; } };
template
ObjectT* Singleton::object = 0;
class NonSingleton {
typedef Singleton<> SingletonType;
public:
NonSingleton() {
std::cout << "0 arg constructor. Singleton: " <<
(&SingletonType::Instance()) << std::endl; }
NonSingleton(int i) {
std::cout << "1 arg constructor. Singleton: " <<
(&SingletonType::Instance()) << std::endl; }
~NonSingleton() {
std::cout << "Destructor. Singleton: " << (&SingletonType::Instance())
<< std::endl; } };
#endif
-- one.cpp
#include "nonsingleton.hpp"
void f() {
NonSingleton a; }
-- two.cpp
#include "nonsingleton.hpp"
int main() {
NonSingleton a;
NonSingleton b(1);
return 0; }
-- output
0 arg constructor. Singleton: 0x502010
1 arg constructor. Singleton: 0x502030
Destructor. Singleton: 0x502010
Destructor. Singleton: 0x502010
Re: How could I get alias set information from data_reference_p
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 with get_alias_set (tree) > (I've no idea how this function works, just a experimental > trying), for my testcase, it returns 2 for all the > data_reference_p->ref, which I think is unreasonable. > So I think I may go wrong somewhere. > > The question will be: how could I get it's relevant > alias set information from data_reference_p? > > p.s. : > In Graphite, the data reference was built for each > gimple stmt with: > get_references_in_stmt (stmt, &references); > then for each ref in references, data reference is created with: > dr = create_data_ref (nest, *ref->pos, stmt, ref->is_read); get_alias_set (dr->ref) is the correct thing. Why do you think it is unreasonable to return 2 for all of them? Why do you need alias-set information anyway? Thanks, Richard. > Thanks, > Li >
Re: How could I get alias set information from 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 which
>> alias set it is in.
>>
>> I tried to get the alias set information with get_alias_set (tree)
>> (I've no idea how this function works, just a experimental
>> trying), for my testcase, it returns 2 for all the
>> data_reference_p->ref, which I think is unreasonable.
>> So I think I may go wrong somewhere.
>>
>> The question will be: how could I get it's relevant
>> alias set information from data_reference_p?
>>
>> p.s. :
>> In Graphite, the data reference was built for each
>> gimple stmt with:
>> get_references_in_stmt (stmt, &references);
>> then for each ref in references, data reference is created with:
>> dr = create_data_ref (nest, *ref->pos, stmt, ref->is_read);
>
> get_alias_set (dr->ref) is the correct thing. Why do you think it
> is unreasonable to return 2 for all of them? Why do you need
> alias-set information anyway?
The testcase looks like this, where I assume that
p and a in the same alias set, while q and Q in another, and so on.
But between them, the alias set number should be different, otherwise
maybe I misunderstood somewhere about the alias set.
int Q[10];
int foo()
{
int i;
int a[10], b[20];
int *p = a;
int *q = Q;
for (i = 0; i < 10; i++)
{
p[i] = i;
a[i]= i - 5;
b[i] = i*i;
q[i] = 5;
}
return Q[3]*a[2]*b[10];
}
For you question,
We are using this information before dependency checking under
polyhedron, if 2 data references get different dimensions and they
are not in the same alias set, we could conclude that they
takes no dependency.
Li
Re: How could I get alias set information from data_reference_p
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, 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 with get_alias_set (tree)
>>> (I've no idea how this function works, just a experimental
>>> trying), for my testcase, it returns 2 for all the
>>> data_reference_p->ref, which I think is unreasonable.
>>> So I think I may go wrong somewhere.
>>>
>>> The question will be: how could I get it's relevant
>>> alias set information from data_reference_p?
>>>
>>> p.s. :
>>> In Graphite, the data reference was built for each
>>> gimple stmt with:
>>> get_references_in_stmt (stmt, &references);
>>> then for each ref in references, data reference is created with:
>>> dr = create_data_ref (nest, *ref->pos, stmt, ref->is_read);
>>
>> get_alias_set (dr->ref) is the correct thing. Why do you think it
>> is unreasonable to return 2 for all of them? Why do you need
>> alias-set information anyway?
>
> The testcase looks like this, where I assume that
> p and a in the same alias set, while q and Q in another, and so on.
> But between them, the alias set number should be different, otherwise
> maybe I misunderstood somewhere about the alias set.
>
> int Q[10];
>
> int foo()
> {
> int i;
> int a[10], b[20];
> int *p = a;
> int *q = Q;
>
> for (i = 0; i < 10; i++)
> {
> p[i] = i;
> a[i]= i - 5;
> b[i] = i*i;
> q[i] = 5;
> }
>
> return Q[3]*a[2]*b[10];
> }
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.
> For you question,
> We are using this information before dependency checking under
> polyhedron, if 2 data references get different dimensions and they
> are not in the same alias set, we could conclude that they
> takes no dependency.
For dependency checking you should use the dependence
checking routines or query the alias-oracle.
Richard.
> Li
>
Re: A question about df_get_live_in
> > 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 are still correct given the properties
of the aforementioned controlled way.
Here we start from the beginning of the function for insn 32 with
;; Start of basic block ( 0) -> 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(15){ }}
;; lr in4 [r4] 5 [r5] 6 [r6] 15 [r15] 146 [pr] 151 []
;; lr use 4 [r4] 5 [r5] 15 [r15] 146 [pr]
;; lr def 1 [r1] 2 [r2] 3 [r3] 15 [r15] 147 [t]
;; live in 4 [r4] 5 [r5] 6 [r6] 146 [pr]
;; live gen 1 [r1] 2 [r2] 3 [r3] 15 [r15] 147 [t]
;; live kill
and run into
(insn/f 111 8 112 fs/ext3/balloc.c:51 (set (mem:SI (pre_dec:SI (reg/f:SI 15
r15)) [0 S4 A32])
(reg:SI 146 pr)) 171 {movsi_i} (expr_list:REG_DEAD (reg:SI 146 pr)
(expr_list:REG_INC (reg/f:SI 15 r15)
(nil
The problem is that resource.c is doing life analysis the old fashioned way,
i.e. the LR way, with a mere
note_stores (PATTERN (real_insn), update_live_status, NULL);
which doesn't take into account PRE_DEC because the register is supposed to be
live before the PRE_DEC. It's true for LR but not for LIVE, as the use of the
stack pointer is considered artificial by the latter.
So I made a mistake when changing back the DF problem to LIVE in
2009-04-27 Richard Sandiford
Eric Botcazou
* resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up
a label's basic block.
(mark_target_live_regs): Tidy and rework obsolete comments.
Change back DF problem to LIVE. If a label starts a basic block,
assume that all registers that used to be live then still are.
(init_resource_info): If a label starts a basic block, set its
BLOCK_FOR_INSN accordingly.
(fini_resource_info): Undo the setting of BLOCK_FOR_INSN.
it should be reset to LR.
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): Reset DF problem to LR.
--
Eric Botcazou
Index: resource.c
===
--- resource.c (revision 149515)
+++ resource.c (working copy)
@@ -948,10 +948,11 @@ mark_target_live_regs (rtx insns, rtx ta
/* If we found a basic block, get the live registers from it and update
them with anything set or killed between its start and the insn before
- TARGET. Otherwise, we must assume everything is live. */
+ TARGET; this custom life analysis is really about registers so we need
+ to use the LR problem. Otherwise, we must assume everything is live. */
if (b != -1)
{
- regset regs_live = df_get_live_in (BASIC_BLOCK (b));
+ regset regs_live = DF_LR_IN (BASIC_BLOCK (b));
rtx start_insn, stop_insn;
/* Compute hard regs live at start of block. */
@@ -1055,7 +1056,7 @@ mark_target_live_regs (rtx insns, rtx ta
{
HARD_REG_SET extra_live;
- REG_SET_TO_HARD_REG_SET (extra_live, df_get_live_in (bb));
+ REG_SET_TO_HARD_REG_SET (extra_live, DF_LR_IN (bb));
IOR_HARD_REG_SET (current_live_regs, extra_live);
}
}
Re: A question about df_get_live_in
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): Reset DF problem to LR. Thanks for taking a look at this! I've just fired the tests with it on sh4-unknown-linux-gnu. Regards, kaz
Re: template instantiation and anonymous namespaces
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. Your test case doesn't compile, so it's hard to be sure what is going on. The linker should normally merge template instantiations which have the same name, but making the function static may be causing it to be static in the file, and thus not merged. Ian
Re: How could I get alias set information from data_reference_p
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 should use the dependence > checking routines or query the alias-oracle. How could we use the alias-oracle to output a different number for each alias set? Could you provide some directions to implement such a function? Thanks, Sebastian
Re: decimal float support for C++
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
Re: How could I get alias set information from data_reference_p
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. >> > > I also have misunderstood this. > >> For dependency checking you should use the dependence >> checking routines or query the alias-oracle. > > How could we use the alias-oracle to output a different number for > each alias set? Could you provide some directions to implement such a > function? What do you mean by 'different number for each alias set'? If you want to have a number that is the same for all conflicting memory references then you have to build the full conflict map and partition it. Likely not what you want? Why do you need alias-set numbers? Thanks, Richard. > Thanks, > Sebastian >
Re: How could I get alias set information from data_reference_p
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 you have to build the full conflict map and > partition it. > Likely not what you want? maybe > 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_access[6][10]". For B[3][4] with base array B in alias set 7 and 8, we would represent this as "memory_access[7][3][4] or memory_access[8][3][4]". The data dependence test that we currently have in the graphite branch would work with alias sets represented by an extra dimension to the array dimensions. Sebastian
Re: How could I get alias set information from data_reference_p
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_access[6][10]". > > For B[3][4] with base array B in alias set 7 and 8, we would represent > this as "memory_access[7][3][4] or memory_access[8][3][4]". > > The data dependence test that we currently have in the graphite branch > would work with alias sets represented by an extra dimension to the > array dimensions. And by the way, right now we consider that all the data refs alias each other, that means that we set the alias dimension of the memory accesses to 1 for every data reference. This makes the test very conservative: in the example above, with the current implementation, we would have: A: memory_access[1][10] B: memory_access[1][3][4] Sebastian
Re: decimal float support for C++
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 support in > the ABI. What's the forum for discussions about the C++ ABI? Janis
[lto] Mainline merge at rev 149625
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 %J in calls to error with calls to error_at and a specific location.
Re: decimal float support for 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
Adding constraints.md to my port
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 constraints from the mips port). And add a : (include "constraints.md") to my md file, I get these during the compilation: 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/toto/gcc-4.3.2/gcc/defaults.h:797:1: warning: this is the location of the previous definition In file included from ./tm_p.h:5, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35: ./tm-preds.h:42:1: warning: "REG_CLASS_FROM_CONSTRAINT" redefined In file included from ./tm.h:6, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:24: /home/toto/gcc-4.3.2/gcc/defaults.h:810:1: warning: this is the location of the previous definition In file included from ./tm_p.h:5, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35: ./tm-preds.h:44:1: warning: "CONST_OK_FOR_CONSTRAINT_P" redefined In file included from ./tm.h:6, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:24: /home/toto/gcc-4.3.2/gcc/defaults.h:801:1: warning: this is the location of the previous definition In file included from ./tm_p.h:5, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35: ./tm-preds.h:47:1: warning: "CONST_DOUBLE_OK_FOR_CONSTRAINT_P" redefined In file included from ./tm.h:6, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:24: /home/toto/gcc-4.3.2/gcc/defaults.h:805:1: warning: this is the location of the previous definition In file included from ./tm_p.h:5, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35: ./tm-preds.h:49:1: warning: "EXTRA_MEMORY_CONSTRAINT" redefined In file included from ./tm.h:6, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:24: /home/toto/gcc-4.3.2/gcc/defaults.h:781:1: warning: this is the location of the previous definition In file included from ./tm_p.h:5, from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35: ./tm-preds.h:51:1: warning: "EXTRA_ADDRESS_CONSTRAINT" redefined Any ideas why this happens when I add a constraint to my machine description? As always, thank you very much for your time, Jean Christophe Beyler
updating autotools status
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 conversion of the GCC source repository. What's the eta for the 2.64 autoconf release? How is this to be timed with the end of GCC Stage 1? If autoconf 2.64 is not out by the end of July, does it make sense to use autoconf 2.63 instead? -benjamin
Re: Status of LTO merge to mainline
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 testing that tools still work with LTO disabled. -- Joseph S. Myers jos...@codesourcery.com
Re: Adding constraints.md to my port
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/toto/gcc-4.3.2/gcc/defaults.h:797:1: warning: this is the > location of the previous definition See defaults.h: #if !defined CONSTRAINT_LEN\ && !defined REG_CLASS_FROM_LETTER \ && !defined REG_CLASS_FROM_CONSTRAINT \ && !defined CONST_OK_FOR_LETTER_P \ && !defined CONST_OK_FOR_CONSTRAINT_P \ && !defined CONST_DOUBLE_OK_FOR_LETTER_P \ && !defined CONST_DOUBLE_OK_FOR_CONSTRAINT_P \ && !defined EXTRA_CONSTRAINT \ && !defined EXTRA_CONSTRAINT_STR \ && !defined EXTRA_MEMORY_CONSTRAINT \ && !defined EXTRA_ADDRESS_CONSTRAINT #define USE_MD_CONSTRAINTS Make sure that your CPU.h file does not define any of those macros. Ian
Code optimization with GCSE
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;
}
return data[0] + data[1] + data[2];
}
However, the code I get is:
la r9,data
mov r8, r9
#LOOP, of no consequence, it uses r8 for the stores...
la r7,data+8#Loads data+8 in r7 instead of using r9 directly
ldd r9,0(r9) #This loads from r9 and the two next from r7
ldd r6,0(r7)
ldd r8,8(r7)
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.
Any ideas where I can look for this, or is this going to be difficult to fix?
Thanks !
Jean Christophe Beyler
Re: bitfields: types vs modes?
> >> 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 that the AAPCS functionality is suitable for their ports as well. What's the next step?
Re: Adding constraints.md to my port
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, 2009 at 3:53 PM, Ian Lance Taylor wrote: > 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/toto/gcc-4.3.2/gcc/defaults.h:797:1: warning: this is the >> location of the previous definition > > See defaults.h: > > #if !defined CONSTRAINT_LEN \ > && !defined REG_CLASS_FROM_LETTER \ > && !defined REG_CLASS_FROM_CONSTRAINT \ > && !defined CONST_OK_FOR_LETTER_P \ > && !defined CONST_OK_FOR_CONSTRAINT_P \ > && !defined CONST_DOUBLE_OK_FOR_LETTER_P \ > && !defined CONST_DOUBLE_OK_FOR_CONSTRAINT_P \ > && !defined EXTRA_CONSTRAINT \ > && !defined EXTRA_CONSTRAINT_STR \ > && !defined EXTRA_MEMORY_CONSTRAINT \ > && !defined EXTRA_ADDRESS_CONSTRAINT > > #define USE_MD_CONSTRAINTS > > > Make sure that your CPU.h file does not define any of those macros. > > Ian >
Re: How could I get alias set information from data_reference_p
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 A is in alias set 6, this would be >> represented as "memory_access[6][10]". >> >> For B[3][4] with base array B in alias set 7 and 8, we would represent >> this as "memory_access[7][3][4] or memory_access[8][3][4]". >> >> The data dependence test that we currently have in the graphite branch >> would work with alias sets represented by an extra dimension to the >> array dimensions. > > And by the way, right now we consider that all the data refs alias each > other, that means that we set the alias dimension of the memory > accesses to 1 for every data reference. This makes the test very > conservative: in the example above, with the current implementation, > we would have: > > A: memory_access[1][10] > B: memory_access[1][3][4] Well, so you really want to have sort-of the base objects partitioned into must(!)-conflict sets? Thus, (*p)[1][2] (*q)[1][3] is only correct if the resulting accesses may not alias? (that is, p == q?) No, we don't have such information readily available. You have to compute it. Likely by building a complete conflict map of the bases of all memory references and partitioning it. Which doesn't sound like a great idea - it's quadratic. Thus, can't you represent this in a more sparse way? Richard. > Sebastian >
gcc-4.4-20090714 is now available
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/gcc-4_4-branch revision 149648 You'll find: gcc-4.4-20090714.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090714.tar.bz2 C front end and core compiler gcc-ada-4.4-20090714.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090714.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090714.tar.bz2 C++ front end and runtime gcc-java-4.4-20090714.tar.bz2 Java front end and runtime gcc-objc-4.4-20090714.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090714.tar.bz2The GCC testsuite Diffs from 4.4-20090707 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: bitfields: types vs modes?
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 the next step? At the risk of being naive: implement it. I'm not quite sure what you're looking for here? I'd assume that we should try to do some of this at the tree->rtl conversion point, in a platform-independent manner, but I'm not an expert on those bits. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: bitfields: types vs modes?
> 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 target now.
Re: Code optimization with GCSE
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
Re: Adding constraints.md to my port
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 constraints then. That's good, it's usually much more readable. However, as you found out, it's an "all or nothing" decision for each port. Paolo
Re: updating autotools status
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 only open issues standing in the way of the conversion of the GCC source repository. What's the eta for the 2.64 autoconf release? How is this to be timed with the end of GCC Stage 1? If autoconf 2.64 is not out by the end of July, does it make sense to use autoconf 2.63 instead? Once we switch to 2.60 or later, we can always require the latest and greatest just like we did between 2.54 and 2.59. Paolo
Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
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 -fschedule-insns
I get an internal compiler error:
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version
2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version
2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c91a929a0209c0670a3ae8b8067b9f9a
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:
In function 'foo':
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
error: insn does not satisfy its constraints:
(insn 171 170 172 4
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:17
(set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35
{*addsi3_compact} (nil))
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
This looks much like PR37053 on m68k/ColdFire; the easiest way to check
if this ICE was caused by the same error is to revert hunk in rtlanal.c:
commutative_operand_precedence() -- see in the PR.
As to the fix, there are several patches being discussed here
(http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00816.html) and here
(http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00823.html).
My $0.02.
--
Maxim
