Mark Mitchell <[EMAIL PROTECTED]> writes:
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_summary script, an
Jonathan Larmour <[EMAIL PROTECTED]> writes:
> On MIPS, libgcc is built with -G 0, which is used to ensure the contents
> don't assume they will be placed in the small data/bss section. Setting
> -G 0 is used to allow for the possibility of large applications, or
> those where even small data may b
commented onMark Mitchell wrote:
The changes that I anticipate between now and the final release are
(a) documentation changes, (b) a patch for 20991, and (c) a possible
patch for 20973. Other than that, I will only consider patches that
fix egregious problems, like a fail to bootstrap on a primar
Richard Sandiford <[EMAIL PROTECTED]> writes:
> The only reliable way to get what you want is to either (a) add -G0
> multilibs or (b) change the default -G setting. Perhaps a configure
> option would be useful here. Maybe something like --with-sdata-limit,
> to go alongside options like --with-
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> The only reliable way to get what you want is to either (a) add -G0
>> multilibs or (b) change the default -G setting. Perhaps a configure
>> option would be useful here. Maybe something like --with-sdata
James E Wilson wrote:
>Björn Haase wrote:
>>In case that one should not use machine specific atttributes, *is*
>>there a standard way for GCC how to implement different address spaces?
>
>Use section attributes to force functions/variables into different sections,
>and then use linker scripts t
Hi,
I am working on interprocedural data flow analysis(IPDFA) and need some
feedback on scalability issues in IPDFA. Firstly since one file is
compiled at a time, we can do IPDFA only within a file. But that would
prevent us from doing analysis for funcitons which are called in file
A , but
Richard Sandiford wrote:
Zack Weinberg <[EMAIL PROTECTED]> writes:
Richard Sandiford <[EMAIL PROTECTED]> writes:
The only reliable way to get what you want is to either (a) add -G0
multilibs or (b) change the default -G setting. Perhaps a configure
option would be useful here. Maybe something lik
James E Wilson wrote:
Ling-hua Tseng wrote:
It's obvious that `movil' and `movim' are only access the partial
16-bit of the 32-bit register. How can I use RTL expression to
represent the operations?
As you noticed, within a register, subreg can only be used for low
parts. You can't ask for the h
Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
Is this as expected?
Are the 2 libraries compatible? Interchangeable? Looking in the map
file, I don't think so.
If not, how can I make the most correct separation for a 3.4 and 4.0
Hi Richard,
I've recently experimented with TARGET_SHIFT_TRUNCATION_MASK
macro and have posted a patch defining it for S/390.
On S/390 only the least significant six bits of a shift count
operand are used and I therefore expected the modulo operation
in the following example to be optimized awa
Andreas Krebbel <[EMAIL PROTECTED]> writes:
> In:
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00456.html
>
> you proposed to take care of this in the 4.1 (formerly 3.6) timeframe fixing
> all places where shift rtxes are generated besides optabs.
> Is this still on your todo list?
Yes, but so a
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if people would test these bits
> > on primary and secondary platforms, post tes
Hi,
Just a minor thing, but I hit this problem times to times, I know
the CPP preprocessor has no warning like "end of line ignored"...
GCC-3.3.5 and 3.4.3.
[EMAIL PROTECTED]:~/projet$ cat > tmp.c
#define OPTION1 0x0001
#define OPTION2 0x0002
#define OPTION3 0x0004
#define OPTION4 0x0008
#
On Tue, Apr 19, 2005 at 03:28:07PM +0200, Etienne Lorrain wrote:
> Hi,
>
> Just a minor thing, but I hit this problem times to times, I know
> the CPP preprocessor has no warning like "end of line ignored"...
> GCC-3.3.5 and 3.4.3.
This is just order of operations.
> [EMAIL PROTECTED]:~/pr
On Tue, Apr 19, 2005 at 02:23:26PM +0200, Peter FELECAN wrote:
> Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
> i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
>
> Is this as expected?
Yes.
> Are the 2 libraries compatible? Interchangeable? Looking in the map
> file, I don'
Results for i686-pc-cygwin (c, c++, gfortran, objc) are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01363.html
No regressions for c, c++, gfortran relative to RC1.
There are several new tests, which all pass, and one less failed test in
libstdc++:
26_numerics/cmath/c99_classification_m
On Apr 18, 2005, at 9:22 PM, Eric Christopher wrote:
Though of course, this doesn't mean that we can't have an option to
control it. -Wno-cast-qual doesn't seem like the right choice, as
there is no user cast here. Maybe something like -Wno-discard-
qual, where -Wdiscard-qual is the default.
I no
Hi all,
I maintain a port of gcc for a 16-bit VLIW processor. For the last few
months the port has been based on 3.4.1, but I've just decided to
upgrade to gcc 4.0.0 branch. I've now got my port to compile with the
latest code from the branch, and I'm doing regression tests. I've come
across a
As a quick introduction, my name is Robert Kidd, and I'm working with
the Gelato Federation to improve the performance of GCC on Itanium. In
particular, I'm looking into improving GCC's superblock support,
hopefully bringing over some of what we have learned with the IMPACT
compiler project.
Jakub Jelinek <[EMAIL PROTECTED]> writes:
> On Tue, Apr 19, 2005 at 02:23:26PM +0200, Peter FELECAN wrote:
> > Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
> > i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
> >
> > Is this as expected?
>
> Yes.
>
> > Are the 2 libraries c
ppc-linux 32-bit.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01370.html
Andreas
Kaveh R. Ghazi wrote:
> > 2005-04-12 Paolo Bonzini <[EMAIL PROTECTED]>
> >
> > * acx.m4 (ACX_PROG_GNAT): Remove stray break.
>
> OK for 4.0.0.
Mark,
When this patch went into 4.0, Paolo didn't regenerate the top level
configure, although the ChangeLog claims he did:
http://gcc.gnu.org/m
Would you care to take care of that? (I am travelling, and don't have
much time online.) If so, I'd be very appreciative.
Done.
I'll apply to mainline soon.
Paolo
Richard Sandiford wrote:
Results for mips-elf are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01331.html
and look good. No regressions.
Thanks; added to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
James E Wilson wrote:
commented onMark Mitchell wrote:
The changes that I anticipate between now and the final release are
(a) documentation changes, (b) a patch for 20991, and (c) a possible
patch for 20973. Other than that, I will only consider patches that
fix egregious problems, like a fail to
On Tue, Apr 19, 2005 at 03:28:07PM +0200, Etienne Lorrain wrote:
> > #define OPTION1 0x0001
> > #define OPTION2 0x0002
> > #define OPTION3 0x0004
> > #define OPTION4 0x0008
> > #define CONFIGURATION (OPTION1 | OPTION3)
> > // There is the problem: the "== 0" is ignored
> > #if CONFIGURATION & OPT
Andrew Haley wrote:
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if people would test these bits
> > on primary and secondary
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary
On Tue, Apr 19, 2005 at 02:23:26PM +0200, Peter FELECAN wrote:
> > > Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
> > > i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
> > >
> > > Is this as expected?
Jakub Jelinek <[EMAIL PROTECTED]> writes:
> > Yes.
Peter:
> > > Are the
Eric Botcazou wrote:
SPARC/Solaris is OK:
Thanks; I've added your information to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Mark Mitchell writes:
> Andrew Haley wrote:
> > Geoffrey Keating writes:
> > > Mark Mitchell <[EMAIL PROTECTED]> writes:
> > >
> > > > RC2 is available here:
> > > >
> > > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> > > >
> > > > As before, I'd very much appreciate
Joe Buck wrote:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01307.html
Thanks.
For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
but I may be doing something wrong, as I usually avoid the Java build
on Solaris (since it takes most of a day to build and test).
Thanks.
On Tue, 2005-04-19 at 10:17 -0500, Robert Kidd wrote:
> As a quick introduction, my name is Robert Kidd, and I'm working with
> the Gelato Federation to improve the performance of GCC on Itanium. In
> particular, I'm looking into improving GCC's superblock support,
> hopefully bringing over som
Joe Buck <[EMAIL PROTECTED]> writes:
> On Tue, Apr 19, 2005 at 02:23:26PM +0200, Peter FELECAN wrote:
> > > > Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
> > > > i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
> > > >
> > > > Is this as expected?
>
> Jakub Jelinek <[EMAIL
On Tue, 2005-04-19 at 08:49 +0200, Eric Botcazou wrote:
> > So the combination of the TCB merge plus the pending jump threading
> > changes apparently has ticked a reload bug which manifests itself with
> > the stage1 compiler mis-compiling the stage2 compiler.
> >
> > [...]
> >
> > Which faults be
On Tue, Apr 19, 2005 at 08:12:05AM +0200, Eric Botcazou wrote:
> > For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
> > but I may be doing something wrong, as I usually avoid the Java build
> > on Solaris (since it takes most of a day to build and test).
>
> Known glitch.
The C++ front-end (and probably the C front-end) strips zero-width
(and possibly unnamed) bitfields after class layout. This can be
justified in that those bitfields only affect layout; one doesn't need
the middle-end to copy them around, etc. So, you could probably fix
this i
On Mon, 18 Apr 2005, Joe Buck wrote:
> It appears the bug is because there's a libiconv.so in /usr/local/lib on
> that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> in my LD_LIBRARY_PATH. configure finds the declaration and assumes it
> can call the function. Sorry, I d
Andrew Haley wrote:
Do you mean running through the struct removing such fields from the
list? OK, I can do that.
Yes.
> So, I would suggest fixing this in the Java front end.
I'll see if I can find the C++ front end code you refer to and use it
as a reference.
Look in class.c for remove_zero_wid
A Dwarf interpretation question:
We have a problem to make GCC-compiled code interact with the HP
native debugger, and it looks like it is caused by the way the
attribute DW_AT_frame_base is interpreted. Apparently, when a frame
pointer can be found in a register, the value generated by GCC for t
On Tue, Apr 19, 2005 at 04:20:19PM +, Joseph S. Myers wrote:
> On Mon, 18 Apr 2005, Joe Buck wrote:
>
> > It appears the bug is because there's a libiconv.so in /usr/local/lib on
> > that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> > in my LD_LIBRARY_PATH. configur
On Tue, Apr 19, 2005 at 06:29:27PM +0200, Jerome Guitton wrote:
>
> A Dwarf interpretation question:
>
> We have a problem to make GCC-compiled code interact with the HP
> native debugger, and it looks like it is caused by the way the
> attribute DW_AT_frame_base is interpreted. Apparently, when
Daniel Jacobowitz ([EMAIL PROTECTED]):
> You may want to join the dwarf-discuss list, where this exact same
> conversation is taking place - probably about the exact same
> interaction.
OK, thanks!
--
Jerome
On Tue, 2005-04-19 at 18:29 +0200, Jerome Guitton wrote:
> A Dwarf interpretation question:
>
> We have a problem to make GCC-compiled code interact with the HP
> native debugger, and it looks like it is caused by the way the
> attribute DW_AT_frame_base is interpreted. Apparently, when a frame
>
Andrew Haley writes:
> Mark Mitchell writes:
> >
> > The C++ front-end (and probably the C front-end) strips
> > zero-width (and possibly unnamed) bitfields after class layout.
> > This can be justified in that those bitfields only affect
> > layout; one doesn't need the middle-end to c
> Eric Botcazou writes:
>> Jeffrey A Law writes:
>> ...
>> Which faults because the memory location is actually read-only memory.
>
> PR rtl-optimization/15248.
>
>> What's not clear to me is how best to fix this.
>>
>> We could try to delete all assignments to pseudos which are equivalent
>> to M
Joe Buck <[EMAIL PROTECTED]> writes:
> GCC has the "suggest parentheses" warning elsewhere (to catch people
> writing "if (foo = 0)" and the like; maybe there should be a warning
> for this one as well.
I'd be happy to take a patch to add -Wparentheses support to
libcpp/expr.c.
zw
> From: Paul Schlie <[EMAIL PROTECTED]>
>
> some-const-char*-funct("abc"); // "C.x[4] = {'a','b','c',0} array
>// of "literal static const data"
>// some-const-char*-funct(C.x);
Or rather I suspect it implies the allocation of a temp
> "Henrik" == Henrik Sorensen <[EMAIL PROTECTED]> writes:
Henrik> For the PL/I front-end project (pl1gcc.sourceforge.net), I am
Henrik> just about to begin to add a preprocessor expansion step, and
Henrik> was wondering what other front-end do.
Henrik> My initial thoughts were to create a com
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> At compile time we don't know the field offset of fields that we
Andrew> inherit, because it can change at runtime. So, we don't set the
Andrew> FIELD_OFFSET, and that is is why dbxout is aborting.
Andrew> All I want is for FIELD
On Apr 18, 2005, at 18:17, Robert Dewar wrote:
Is there anything in the language specifications (mainly C++ in this
context, but is this an area where C and C++ are going to diverge, or
is C likely to follow suit?) that prohibits spurious writes to a
location?
Surely the deal is that spurious wr
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> At compile time we don't know the field offset of fields that we
> Andrew> inherit, because it can change at runtime. So, we don't set the
> Andrew> FIELD_OFFSET, and that is is why dbxout is aborting
Ling-hua Tseng wrote:
James E Wilson wrote:
I read the descriptions of (high:m exp) and (lo_sum:m x y) in the gcc
internal manuls (Section 10.7 and 10.9).
The last line of their descriptions confused me because they wrote "m
should be Pmode".
A doc bug. You only need Pmode if you are operating o
Devang Patel wrote:
On Apr 18, 2005, at 6:29 PM, James E Wilson wrote:
I notice that these are pedwarns,
In that case, we can enable it only when -pedantic is used (like many
pedwarns) ?
Consider this small modification to your testcase.
const char *a( void )
{
return "abc";
}
int main( void )
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla ass
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all rel
On Apr 19, 2005, at 11:51 AM, James E Wilson wrote:
Devang Patel wrote:
On Apr 18, 2005, at 6:29 PM, James E Wilson wrote:
I notice that these are pedwarns,
In that case, we can enable it only when -pedantic is used (like
many pedwarns) ?
Consider this small modification to your testcase.
const
> Yes, you sent me a message before when I couldn't build at all, which I
> applied, but you pointed me to a different patch:
I was talking about a second message.
> If an additional patch is needed, install/specific.html should be updated,
> and perhaps a single patch that does the whole job sho
> > For 3.3 and 3.4, this was "fixed" by not recording memory equivalences
> > that have the infamous RTX_UNCHANGING_P flag set.
>
> Also a possibility. Making the equivalent change (!MEM_READONLY_P)
> appears to do the trick for mainline.
Yes, but that's of course not optimal, unnecessary spills
Am Dienstag, 19. April 2005 00:30 schrieb James E Wilson:
> Björn Haase wrote:
> > In case that one should not use machine specific atttributes, *is* there
> > a standard way for GCC how to implement different address spaces?
>
> Use section attributes to force functions/variables into different
>
t001_x of the struct-layout test has such beauties as:
typedef _Bool Tal16bool __attribute__((aligned (16)));
struct S49 { Tal16bool a:1; } ;
. a only gets BIGGEST_ALIGNMENT (i.e. 64 bits), rather than the 128 bits
required for Tal16bool. Should we enforce that any storage element
allocated
for
On Tue, 2005-04-19 at 21:36 +0200, Eric Botcazou wrote:
> > > For 3.3 and 3.4, this was "fixed" by not recording memory equivalences
> > > that have the infamous RTX_UNCHANGING_P flag set.
> >
> > Also a possibility. Making the equivalent change (!MEM_READONLY_P)
> > appears to do the trick for ma
Ken Raeburn wrote:
That's what I thought. So, unless the compiler (or language spec) is
going to become thread-aware, any data to be shared across threads needs
to be declared volatile, even if some other mechanism (like a mutex) is
in use to do some synchronization. Which means performance wo
On Tue, Apr 19, 2005 at 09:23:17PM +0200, Eric Botcazou wrote:
> > Yes, you sent me a message before when I couldn't build at all, which I
> > applied, but you pointed me to a different patch:
>
> I was talking about a second message.
I don't recall seeing it, but then I get a lot of mail. Sorry
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Ken Raeburn wrote:
>> That's what I thought. So, unless the compiler (or language spec)
>> is going to become thread-aware, any data to be shared across
>> threads needs to be declared volatile, even if some other
>> mechanis
Paul Koning wrote:
"Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Ken Raeburn wrote:
>> That's what I thought. So, unless the compiler (or language spec)
>> is going to become thread-aware, any data to be shared across
>> threads needs to be declared volatile, even if some other
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Paul Koning wrote:
>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
>>
Robert> Ken Raeburn wrote:
>> >> That's what I thought. So, unless the compiler (or language
>> spec) >> is going to become thread-aware, any
Devang Patel wrote:
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is represented
by the logical START_LOCATION. TO_LINE+L at column C is represented by
START_LOCATION+(L*(1<
What happens when column number is >= 128 ?
The
> I don't recall seeing it, but then I get a lot of mail. Sorry if I lost
> it.
No problem, I only wanted to check.
> But if these failures are important, shouldn't we be recommending the
> second patch to users?
It's 64-bit STABS and nobody uses 64-bit STABS (as generated by GCC).
As an altern
Øyvind Harboe wrote:
How does the i386 backend optimise the stack slot assignment to minimize
the displacement offset?
We don't. We just assign sequential addresses as we allocate stack slots.
; -O0 => large offset
leal8268(%esp), %eax
incl(%eax)
; -O3 => small offset
> -O3 enables function inlining. With function inlining, we can see that
> the arrays are unused and we optimize them away. Without the arrays,
> the stack frames are small, and hence you get small offsets.
The external functions in my example using the arrays ensures that the
arrays are not o
Hi,
when working on removing avr's present monolithic SI-mode instruction patterns
by splitters after reload and lowering to QI modes after expand, I have
stepped over the following general issue:
The mid-end seems not to be able to simplify nested subreg expressions. I.e.
it seems that there
Joe Buck wrote:
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all
Joseph S. Myers wrote:
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
Thanks; posted on the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Haley wrote:
At compile time we don't know the field offset of fields that we
inherit, because it can change at runtime. So, we don't set the
FIELD_OFFSET, and that is is why dbxout is aborting.
OK. I certainly can't claim that this aspect of the GCC IR is
particularly well specified. Fo
Øyvind Harboe wrote:
The external functions in my example using the arrays ensures that the
arrays are not optimized away.
Ah, right, stupid mistake on my part.
The registers that are spilled are allocated place in the stack frame
last, so when FRAME_GROWS_DOWNWARD, the displacement offsets are
sma
On Tue, 2005-04-19 at 15:36 +0530, Virender Kashyap wrote:
> Hi,
> I am working on interprocedural data flow analysis(IPDFA) and need some
> feedback on scalability issues in IPDFA. Firstly since one file is
> compiled at a time, we can do IPDFA only within a file.
For starters, we're worki
On Apr 18, 2005, at 3:12 PM, Julian Brown wrote:
Results for arm-none-elf, cross-compiled from i686-pc-linux-gnu
(Debian)
for C and C++ are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01301.html
Relative to RC1, there are several new tests which pass, and:
g++.dg/warn/Wdtor1.C (test fo
Andrew Haley wrote:
However, these fields are real, and they are used, but we shouldn't
output any debug info for them.
Does Dwarf support "computed field offsets"? (This might be needed
for Ada, to.) If so, the Right Thing might be to emit DIEs so gdb
can calculate the field offsets, mimicing th
On 19/04/2005, at 6:24 AM, Andrew Haley wrote:
Geoffrey Keating writes:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these
bits
on primary and secondary platforms,
> > Would you care to take care of that? (I am travelling, and don't have
> > much time online.) If so, I'd be very appreciative.
Sure but...
> Done.
> I'll apply to mainline soon.
> Paolo
Aleady done.
Thanks Paolo! :-)
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> On Thu, 14 Apr 2005, Kaveh R. Ghazi wrote:
> > I guess "x" is fine with me. However can we use "x" only in the
> > anchor and not the link's text label? E.g.:
> >
> >alpha*-*-*
> >
> > That way, the part people actually read in the document still uses
> > asterisk that they are us
Daniel Berlin wrote:
I am working on interprocedural data flow analysis(IPDFA) and need some
feedback on scalability issues in IPDFA. Firstly since one file is
compiled at a time, we can do IPDFA only within a file.
For starters, we're working on this.
(I was curious, so I searched a bit. I
On Tuesday 19 April 2005 20:40, Chris Wright wrote:
> * Denis Vlasenko ([EMAIL PROTECTED]) wrote:
> > On Tuesday 19 April 2005 08:42, Denis Vlasenko wrote:
> > > modprobe tcrypt hangs the box on both kernels.
> > > The last printks are:
> > >
> > >
> > >
> > > testing wp384
> > > NNUnable to han
> I see what I missed the first time. Without optimization, we have stack
> locals, which get allocated early. With optimization, we have
> pseudo-regs which get spilled to the stack, which get allocated late.
> So you are right, it is FRAME_GROWS_DOWNWARD that caused the behaviour
> you saw.
86 matches
Mail list logo
