Hi,
On Wed, 6 Jul 2011, Richard Sandiford wrote:
> > If the target allows (q-p)[n] to be used directly as an address, and
> > if the target has no post-increment instruction, then it might be
> > better. But I think it's a loss on other targets. It might even be a
> > loss on targets (like Po
Hi,
On Wed, 6 Jul 2011, Richard Sandiford wrote:
> The individual difference_cost and add_cost seem reasonable (4 in each
> case). I don't understand the reasoning behind the division though. Is
> the idea that this should be hoisted?
Yes, it should be hoisted outside the loop. The differenc
Hi,
On Tue, 5 Jul 2011, Richard Sandiford wrote:
> FWIW, the reason I asked was because I'm using a splay tree in a patch
> that I hope to send soon. The libiberty structures are a bit heavyweight,
> with the hooks stored alongside the root pointer, and with each node
> being a separate structur
Hi,
On Mon, 4 Jul 2011, Jakub Jelinek wrote:
> No, what you can get out of that is e.g. optimizing away otherwise unneeded
> large variable.
> Consider:
> static const int i[131072] = { 1, 2, 3, 4, 5 };
> void foo (void)
> {
> __asm volatile ("" : : "m" (i[0]));
> }
> By giving the asm just add
Hi,
On Mon, 4 Jul 2011, Michael Matz wrote:
> > There were other people pointing out issues with the splay tree (but
> > all w/o copyright assignment and much larger patches).
> >
> > I know I did the last re-write of this piece of code but it's been a
> >
Hi,
On Mon, 4 Jul 2011, Richard Guenther wrote:
> There were other people pointing out issues with the splay tree (but all
> w/o copyright assignment and much larger patches).
>
> I know I did the last re-write of this piece of code but it's been a
> long time ... in any case, previous reports
Hi,
On Fri, 1 Jul 2011, Jakub Jelinek wrote:
> > GCC turns this into:
> > "movaps%0, %%xmm0
> > shufps$27, %%xmm0, %%xmm0
> > movaps%1, %%xmm5
> > movaps%%xmm5, %%xmm6
> > " : : "m" costab_mmx[24], *"m" -2147483648*);
> >
> > The new constant might e
Hi,
On Tue, 19 Apr 2011, Eric Botcazou wrote:
> > I was LTO bootstrapping yesterday just fine. You're talking about
> > bootstrap-profiled.
>
> Not clear at all, a regular LTO bootstrap had failed on cc1 for days here.
Hmpf. Strange. I've bootstrapped with all languages except Ada
yesterday
Hi,
On Mon, 18 Apr 2011, H.J. Lu wrote:
> LTO bootstrap has been broken for more than a month:
I was LTO bootstrapping yesterday just fine. You're talking about
bootstrap-profiled.
Ciao,
Michael.
Hi,
On Mon, 28 Mar 2011, Paolo Bonzini wrote:
> > At expansion time we have the following for the call argument:
> >
> >> type > size
> > unit size
> > align 8 symtab 0 alias set -1 canonical type 0x75b29540
> >
> > which looks ok to me.
>
> It already isn
Hi,
On Sat, 26 Mar 2011, Levon Haykazyan wrote:
> I was trying to configure vim to work better with gcc coding
> conventions. When I set 'tab' symbol to be interpreted as 2 spaces, I
> noticed that a lot of formatting in e.g. gcc/cp/parser.c was gone.
Yeah, never change tabstop, change shiftwi
Hi,
On Sun, 20 Mar 2011, H.J. Lu wrote:
> I don't think it will help x32 and I think it will make it harder to add
> x32 support. I still want to see a real usage before I add it.
% cat real-world.c
/* intptr_t; what's that? */
union space_saving_htab_element {
void *generic_pointer;
/* Usu
Hi,
On Wed, 9 Mar 2011, DJ Delorie wrote:
> To avoid having two completely independent definitions of the
> peripheral register structures, would it be acceptable to add a target
> hook to tell gcc to reverse the bitfields? This can be done in
> finish_record_layout() by adjusting bit offsets, b
Hi,
On Wed, 2 Mar 2011, Kyle Girard wrote:
> > > Can I count on the uid for a type in a header to be the same across
> > > all compilation units that use that header?
> >
> > ... no.
> >
>
> Is there anyway in gcc to get a unique id for a type that would be the
> same across compilation unit
Hi,
On Wed, 2 Mar 2011, Kyle Girard wrote:
> Question, how is the uid for a type calculated? What are the
> contributing factors?
It's simply a counter incremented each time a type node is created (see
next_type_uid), hence ...
> Can I count on the uid for a type in a header to be the same acr
Hi,
On Thu, 24 Feb 2011, Jeff Law wrote:
> > Target avr suffers from similar problems in 4.3, 4.4 and 4.6 which are
> > all reported against avr backend, not against middleend/rtl optimizers.
> insn 33 and 34 are fine. 33 sets the high part of the HImode register
> to the result of the call to f
Hi,
On Fri, 11 Feb 2011, Paulo J. Matos wrote:
> On 11/02/11 12:03, Eric Botcazou wrote:
> > > if (! volatile_ok&& MEM_VOLATILE_P (op))
> > > return 0;
> >.
> >
> > It's more of the other way around: MEM_VOLATILE_P is a general operand
> > unless
> > explicitly requested via init
Hi,
On Sat, 22 Jan 2011, Nathan Froyd wrote:
> - Similarly to the work I did for s/TREE_CHAIN/DECL_CHAIN/, I'd like to
> replace TREE_TYPE for things like {POINTER,FUNCTION,ARRAY}_TYPE, etc.
> This work would be a good step towards both staticizing trees and
> tuplification of types.
While
Hi,
On Fri, 3 Dec 2010, Ian Lance Taylor wrote:
> Joern Rennecke writes:
>
> > Quoting Andrew Pinski :
> >
> >> On Thu, Dec 2, 2010 at 8:41 PM, Ian Lance Taylor wrote:
> >>> The Go language is not built by default, so this should not have a
> >>> significant effect on most developers.
> >>
> >
Hi,
On Thu, 18 Nov 2010, Jeff Law wrote:
> > I think that it should still be the case that if you break Java, and
> > one of the Java testers catches you, you still have an obligation to
> > fix the problem. All we're changing is whether you build Java by
> > default; nothing else.
>
> Agree
Hi,
On Mon, 8 Nov 2010, Dave Korn wrote:
> void foo (void)
> {
> int x, y, z;
> x = 23;
> asm ("do something" : "=r" (y) : "r" (x) );
> z = y + 1;
> }
The case in i8k.c really is different. It does use the value by
influencing the return value and the callers use the returned value in
Hi,
On Mon, 8 Nov 2010, Andi Kleen wrote:
> Richard Guenther writes:
>
> > On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen wrote:
> >> Andreas Schwab writes:
> >>>
> >>> The asm fails to mention that it modifies *regs.
> >>
> >> It has a memory clobber, that should be enough, no?
> >
> > No. A m
Hi,
On Fri, 20 Aug 2010, H.J. Lu wrote:
> int x = 0;
>
> to silence gcc from uninitialized warnings when I know it is
> unnecessary. Is that a good idea to add
>
> int x __attribute__ ((uninitialized));
>
> to tell compiler that it is OK for "x" to be uninitialized?
int x = x;
is the way GC
Hi,
On Mon, 16 Aug 2010, Mohamed Shafi wrote:
> Hello all,
>
> I am trying to port GCC 4.5.1 for a processor that has the following
> addressing capability:
>
> The data memory address space of 64K bytes is represented by a total
> of 15 bits, with each address selecting a 16-bit element. When
Hi,
On Thu, 1 Jul 2010, Richard Guenther wrote:
> Does --cref work with .comm symbols properly (listing the biggest one
> first)?
Unfortunately no.
(I find it mildly ugly to make collect2 act as a file filter. Why
shouldn't the --cref parser be implemented in the lto frontend, next to
the r
Hi,
On Tue, 15 Jun 2010, Paulo J. Matos wrote:
> >> Is GCC slowly losing support for certain archs or it is still
> >> striving to be as generic as possible?
> >
> > GCC looses and gains support for architectures depending on the
> > availability of competent volunteer maintainers for these
>
Hi,
On Sun, 13 Jun 2010, H.J. Lu wrote:
> > We shouldn't turn GNU x86 assembler into an optimizing assembler. Next
> > people may ask assembler to remove redundant instructions, ...
Well, but currently nobody is asking for such thing, right?
> > Right now, when something goes wrong, people don
Hi,
On Wed, 2 Jun 2010, Richard Guenther wrote:
> Well, on the one hand I agree - but on the other hand I see people
> eagerly waiting to be the first to post patches to convert all VEC uses
> that allocate from the heap(!) (yes - we can't use STL for GC allocated
> stuff!), leaving us with fi
Hi,
On Tue, 1 Jun 2010, Ian Lance Taylor wrote:
> >> > * Use C-style comments for multi-line comments, and C++-style comments
> >> > for single-line comments.
> >>
> >> I'm not sure i agree with this, because I don't see anything wrong
> >> with multi-line C++-style comments.
> >
> > It assume
Hi,
On Tue, 18 May 2010, Diego Novillo wrote:
> On Mon, May 17, 2010 at 16:15, Sandeep Soni wrote:
>
> > 1. What should be the format of representation of the GIMPLE tuples in
> >text?
>
> I liked Andrew's suggestion about S-expressions.
I can see that for describing types, maybe. But i
Hi,
On Mon, 17 May 2010, Andrew MacLeod wrote:
> > > Well, you get the same thing you get today. Any synchronization
> > > done via a function call will tend to be correct since we never move
> > > shared memory operations across calls. Depending on your
> > > application, the types of data
Hi,
On Mon, 17 May 2010, Ian Lance Taylor wrote:
> >> Since the atomic operations are being built into the compiler, the
> >> intent is to eventually optimize and inline them for speed... and in
> >> the best case, simply result in a load or store. That's further work
> >> of course, but these
Hi,
On Wed, 12 May 2010, Andrew MacLeod wrote:
> Well, you get the same thing you get today. Any synchronization done
> via a function call will tend to be correct since we never move shared
> memory operations across calls. Depending on your application, the
> types of data races the option
Hi,
On Fri, 30 Apr 2010, Diego Novillo wrote:
> On 4/30/10 09:35 , Massimo Nazaria wrote:
>
> > fprintf (dump_file, "gimple_code: %d\n",
> > gimple_code (def_stmt)); // Here I get segmentation fault...
>
> For default SSA names, the defining statement will be
Hi,
On Tue, 27 Apr 2010, Greg McGary wrote:
> (define_insn "*udivmodsi4_libcall"
> [(set (reg:SI 4)
> (udiv:SI (reg:SI 1)
> (reg:SI 2)))
>(set (reg:SI 1)
> (umod:SI (reg:SI 1)
> (reg:SI 2)))
>(clobber (reg:SI 2))
>(clobber (reg:SI 3))
>(clobber (reg:CC
Hi,
On Thu, 18 Mar 2010, Frank Isamov wrote:
> From the h file:
>
> #define REG_CLASS_CONTENTS \
> {
> \
> {0x, 0x, 0x}, /* NO_REGS*/ \
> {0x, 0x, 0x}, /* D_REGS*/ \
Hi,
On Thu, 18 Mar 2010, Vincent Lefevre wrote:
> On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
> > pow (a, 0.5) is always expanded to sqrt(a).
>
> This violates the ISO C99 standard for -0.0.
>
> According to N1256, F.9.4.4:
>
> pow(±0, y) returns +0 for y > 0 and not an odd integer
Hi,
On Sat, 27 Feb 2010, Joern Rennecke wrote:
> > >I wonder whether there is a plan to optimize code such as this:
> > >
> > >extern int (const int x);
> > >void () {
> > > (444);
> > > (444);
> > > }
> > >
> > >by not pushing the constant argument twice. It seems safe to
Hi,
On Tue, 23 Feb 2010, Paulo J. Matos wrote:
> On Tue, Feb 23, 2010 at 2:26 PM, Dave Korn
> wrote:
> > On 23/02/2010 13:23, Paulo J. Matos wrote:
> >
> >> That would make sense if the rtx is a set but in this case it is not.
> >> local-alloc.c:set_preference, line 1612 in particular, is called
Hi,
On Sun, 21 Feb 2010, Jon Turner wrote:
> I have recently encountered a gross inaccuracy in gprof that
> I can't explain. Yes, I know gprof uses a sampling technique
This is incorrect. Code compiled with -pg will call mcount on each
function entry. If there are many calls (compared to othe
Hi,
On Sat, 6 Feb 2010, Richard Guenther wrote:
> > CSE detects that the same subexpression is used in two places and
> > substitutes a reaching register for the reference to u32.word without
> > noticing that the memory has been modified by the bit field reference.
> > Adding a call to invalida
Hi,
On Sun, 10 Jan 2010, Dave Korn wrote:
> Ok. So if I had four ints, and I wanted to cast the pointers to char
> and compare them as 16 chars, that would be OK, because the chars would
> alias the ints; but in this case, where they started as chars and I cast
> them to ints, those ints do
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > So, IMO we have two sensible proposals:
> > (a) specify that bits <7:1> must be zero
> > (b) specify that bits <31:1> must be zero
>
> I uploaded sources and object files generated by gcc 4.4, icc 11.1
> and Sun Studio 12 Update 1 at -O to:
>
> http://
Hi,
[oh my, coming late to this thread, I'm sorry about restarting it but I
feel the urge to comment on some misconceptions I read, I believe ;-) ]
Commenting on the first mail where I think one subthread went down the
wrong path:
On Tue, 5 Jan 2010, Andrew Haley wrote:
> On 01/05/2010 02:09
Hi,
On Sun, 13 Dec 2009, Richard Guenther wrote:
> *** free_lang_data_in_decl (tree decl)
> *** 4380,4408
> }
> }
>
> ! if (TREE_CODE (decl) == PARM_DECL
> ! || TREE_CODE (decl) == FIELD_DECL
> ! || TREE_CODE (decl) == RESULT_DECL)
> ! {
> !
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > Then fix the psABI.
>
> Don't we need to specify passing and returning char, short and int since
> they are smaller than the integer class, which is eightbytes?
Since the mapping from domain to bitpatterns is bijective, we don't have
to (although if
Hi,
On Wed, 9 Dec 2009, Andrew Haley wrote:
> > The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
> > (and higher bits as don't cares, the same way a char is passed), as
> > opposed to the current text which requires <63:1> == 0 when passed as
> > registers or on the stack
Hi,
On Wed, 9 Dec 2009, H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
> >>
> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
> >
> > Right now they are specified in the psABI, you suggested to remove that
&
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> >> Why should the _Bool byte in "void foo(_Bool bar)" be any different?
> >
> > Because it can be different when the psABI doesn't say otherwise.
> >
>
> The psABI doesn't say anything about the _Bool return value.
That's a bug in the psABI. We probabl
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
> > ... because this part can only be guaranteed by the ABI. Without the
> > above language a compiler would be free to implement any non-zero byte as
> > true for parameter passing without violating the ABI.
> >
>
> Aren't bits in the _Bool byte of"bar" s
Hi,
On Tue, 8 Dec 2009, H.J. Lu wrote:
> Both icc and gcc generate:
>
> [...@gnu-26 pr42324]$ cat b4.c
> extern unsigned int bartmp;
>
> void foo(_Bool bar)
> {
> bartmp = bar;
> }
> [...@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b4.c -S
> [...@gnu-26 pr42324]$ cat b4.s
> .file "b4.c"
Hi,
On Mon, 7 Dec 2009, H.J. Lu wrote:
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
That was the outcome of a discussion in 2005/2006. We put this language
in because at that time all compilers booleanized
Hi,
On Fri, 27 Nov 2009, Dave Korn wrote:
> > PLEASE DO NOT DO THIS.
>
> However I don't think it's going to happen,
Yes, it's probably not going to happen; neither the requested revert.
But now I at least know a strategy how to sneak in controversial patches.
> given that it's been a coup
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
> > 1. What to do in the immediate term with the repo. I've got no strong
> > opinions here.
>
> I do understand most of the opinions, but I would rather prefer that we
> don't revert the trailing whitespace patch. I definitely can live wi
Hi,
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > In my mind it's very simple: trailing whitespace poses exactly _no_
> > problem (except of being against the coding standard),
>
> It's against the coding standards for a very good reason, which is that it
> makes patching harder because you h
Hi,
On Wed, 25 Nov 2009, Richard Kenner wrote:
> > And local patches. Basically _no_ patch will apply anymore as HJ changed
> > every single file.
>
> That's an exaggeration since only a few lines in each file were change.
The top 12 from the 2.2 MB patch:
tree-vect-loop.c | 3
Hi,
On Wed, 25 Nov 2009, Jeff Law wrote:
> On 11/25/09 09:51, Richard Kenner wrote:
> > > Can someone please remove this revision from the subversion database
> > > on the server and fix things up? If that's not possible at least
> > > the revision should be reverted.
> > >
> > Why the lat
Hi,
On Wed, 25 Nov 2009, Richard Guenther wrote:
> > Remove trailing white spaces.
> >
> > WTF?
> >
> > Thankyouverymuch.
> >
> > This 1) wasn't posted or approved 2) is bad as it breaks svn blame
> > 3) chokes all branches.
> >
> > What's up?
>
> Can someone please remove this revision from
Hi,
On Wed, 14 Oct 2009, Ben Elliston wrote:
> I deleted a personal branch from 5 years ago and have added the revision
> number of the delete commit to the branch description in svn.html.
>
> Would these two conventions suffice?
Well, I'm always of the opinion that it's better to have some te
Hi,
On Mon, 12 Oct 2009, Jeff Law wrote:
> To put things in perspective, the particular person I spoke with spent
> many days trying to understand why a particular function wasn't being
> inlined -- presumably they'd see "grep logfile" as a
> huge improvement over the days and days of twiddli
Hi,
On Mon, 12 Oct 2009, Jason Merrill wrote:
> On 10/12/2009 10:22 AM, Paolo Bonzini wrote:
> > Yep. Anyone deleting dead branches should add a link to the last "live"
> > version in branches.html. It seems easier to me to move them under
> > branches/dead, and possibly create branches/merged.
>
Hi,
On Tue, 6 Oct 2009, Paul Edwards wrote:
> Thanks Michael. That's exactly the sort of thing I was after. Just
> one thing - I'll need more than cc1. I need the files that normally
> go into gcc as well. So a combination of those two sets of source,
> so that I can get a single standalone e
Hi,
On Sun, 4 Oct 2009, Paul Edwards wrote:
> With 3.4.6, I have a script called "compile", which looks like this:
>
> call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bb-reor
Hi,
On Tue, 8 Sep 2009, Alex Turjan wrote:
> (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [19 fac_iter+0 S4 A32])
> (reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48
> {si_indexed_store_incl_ra} (nil))
An SI store to
Hi,
On Mon, 31 Aug 2009, Pedro Lamarão wrote:
> 2009/8/28 Pedro Lamarão :
>
> > I have not yet made complete size and execution speed measurements, though.
> > I've run the test suite and there are some failures; I think many of
> > them are not regressions when compared with a pure build with C
Hi,
On Mon, 10 Aug 2009, Richard Henderson wrote:
> On 08/10/2009 05:53 AM, Michael Matz wrote:
> > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin
> > functions with proper attributes.
>
> Yes, that would be entirely possible. I thought abo
Hi,
On Mon, 10 Aug 2009, Richard Guenther wrote:
> >> No and no. They will eventually resolve to pseudos generated during
> >> rtl eh expansion. But to avoid silliness at the gimple level I don't
> >> want to allow them to appear at random.
> >
> > Shouldn't it be enough to have EXC_PTR_EXPR/
Hi,
On Fri, 7 Aug 2009, Richard Henderson wrote:
> On 08/07/2009 12:31 PM, Richard Guenther wrote:
> > > L.N:
> > > exc_ptr.1 = EXC_PTR_EXPR (N);
> > > filter.1 = FILTER_EXPR (N);
> >
> > Does the above have
> > virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR
> > or FILT
Hi,
On Thu, 18 Jun 2009, Paolo Bonzini wrote:
> > > - Memory consumption in cc1/cc1plus at -Ox -g over that set of apps.
>
> People usually just look at top's output, but Honza has a memory tester
> so I thought maybe you can script it... Indeed here is a script to do
> that
The memory teste
Hi,
On Sun, 17 May 2009, Michael Eager wrote:
> If the LSDA is only interpreted by the personality routine pointed to
> by the unwind table, then all that should be needed is to describe the
> the functionality of that routine.
Yep, that was what my confusion above was about, if the LSDA format
Hi,
On Sun, 17 May 2009, Michael Eager wrote:
> > But the _format_ of the LSDA is not specified. It's really an
> > implementation detail of the compiler/language and doesn't have to be
> > agreed upon for mixing .o files from different compilers, as every
> > compilation unit can have it's o
Hi,
On Fri, 15 May 2009, Michael Eager wrote:
> Is there any documentation on the contents of .eh_frame
> and the augmentations used?
.eh_frame simply contains normal unwinding information, in DWARF2(34)
format, you're familiar with that :)
And nothing more, specifically it does _not_ contain
Hi,
On Wed, 6 May 2009, Michael Matz wrote:
> > There's already emit_insn_at_entry in cfgrtl.c. Would that work?
>
> Unfortunately not. That one also wants to immediately commit the just
> inserted instructions, which doesn't work during the transition phase
> f
Hi,
On Wed, 6 May 2009, Richard Earnshaw wrote:
> > Or like alpha:
> >
> > insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));
> >
> > That's not for the PIC load, but should work okay as expand from SSA
> > commits instructions on edges later. That actually seems even nicer
> >
Hi,
On Wed, 6 May 2009, Paolo Bonzini wrote:
> Looks like something like this could be useful to avoid code
> duplications in the backends:
>
> void
> emit_insn_at_top (rtx insn)
> {
> rtx scan;
>
> gcc_assert (current_ir_type () != IR_RTL_CFGLAYOUT);
> push_topmost_sequence ();
> scan
Hi,
On Wed, 6 May 2009, Mark Mitchell wrote:
> >> How about emitting a set at each place the PIC register is needed,
> >> and making sure that gcse will will common these sets where
> >> appropriate?
>
> > I'd rather not. -O0 code is bad enough already; and this just makes
> > more work for
Hi,
On Wed, 6 May 2009, Joern Rennecke wrote:
> Richard Earnshaw:
> >That won't work because the PIC register on ARM is a pseudo, so
> >generating it during prologue generation is too late. It needs to exist
> >before data flow analysis starts on the RTL.
>
> How about emitting a set at each pl
Hi,
On Wed, 6 May 2009, Richard Earnshaw wrote:
> > The easiest solution would be to just make a note that you need the
> > PIC register and then, when expanding the prologue emit the necessary
> > instructions. IMO that makes sense as PIC register setup usually is
> > something the prologue
Hi,
On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
> >>> The slush that I requested last week has been lifted. However, I
> >>> have asked for relative calm until the cond-optab branch has been
> >>> merged to mainline, which will hopefully occur on Friday, May 8th.
> >>
> >> As of this morni
Hi,
On Thu, 9 Apr 2009, Paolo Bonzini wrote:
> Fixed like this:
>
> Index: gcc/optabs.c
> ===
> --- gcc/optabs.c(branch cond-optab)
> +++ gcc/optabs.c(working copy)
> @@ -4026,6 +4026,8 @@ prepare_cmp_insn (rtx x, rt
Hi,
On Mon, 16 Feb 2009, Jeff Law wrote:
> > If the initial alternative selection was done cleverly (like chose the
> > alternatives allowing the largest register sets which don't
> > immediately create conflicting demands for a pseudo register) the
> > opportunities for making an uncolorable
Hi,
On Fri, 13 Feb 2009, Paolo Bonzini wrote:
> > We'd want to encode [early insn alternative selection] information in
> > the conflict graph so that IRA would allocate registers so as to fit
> > the constraints of the early insn alternative selection. Right? In
> > the case where the graph
Hi,
> This program appears to me to be invalid according to C99 6.7.3.1,
> which is the only definition of restrict that we have.
>
> If P is assigned the value of a pointer expression E that is based
> on another restricted pointer object P2, associated with block B2,
> then either t
Hi,
On Wed, 19 Nov 2008, H.J. Lu wrote:
> On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 18 Nov 2008, H.J. Lu wrote:
> >
> >>> I used malloc to create my arrays instead of creating the in the stack.
> >>> My program is working now but it is very slow
Hi HJ,
On Mon, 3 Nov 2008, H.J. Lu wrote:
> Icc will introduce to support intrinsics for current and
> future instruction sets, starting with AVX.
So how about the (IMO) nicer name this list came up the last time this was
brought up (April): x86intrin.h .
> My question is if we should put AV
Hi Bill,
On Fri, 1 Aug 2008, Diego Novillo wrote:
> > Finding that DECL_CONTEXT might include portions of what looked like
> > template definitions, and surmising that lexical nesting was a
> > language artifact that should no longer be of significance beyond the
> > front-end, I attempted to cl
Hi,
On Tue, 29 Jul 2008, Agner Fog wrote:
> g++ (v. 4.2.3) without any options converts memcpy with unknown size to rep
> movsb
Use newer GCCs. They will (1) not expand memcpy inline for unknown sizes
(without special options, also make sure you don't get the glibc inlines)
and (2) won't exp
Hi,
On Mon, 28 Jul 2008, Agner Fog wrote:
> Glibc 2.8 is still almost 5 times slower than the best function
> libraries for unaligned data on Intel Core 2, and the default builtin
> function is slower than any other implementation I have seen (copies 1
> byte at a time!).
You must be doing so
Hi,
On Fri, 25 Jul 2008, Chris Lattner wrote:
> >But not all the trees implementing those types (and all the
> >cross-references between those, that are important for parsing but not
> >interesting at all for the middle-end). All you need is a tag (alias
> >set number) per type and a graph gi
Hi,
On Fri, 25 Jul 2008, Chris Lattner wrote:
> >the frontends, but can concentrate on what is useful and needed for the
> >middle-end right now.
>
> Sure, this makes plenty of sense to me (and sounds very *very*
> familiar). Do you intend to include things like TBAA in the initial
> type sy
Hi,
On Tue, 3 Jun 2008, Diego Novillo wrote:
> On Tue, Jun 3, 2008 at 04:51, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
>
> > You may want to read
> >
> > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html
>
> Thanks. I think I will try to incorporate this in LTO so we won't
> even nee
Hi,
On Mon, 31 Mar 2008, Tom Tromey wrote:
> > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
>
> Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll,
> Joe> who has just enough technical knowledge to derail conversation.
>
> I think that if we've reached the point where
Hi,
On Thu, 6 Mar 2008, Andi Kleen wrote:
> To be realistic it is very unlikely anybody will measure a difference
> from a few more or a few less clds in a program.
Only an assumption, and in fact wrong. See upthread for a benchmark.
IIRC Uros also made measurements to justify the removal of
Hi,
On Wed, 5 Mar 2008, H. Peter Anvin wrote:
> Michael Matz wrote:
> >
> > Many bugs are a big issue to people who actually hit them, and we had (and
> > probably still have) far nastier corner case miscompilations here and there
> > and nevertheless released.
Hi,
On Wed, 5 Mar 2008, David Miller wrote:
> I will be sure to hunt you down to help debug when someone reports that
> once every few weeks their multi-day simulation gives incorrect results
> :-)
Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(),
installing a trampoli
Hi,
On Wed, 5 Mar 2008, Chris Lattner wrote:
>
> On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
>
> >Richard Guenther wrote:
> > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > >than
> > >three month.
> >
> >Well, how often do you take a trap inside an overlappi
fix on kernel side in signal handling, or by
> > > removing std usage completely
>
> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > That is true. But it requires updating the kernel to a fixed one if you
> > want to run your programs compiled by 4
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > alias_sets_conflict_p() is used to determine if an addressable variable
> > and a type conflict also from the tree-ssa alias machinery (in effect to
> > determine which virtual variables need to be clobbered). It just isn't
> > feed COMPONENT_
Hi,
On Wed, 5 Mar 2008, Jan Hubicka wrote:
> Kernels almost never follow ABI used by applications to last detail.
But we aren't talking about the ABI the kernel uses internally, but about
what is exposed to user-space via signal handlers. _That_ part needs to
be followed, and if it isn't it'
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > The problem lies in the way how we represent load and store dependencies
> > as virtual operands. Conflicts between a pair of mem accesses are not
> > evaluated by asking alias_set_conflicts_p() on both accesses, but instead
> > via a chain of
301 - 400 of 480 matches
Mail list logo
