Hi,
On Fri, 27 Jan 2012, William J. Schmidt wrote:
>
> int
> test_switch_1 (unsigned int *index, int i)
> {
> switch (*index)
...
> However, for the first case, temporary expression replacement has
> effectively removed th
Hi,
On Wed, 1 Feb 2012, Jiri Kosina wrote:
> # cat x.c
> struct x {
> long a;
> volatile unsigned int lock;
> unsigned int full:1;
> };
>
> void
> wrong(struct x *ptr)
> {
> ptr->full = 1;
> }
>
> In my opinion, this is a clear bug
Even that depends (sadly) on who you ask.
Hi,
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> But I also think that gcc is simply *buggy*, and has made them much
> nastier than they should be. What gcc *should* have done is to turn
> bitfield accesses into shift-and-masking of the underlying field as
> early as possible, and then do all o
Hi,
On Thu, 2 Feb 2012, Aldy Hernandez wrote:
> > Seriously - is there any real argument *against* just using the base
> > type as a hint for access size?
>
> If I'm on the hook for attempting to fix this again, I'd also like to
> know if there are any arguments against using the base type.
S
Hi,
On Fri, 3 Feb 2012, Richard Guenther wrote:
> > int main(void)
> > {
> > double a = 4.47460300787e+182;
> > slipped = -1.141385
> > That is correct.
> >
> > slipped = -0.432436
> > That is obviously incorrect.
How did you determine that one is correct and the other obviously
incorrect? N
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
> > >No normal math library supports such an extreme range, even basic
> > >identities (like cos^2+sin^2=1) aren't retained with such inputs.
> >
> > I agree: the program is complete nonsense.
>
> I disagree: there may be cases where large inputs c
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
> > > For the glibc, I've finally reported a bug here:
> > >
> > > http://sourceware.org/bugzilla/show_bug.cgi?id=13658
> >
> > That is about 1.0e22, not the obscene 4.47460300787e+182 of the
> > original poster.
>
> But 1.0e22 cannot be handle
On Fri, 3 Feb 2012, Dominique Dhumieres wrote:
> Note that sqrt(2.0)*sin(4.47460300787e+182+pi/4) gives a diffeent value
> for the sum.
In double: 4.47460300787e+182 + pi/4 == 4.47460300787e+182
Ciao,
Michael.
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 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 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, 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 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 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, 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 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 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 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 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, 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 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, 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, 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 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 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 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 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 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. 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, 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.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 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,
[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 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,
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 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, 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 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 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 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 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 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,
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,
> 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 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,
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 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 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 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, 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, 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, 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, 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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,
some people already noticed it seems, so this may be a little too late,
but still. We now have a nightly SPEC tester running which posts the
results to
http://www.suse.de/~gcctest/SPEC/CINT/sb-terbium-head-64/
http://www.suse.de/~gcctest/SPEC/CFP/sb-terbium-head-64/
The machine is a d
Hi,
On Tue, 7 Mar 2006, Andrew Haley wrote:
> Our config tools return "x86_64" as an arch. Like this:
The canonical name is "x86_64" with underscore ...
> [EMAIL PROTECTED] ~]$ gcc -S add-entropy.c -march=x86_64
> add-entropy.c:1: error: bad value (x86_64) for -march= switch
> [EMAIL PROTECTED
Hi,
On Mon, 13 Mar 2006, Jeffrey A Law wrote:
> > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that a variable with a
> restricted range can never hold a value outside that the
> restricted range in a conformin
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
> What I am going to do in short perspective is
> o work on code quality of some SPECINT tests (e.g. reload is doing
>better job for crafty with many multi-registers than YARA)
I haven't looked at the new branch yet, so forgive me
Hi,
On Thu, 8 Jun 2006, Richard Guenther wrote:
> > Please don't get too fixated on the above pseudo-code. I have not
> > thought about this through in detail. I just want to bring this up,
> > particularly for folks doing data dependency. Perhaps we need
> > different
> > expressions altoget
Hi,
On Thu, 8 Jun 2006, Daniel Berlin wrote:
> >>> with base being either some memory object or an INDIRECT_REF of a
> >>> pointer and be done with that tree code.
> >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> >> any better in removing recursion :)
> >
> > What type
Hi,
On Thu, 8 Jun 2006, Daniel Berlin wrote:
> >> Thoughts?
> >
> > We (me and Matz) thought over this as well and concluded it would be
> > nice to have
> >
> > - MEM_REF ( base, offset, alias_tag )
> >
> > with base being either some memory object or an INDIRECT_REF of a
> > pointer and be
Hi,
On Wed, 14 Jun 2006, Joe Buck wrote:
> On Wed, Jun 14, 2006 at 11:34:33AM -0700, Mike Stump wrote:
> > I'd welcome the issue be addressed by the SC. I'd favor more timely
> > reviews. Maybe auto approval for a patch that sits for more than a
> > week? :-)
>
> I see your smilie, Mike,
Hi,
On Wed, 7 Jun 2006, Daniel Jacobowitz wrote:
> On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> > And string does not answer localization issue, however for numbers at least
> > there is one precedent to follow.
>
> I think this discussion has gotten totally sidetracked. When
Hi,
On Thu, 13 Jul 2006, Maurizio Vitale wrote:
> my understanding of the x86_64 ABI is that the following structure should be
> passed in registers:
Right.
> struct data {
> unsigned int x;
> unsigned int y;
> unsigned long z;
> };
>
> but when I compile:
>
> #include
>
>
Hi,
On Sun, 16 Jul 2006, Steven Bosscher wrote:
> On 7/16/06, Tim Prince <[EMAIL PROTECTED]> wrote:
> > > On my computer, the installed version of gcc is 4.1.0-25 and i could not
> > > find any compatible version of g77 to install. For the installation of
> > > octave, i need exactly gcc-g77 not
Hi,
On Sat, 15 Jul 2006, Gabriel Dos Reis wrote:
> | I don't see how they get past this issue. I've had some claim, but
> | it's a feature, not a bug.
> |
> | The basic question is, are two unrelated types in different dlls the
> | same, just because they have the same name? How do you preve
Hi,
On Fri, 14 Jul 2006, Mark Mitchell wrote:
> > Everything must be explicitly represented in the IL, totally
> > independent from the input language.
>
> FWIW, I agree. However, I do not agree that two types are compatible
> iff they would produce identical RTL. GIMPLE should still know th
e. The branch is maintained by Michael Matz.
Architecture-specific
Hi,
On Mon, 14 Aug 2006, Mark Mitchell wrote:
> pressure build on some set of infrastructure until it has been painfully
> obvious for some amount of time that it has to change. (In my
> experience, the same thing happens in developing proprietary software;
> convincing product management to let
Hi,
On Wed, 11 Oct 2006, Kai Tietz wrote:
> > -mcmodel=small'
> > Generate code for the small code model: the program and its
> > symbols must be linked in the lower 2 GB of the address space.
> > Pointers are 64 bits. Programs can be statically or dynamically
> > linked. This is the de
Hello,
On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote:
> Well, I was thinking of this test-case:
>
> int f(int cond1, int cond2, int cond3, int x, int y)
> {
> void f1();
> void f2(int);
> void f3();
>
> if (cond1)
> f1 ();
> else
> {
> if (cond2)
> f2 (x
Hello Martin,
On Mon, 31 May 2021, Martin Liška wrote:
> I've made quite some progress with the porting of the documentation and
> I would like to present it to the community now:
> https://splichal.eu/scripts/sphinx/
>
> Note the documentation is automatically ([1]) generated from texinfo with
Hello,
On Tue, 1 Jun 2021, Martin Liška wrote:
> On 5/31/21 5:49 PM, Michael Matz wrote:
> > Hello Martin,
> >
> > On Mon, 31 May 2021, Martin Liška wrote:
> >
> >> I've made quite some progress with the porting of the documentation and
> >&g
Hello,
On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:
> > The original problem is that the PR wasn't _in the body_ of the commit
>
> But I see [PR100085] right there at the end of the _summary line_:
Emphasis mine.
Ciao,
Michael.
t;
> > gold and ld.lld just emit an error unconditionally. I think non-x86
> > GNU ld ports which never support "copy relocations on protected data
> > symbols" may want to make the diagnostic unconditional as well.
> > Well, while (Michael Matz and ) I think compatibility che
Hello,
On Tue, 22 Jun 2021, H.J. Lu wrote:
> > > The issue is that libfoo.so used in link-time can be different from
> > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time
> > > has the default visibility. But foobar in libfoo.so at run-time can be
> > > protected. ld.so sh
Hello,
On Thu, 1 Jul 2021, Martin Liška wrote:
> On 7/1/21 3:33 PM, Eli Zaretskii wrote:
> > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> > > From: Martin Liška
> > > Date: Thu, 1 Jul 2021 14:44:10 +0200
> > >
> > > > It helps some, but not all of the issues disappe
Hello,
On Thu, 22 Jul 2021, Richard Biener via Gcc wrote:
> But how does TLS usage transfer between threads? On the gimple level
> the TLS pointer is not visible and thus we'd happily CSE its address:
Yes. All take-address operations then need to be encoded explicitely with
a non-CSE-able in
201 - 300 of 483 matches
Mail list logo
