On Mon, Nov 23, 2009 at 10:17 AM, Ian Bolton wrote:
> David Edelsohn wrote:
>> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton
>> wrote:
>> > From some simple experiments (see below), it appears as though GCC
>> aims
>> > to
>> > create a lop-sided tree when there are constants involved (func1
>> be
On Wed, Nov 25, 2009 at 08:31:27PM +0100, Richard Guenther wrote:
> And patch doesn't have an option to ignore whitespace changes.
Sure it does. -l (for loose, or --ignore-whitespace).
QUILT_PATCH_OPTS for quilt.
--
Daniel Jacobowitz
CodeSourcery
>
> Such a thing already existed a few years ago (IIRC Haifa had something
> that Dan picked up and passed on to me). But it never brought any
> benefits. I don't have the pass anymore, but perhaps Dan still has a
> copy of it somewhere.
It was actually posted and reviewed, you can find it in the
On Sun, Nov 29, 2009 at 3:33 PM, Richard Guenther
wrote:
> On Sun, Nov 29, 2009 at 9:18 PM, Daniel Berlin wrote:
>>>
>>> Such a thing already existed a few years ago (IIRC Haifa had something
>>> that Dan picked up and passed on to me). But it never brought any
Hi,
I met a bug in my gcc porting. It work fine when executing with -O0.
But with -Os, there is a insn missed. I dumped the RTL and checked them.
When in movebug.c.175r.lreg, it is fine. But in next phase --
movebug.c.176r.greg, the insn missed.
Here is the simple c program (movebu
Hi,
Addition information, I just found. It was deleted in function: void
set_insn_deleted (rtx insn), in emit-rtl.c.
It is called by reload() in reload1.c.
Here is the code in reload():
/* If a pseudo has no hard reg, delete the insns that made the equivalence.
If that insn didn't set t
ntation caller and __aeabi_read_tp() must run in
> the same mode.
I don't believe that this is true. In what way is it not safe?
--
Daniel Jacobowitz
CodeSourcery
blems. Do you have a concrete problem?
> Is the implementation still incomplete?
No. It's been finished for two years or more.
--
Daniel Jacobowitz
CodeSourcery
> When a pseudo which has an equivalent form (via the REG_EQUIV note) fails to
> get a hard register, reload deletes the insn which sets the pseudo and
> instead will reload the equivalent form into a suitable hard register prior
> to use points.
>
> What you want to do is look at the reloads gener
> Yeah. The Move Symbol to R0 register is deleted, which is weird.
> And I still can not figure out why. Which means I still need to dig it.
> But I found when I used the gcc-4.0.2 version, the Call insn call the
> function direction
> call the function symbol which is OK.
> I mean how gcc determin
>
> You might start by monitoring emit_reload_insns's behavior when it handles
> your insn.
I just debug the source code with your advice. Check the function
emit_reload_insns.
That insn was deleted before entering funcion emit_reload_insns. It
was deleted in reload(...) in reload1.c file just bef
Hi Jeff:
I have already fixed the bug. this occurs due to register
allocation failed in function global_alloc. After calling the
find_reg(), the reg_renumber still keep the value -1 in it. So the
reload() in reload1.c delete the insns.
I didn't set any call saved registers which means ever
Hi,
I have a problem about RTL sequence.
If I wanna generate the RTL in sequence, and don't let gcc to schedule them.
Like the following(all the variable is rtx):
emit_insn(reg0, operands[0]);
emit_insn(reg1, reg0);
emit_insn(operands[0], reg1);
But gcc will will re
2009/12/11 Ian Lance Taylor :
> daniel tian writes:
>
>> I have a problem about RTL sequence.
>> If I wanna generate the RTL in sequence, and don't let gcc to schedule
>> them.
>> Like the following(all the variable is rtx):
>>
>>
insn = make_insn_raw (par);
>
> sur = NEXT_INSN(insn1);
>
> PREV_INSN(insn) = insn1;
> NEXT_INSN(insn) = sur;
> delete_insn(insn1);
>
> delete_insn(insn2);
> }
>
>
> 2009/12/11 daniel tian :
>> 2009/12/11 Ian Lance Taylor :
>>
>> Does there any solution in RTL level?
>> Because I already solve the problem in ASM output level, exactly the
>> same solution as you suggest in this email.
>> I may need do some optimization later. So RTL level will be great!
>
> As far as I know there is no way to do this at the RTL level. I
Ian:
By the way, I don't underand the start_sequence and end_sequence.
What does those function mean.
I checked the source code in emit-rtl.c.
I still can't figure out what they do.
There is a structure sequence_stack, I don't what it does.
Thanks.
esn't. You may have heard of a commercial testsuite built on this
principle :-)
--
Daniel Jacobowitz
CodeSourcery
tion
>
> However, the solution seems to work, except in O0, where I get this error:
This means whatever is calling gen_newrtl to create the insn is not
checking operand predicates first. That's probably code you wrote
too.
--
Daniel Jacobowitz
CodeSourcery
at and how do I handle the cost then ?
>- Just say that an unspec has a higher cost?
Are you really talking about rtx_costs? It sounds to me more like you
want to change your scheduler.
--
Daniel Jacobowitz
CodeSourcery
se EPILOGUE_USES to say that changes to the
accumulator should not be discarded. You could also use
unspec_volatile instead of unspec, but that may further inhibit
optimization.
--
Daniel Jacobowitz
CodeSourcery
On Sat, Dec 19, 2009 at 2:48 PM, Steven Bosscher wrote:
> On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher
> wrote:
>> I'll see if I can make the intraprocedural version work again before
>> Christmass.
>
> Well, it works, but then again it really does not. For example, the
> original implement
Hi,
I have a problem with load/store pattern. Because in my target,
the load/store memory operand must like this form: (MEM: (REG) ),
(MEM: (REG + CONST_INT)), (MEM: (REG + REG)).
const_int should less than 256. But in CALL insn, the memory operand
can should be in (MEM: (REG)), (MEM:(SYMBOL_
For the sake of conversation I'll call them Alice and
Bob... no, I'll call them TARGET_MAVERICK and TARGET_NEON. Now you
need a minimum of three copies of the mov pattern that are
mostly the same.
It'd be nice if there was a way to compose instruction patterns :-(
--
Daniel Jacobowitz
CodeSourcery
h weird operand predicates. For instance,
in a patch I'm working on for ARM cmpdi patterns, I ended up needing
"cmpdi_lhs_operand" and "cmpdi_rhs_operand" predicates because Cirrus
and VFP targets accept different constants. Automatically generating
that would be a bit excessive though.
--
Daniel Jacobowitz
CodeSourcery
the 64-bit insns
> it still fails the openssl testsuite.
Interesting, I knew you had a lot of Cirrus patches but I didn't
realize the state of the checked-in code was so bad.
Is what's there useful or actively harmful?
--
Daniel Jacobowitz
CodeSourcery
> In general it will be tricky for latter passes to clean up the messes.
> The fundamental problem is that the address computation is exposed to
> PRE prematurely (for a given target ) at GIMPLE level.
Yeah, i'm not sure PRE can really do anything different here.
I also think you would have a ve
er I identified a candidate and put a
breakpoint there, execution never actually stopped there ^^
Hints where these .zero lines are generated and why, where to put a breakpoint
and what to look for -- or anything else that puts me on the right track --
would be appreciated.
Thanks
On Sunday 27 December 2009 07:09:08 Jerry DeLisle wrote:
> Daniel Franke wrote:
> > The problem: for some reason the .o file for a small fortran program may
> > be blown up to multiple GB. The diff below shows the differences in
> > assembler of the testcase gfortran.dg/actu
of host systems where shell scripts aren't a viable
option for ld. Why make everyone write the wrapper script? Makes
sense to me to have gcc decide.
--
Daniel Jacobowitz
CodeSourcery
can also ignore it.
--
Daniel Jacobowitz
CodeSourcery
port for o32 entirely.
I don't think anyone's suggested that. o32 is the default ABI for
32-bit MIPS GNU/Linux targets which are still in wide use.
--
Daniel Jacobowitz
CodeSourcery
tion to select alternatives; (C) branch shortening to
determine branch alternatives.
I'm curious if anyone thinks there's a generic solution to this (that
doesn't involve a complete instruction selection rewrite :-).
--
Daniel Jacobowitz
CodeSourcery
you even know what the registers
are.
--
Daniel Jacobowitz
CodeSourcery
any support for shared libraries. It
will ignore profiling samples that lie outside the executable. And in
this case, that includes _mcount (which is in libc.so.6). That's
probably why.
--
Daniel Jacobowitz
CodeSourcery
for now at least. Too bad.
Despite all that exchange, I don't think you ever answered Andreas's
question - at least not in a way that I could understand. A size of
what? The size of the *type* on x86 is 16; the size of the *data
bits* is 10. But what cares about the size of the d
;s a prototype:
http://sourceware.org/ml/gdb-patches/2006-10/msg0.html
--
Daniel Jacobowitz
CodeSourcery
ICE
trying to emit (set (const) (reg)).
It seems to me that the problem is marking a register in the RHS of a
set as an output constraint. The reg becomes function_invariant_p and
chaos ensues.
Is this right? If so, is there somewhere that should assert if an
operand's constraint is marked as an output, but not somewhere that
the RTL allows modification of the operand?
--
Daniel Jacobowitz
CodeSourcery
On Fri, Apr 02, 2010 at 12:06:28AM +0100, Bernd Schmidt wrote:
> On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote:
> > I'm debugging a Thumb-2 glibc build failure on trunk for
> > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
> > 2010-02-01 pa
to tears if they're both outputs.
Hrm. Yeah, those really should be two pseudos. I'll fix that.
--
Daniel Jacobowitz
CodeSourcery
d are "externally visible".
Then you can think about it as "does not alias any non-device
memory", or any number of variants on that.
--
Daniel Jacobowitz
CodeSourcery
just a parser and a syntax tree).
--
Daniel Jacobowitz
CodeSourcery
work. The first step
in cross building a native compiler like this is to build a cross
compiler of the right version.
> If this is ok, I will post a little patch.
That sounds fine, but the whole process is trouble.
--
Daniel Jacobowitz
CodeSourcery
On Sun, Oct 12, 2008 at 03:13:47AM +0800, Zhang Le wrote:
> On 00:06 Sat 11 Oct , Daniel Jacobowitz wrote:
> > > If this is ok, I will post a little patch.
> >
> > That sounds fine, but the whole process is trouble.
>
> Would you explain why it is trouble? Tha
>
> It's a field in the class$ structure. class$ is initialized by creating a
> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The
> DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
>
> _CD_pp is an array of void*. These are initialized by DECL_INITIAL too.
>
> InitCla
that r77 is not used in it's function after this instruction
> and thus DCE deletes it.
Don't focus on DCE. That's not the problem; the fact that there's no
visible dependence is the problem. Can you make the next instruction
have a use for r77 explicitly (CALL_INSN_FUNCTION_USAGE)?
--
Daniel Jacobowitz
CodeSourcery
I am still looking into this, it's on my stack of PRE weirdness :)
On Thu, Oct 16, 2008 at 11:39 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-10-16 at 11:29 +0200, Richard Guenther wrote:
>>
>> Do we have a bug for these FAILs? Maybe we should add the analysis that
>> happened so
Sure, that's why they are there.
On Thu, Oct 23, 2008 at 10:00 AM,
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> Can i make use of functions defined in "tree-data-ref.h" for data dependency
> analysis on GIMPLE trees ?
>
> Thanks.
>
>
I have placed a continuous builder (IE it does one build per svn
change) for GCC for x86_64 on an 8 core machine (nicely provided by
Google), and it has results here:
http://home.dberlin.org:8010/waterfall
(I have not made it summarize the warnings yet, and these deliberately
do not run the tests
On Mon, Oct 27, 2008 at 5:57 PM, Peter A. Felvegi
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've run today into an infinite loop when compiled a test suite w/
> optimizations. The original tests were to do some loops with all the
> nonnegative values of some integral types. Instead of hardwiring
On Tue, Oct 28, 2008 at 8:02 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/10/25 Daniel Berlin <[EMAIL PROTECTED]>:
>> I have placed a continuous builder (IE it does one build per svn
>> change) for GCC for x86_64 on an 8 core machine (nicely provided by
>
On Wed, Oct 29, 2008 at 9:16 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/10/29 Daniel Berlin <[EMAIL PROTECTED]>:
>> The patch tracker was an experiment in trying to see if it would
>> improve the rate of patches falling through the cracks.
>> It ha
On Wed, Oct 29, 2008 at 11:42 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
>>> A bi-weekly status report of the patch tracker sent to gcc-patches
>>> would definitively make the list of unreviewed pat
On Fri, Oct 31, 2008 at 01:02:18PM -0400, Jack Howarth wrote:
>Can anyone explain if the recent change in Apple dropping their
> NDA will have any impact on the GPLv3 issue with Apple and FSF?
Please discuss this on some more appropriate forum, not here.
--
Daniel Jacobowitz
CodeSourcery
R_MIPS_TLS_DTPREL type with the
> R_MIPS_TLS_DTPMOD, since for each tls variable in global dynamic
> model, tls_get_addr must receive the module index and the offset. Here
> is the second problem...
That's because this is the local dynamic model.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Nov 20, 2008 at 9:28 PM, Alexey Salmin <[EMAIL PROTECTED]> wrote:
> 2008/11/20 Michael Matz <[EMAIL PROTECTED]>:
>> 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 wro
tant.
This is all very interesting, but you didn't answer my question: is
this causing some problem, or just confusing? These are all intended
optimizations.
--
Daniel Jacobowitz
CodeSourcery
r four words. The second and fourth words will be
the offsets. This is a global dynamic sequence, since it passes
non-zero offsets to __tls_get_addr.
--
Daniel Jacobowitz
CodeSourcery
On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
>>> 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 poi
nop
> 5ffe14bc: 8000sdc3$31,-32768(ra)
>
> We can see that the offsets are prefixed by 8. Why is that?
The offsets are biased; that's -32768, the lowest 16-bit signed
offset. The bias is used to expand the addressable range of the
thread pointer.
Glad I could help!
--
Daniel Jacobowitz
CodeSourcery
Hi all.
I'm a Gentoo user with an Athlon XP:
[EMAIL PROTECTED] ~ $ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 3000+
stepping: 0
cpu MHz : 2157.092
cache size : 512 KB
fdiv
Toon Moene wrote:
All,
During the IRC meeting of GNU Fortran hackers last Friday, I was asked
to propose the following contributors to the Fortran compiler and run
time library for the position of "reviewer" to the Steering Committee:
Daniel Kraft
Janus Weil
Mikael Morin
Thank
ny difference for the optimizer? If yes, where and how should these
attributes be applied to the function symbol?
Are these the right questions to ask or am I barking up the wrong tree?
Thanks
Daniel
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "general_operand" "")
)]
""
{
if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
{
if(!no_new_pseudos)
{
operands[1]=force_reg(
Hi Dr. Uday Khedker:
Happy New Year!
I met hazard problem. And I have debuged this error for a few
days. I wrote DFA to avoid load hazard, but still it exists. I wonder
whether in default the command './cc1 hazard.c' doesn't compile the
file with DFA. And in default without any optimization
On Saturday 10 January 2009 19:06:48 Toon Moene wrote:
> Now, however, I want to congratulate Daniel Franke and Steve Kargle (who
> has been a GNU Fortran maintainer before) with their new status of
> "reviewer".
>
> Thanks Daniel and Steve, for (re-)joining the club !
? And the tests use
> that rather than testing for a specific CPU model?
This doesn't answer what you should do now, but I can explain the
precedent: the only reason there is a predefine for 405 is so that the
atomicity routines in libstdc++ know to avoid lwsync.
--
Daniel Jacobowitz
CodeSourcery
17,327,572 k
:)
On Wed, Jan 21, 2009 at 8:13 PM, Paolo Carlini wrote:
> Hi,
>
> for the record, today I started an rsync to get a local copy of the
> repository and, at variance with the information in:
>
> http://gcc.gnu.org/rsync.html
>
> the size I'm seeing is already > 17G, and counting...
nding warning would be a win? "warning: ignored NULL check
because pointer has already been dereferenced"?
--
Daniel Jacobowitz
CodeSourcery
centralized, and (B) standardized. Otherwise the right way to pass
arguments will end up different for every plugin.
--
Daniel Jacobowitz
CodeSourcery
t cases where 4.0.2 gives smaller code with -Os
than a 4.4 snapshot, please, file them in bugzilla.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston wrote:
> On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
>
>> Our plugins do not break when switching compiler binaries. In fact, I
>> have had plug-in binaries that perform very simple tasks work fine
>> when switching (minor!) compiler releas
nner
RTX. Search arm_rtx_costs_1 for "CONST_INT:".
--
Daniel Jacobowitz
CodeSourcery
On Fri, Jan 30, 2009 at 7:44 AM, Bingfeng Mei wrote:
> Hello,
> I try to make modulo scheduling work more efficiently for our VLIW target. I
> found one serious issue that prevents current SMS algorithm from achieving
> high IPC is so-called "transitive closure" problem, where scheduling window
.
Did you try mips-unknown-linux-gcc -EL -print-search-dirs?
--
Daniel Jacobowitz
CodeSourcery
s a static variable, then
> multiple translation units require access to the static variable. That
> does not imply that the static variable has external linkage.
Does this mean that if you compiled some of those TUs with GCC, and
some with icc, they might legitimately access different copies of the
static variable? Seems odd.
--
Daniel Jacobowitz
CodeSourcery
* slower, please report it as a bug in
Bugzilla.
--
Daniel Jacobowitz
CodeSourcery
hello,
there is a 'movm' problem that puzzled me. In my target machine,
to load a large immediate data, can only move into zero register "R0".
but R0 is a generally register. I defined the the way in the
following:
if the immediate data (op1) is larger than 1024
then do
{
If you want to help admin the wiki, I am more than happy to make you a
super user.
That goes for Steven, etc.
On Thu, Feb 26, 2009 at 12:31 PM, Manuel López-Ibáñez
wrote:
> 2009/2/25 Gerald Pfeifer :
>> On Tue, 24 Feb 2009, Steven Bosscher wrote:
>>> Can someone *please* ban this nutcase from t
2009/2/26 Joern Rennecke :
>> the address label "common_reg " used many times. I think it will
>> load one time. But after optimized with '-Os' or '-O2', it still loads
>> the label "common_reg " six times..
>
> Previously, you could define LEGITIMIZE_ADDRESS and
> LEGITIMIZE_RELOAD_ADDRESS
> to ge
2009/2/26 Dave Korn :
> daniel tian wrote:
>
>> there is a 'movm' problem that puzzled me. In my target machine,
>> to load a large immediate data, can only move into zero register "R0".
>> but R0 is a generally register. I defined the the way in
2009/2/27 Joern Rennecke :
> Quoting daniel tian :
>
>> 2009/2/26 Joern Rennecke :
>>>>
>>>> the address label "common_reg " used many times. I think it will
>>>> load one time. But after optimized with '-Os' or '-O2', i
2009/2/27 Dave Korn :
> daniel tian wrote:
>
>> That seems to solving a address mode problem. My problem is that while
>> loading a large immediate data or SYMBOL_REF, the destination is a
>> specified general register (register 0:R0). So I don't how to let the
>&g
haven't written C++ in a while, so forgive any obvious gaffes.
class X {
int x, *y;
X() {
y = &x;
}
X(X &obj) {
x = obj.x;
y = &x;
}
}
Memcpy that somewhere else and the internal pointer is invalid.
--
Daniel Jacobowitz
CodeSourcery
500, Daniel Berlin wrote:
>>If you want to help admin the wiki, I am more than happy to make you a
>>super user.
>>That goes for Steven, etc.
>
> Wait. Are we talking about giving people root access on sourceware
> just to clean up a wiki? Hopefully this is not the case.
>
> cgf
>
2009/2/27 daniel tian :
> 2009/2/27 Dave Korn :
>> daniel tian wrote:
>>
>>> That seems to solving a address mode problem. My problem is that while
>>> loading a large immediate data or SYMBOL_REF, the destination is a
>>> specified general register
2009/3/2 daniel tian :
> 2009/2/27 daniel tian :
>> 2009/2/27 Dave Korn :
>>> daniel tian wrote:
>>>
>>>> That seems to solving a address mode problem. My problem is that while
>>>> loading a large immediate data or SYMBOL_REF, the destination
32768==0x8000.
Are you sure both of those code sequences are calling __tls_get_addr?
If so, compare the arguments they passed.
> Last question, is there a difference between DSO and PIE objects other
> than the INTERP entry in the program header?
Yes. Symbol preemption is allowed for DSOs but not for PIEs or normal
executables. That explains the different choice of model.
--
Daniel Jacobowitz
CodeSourcery
On Thu, Mar 12, 2009 at 9:32 AM, Paolo Carlini wrote:
> Hi,
>> Notice how the third argument is 'int' instead of 'const int'. Is
>> this the way C++ is supposed to behave or is this a bug in the FE?
>>
> Well, I would say this is a rather well known C++ feature not a bug. It
> took me a little ti
f the symbol. This
> name then allows to look up the symbol. Unfortunately, in the case of
> local-dynamic, ELF_R_SYM will return 0 which is not correct (the same
> for global-dynamic will return 9): we can see by the way that readelf
> is not able to get the symbol name. What do you thi
On Thu, Mar 12, 2009 at 11:15 AM, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
>> But if it was following this and removing const qualifiers, shouldn't
>> it have remove the const from const char * too?
>> Or am i missing something?
>
> No, that is not a
for
>
> [...]
>
> > Can anyone clarify if the SC *really* need us to not branch before the
> > license change, as opposed to merely not /release/ until then?
>
> The topmost sentence should be unambiguous. Yes, the SC asked us not
> to branch.
But:
> (And why, if so?)
--
Daniel Jacobowitz
CodeSourcery
On Mon, Mar 16, 2009 at 12:11 PM, Adam Nemet wrote:
> Ramana Radhakrishnan writes:
>> [Resent because of account funnies. Apologies to those who get this twice]
>>
>> Hi,
>>
>> > > This problem is reported every once in a while, all targets with
>> > small
>> > > load-immediate instructions suffer
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
> 2009/3/12 Daniel Jacobowitz :
> > On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
> >> > Check what symbol is at, or near, 0x4003 + 22368. It's probably
> >> > the GOT plus a c
hile(*str)
> *tty = *str++;
> }
If you believe there is a bug, and you have a testcase, please report
it in bugzilla. Thanks.
--
Daniel Jacobowitz
CodeSourcery
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
> 2009/3/17 Daniel Jacobowitz :
> > On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
> >> I don't understand how the runtime loader could know that! As far as I
> >> know, the tls model is n
x27;s what I said. This is how the uClibc and GLIBC dynamic
loaders work and I believe it's described in Ulrich's paper.
--
Daniel Jacobowitz
CodeSourcery
On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>> The topmost sentence should be unambiguous. Yes, the SC asked us not
>> to branch.
>
> The request came from RMS, the SC just passed it on.
>
There are two things here that both
On Fri, Mar 20, 2009 at 11:17 AM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 9:34 AM, Daniel Berlin wrote:
>> On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
>>> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>>>> The topmost sentence shoul
On Fri, Mar 20, 2009 at 12:09 PM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
>
>> Okay then, as the leadership body of the GCC community, part of your
>> responsibility is keeping your constituents (the rest of us!) informed
>>
1101 - 1200 of 2007 matches
Mail list logo
