On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
> It appears that memory references to arrays aren't being hoisted out
> of loops: in this test case, gcc 3.4 doesn't touch memory at all in
> the loop, but 4.3pre (and 4.2, etc) d
me config-ml.in to enable multilibs that libiberty
does. You're going to have to figure out why that's decided that we
shouldn't build multilibs. It starts by checking xgcc
-print-multi-lib; that works, right? Could it have picked up
a bad setting for $CC?
--
Daniel Jacobowitz
CodeSourcery
It is possible that somebody else will disagree with me.
FWIW, our currently aliasing set implementation agrees with you on
both counts :)
And honestly, I have no idea how that happened. Does it happen
with a current GDB? I suspect from the error message that this
one is not too recent.
--
Daniel Jacobowitz
CodeSourcery
6.5, so reasonably recent.
Please try a current snapshot. Thanks.
--
Daniel Jacobowitz
CodeSourcery
On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Menezes, Evandro wrote:
> Though not as pronounced, definitely significant.
>
Using binary search I've detected that 30% performance regression of
cpu2006/437.leslie3d benchmark is caused by revision 117891.
http://gcc.gnu.org/viewcvs?vi
On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote:
> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
> >Menezes, Evandro wrote:
> >> Though not as pronounced, definitely significant.
> &
> You must be new around here:
>
> http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
>
> :-) Which is the I feel lucky google("site:gcc.gnu.org how to run
> installed GCC_UNDER_TEST") result.
For the less old-school inclined, try contrib/test_installed.
--
Daniel Jacobowitz
CodeSourcery
ivdi3. It there a way
> of making use of this facility in a more elegant way than putting the whole
> gcc command line in a target makefile fragment?
I'm not sure I understand what you want to do. Could you give me a
bigger example? Those bits are only used for fix/float conversions.
-
xt),$(siintfuncs))
ifeq ($(enable_shared),yes)
libgcc-s-objects += $(patsubst %,%_s$(objext),$(siintfuncs))
endif
If you think it would be useful for enough targets, you could add some
code to automatically extract the bits before and after the colon and
give this a standard name that tdep files could s
> This is a typical example of removing an if branch because signed
> overflow is undefined. This kind of code is common enough.
I could not have made my point any better myself.
And you think that somehow defining it (which the definition people
seem to favor would be to make it wrapping) am
> Every leading C compiler has for years done things like this to boost
> performance on scientific codes.
The Sun cc is a counter-example. And even then, authors of scientific
code usually do read the compiler manual, and will discover any
additional optimizer flags.
Errr, actually, Seongbae
I've put up some information on the wiki about moving configuration
information from gcc to libgcc. Please, feel free to add to it!
http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration
--
Daniel Jacobowitz
CodeSourcery
On 1/29/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Hi!
GCC 4.3 compiler revision 121206 gets ICE while compiling
cpu2006/447.dealII source file data_out_base.cc at -O2 optimization
level on x86_64-redhat-linux.
Similar to previously reported cpu2k6/perlbench failure, this regression
is ca
by "Rewrite of portions of points-to solver"
patch http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01541.html
revision 120931 http://gcc.gnu.org/viewcvs?view=rev&revision=120931
Patch attached and committed after bootstrap and regtest on i686-darwin.
2007-01-29 Daniel Berlin <[E
On 1/29/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/29/07 06:35:
> On 1/29/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> -fdump-tree-all gives you all the dumps by the high-level optimizers.
>> -fdump-all-all gives you all the dumps by both GIMPLE and RTL optimizers.
On 1/29/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
> Joe Buck writes:
Joe> There you go again. Mark did not support or oppose rth's change, he just
Joe> said that rth probably thought he had a good reason. He was merely
Joe> opposing your personal attack. We're all human, we make mista
On 1/29/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote:
Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33:
> Hi,
>
> Does gcc apply inter-procedural optimizations across functions called
using
> a function pointer? I guess that gcc performs conservatively assuming
that
> the pointer could poin
Clear your cookie, try again, and it should fix it.
(Sorry, i'm working on the cookie issues. There is something very odd going on)
On 2/5/07, Matthias Klose <[EMAIL PROTECTED]> wrote:
Got this page, trying to add an attachment to #30706.
Matthias
This is GCC Bugzilla
This is GCC Bugzilla
ew in 4.1.2, and
therefore I don't consider them showstoppers.
The following issues seem to be the 4.1.1 regressions:
http://gcc.gnu.org/wiki/GCC_4.1.2_Status
PR 28743 is only an ICE-on-invalid, so I'm not terribly concerned.
Daniel, 30088 is another aliasing problem. IIIRC, you
reading this know what the right thing to do is? Is there
anything in the autoconf documentation about not using some macros
inside conditional statements?
--
Daniel Jacobowitz
CodeSourcery
e are in a Canadian setting, we can set
> all the variables that Autoconf sets, in the `then' branch. So we'd set
> ac_objext=.o in the `then' branch.
This seems horribly wrong somehow. Aren't we intested in the ${build}
-> ${host} compiler at this point anyway? So shouldn't we be testing
it? I think the whole block can go.
--
Daniel Jacobowitz
CodeSourcery
t; Hmm, it says indeed "this is going to change when we autoconfiscate".
> Something like this?
Yes, pretty much (though I don't see the point in the CFLAGS -g
assignment either).
--
Daniel Jacobowitz
CodeSourcery
On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote:
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement "Skip virtual
phi's. The data dependences that are associat
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don'
On 2/15/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> Hi,
>
> while playing with gcc-4.3 rev. 121994, i encountered a problem with
> autovectorisation.
>
> In the following simple code, the inner loop of c1() becomes vectorized
as
> expected, but the inner loop of c2() not because of
>
>test2
On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote:
> Hello, Daniel
>
> It looks like your changeset listed bellow makes performance
> regression ~40% on SPEC2006/leslie3d. I will try to create minimal
> test for
On 2/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 2/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote:
> > > Hello, Daniel
> > &
e something in
/usr/local/bin/x86_64-pc-mingw32-gcc.exe also; do you?
The one in /usr/local/x86_64-pc-mingw32/bin is different, and may not
work - I think the way that normally happens involves symbolic links,
or something similar. Anyway, you don't need to use it.
--
Daniel Jacobowitz
CodeSourcery
On 2/19/07, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I've got a question for experts of alias analysis in GCC.
In the CLI back-end of GCC, there is a CLI-specific pass responsible of
some modifications on GIMPLE that simplify the emission of CIL bytecode
(see http://gcc.gnu.org/projects/c
On 2/19/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the vi
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> > > > It looks like your changeset listed bellow makes performance
>> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
>> > > > test
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> 2. What is the effort required to backport the necessary infrastructure
>> from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two
>> weeks" or &
e my statement. And if that holds, I continue to stand by it.
On the other hand, I consider this a fairly serious bug in 4.1 (and
I've seen customers encounter it at least twice off the top of my
head). It depends what your tolerance for wrong-code bugs is.
--
Daniel Jacobowitz
CodeSourcery
On 2/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
On Wed, Feb 21, 2007 at 11:33:39AM -0500, Kaveh R. GHAZI wrote:
> My tolerance is pretty low. I'm relying on the fact that the bug occurs
> rarely in real code. I'm trying to reconcile your statement about
> customer feedback with Daniel B's claim here:
> http:/
aybe don't ship 4.2.0 at all.
>
> so, I don't see backporting more patches or even re-branching as
> a real option.
I've been convinced of the same. If we (GCC developers) shipped it
with the aliasing fixes reverted, I'm not sure quite what we
(CodeSourcery) would do
On 2/20/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
We saw that the reassociation pass does not operate on built-in functions,
for example:
vp3 = vec_madd (vp1, vp2, vp3);
In the RTL level the function is expanded to regular insn:
(insn 87 91 88 9 (set (reg/v:V4SF 217 [ vp3 ])
On 2/24/07, Serge Belyshev <[EMAIL PROTECTED]> wrote:
I have compared 4.1.2 release (r121943) with three revisions of 4.2 on spec2k
on an 2GHz AMD Athlon64 box (in 64bit mode), detailed results are below.
In short, current 4.2 performs just as good as 4.1 on this target
with the exception of hug
On 2/25/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 2/24/07, Serge Belyshev <[EMAIL PROTECTED]> wrote:
> I have compared 4.1.2 release (r121943) with three revisions of 4.2 on spec2k
> on an 2GHz AMD Athlon64 box (in 64bit mode), detailed results are below.
>
> In sho
On 01 Mar 2007 18:05:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
> > If someone wants a patch committed they will ping it
> > a couple of times and if they lost interest becaus
the lines of the bugmasters.
Good luck keeping people. It's a crappy job.
--
Daniel Jacobowitz
CodeSourcery
ix $SYSROOT to it.
Did you try it? This should already happen if you configured binutils
with a sysroot.
--
Daniel Jacobowitz
CodeSourcery
On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
> I have used "strace -f" to check where linker looked for -lqt-mt. From
> what I have observed, it seems that ld didn't use
> $SYSROOT/etc/ld.so.conf.
Well, it's supposed to, so I suggest you check what&
On 3/5/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
Diego Novillo wrote:
> Maxim Kuvyrkov wrote on 03/05/07 02:14:
>
>>o Fix passes that invalidate tree-ssa alias export.
>
> Yes, this should be good and shouldn't need a lot of work.
>
>>o { Fast but unsafe Gupta's aliasing patch, Unsafe
On 3/6/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/5/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
> > Maxim Kuvyrkov wrote on 03/05/07 02:14:
> >
> >>o Fix passes that invalidate tree-ssa alias export.
> >
> > Yes,
On 3/5/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote:
> One of the bugzilla quips (the headlines appearing at random for each
> bug list) is actually the head of gcc/reload.c (full text below).
That is really obnoxious and should be removed.
orks just fine
> natively and with cross compilations. I'd file a bug report. If it
> is an OS bug, it can be fixed by fixincludes.
He's talking about finding the target's int_fast8_t in the frontend.
That's another issue entirely.
--
Daniel Jacobowitz
CodeSourcery
On 3/12/07, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and su
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
have resolved before the release, together with names of people I'd like
to volunteer to help. (Naturally, I have no command authority, and I'd
encourage anyone else who wan
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Can I recommend something just crazy, rewrite the C and C++ front-ends
> > so they don't use the tree structure at all except when
On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
> When I said, let's support Doug, I meant let's support Doug from a
> *practical* point of view. Either we suggest something doable with
> a realistically sized effort or a little larger and at th
#x27;t know where your acres and acres are,
but they aren't in most GNU software. This is, unsurprisingly, how
emacs behaves.
Personally I think that regardless of your indentation preferences,
using anything besides eight column tab stops for \t is silly; that's
what "cat" is going to use.
--
Daniel Jacobowitz
CodeSourcery
t; being possibly undefined). I think I want the -I options though.
Yes, you always want to match ACLOCAL_AMFLAGS from Makefile.am.
--
Daniel Jacobowitz
CodeSourcery
time your patch was first written, we decided to
fix this in the driver instead and leave make_relative_prefix
unchanged:
2006-04-28 Joseph S. Myers <[EMAIL PROTECTED]>
* gcc.c (process_command): Add program name to GCC_EXEC_PREFIX
value before passing to make_relative_prefix.
--
Daniel Jacobowitz
CodeSourcery
Uh, since when did 4.1 support IPA GIMPLE?
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just ha
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Uh, since when did 4.1 support IPA GIMPLE?
>
>
What do you mean by that?
I'm pretty sure there were a number of cgraph and other related
changes necessary t
On Mon, Mar 19, 2007 at 05:25:37AM -0700, Karthikeyan M wrote:
> Thanks for the information.
> So, if I want to debug a bug in the cc1 code that causes target
> library build to fail -
> should I just use the cc1 that is generated in /gcc/ ?
Yes.
--
Daniel Jacobowitz
CodeSourcery
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> Perhaps this ought to be looked at again with some seriousness.
I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than that of other compilers I've used.
--
Dani
se
'make install' into a system location, but that's about it. And
usually one shouldn't do that anyway.
There's /lib64 -> lib and /usr/lib64 -> lib symlinks, which help out.
--
Daniel Jacobowitz
CodeSourcery
On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 19 March 2007 22:16, Karthikeyan M wrote:
> What should I do if I want a list of all file-scope variables inside
> my own pass ?
>
> The file_scope variable is local to c-decl.c . Is there a reason why
> the scope holding variables are local to
d static in C")
Will the cgraph nodes also have global declarations that are never
used inside any
function .
If you ask for all of them, it will give you all of them
If you ask for only the needed ones, it will give you all of the
needed ones (see FOR_EACH_STATIC_VARIABLE)
On 3/20/0
trunk (or a branch of the development
trunk).
If for no other reason than we only fix regressions on release branches.
Thanks a lot.
On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
> > Thanks.
> >
rictly necessary if you've got nothing but a type
code in it. Have a couple of constant TYPE_LANG_SPECIFIC instances
in rodata :-)
Which is less useful if you want to move things out of the common
tree, of course.
--
Daniel Jacobowitz
CodeSourcery
On 3/21/07, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
On Wed, 21 Mar 2007, Paul Brook wrote:
> The problem is that I don't think writing a detailed "mission statement" is
> actually going to help anything. It's either going to be gcc contributors
> writing down what they're doing anyway, or
On 3/22/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote:
> > The tree_opt_pass for my pass has PROP_ssa set in the
> properties_required
> > field. Is this all I need to do?
>
> You need to put your pass after pass_build_ssa. Setting PROP_ssa does
> not build SSA itself, but it will cause an a
But at least the patch shows the
> problem and a possible solution, so maybe you (or someone who
> understsands the build scripts) can fully test it.
libgcc should not use AC_CANONICAL_TARGET; --target doesn't mean
anything to a target library. I'm not sure about libdecnumber - it
On 3/23/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
Hello,
I would be pleased to see Ayal Zaks as my mentor, because proposed
improvement is primarily targeted as modulo scheduling improvement. In
case this is not possible, I will seek guidance from Maxim Kuvyrkov.
Ayal has not signed up
On 3/23/07, Marc Espie <[EMAIL PROTECTED]> wrote:
In article <[EMAIL PROTECTED]> you write:
>On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> similar justifications for yet another small% of slowdown have been
>> given routinely for over 5 years now. small% build up;
ode above like this:
> gcc test.c -o test.so -shared -fPIC [-s]
> The problem is that i'd expect gcc/ld to abort with an error,
> but it just 'successfully' links something.
> Am i missing something? How can ld link against a
> definitely unknown function?
See
On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote:
> - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
> + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)'
Don't you need more quotes than that?
--
Daniel Jacobowitz
CodeSourcery
lude)'
> >
> > Don't you need more quotes than that?
>
> I think if we quoted it more, we'd end up passing the backticks along
> instead of processing them, and we'd end up right where we started.
I only meant:
CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")'
--
Daniel Jacobowitz
CodeSourcery
s quoting?
$(gcc_tooldir) starts with $(libsubdir) starts with $(libdir) which
will come from $(prefix), so there's an unquoted $(prefix) there.
../gcc/configure --prefix=/usr/local/"where * am * i" will thus lead
to $(shell echo /usr/local/where * am * i/sys-include), which will
wildcard.
--
Daniel Jacobowitz
CodeSourcery
On 3/27/07, Antoine Eiche <[EMAIL PROTECTED]> wrote:
Dear all,
I want to insert functions calls during a new pass.
Which version of GCC?
The problem is to
create parameters. At this time, I successfully create a function call
with two constante as parameter and insert it (I can see that in t
xpressions
> >have no location anyhow.
> And I know from past experiences, that this is really a bug that they
> don't produce expressions with locations. I remember Daniel Berlin
> was talking about how SRA does the correct thing with respect of
> locations and other passe
se where the current approach would even
require locations on constants. And that's obviously infeasible, so...
--
Daniel Jacobowitz
CodeSourcery
On 3/29/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote:
> On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >Why will expressions have location? It seems to me preferable to save
&g
On 3/30/07, Antoine Eiche <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> On 3/27/07, Antoine Eiche <[EMAIL PROTECTED]> wrote:
>> Dear all,
>>
>> I want to insert functions calls during a new pass.
>
> Which version of GCC?
> The problem i
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Aldy Hernandez <[EMAIL PROTECTED]> writes:
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR,
On 3/30/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
> variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different thi
On 3/30/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> The lang hook is supposed to mark the variable as addressable.
> The lang hook should not be changing other things that have an affect
> on the *middle end*. No exceptions.
But how is it "supposed to mark the variable as addressable"? If
he result of non standard
compliant bugs in gcc? If not, what's the explanation? If so, let me
know if you'd like me to fill out a bug report.
Thanks!
Daniel Walker
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
tation, described in more details below. The
proposal is based on the previous discussions
(http://gcc.gnu.org/ml/gcc/2006-06/msg00295.html) and on what I learned
about the way memory references are represented in ICC.
It also subsumes the patches of Daniel to make p[i] (where p is pointer)
use ARRA
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
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 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
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
On 4/5/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
Hi,
My goal is to get more involved in Binutils, GCC, and possibly GDB, for the
AVR port, to help where I can. My FSF paperwork is in process on my
company's side but it may take a while. In the meantime I would like to
request Bugzilla-only
uld not make a significant difference.
--
Daniel Jacobowitz
CodeSourcery
last month I discovered that
there is a use of operator new[] with a subscript of INT_MAX - 1
(INT_MAX is handled specially). In general this still works out
to be more memory than can be allocated and the test tests what it
wanted to (bad_alloc).
--
Daniel Jacobowitz
CodeSourcery
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementati
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote on 04/10/07 13:53:
> I seem to recall that at one point somebody worked on a gensimplify
> program or something like that. Would it make sense to revive that
> approach, and use it to generate simplifiers for trees, GIM
read in, we
> might even see some cache friendly accesses for a change.
FYI, I did this with PCH once... I never followed it through well
enough to get consistent results from it, but I did get some
remarkable jumps during testing.
--
Daniel Jacobowitz
CodeSourcery
o install the library if you do that?
SHLIB_INSTALL = \
$(mkinstalldirs) $(DESTDIR)$(slibdir); \
$(INSTALL_DATA) $(SHLIB_SONAME) \
$(DESTDIR)$(slibdir)/$(SHLIB_SONAME)
--
Daniel Jacobowitz
CodeSourcery
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]> wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
The FSF libstdc++ is, I believe,
binary incompatible wit
which you didn't show the type of - but there's probably nothing in
the C builtin decl that says it modifies its arguments. If the RTL
says that it clobbers its first input, then the RTL register allocator
is responsible for handling that.
--
Daniel Jacobowitz
CodeSourcery
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easi
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues i
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuse
101 - 200 of 2005 matches
Mail list logo
