On Wed, Nov 08, 2006 at 02:33:08PM +0100, Bruno Haible wrote:
> * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> TLS via __thread.
Ok.
r~
On Sun, Jan 28, 2007 at 12:43:36AM +0100, Richard Guenther wrote:
> >Can you explain what went through your mind when you picked the
> >tree_exp.complexity field for something implemented new... :-(
>
> Not much...
>
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html
>
> "... but my brai
On Tue, Jan 30, 2007 at 08:36:47AM +0100, Paolo Bonzini wrote:
> * cp/cp-tree.h (OMP_ATOMIC_CODE): Delete.
> (OMP_ATOMIC_DEPENDENT_P): Rewrite.
> * cp/pt.c (tsubst_expr): Adjust for new format of dependent OMP_ATOMIC
> expressions.
> * cp/semantics.c (finish_omp_atomic
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
> Does it seem overly aggressive to you to assume "f" cannot throw
> in "g", given:
>
> void f() {}
> void g() { f(); }
>
> where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > But, aren't big C++ shared libraries rather different? Does KDE
> > actually use throw() everywhere, or visibility attributes? But,
> > presumably, most people don't replace the im
On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote:
> ;; calls that return int in r1
> ;;
> (define_insn "call_val_internal_return_r1"
> [(parallel [(set (reg:SI 1)
> (call (match_operand:QI 0 "sym_ref_mem_operand" "")
Why would you have a specific pattern for (reg:SI
On Thu, Feb 22, 2007 at 05:03:21PM -0800, Ian Lance Taylor wrote:
> > > It is to improve performance of string functions on larger chunks of
> > > data. x86-64 specify this, for x86 it is optional. I don't think we
> > > should end up warning here - it is done only for static variables where
> >
On Fri, Feb 23, 2007 at 07:00:01AM -0800, Ian Lance Taylor wrote:
> gcc currently does a relatively crummy job of handling this type of
> VLIW architecture. You can describe the dependencies in the
> scheduler, but the scheduler won't insert any required nops for you.
> The usual approach is walk
On Fri, Feb 23, 2007 at 01:42:42PM -0500, DJ Delorie wrote:
> I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
So do I.
> Note that elfos.h defines MAX_OFILE_ALIGNMENT so big that it is
> effectively unlimited, so no elf target would ever trip over these
> types of bugs.
Yep.
r~
On Fri, Feb 23, 2007 at 06:19:28PM -0500, DJ Delorie wrote:
> Something like this, then?
Sure.
r~
On Fri, Feb 23, 2007 at 04:13:39PM -0800, sdutta wrote:
> I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
> instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
> additions, subtractions, multiplications & shift operations simultaneously.
>
> I would l
On Mon, Feb 26, 2007 at 09:40:59AM +0100, Kai Tietz wrote:
> So is there allready a mechanism in gcc, by whom I can reserve for all
> methods simple space on stack for the 4 used register parameters, even if
> they are not used for argument passing ?
See sparc.h.
r~
On Mon, Feb 26, 2007 at 02:04:36PM -0800, Steve Ellcey wrote:
> I am looking at PR target/30826 (an IA64 ABI bug) and have come up with
> a patch that basically involves turning off the
> CALL_EXPR_RETURN_SLOT_OPT optimization in some instances and forcing GCC
> to create a temporary for the (large
On Fri, Mar 02, 2007 at 02:12:30PM +, Richard Sandiford wrote:
> CodeSourcery is gearing up to submit support for the VxWorks RTP PIC
> model. Six targets are affected: arm, i386, mips, rs6000, sh and sparc.
> All this code is conditional on TARGET_VXWORKS_RTP being true and refers
> to two ot
On Mon, Mar 05, 2007 at 02:29:05PM +0100, Roman Zippel wrote:
> challenges, as m68k is still a cc0 target and with instructions like
> addx.l above, so far I avoided splitting these at all.
It would be possible to add an X register to model that one
bit from the flags, since X is generally preser
On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
> In gcc the file emutls.c assumes that a long has sizeof void * in function
> emutls_destroy.
Not really. It assumes you can store the size of the array
in min(sizeof(long), sizeof(void*)) bytes.
r~
On Mon, Mar 12, 2007 at 08:32:43AM -0400, Jack Howarth wrote:
> - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
> + else if (decl_readonly_section (exp, reloc))
Not just that. Try this.
* config/darwin.c (machopic_reloc_rw_mask): New.
(machopic_select_sect
On Wed, Mar 21, 2007 at 01:11:36PM +0100, Kai Tietz wrote:
> #include
> void *(my_malloc_hook)(size_t) = malloc;
>
> GCC tells me, that malloc isn't a constant symbol. Clear malloc is defined
> by using the attribute dllimport, because it comes out of the MSVCRT and
> has the name "__imp__mallo
On Wed, Mar 21, 2007 at 04:16:20PM -, Dave Korn wrote:
> Presumably there would be no problem in just waiting until runtime to
> initialise the my_malloc_hook variable dynamically instead of trying to
> statically initialise it?
Dunno. One could also wait to expand *__imp_foo, for functions
On Thu, Mar 22, 2007 at 03:58:43PM -0700, Mike Stump wrote:
> Also, the correctness of: ...
> is more obvious than the correctness of the subcoding. Thoughts?
Totally agreed.
r~
On Thu, Mar 29, 2007 at 04:16:35PM -0400, Aldy Hernandez wrote:
> * By extension, we will also need:
>
> typedef struct gimple_expression_d { ... } * gimple_expr;
>
> For example, PLUS_EXPR, etc. These will have location, btw.
> Something like:
>
> gimple
On Fri, Mar 30, 2007 at 01:59:12PM +0100, Thomas Gill wrote:
>
> Hi there,
>
> I maintain a GCC port for a small 16 bit processor called XAP2+. I'm
> having problems with strings of wide characters.
>
> I have the following defines, among others:
>
> #define BITS_PER_UNIT 16
> ...
> #
On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote:
> Am i just wrong believing that ought to work?
Yes.
r~
On Tue, Apr 03, 2007 at 01:54:16AM +0200, tbp wrote:
> >> Am i just wrong believing that ought to work?
> >
> >Yes.
> It's hard to argue with a terse compiler or maintainer. Perhaps i
> should have picked an easier target like
> http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html: "GCC will
> al
On Mon, Apr 02, 2007 at 10:54:12PM -0400, Alexander Kabaev wrote:
> This creates a dependency cycle that I need to break. The simplest way
> to go appears to follow Linux's lead and eliminate the need for shared
> modules to have explicit frame into registration calls at startup and
> allow excepti
On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote:
> ... Note that a change of default precision control may
> affect the results returned by some of the mathematical functions.
>
> to the documentation to warn users about this fact.
Eh. It can seriously break some libm implementation
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
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
On Mon, Apr 09, 2007 at 07:37:31PM +0100, Dave Korn wrote:
> Should promotion of function arguments be explicitly represented in GIMPLE,
> or should it be performed when generating the corresponding RTL?
There are two things here:
(1) Promotion of arguments to their devlared types, should
On Mon, Apr 09, 2007 at 11:55:14PM +0100, Dave Korn wrote:
> Thanks, I think you're right on there. The comments on PR31136 make it
> fairly clear what's wrong; perhaps the best solution might be for
> STRIP_SIGN_NOPS to mask out the high bits when it's discarding a size-reducing
> NOP_EXPR? Or
On Tue, Apr 10, 2007 at 10:53:19AM -0700, Ian Lance Taylor wrote:
> As you know, we have a lot of basic optimizations in fold-const.c that
> operatee on trees. We also have a lot of basic optimizations in
> simplify-rtx.c that operate on RTL. These sets of optimizations are
> independent implemen
On Tue, Apr 10, 2007 at 11:13:44AM -0700, Ian Lance Taylor wrote:
> The obvious way to make the proposed tuples position independent would
> be to use array offsets rather than pointers.
I suggest instead, if we want something like this, that we make
the references be pc-relative. So something li
On Tue, Apr 10, 2007 at 05:49:03PM -0700, Ian Lance Taylor wrote:
> But fold_binary takes trees as parameters. How are you thinking of
> calling it?
The operands of gimple statements are still trees.
Very simple trees, mind, but trees.
r~
On Tue, Apr 10, 2007 at 08:48:27PM -0400, Diego Novillo wrote:
> Sure, but things will be different if/when the operands stop being 'tree'.
We'll burn that bridge when we come to it.
It's possible to parameterize the fold-const even further.
One passes in void* instead of tree, and have a set of
On Tue, Apr 10, 2007 at 06:53:07PM -0700, Mark Mitchell wrote:
> Self-relative, not PC-relative, right?
Yes. I tend to use the terms interchangably, since if you're generating
object files, the relocation is still named "pc-relative".
r~
On Thu, Apr 12, 2007 at 02:35:10PM -0700, H. J. Lu wrote:
> i386.c has many
>
> static const struct builtin_description bdesc_comi[] =
> {
> { MASK_SSE, CODE_FOR_sse_comi,
Yes, and you could move all of the ones specifically related to
the ISA to it's own variable.
r~
On Thu, Apr 12, 2007 at 03:09:55PM -0700, H. J. Lu wrote:
> BTW, I noticed that there are 2 bits
>
> NO_PUSH_ARGS
> SVR3_SHLIB
>
> defined in i386 backend. But they aren't checked at all. Can we remove
> them?
I don't see why SVR3_SHLIB can't be removed. Probably from
some port that got depreca
On Thu, Apr 12, 2007 at 05:31:36PM -0700, H. J. Lu wrote:
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00738.html
Ok.
r~
On Thu, Apr 19, 2007 at 03:30:03PM -0400, DJ Delorie wrote:
> Why don't we unconditionally emit this?
No idea.
r~
On Fri, Apr 20, 2007 at 01:07:14PM -0400, Aldy Hernandez wrote:
> + /* There can be 3 types of unary operations:
> +
> + SYM =<== GSS_ASSIGN_UNARY_REG
> + SYM = SYM2 <== GSS_ASSIGN_UNARY_MEM
Um, ssa_name = ssa_name isn't a memory
> +/* A seq
On Mon, Apr 23, 2007 at 04:30:40PM -0400, Aldy Hernandez wrote:
> I figured
> it'd be better than doing GS_SEQP_FIRST(&non_pointer), but I can if you
> prefer.
I think I would, though without the "P".
r~
On Wed, Apr 25, 2007 at 01:51:34PM +0200, Rask Ingemann Lambertsen wrote:
> (define_mode_macro GT16 [SI DI TI SF DF XF SC DC XC SD DD TD CHI CSI CDI
> CTI])
>
> (define_insn_and_split "*push1"
You almost certainly do not want to handle complex yourself,
and instead rely on the fallback code in ex
On Thu, Apr 26, 2007 at 09:49:16PM +0200, Rask Ingemann Lambertsen wrote:
>Unfortunately, the fallback code isn't exactly optimum, as it produces
> something like
>
> addw$-N*2, %sp
> movw%sp,%basereg
> movw%wordN, N*2(%basereg)
> ...
> movw%w
On Fri, Apr 27, 2007 at 04:00:13PM +0200, Rask Ingemann Lambertsen wrote:
>I don't see how emit_move_complex_push() can ever generate a push
> instruction. Here's a backtrace:
emit_move_insn (gen_rtx_MEM (submode, XEXP (x, 0)),
read_complex_part (y, imag_first));
return e
On Fri, Apr 27, 2007 at 04:23:35PM +0200, Erven ROHOU wrote:
> I think it should be BT_FN_INT_UINT. (Other functions like clz, parity,
> popcount are defined with unsigned int.)
> Unless I am missing something...
man 3 ffs.
r~
On Tue, Mar 01, 2005 at 11:50:04PM -0500, Peter Barada wrote:
>
> >> which seems to work, but I'm really concerned about the manuals
> >> warning of the input and output operads being in seperate places.
> >>
> >> Which form is correct?
> >
> >static __inline__ void atomic_inc(atomic_t *v)
> >{
>
On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> to specify a reference to the first operand is returned for values
> comparing equal.
NOT true. And the docs explicitly say so.
r~
On Mon, Mar 07, 2005 at 08:29:48PM -0700, Roger Sayle wrote:
> Which docs?! There's currently *no* documentation for MIN_EXPR
> or MAX_EXPR in c-tree.texi.
Ah, I misremembered the docs for the rtl patterns.
Signed minimum and maximum operations. When used with floating point,
if both operan
On Tue, Mar 08, 2005 at 10:15:09AM -0700, Jeffrey A Law wrote:
> FWIW, there is actually a system which varies its ABI based on whether
> or not an argument is named -- my old favorite, the 32bit PA SOM ABI
> behaves in this manner. In fact, I believe it is the only port which
> gives a hoot about
On Fri, Mar 11, 2005 at 02:48:35AM +0100, Hans-Peter Nilsson wrote:
> > Isn't a compiler option -fglobalize-symbol also a form of source-level
> > instrumentation? Either way, you need the source, and you get different
> > code emitted.
>
> This isn't a source-level modification, by definition.
On Sat, Mar 12, 2005 at 06:30:00PM +0200, Kai Henningsen wrote:
> Anyway, that seems to be very much the wrong tool to me. For stuff like
> thes, you'd really want a tool that understands C, so it can make a
> certain modification for certain syntactical places.
I don't see why. If the source
On Wed, Mar 16, 2005 at 05:43:32PM -0800, Mike Stump wrote:
> I have a question about libgcc export for shared libraries... libgcc
> exports (via libgcc-std.ver):
>
> __ffsdi2
>
> but not:
>
> __ffssi2
I suppose it would be ok, but it would only be relevent for
embedded targets where "int
On Sat, Mar 19, 2005 at 09:59:32PM +0100, Zdenek Dvorak wrote:
> > x = 22;
>
> what is the semantics of this expression? Should not this rather be
>
> x = 22
>
> (or just INTEGER_CST:some_type 22)?
The semantics are, exactly,
union {
some_type st;
int_type it
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
> The reload will generate addhi3 and reload will have a problem with
> two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
> surprise for reload. :( As I remember.
In order to expose the flags register before reload, you
On Sun, Mar 20, 2005 at 12:06:31PM -0500, Paul Schlie wrote:
> - so in AVR's case, simply pretending that add operations don't modify
> CC state may only be asking for trouble; however may it be sufficient to
> somehow force spill/reload to only use indexed/auto-inc/dec load/store
> operation
On Sun, Mar 20, 2005 at 12:41:39PM -0500, Paul Schlie wrote:
> - what about blk moves? (as they would seem to most likely destructively
> modify the machine's cc state in most implementations, as their
> implementation implies a conditional loop; or are they an exception?
> if so, why?)
Why
On Mon, Mar 21, 2005 at 01:12:40AM +0100, Marek Michalkiewicz wrote:
> On the other hand, branches within the same function should avoid the
> extra jump and go to "1:" directly. If the same label is used in both
> ways (direct jump/branch, and address taken), two separate labels (at
> the same ad
> They (load, store, add) can modify flags before reload.
> (while no reload_in_progress)
> Is this OK ?
Yes.
r~
On Mon, Mar 21, 2005 at 01:45:19PM +0100, Richard Guenther wrote:
> I also cannot
> see why we zero the mm registers before loading and why we
> load them high/low separated:
We load hi/lo separate because movlps+movhps is faster than movups.
We zero first to break the insn dependency chain befor
On Mon, Mar 21, 2005 at 02:28:49PM +0100, Richard Guenther wrote:
> I'd like to specify (for vectorization) the alignment of the
> target of a pointer.
This is not possible in gcc at present.
r~
On Thu, Mar 24, 2005 at 11:44:52AM -0500, Ian Lance Taylor wrote:
> OK, here is a different approach toward eliminating cc0, based on a
> combination of my earlier proposal and what Alex described. I'm
> looking for comments from anybody.
One potential problem: once the NOTICE_UPDATE_CC pass is d
On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote:
> 17855 ICE on C code that modifies call return values
>
> RTH and Joseph looked at this; no fix yet.
I'm not sure why this is marked as ice-on-valid; the construct in
question has undefined behaviour.
> 20342 ICE in reload w/ SSE/
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
> Undefined behavior on execution, not on translation.
It's still a stretch on the word "valid".
r~
On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
> My head hurts about the GGC implications of opaque pointers in such a
> hash table, and retaining pointers in the hash table that have already
> been otherwise freed.
These are solved problems.
Joe has the correct answer to the qu
On Fri, Apr 08, 2005 at 07:57:31PM -0400, Daniel Berlin wrote:
> Some of these global properties probably belong in cgraph_var node's
> instead of shoving them into the tree structure.
I tend to agree. This would allow us to do things like find out
that the variable is read-write while compiling
On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
> These issues can be fixed by not adding/subtracting 0.5, but Pred (0.5).
An interesting idea. Usually I see libraries switch to chopped
rounding instead, which also avoids the problem described.
r~
On Mon, Apr 11, 2005 at 05:41:56PM -0300, Alexandre Oliva wrote:
> I take that back. The hash tables seem to be fine. I suspect it's
> the sorting on pointers in the goto_queue that triggers the problem.
> In fact, I'm pretty sure comparing pointers that are not guaranteed to
> be in the same arr
Is anyone else seeing this? I see the same with either 3.3 or 3.4
as the build compiler.
gcc -c -g -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \
../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o
exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531
exp_ch
On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote:
> * tree-eh.c (lower_try_finally_copy): Generate new code in
> response to goto_queue entries as if the queue was sorted by
> index, not pointers.
> (lower_try_finally_switch): Likewise.
Ok.
r~
On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote:
> GNU ld version 2.14.90.0.4 20030523
Worked for me with 2.15.94.
r~
On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote:
> No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the
> library is loaded, while TR 15580 commands will be ran afterwards (during
> execution).
You'll find that globally changing the rounding mode will
On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote:
> Does gcc support
> #pragma STDC FENV_ACCESS
No, but we currently act like access is "on".
r~
On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
> Consider Double-Checked Locking
> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
> I used DCL with explicit memory barriers to implement thread-safe
> initialization of function-local statics
> (libstdc++-v3
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
> Richard, what's your level of confidence here? I'd rather not break C++
> or Java...
I think it's pretty safe.
r~
On Mon, Apr 18, 2005 at 02:48:27PM -0700, Geoffrey Keating wrote:
> The documentation for the atomic operation patterns says things like:
>
> >This pattern must issue any memory barrier instructions such that the
> >pattern as a whole acts as a full barrier.
>
> Should the barrier happen before t
On Sat, Apr 23, 2005 at 07:18:22PM +0200, Martin Koegler wrote:
> For implementing the type attributes, I propose:
> Add the field "tree type;" to "struct mem_attrs". This field holds the type,
> if present,
> or 0, if no type information is available.
>
> To access it, I propose:
> #define MEM_T
On Tue, Apr 26, 2005 at 10:57:07PM -0400, Daniel Jacobowitz wrote:
> I would expect it to be drastically faster. However this won't show up
> clearly in the bootstrap. The, bar none, longest bit of the bootstrap
> is building stage2; and stage1 is always built with optimization off and
> (IIRC) c
On Wed, Apr 27, 2005 at 12:36:41AM -0600, Jeffrey A Law wrote:
> Anyway, I'm going to look into why we're seeing so many *& expressions
> during TER.
We have an open PR for this. We don't propagate the & when
it's not a constant. Like in &x->y.
r~
On Fri, Apr 29, 2005 at 01:30:13PM -0400, Ian Lance Taylor wrote:
> I don't know of a way to tell libtool to not do duplicate compiles.
> You can use -prefer-pic, but at least from looking at the script it
> will still compile twice, albeit with -fPIC both times.
Incidentally, libtool does not com
On Fri, Apr 29, 2005 at 03:22:59PM -0700, Joe Buck wrote:
> I think you need to talk to the binutils people. It should be possible
> to make ar and ld more memory-efficient.
For ld, at least, --no-keep-memory. Normally it makes things run
slower, but that may not actually be the case for libjava
On Sat, Apr 30, 2005 at 10:33:43AM +0100, Andrew Haley wrote:
> OK, so the low-hanging fruit that remains is the libtools script and
> the linker. In the latter case, it seems that the big link causes
> severe problems with small memory systems.
I did some experiments today just to see what kind
On Sun, May 01, 2005 at 10:31:05PM +, Thorsten Glaser wrote:
> Could you please go to http://wiki.mirbsd.de/MirbsdKsh, get the source,
> compile it and try with it instead of your usual /bin/sh (I suppose GNU
> bash) again?
>
> I'd be interested if that warrants a noticeable speedup.
No visib
On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> GENERIC
> GIMPLE
> GOMP_ATOMIC
Do we gain anything over expanding this to the approprate __sync_foo
builtin in the front end.?
> GENERIC
> GIMPLE
> GOMP_FLUSH
Likewise.
> #pragma omp threadprivate
> -
On Tue, May 03, 2005 at 05:27:26PM -0400, Diego Novillo wrote:
> > Do we gain anything over expanding this to the approprate __sync_foo
> > builtin in the front end.?
> >
> Can the optimizers tell that this is an atomic builtin? If so,
> then no, they're not necessary.
Sure, in the same way we k
On Wed, May 04, 2005 at 09:06:14AM +0900, Peter O'Gorman wrote:
> Part of the problem here is the use of a convenienve library to hold several
> thousand object files and then making a shared library with the convenience
> library. On many platforms, those without a --whole-archive flag, libtool
>
On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote:
> Recursively calling instantiate_virtual_regs_in_insn does not look
> right.
Indeed it is not.
I'd like to see the define_insn for {addhi3}. I'm a bit confused as
to how I could have missed iterating over what appears like it ough
On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> For that instruction, instantiate_virtual_regs_in_insn
> enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
> is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
> It then jumps to verify, without changi
On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote:
> The savings of creating static libraries would be small if we
> refrained from building non-PIC object files.
But still largely useless. Who in their right mind is going to
use an 83MB static library when a shared library is avail
> The problem with C++ is in fold as we now have to disable the
> optimization
> which converted "a >= b ? b : a" to MIN_EXPR.
Which begs the question of why it doesn't happen when we get into
the tree optimizers and have lvalues there.
r~
On Fri, May 06, 2005 at 10:18:15PM +0200, Björn Haase wrote:
> When implementing "lowering" of SImode and HImode expressions to QImode
> sequences by splitters after reload, quite a number of new optimization
> opportunities show up that presently are not realized.
No, the real problem is repres
On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote:
> I was wondering if anyone could tell me how to write an (empty)
> instruction pattern that does a truncate/extend conversion on a register
> 'in place'.
>
> All the conversions I see are like this one in ia64/ia64.md:
>
> (define_ins
On Sun, May 08, 2005 at 04:33:28PM +0200, Steven Bosscher wrote:
> Can we expose this kind of address arithmetic to the tree
> optimizers? Should we?
No and no. I've always believed that we'd be keeping an rtl gcse
pass exactly for the reason of address arithmetic.
r~
On Sun, May 08, 2005 at 10:06:04PM +0200, Steven Bosscher wrote:
> A test case that shows what is going on is this:
>
> extern char *x;
> void
> foo (char *a, char *b)
> {
> if (!x)
> x = a;
> else
> x = b;
> }
This test case doesn't show anything. .04.cse merges all the high parts
o
On Sun, May 08, 2005 at 10:26:19PM +0200, Steven Bosscher wrote:
> Oops. Not a modified tree, non-standard command line options:
> -O -fgcse --param max-cse-path-length=1
Ah, I see. Well, I think this is a misfeature of gcse in how
it decides how to update expressions. With a bit more thought
w
On Sun, May 08, 2005 at 07:27:46PM +0200, Herman ten Brugge wrote:
> So here the sizeof(s) is also 1. This looks wrong to me as well.
It's correct.
> I can not find any refence in the gcc.info file about the sizeof an
> initialized structures with zero length arrays.
See ISO C99 6.7.2.1 paragra
On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote:
> > The best way is to have a post-reload splitter that splits the insn
> > into nothing at all.
>
> Is that really valid? I would have thought it would break the data flow.
Obviously you only split to nothing when the registers m
On Mon, May 09, 2005 at 05:45:24PM +0300, Mostafa Hagog wrote:
> EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
> {
> ! if (! MEM_READONLY_P (x))
Looks like you should push this check here:
case MEM:
if (!MEM_READONLY_P (x))
On Mon, May 09, 2005 at 05:26:10PM +0100, Richard Earnshaw wrote:
> So do we fully recreate *all* the flow information before a scheduling
> pass?
Yes.
r~
On Tue, May 10, 2005 at 11:37:50AM +0300, Mostafa Hagog wrote:
> I want to add the below example as a regression test; the difference
> between the success and failure is the position of a load operation. Is
> there a possibility to check this using the scan-assembler?
No.
r~
On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> Am I missing something here?
Probably not.
r~
1 - 100 of 812 matches
Mail list logo
