Hi gcc Team,
I would estabilish a gcc mirror on my website potius.org, in the path
http://www.gcc.potius.org, located in Texas (US).
Is it possible to mirror ggc via rsync? If so, please, let me know the
command line to make it.
Best regards,
Andrea
Hi,
I tried to calculate the relations:
a=b**1.5
and
a=sqrt(b)**3
they are the same in the mathematical point of view but the second
version works 7 times faster. I tried it with various optimization
levels without big difference.
I think that it is easy to optimize no the code level.
I'm
On 4/4/07, jbijak <[EMAIL PROTECTED]> wrote:
Hi,
I tried to calculate the relations:
a=b**1.5
and
a=sqrt(b)**3
This is already optimized with mainline.
Richard.
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple. For example, there are about 1000 of
lines of quite
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
On Apr 2, 2007, at 2:32 AM, Brendon Costa wrote:
I have for a while been working on a tool that performs static
analysis
I agree that Brendon's project is a very good idea, but I still
have an argument against it: having such an analysis into gcc forces
the gcc development community to maintai
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I rea
Hello,
I've noticed some strange behavior regarding C++ SFINAE that I believe
may not be ISO-14882 compliant. I've tried to get a minimal example to
reproduce the compilation errors I'm getting, but some explanation is
needed.
I'm working on a boolean metafunction to detect nested member
templat
Hello,
> >> This looks like a very complicated (though very generic) way of
> >> specifying a memory
> >> reference. Last time we discussed this I proposed to just have BASE,
> >OFFSET
> >> and accessed TYPE (and an alias tag of the memory reference). I realize
> >> this
> >> doesn't cover acce
On 4/4/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> at the moment, any pass that needs to process memory references are
> complicated (or restricted to handling just a limited set of cases) by
> the need to interpret the quite compl
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple
Hello,
> >Proposal:
> >
> >For each memory reference, we remember the following information:
> >
> >-- base of the reference
> >-- constant offset
> >-- vector of indices
> >-- type of the accessed location
> >-- original tree of the memory reference (or another summary of the
> > structure o
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >Proposal:
> >
> >For each memory reference, we remember the following information:
> >
> >-- base of the reference
> >-- constant offset
> >-- vector of indices
> >-- type of the accessed location
> >-- original tree of the memory ref
Hello,
> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also keeping it in the references.
> >
> >The lower bound and
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also kee
On 4/4/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> at the moment, any pass that needs to process memory references are
> complicated (or restricted to handling just a limited set of cases) by
> the need to interpret the quite compl
On Wed, Apr 04, 2007 at 04:35:08PM +0200, Zdenek Dvorak wrote:
> For each memory reference, we remember the following information:
>
> -- base of the reference
> -- constant offset
> -- vector of indices
> -- type of the accessed location
> -- original tree of the memory reference (or another summ
It's poorly implemented, unrefactored, without formal specification,
without OO hierarchy, etc.
"The pointers are the evilness of the optimization".
> What do you do with Ada COMPONENT_REFs, at a variable offset?
You can certainly get COMPONENT_REFs with variable offsets in GNU C,
but I'm familiar enough with the VLA stuff in the standard to know if
it can occur in standard C.
Hello,
> > -- base of the reference
> > -- constant offset
> > -- vector of indices
> > -- type of the accessed location
> > -- original tree of the memory reference (or another summary of the
> > structure of the access, for aliasing purposes)
> > -- flags
>
> What do you do with Ada COMPO
On Wed, Apr 04, 2007 at 09:27:12PM +0200, Zdenek Dvorak wrote:
> 3) making this offset into an index, i.e, having
>base: &a, indices: (step:1, value: n)
>
> Out of these, I like 3) the most, although it might be fairly expensive
> memory-wise (any idea how common the variable offsets are?)
Hm
Hello,
> >at the moment, any pass that needs to process memory references are
> >complicated (or restricted to handling just a limited set of cases) by
> >the need to interpret the quite complex representation of memory
> >references that we have in gimple. For example, there are about 1000 of
>
Hello,
> >> >> That is, unless we could share most of the index struct (upper,
> >> >> lower, step) among expressions that access them (IE make index be
> >> >> immutable, and require unsharing and resharing if you want to modify
> >> >> the expression).
> >> >
> >> >That appears a bit dangerous
Zdenek Dvorak wrote:
Sorry, but you are completely out here. I have spent a lot of time
working with the code for dealing with memory references, trying many
different approaches.
[ to put a different spin on it ]
It just might be that most of Roger Sayle's Fortran front end
optimizations -
I don't have a lot of experience with GCC development. I know enough to
have done what i needed to do.
As for a place to start i would read the GCC internals documentation as
a first step. There is also a lot of info on the Wiki too. However a lot
of documentation is specific to either creating a
Hi all,
I'm using g++ 4.1.1 under Fedora Core 5 on an Intel system. I'm
compiling
the following code with "g++ -Wextra tst.cpp".
enum my_enum { FOO = 10, BAR, BAZ };
int
main()
{
my_enum e = BAR;
while (e == 15);
for (;e == 15;);
Matt Thomas <[EMAIL PROTECTED]> writes:
> Over the past several weeks, I've revamped the VAX backend:
>
> - fixed various bugs
> - improved 64bit move, add, subtract code.
> - added patterns for ffs, bswap16, bswap32, sync_lock_test_and_set,
> and
> sync_lock_release
> - modified it t
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> Proposal:
>
> For each memory reference, we remember the following information:
>
> -- base of the reference
> -- constant offset
> -- vector of indices
> -- type of the accessed location
> -- original tree of the memory reference (or another summary o
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple
32 matches
Mail list logo
